-
Notifications
You must be signed in to change notification settings - Fork 14
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
Optimize block links #148
Comments
For a more visual representation, where
|
Hmm - the original Chainiac paper presenting the skipchain idea propose two chains:
Both chains contain not only links from block N to block N+1, but also higher-level skips. So if the client has block 0, and wants to proof that block 400'000 is valid, it has to download only a subset of blocks. Whether there was a roster change or not. In the cothority-skipchain, the So does Dela have anything like skipchains? Are higher-level skips implemented? Because if we have 100 elections with 2000 votes each, it will take a long time for a client to catch up. |
Currently, a link to a block is signed from the digest of the previous block. This is fine but not optimal because it's the block with the current roster that should sign it so that a chain to a block (the proof of consistency) is shaped with the smallest possible number of blocks. In other words, a proof to a block should look like this:
Basically, every block that has a change in the roster is a new checkpoint for the chain. New blocks should always be signed with the most recent roster to prevent a group of malicious nodes to take over the chain (i.e. an old roster with few nodes thus a small failure threshold).
The text was updated successfully, but these errors were encountered: