Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AIP 4: Number of Forging Delegates #3

Closed
Doweig opened this issue Jan 27, 2017 · 8 comments
Closed

AIP 4: Number of Forging Delegates #3

Doweig opened this issue Jan 27, 2017 · 8 comments

Comments

@Doweig
Copy link
Contributor

Doweig commented Jan 27, 2017

cosmos/cosmos#43 (comment)

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.

@liondani
Copy link

except we are globally all connected with fiber optics in the future

@Doweig
Copy link
Contributor Author

Doweig commented Feb 1, 2017

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)

@2mdoty
Copy link

2mdoty commented Feb 2, 2017

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.

@fix
Copy link
Contributor

fix commented Feb 14, 2017

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.

@corsaro1
Copy link

corsaro1 commented Apr 6, 2017

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.

@dakk
Copy link

dakk commented Apr 6, 2017

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

@fix
Copy link
Contributor

fix commented Apr 6, 2017

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

@doubled1c3
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants