Add proposal for tick verification in slots #6512
Conversation
| slashing proof. In this case, blocktree will also not insert `s`. | ||
|
|
||
|
|
||
| # Replaying and validating ticks |
There was a problem hiding this comment.
@jstarry I think these are the conditions related to your PR.
The only case where we don't mark slots as dead is when we detect extra shreds that come after the last tick or the last shred (they should be one and the same under this proposal, and are handled by the above secction Blocktree receiving shreds)
|
It’s going to be hard to distinguish spam from failures. Leader can always withhold the first block. |
|
@aeyakovenko, you mean the leader could withhold the shred containing the last tick and just fill blocktree with spam? |
|
@carllin yep. The only real solution is to let the next leader start because the previous block timed out, and if no one votes on it the spam gets cleaned up anyways. |
@carllin what spam could this be? Replay stage will mark a slot as dead if it gets too many hashes without a tick or just too many ticks |
| then the cluster must handle the possibility of both transmissions being live. | ||
|
|
||
| Thus this means we cannot mark the erronenous transmission `T` as dead because | ||
| the cluster may have reached consensus on `T`. These cases necessitate a |
|
|
||
| When blocktree receives a new shred `s`, there are two cases: | ||
|
|
||
| 1) `s` is marked as `LAST_SHRED_IN_SLOT`, then check if there exists a shred |
There was a problem hiding this comment.
Is it possible for the blocktree to receive two different shreds for the same index?
There was a problem hiding this comment.
Seems like we should add a case for that too
There was a problem hiding this comment.
Nvm I see we have a separate proposal for this case (duplicate blocks) maybe link to it?
There was a problem hiding this comment.
ya that one's a nasty bugger. It hasn't been checked in yet, you mean link it here in this PR?
There was a problem hiding this comment.
Oh I meant link in the book to the other proposal so that all the cases are covered for how to handle a new shred. Or for now, say proposal pending?
@jstarry So that's only if replay stage actually gets the entries. Recall Blocktree only feeds consecutive entries to replay stage, because we must play entries in order. However, if there's a gap in blocktree, the everything after that gap can grow unchecked. For instance, if blocktree gets entries with index
Replay stage will only see and verify 0 and 1. |
Problem
No design clarifying how errors and spam should be handled in blocktree and replay stage.
Summary of Changes
Proposal for handling various tick/slot verification failures
Fixes #