---
title: 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.

# Blockstore receiving shreds

When blockstore 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 blockstore for that slot where `s'.index > s.index` If so, together `s`
   and `s'` constitute a slashing proof.

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`.

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 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.

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.