Validator Set Logic High Level Design. about xian-core HOT 5 CLOSED

I propose that we design a very simple solution first that doesn't take much time to implement and then later on come up with a better, more decentralized solution that will reply on some governance process.

The reason for this is that we need to get things going and have a solid network up that just works. That's the first stage. By having a running network that users participate in will help iron out issues and will lead to a more stable and solid network. Once that is done, we then have time to think about how a better solution for validator selection looks like.

Trying to do this perfectly first and then do everything else will take up time and probably lead to us reimplementing / adjusting multiple times since we will over time have more experience with a live network. So better use something simple and easy first, let everything grow and then gradually improve one thing after another.

As for the proposal itself:

• Implement logic into nodes to read hostnames / IPs from a contract on startup
• Create a contract that (for now only) core devs can use to add and remove IPs
• Limit validators to a fixed number between 5 and 10
• Nodes only connect to nodes from that contract

We could also just hardcode the nodes into the Tendermint config file but nodes retrieving data from a contarct on startup is a good idea because we will need to do that anyway. It's just that we currently don't know exactly the details of that future contract.

It needs to be clear that this proposal is just the first step and it can in now way stay the final solution. With the application that we use right now for our node communication we have a perfect base to build whatever we want to a level of industry standard but we need to be sure what we want first.

from xian-core.

Let's mention the obvious first: CometBFT is PoS. Thus the question arrises how we appoint validators and how much of them we want to allow. Few questions:

1. What is the reason to not allow an unlimited number of validators?
2. What should the reward for validators be?

from xian-core.

AFAIK, you can add as many validators as you want, once you get past 100 or so, additional validators are expensive to add in terms of throughput & latency.

You could, though have way more than 100, but to keep things fast the nodes would have a lottery or something every x number of blocks to determine who gets to be involved in consensus for the next x blocks and receive rewards. It will be the abci side that determines all the logic around electing validators, bonding & unbonding tokens for validator staking.

There's a few options how validators can be rewarded :

• Inflation
• Transaction Fees

I'm not against some % inflation as this can make it worthwhile starting up the network and running a node when transactions will be low. The thing about inflation though, is it's not fair unless everybody gets to stake and earn a %, so we'd definitely have to allow staking of any amount of tokens to receive something, to make it open to everybody. Iirc Cosmos has a system like this where anyone can stake tokens and use that as a vote towards a node.

from xian-core.

https://docs.cometbft.com/v0.38/core/validators

from xian-core.

I think this makes sense, to take a phased approach to decentralisation.
I definitely think we should control the validator set using a smart contract, so we don't have to hard-fork to update the set.
The initial schema for the masternode contract should probably be something like :

validators = [
    {
        "ip": "0.0.0.0:26656",
        "weight": 10,
        "node-id": "b2308wi13098sdjj20318iasjdn2b41978fnakldhr10"   
    }
]

• The owner of the contract should be a basic multi-sig which is controlled by the team.
• It must have a transfer_owner method
• It should have a generic method where it can whitelist certain contracts to alter it's state, so we can add more functionality to this later (think dynamically adjusting a node's voting weight depending on users staking tokens and delegating to that validator)

I'm sure I've missed a lot of things, but there's a few suggestions to get the creative juices flowing.

from xian-core.