AIP 4: Number of Forging Delegates
Doweig opened this issue · 8 comments
The number of witnesses has indeed been constraint in BitShares 1, but is no longer in BitShares 2. It is yet another shareholder voted parameter that could go from 11 up to 1100 (arbitrary number). The scaling constraints are in fact the time it takes for packages to travel around the world. If you had all the validators in one room, you could easily scale to billions of transactions with block confirmation times of less than 1sec, but a publicly distributed and decentralized network is located around the globe with worst case scenarios of 1-2secs for a roundtrip of packages.
except we are globally all connected with fiber optics in the future
Incremental Delegate Number, every XXX blocks add 1 more delegate. for example in 1 month number is 52, 2 month 53... (keep decentralization as project grow, and also avoid a too competitive environment where going into the 51 means kicking someone out)
Yes, would like to see capability to add more delegates for more decentralization if it can be done without impacting performance, whether algorithmic (preferred) or by vote.
main takeaway: increasing number of delegates will always be at a price of decreasing TPS.
We can take the problem differently: if we increase by 20% the number of delegates, rule of thumbs would be to increase by 20% the blocktime. This way we might keep the TPS
This way we move the issue to "How fast a tx is confirmed". On bitcoin there is even the famous 0 confirmation transaction. It is likely possible to handle.
Also with offchain transactions using channels (like for Lightning networks), this scalability discussion could be over anyway.
what about choosing the 51 forging delegates, randomly at every cycle, among the first 60 or 70 top ranked? This number (the first 60 or 70 top ranked) could be easily scaled every month/quarter, and at the same time keeping costantly 51 delegates at every cycle could warranty the TPS.
So doing, more delegates could be involved in the forging process.
Another possibility could be a variable "probability of forging" based on the delegate rank; in the next round will be selected all the 51 delegates plus other X delegates; for istance:
100% probability: first 51 delegates
and the probability decrease from the 52' delegate to the maybe 202' delegate
Random is not a thing in consensus. This "random" needs to be "agreed" among all nodes.
So the only possible thing is that for each round when the 51 one delegates are calculated, when can tweak the algorithm doing :
- preselect a list of N delegates ( N>51 ) ordered by their voted weight
- launch a predictable algorithm seeded by unpredictable nonce (ie only known by all nodes when we launch the algorithm such as last block id) to extract the active 51
The very advantage is to mitigate the fact that some delegates may be down, diluting their impact to the block forgery.
On the other en mathematical expectation of forged ark will be 2 arks every N*8s on average
avoid a too competitive environment where going into the 51 means kicking someone out
This fierce competition is what drives the effort and work getting put into the community. If you are a forger you should be constantly worried about dropping out and therefore always work as hard as you can for the community