2020-07-10 22:11:07 -07:00
|
|
|
---
|
|
|
|
title: Tick Verification
|
|
|
|
---
|
2019-10-26 16:14:30 -07:00
|
|
|
|
|
|
|
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
|
2020-07-10 22:11:07 -07:00
|
|
|
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
|
2019-10-26 16:14:30 -07:00
|
|
|
`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:
|
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
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.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
|
|
|
Thus this means we cannot mark the erronenous transmission `T` as dead because
|
2020-07-10 22:11:07 -07:00
|
|
|
the cluster may have reached consensus on `T'`. These cases necessitate a
|
2019-10-26 16:14:30 -07:00
|
|
|
slashing proof to punish this bad behavior.
|
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
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.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
2020-01-13 13:13:52 -08:00
|
|
|
# Blockstore receiving shreds
|
2019-10-26 16:14:30 -07:00
|
|
|
|
2020-01-13 13:13:52 -08:00
|
|
|
When blockstore receives a new shred `s`, there are two cases:
|
2019-10-26 16:14:30 -07:00
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
1. `s` is marked as `LAST_SHRED_IN_SLOT`, then check if there exists a shred
|
|
|
|
`s'` in blockstore for that slot where `s'.index > s.index` If so, together `s`
|
|
|
|
and `s'` constitute a slashing proof.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
2. Blockstore 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, blockstore will also not insert `s`.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
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.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
|
|
|
# Replaying and validating ticks
|
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
1. Replay stage replays entries from blockstore, 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.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
Failure scenario 2: If the number of ticks != `ticks_per_slot`, mark slot as
|
|
|
|
dead.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
|
|
|
Failure scenario 3: If the number of ticks reaches `ticks_per_slot`, but we still
|
2020-07-10 22:11:07 -07:00
|
|
|
haven't seen the `LAST_SHRED_IN_SLOT`, mark this slot as dead.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
2020-07-10 22:11:07 -07:00
|
|
|
2. When ReplayStage reaches a shred marked as the last shred, it checks if this
|
|
|
|
last shred is a tick.
|
2019-10-26 16:14:30 -07:00
|
|
|
|
|
|
|
Failure scenario: If the signed shred with the `LAST_SHRED_IN_SLOT` flag cannot
|
2020-07-10 22:11:07 -07:00
|
|
|
be deserialized into a tick (either fails to deserialize or deserializes into
|
|
|
|
an entry), mark this slot as dead.
|