Cosmos-sdk: Proposal: Reward full nodes

[svaishnavy]

Feature Request

Currently Cosmos is a DPoS system, which means the fees are collected by validators and then shared with delegators.

I propose to select one or a few random full nodes in each round and distribute x% of fee collected to the full nodes(who are also delegators) for staying online. This would give incentive for users to run full nodes, make the system distributed and also make the system defensible against security laws. I am afraid due to the nature of DPoS, atoms(and other blockchain tokens that launch using CosmosSDK) may be considered a security.

[ebuchman]

Interesting idea. We recently had a bug in the SDK where we ended up with Tendermint validators with 0% voting power that we tried to punish when they didnt get enough signatures in blocks. We could potentially do that on purpose to allow 0%-voting-power-but-fully-validating nodes on the network and partially reward them if their signatures are being included. But how to elect said full nodes and how much to reward them and so on is a quite difficult problem - would be interested to see a more fleshed out proposal with some economic security analysis.

We're also working on mechanisms to increase the number of validators (like BLS signatures) and of course we eventually expect there to be zones with their own validator sets.

[faddat]

I think this is a fantastic proposal, but for different reasons from @svaishnavy. While he is concerned (@svaishnavy please correct me if I'm wrong!) that a "tight" network could be seen as too centralized and thus tokens on it would legally be a security, I'm more concerned about replication.

Having lots of replication, lots of nodes to sync from, lots of.... basically everything, is a good thing. Thus far, running full nodes has been done out of altruism, but there are arguments, especially surrounding Ethereum and its large chain that the infrastructure itself is centralizing because it's difficult to casually run a node.

If there was a really simple node setup that was compensated for running a full node with none of the challenges of running a validator (maybe no slashing/no risk?) I think that this would help increase the resilience of Cosmos and chains using Cosmos-SDK.

[guylepage3]

+1

It is super important from a UX perspective to have a simple and easy node setup for mass adoption (a massive nodes). Without it I feel @faddat is right.. It will turn into a large chain with only a few players.

Would really like to see this simple node happen sooner rather than later.

[ValarDragon]

I think this would be nice to have. The trouble is, how do you implement this in a sybil resistant manner. If I have one full node, I can easily masquerade as N full nodes. I think this is the same problem FileCoin is trying to tackle in essence. (How to avoid one data host masquerading as N seperate data hosts)

This is quite hard to do, and the method I last heard relied heavily upon latency of cryptography. I think the main blocker on doing this is going to be a concrete proposal on how to make this sybil resistant.

[jlandrews]

:+1: for the goals of this, we should definitely be incentivizing full nodes. The problem is always how to do it with sybil resistance. The easiest ways are to pay nodes for providing a service which can be verified, such as paying for proofs that nodes are storing the block history, or having nodes make micropayments to each other for fulfilling requests for blocks or transaction data.

[jlandrews]

See also: #1136

[kidinamoto01]

Could we use the reserve pool to compensate candidates?

[svaishnavy]

Thanks for all your comments on this and sorry for the delay in my response.

@faddat - my thoughts on this are two fold - one was the security laws - delegating and expecting a return on it, is like doing no work and getting return on their investment - which is one of the criterias - but may be I am wrong, the other was about having more full nodes/decentralization as there would be an incentive to run full nodes.

@ebuchman Here is my proposal for implementing this scheme:
One way to implement this would be to imagine account addresses ordered on a number line. Each round a random number(VRF?) is computed between (1 and maximum account number), and only the (2-3) nearest(or equal) full node accounts on both sides of the number line having a stake and delegated could participate in that round and eligible for reward.

Now that we have elected whom to reward, let's talk about economic/security aspects of all the actors:

1. Full node - there is every incentive for full node to participate in that round/send its signatures. And if the full node is trying to cheat, it will be by creating as many accounts as possible(and having a stake and also delegated), which are going to cost them transaction fees. So it depends on the economic aspects whether the full node operators wants to do this or not. But most would atleast have one or a few accounts with coins and also delegated.
2. Block proposer for the round: Block proposer for the round - could either include the signature(honest) or (s)he chooses not to(dishonest). If the proposer chooses not to, other validators will reject the block(if they have the signature from the participating full nodes).
3. Rest of the validators: They will reject the block if there was no signature from the participating full node as the proposer has not included a signature as that means increased revenue for the proposing validator.

So the proposing validator has to choose between including the signature and getting a part of the fees or risk loosing the entire fees.
We are also limiting the participation of 2-3 nodes every round.

What if there are no signatures received on a given round? The validator consumes the entire fee.

The fees for full nodes could be voted by governance?

Let me know if this analysis is clear or if there are any issues with the proposal.

[Edit1]One obvious disadvantage I see is that it will increase the number of transactions on the network and also the transaction cost as people will be creating transactions to create more accounts. May be this should be a special account/transaction with its own fees to create such a full node account.

[Edit2] There is another issue that pops up - the validators could create their own transactions(for free) and hence they can end up having more accounts. Or, may be we should always have a minimum deposit for the full node account. So rather than having transaction fee to create a full node account, it should be deposit based. The criteria would be that account should have 'x' coins instead of 'x' fees on transaction for creating a full node account.

This doesn't mean we are rewarding full nodes, but rewarding accounts backed by full nodes - a proxy to rewarding full nodes.

[Edit3] We can overcome users creating multiple accounts by splitting the fee based on the proportion of stake of validator producing the block and the full node. This is essentially what is happening with delegation currently. However, the delegators now should run a full node to receive the reward.

[ValarDragon]

This is not Sybil resistant. I go make a ton of accounts, then when one of my accounts gets chosen I just always say I'm the corresponding full node. (Presuming your proposed scheme has the account declare its full node. I dont undersrand otherwiise how youre proposing going from acct to full node) A validator set vrf wouldn't work well, as we'd need a bft dkg. A vdf makes more sense here.

[svaishnavy]

What is bft dkg? What is vdf? What is a validator set vrf?

Not sure if you got a chance to read my full comments, made some edits after posting my initial comments.

I do not understand why this scheme is not Sybil resistant.

[ebuchman]

Loving this discussion and hope it continues but would like to keep this repo focused on current issue tracking rather than larger scale design proposals. I'm going to close this but would love if you could open the discussion in the forum (https://forum.cosmos.network/). If we get to a reasonable and worthy design there, we can bring it back as a concrete proposal here.

Thanks!

[svaishnavy]

Thanks a lot! Just created a discussion topic there: https://forum.cosmos.network/t/discussion-rewarding-full-nodes/538

Looking forward to hearing your thoughts on this topic.

[wimel]

I think this is a good idea, if network have more _fullNodes_, the network will be stronger, something like this is a good option, Vipnode is for Ethereum, but maybe I think it might work with Cosmos too.