AIP 156: Relay node reward

Moustikitos commented 3 years ago

AIP: 156 Title: Relay node reward system Authors: THOORENS Bruno moustikitos@gmail.com Status: Draft Discussions-To: https://github.com/arkecosystem/AIPS/issues/156 Address: AGvTiwbXykX6zpDMYUEBd9E5J818YmPZ4H Type: Standards Category: Protocol Created: 2021-07-24 Last Update: 2021-07-30

Abstract

DEFI ecosystems provide large amount of node so developers only have to focus on IT aspects without worrying about the technical sides. Ark ecosystem made easy blockchain creation independantly from any existing platform but let the node maintenance charge to developer teams.

Blockchain independency gots its prize but there should be a way to minimize it.

Copyright

Motivation

Relay nodes maintenance is a charge not rewarded on Ark nor Ark side chains. This aspect discourages teams to implement their use cases token within Ark ecosystem. This AIP proposes to overcome the lack of relay node incentive.

Specification

Small step for the protocol... Giant leap for the ecosystem!

Relay address

Wallet address is necessary to allow relay nodes receiving rewards. This association can be done the same way a delegate is linked to a node with a passphrase writen in a JSON file. This avoids new transaction implementation and provides the possibility to have multiple relay with a single address (single owner...) or ownership change.

Relay node address should not be mandatory and have to be mentioned in the /api/peers endpoint response.

The protocol

In this specification, first block round is chosen to reward relays. First block of a round is identified with its block_height: $$ residue((block_height-1)/active_delegates) = 0 $$

We assume that an endpoint /api/peers/reward exists and returns a multipayment transaction asset with its sha256 hash. Maximum multipayment size have to be reached if enough relay registered and global amount equals relay_reward:

{
  "status": 200,
  "data": {
    "asset": {
      "payments": [
        {"amount":..., "recipientId":...},
        ...
      ]
    },
    "hash": ...
  },
  ...
}

First block of each round should be rewarded with delegate_reward + relay_reward. To be accepted by other delegates, this block have to contain as first transaction the multipayment with asset provided by /api/peer/reward endpoint and delegate signature of asset hash as vendorField.

simplified algorithm of delegate work

on first block forging:
    [...]
    delegate gets the multipayment asset from API endpoint
    delegate creates the multipayment transaction
    delegate signs the asset hash and puts it into vendorField multipayment transaction
    delegate signs the multipayment transaction
    delegate adds the mutipayment transaction at first position in the block
    [...]
    delegate signs the block and sends it

on first block receiving:
    delegate checks the block:
        [...]
        delegate compute the sha256 hash of the multipayment asset
        delegate checks signature set in multipayment vendorField:
            if it matches --> continue
            else --> reject this first block
        [...]

If block accepted, delegate forging the block gets back the fees.

The `relay_reward`

There are three way to provide supply to relays: inflation rate increase, delegate reward reduction and donation. Once a wallet is associated to a relay, any kind of bounty campaign is possible. When it comes with delegate share and inflation, three scenarii are proposed:

No inflation rate increase - relay_reward = Ѧ0
- Delegate give up block reward and keeps block fees. With 210 rounds per day, a delegate forges the first block round 4 times per day (average), that makes about Ѧ8 loss/delegate/day.
Inlfation rate increase - relay_reward > Ѧ0
- Delegate give up reward and keeps block fees. For a given relay_reward, inflation rate increase is lower (still Ѧ8 loss/delegate/day).
- Delegate keeps reward and fees. The inflation rate choice will determine relay_reward value.

Case relay_reward = Ѧ0 and delegates give up block reward

No inflation rate increase;
With 100 nodes reward is about Ѧ1 533/relay/year;
Delegates loose about Ѧ3 331/year.

Case relay_reward = Ѧ5 and delegates keeps block reward

Inflation rate increase < 0.3%;
With 100 nodes reward is about Ѧ3 832/relay/year;
No loss for delegates.

Relay selection and reward distribution

This task is done by /api/peers/reward endpoint. Because the delegate only have 8 seconds to forge the first block, endoint response should be precomputed during the previous round.

Node number is limited to the maximum addresses a multipayment can handle (64 on v2, 128 on v3). So a selection may occur according to total relay runing the network:

Apply basic filters:
- Node not having a registered address excluded;
- Node not runing the last version of ark-core excluded.
Randomly select from the remaining relays if there are more than places in the multipayment. Otherwise, all relays and a random selection of delegates to complete the maximum capacity of the multipayment.

Once selection is done, two possibilities with the share distribution:

Same amount for all;
Amount according to wallet staking ratio. This option is the best if choice is made with an increase in the inflation rate. Stacking incentive should help reduce supply on the exchanges and counteract the possible negative effects of the rising inflation rate on the token price.

Rationale

Process is managed and secured by delegates;
No new transaction type required;
Keep it stupid simple.

Backwards Compatibility

This AIP needs a core-update for delegates. As relay address is not mandatory, unupdated nodes may still continue to relay transactions.

Reference Implementation

Identified implementations (to be completed):

The /api/peers endpoint have to embed the node address in data response. Node address should not be mandatory (ie no relay.json set);
The /api/peers/reward endpoint giving multipayment asset and its hash;
relay registration with relay.json config file;
Delegates with second secret registered have to store it in delegate.json;
The first block forging and checking protocol.
...

Moustikitos commented 3 years ago

All feedbacks and ideas are welcome.

cambo commented 3 years ago

Don't agree with adding inflation.

If anything, stop giving delegates fees and divide all fees to all relays on peer list. Won't be much, now, but if/when blocks get more tx then incentive increases- more relays, more security.

The erc stuff in the beginning is a little confusing to me.

More to say but I need to think on it and reread.

Moustikitos commented 3 years ago

Yes, forget about the abstract, it is still a WIP.

Inflation is mandatory, at least at the begining. The relay amount can be set to a specific value and be adjusted with time. Since Ark is inflationary and voting system keeps supply out of exchanges, not sure inflation rate increase will have a negative impat on the token itself.

If relay amount is only 5 Arks, with about 210 rounds per day, total ark sent to the 87 relay (138 peers - 51 delegates) is 1050 Arks, that gives an average of 12 Arks/relay/day. If relay number doubles, it is still 6 Arks/relay/day that is at writting time 1500€/year.

Inflation increase on the first year of ARK mainnet with 5 ark more per round is 0.3%, from 6.3% to 6.6%.

Moustikitos commented 3 years ago

Added Relay reward paragraph with possible scenarii. Specification change to secure the multipayment process.

dlecan commented 3 years ago

Interesting! Such a feature would help us (Unikname bridgechain) to grow up our network more quickly.

peterjah commented 3 years ago

Great proposal, I think the main difficulty will be to maintain the relay nodes ranking in a decentralized and secured way. The solution proposed here by counting the POST requests could lead to abuses like spam transactions broadcasted by relays to climb in ranking.

Moustikitos commented 3 years ago

@dlecan: yes for sure ! @peterjah: "decentralized and secure way" is included in the TPN world.

BTW : if TPN is too hard to implement or if it is source of inevitable attacks, relay ranking and eligibility principles could still be applied without the hit ratio info. That makes bullet point 1 of specification not mandatory...

Moustikitos commented 3 years ago

Added post scriptum about the TPN network.

Moustikitos commented 3 years ago

Reformated the AIP proposal: no more TPN network, a simple api endpoint computing the multipayment asset in a simple and fair way.

Moustikitos commented 3 years ago

Added more details about Relay selection and reward distribution.

github-actions[bot] commented 3 years ago

Stale issue message

ArkEcosystem / AIPs