Add proposal for tick verification in slots (#6512)
* Add proposal for tick verification in slots
This commit is contained in:
parent
e1b35f9847
commit
08238e8307
|
@ -0,0 +1,69 @@
|
|||
# Tick Verification
|
||||
|
||||
This design the criteria and validation of ticks in a slot. It also describes
|
||||
error handling and slashing conditions encompassing how the system handles
|
||||
transmissions that do not meet these requirements.
|
||||
|
||||
# Slot structure
|
||||
|
||||
Each slot must contain an expected `ticks_per_slot` number of ticks. The last
|
||||
shred in a slot must contain only the entirety of the last tick, and nothing
|
||||
else. The leader must also mark this shred containing the last tick with the
|
||||
`LAST_SHRED_IN_SLOT` flag. Between ticks, there must be `hashes_per_tick`
|
||||
number of hashes.
|
||||
|
||||
# Handling bad transmissions
|
||||
|
||||
Malicious transmissions `T` are handled in two ways:
|
||||
|
||||
1) If a leader can generate some erronenous transmission `T` and also some
|
||||
alternate transmission `T'` for the same slot without violating any slashing
|
||||
rules for duplicate transmissions (for instance if `T'` is a subset of `T`),
|
||||
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
|
||||
slashing proof to punish this bad behavior.
|
||||
|
||||
2) Otherwise, we can simply mark the slot as dead and not playable. A slashing
|
||||
proof may or may not be necessary depending on feasibility.
|
||||
|
||||
# Blocktree receiving shreds
|
||||
|
||||
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
|
||||
`s'` in blocktree for that slot where `s'.index > s.index` If so, together `s`
|
||||
and `s'` constitute a slashing proof.
|
||||
|
||||
2) Blocktree has already received a shred `s'` marked as `LAST_SHRED_IN_SLOT`
|
||||
with index `i`. If `s.index > i`, then together `s` and `s'`constitute a
|
||||
slashing proof. In this case, blocktree will also not insert `s`.
|
||||
|
||||
3) Duplicate shreds for the same index are ignored. Non-duplicate shreds for
|
||||
the same index are a slashable condition. Details for this case are covered
|
||||
in the `Leader Duplicate Block Slashing` section.
|
||||
|
||||
|
||||
# Replaying and validating ticks
|
||||
|
||||
1) Replay stage replays entries from blocktree, keeping track of the number of
|
||||
ticks it has seen per slot, and verifying there are `hashes_per_tick` number of
|
||||
hashes between ticcks. After the tick from this last shred has been played,
|
||||
replay stage then checks the total number of ticks.
|
||||
|
||||
Failure scenario 1: If ever there are two consecutive ticks between which the
|
||||
number of hashes is `!= hashes_per_tick`, mark this slot as dead.
|
||||
|
||||
Failure scenario 2: If the number of ticks != `ticks_per_slot`, mark slot as
|
||||
dead.
|
||||
|
||||
Failure scenario 3: If the number of ticks reaches `ticks_per_slot`, but we still
|
||||
haven't seen the `LAST_SHRED_IN_SLOT`, mark this slot as dead.
|
||||
|
||||
2) When ReplayStage reaches a shred marked as the last shred, it checks if this
|
||||
last shred is a tick.
|
||||
|
||||
Failure scenario: If the signed shred with the `LAST_SHRED_IN_SLOT` flag cannot
|
||||
be deserialized into a tick (either fails to deserialize or deserializes into
|
||||
an entry), mark this slot as dead.
|
Loading…
Reference in New Issue