This mini-spec is so useful for understanding the official beacon chain specification. It even helped me to find this slashing condition error. Because of the new slashing condition changes in the official spec, I want to maintain this mini spec and update it:
Beacon chain stage 1 (no justification, no dynasty changes)
Suppose there is a validator set V = {V_1 ... V_n} (we assume for simplicity that all validators have an equal amount of “stake”), with disjont subsets S_1 .... S_{64} with |S_i| = \frac{|V|}{64}, where |x| refers to set size (ie. the number of validators, or whatever other kind of object, in x). Suppose also that the system generates a random permutation of validator indices, {p_1 ... p_N}.
Note: if an attacker controls less than \frac{1}{3} of the stake, then if |S_i| \ge 892 there is a less than 2^{-80} chance that the attacker controls more than \frac{1}{2} of S_i, and there is a less than 2^{-100} chance that an attacker controls all 64 indices in a given span i_k .... i_{k+63}. We can assume that it is certain that neither of these things will happen (that is, we can assume there exists a substring of validator indices p_{i_1}, p_{i_2} ... with p_{i_{k+1}} - p_{i_k} < 64 and that every S_i is majority honest).
We divide time into slots; if the genesis timestamp of the system is T_0, then slot i consists of the time period [T_0 + 6i, T_0 + 6(i+1)).
When slot i begins, validator V_{p_{i\ mod\ N}} is expected to create (“propose”) a block, which contains a pointer to some parent block that they perceive as the “head of the chain”, and includes all of the attestations that they know about that have not yet been included into that chain.
3 seconds after the start of slot i, validators in S_{i\ mod\ 64} are expected to determine what they think is the “head of the chain” (if all is well, this will generally be the newly published block), and publish a (signed) attestation, [current\_slot, h_0, h_2 .... h_{63}], where h_i \in {h_0 ... h_{63}} is the hash of the block at slot current\_slot - i (if a chain has a missing slot, then we consider the block at that slot to be the hash of the most recent block in the chain before that slot), and current\_slot is the current slot number.
The fork choice used is “latest message driven GHOST”. The mechanism is as follows:
- Set H to equal the genesis block.
- Let M = [M_1 ... M_n] be the most-recent messages (ie. highest slot number messages) of each validator.
- Choose the child of H such that the subset of M that attests to either that child or one of its descendants is largest; set H to this child.
- Repeat (2) until H is a block with no descendants.
Claims:
- Safety: assuming the attacker controls less than \frac{1}{3} of V, and selected the portion of V to control before the validators were randomly sorted, the chain will never revert (ie. once a block is part of the canonical chain, it will be part of the canonical chain forever).
- Incentive-compatibility: assume that there is a reward for including attestations, and for one’s attestation being included in the chain (and this reward is higher if the attestation is included earlier). Proposing blocks and attesting to blocks correctly is incentive-compatible.
- Randomness fairness: in the long run, the attacker cannot gain by manipulating the randomness
Beacon chain stage 2 (add justification and finalization)
We cluster slots into epochs: Every 64th slot is an epoch\_boundary\_slot and all 63 consecutive slots of an epoch\_boundary\_slot belong to the same epoch. The chain state keeps track of a map justified\_hashes, which starts at \{\}, and will add new justified\_hashes. A valid attestation references to the last justified\_hash of the current chain, the current slot and the hash of the current epoch\_boundary\_slot of this slot. At each epoch boundary (ie. when processing a block where floor(\frac{b.slot}{64}) > floor(\frac{b.parent.slot}{64})), the state transition function performs the following steps.
If there exists some hash h which is the hash of an epoch\_boundary\_slot in the chain, and the chain contains valid attestations from a set of validators V_B with epoch boundary claim h, with |V_B| \ge |V| * \frac{2}{3}, then we insert h into justified\_hashes.
Suppose that in a chain, the most recent epoch boundary blocks are B1, B2, B3, B4 (B4 being the most recent). In the following three cases, we “finalize” a block:
- If B4 and B3 are in justified\_hashes and the attestations that justified B4 used B3 as the justified\_hash, then we finalize B3.
- If B4, B3 and B2 are in justified\_hashes and the attestations that justified B4 used B2 as the justified\_hash, then we finalize B2.
- If B3, B2 and B1 are in justified\_hashes and the attestations that justified B3 used B1 as the justified\_hash, then we finalize B1.
Note that the algorithm can work if only the first rule exists, but we add the other two rules to satisfy the cases where it takes longer for attestations to get included in the chain.
We change the fork choice rule above so that instead of starting H from the genesis block, it works as follows:
- Set H_F to the highest-slot finalized block.
- Set H_J to the highest-slot block which is justified and the client has known is justified for a period of at least 64 * 8 seconds.
- Start the fork choice from H_J.
We then add two slashing conditions:
- A validator cannot make two distinct attestations in the same epoch
- A validator cannot make two attestations with epoch boundary slots t1, t2 and justified slots s1, s2 such that s1 < s2 < t2 < t1 and s2 & t2 are consequtive epoch boundary slots.
Claims:
- Safety: once a block becomes finalized, it will always be part of the canonical chain as seen by any node that has downloaded the chain up to the block and the evidence finalizing the block, unless at least a set of validators V_A with |V_A| \ge |V| * \frac{1}{3} violated one of the two slashing conditions (possibly a combination of the two).
- Plausible liveness: given an “honest” validator set V_H with |V_H| \ge |V| * \frac{2}{3}, V_H by itself can always finalize a new block without violating slashing conditions.
Beacon chain stage 3: adding dynamic validator sets
Every block B comes with a subset of validators S_B, with the following restrictions:
- Define the dynasty of a block recursively: dynasty(genesis) = 0, generally dynasty(B) = dynasty(parent(B)) except when the processing of B finalizes a block, in which case dynasty(B) = dynasty(parent(B)) + 1.
- Each block B has a local validator set $LVS(B). For two blocks in the chain, if B_1 and B_2, dynasty(B_2) - dynasty(B_1) = k, then |LVS(B_1)\ \cap\ LVS(B_2)| \ge LVS(B_1) * (1 - \frac{k}{64}) (and likewise wrt LVS(B_2)). That is, at most \frac{1}{64} of the local validator set changes with each dynasty.
Claims:
- All of the above claims hold, with appropriate replacements of V with LVS(...), except with fault tolerance possibly reduced from \frac{1}{3} to approximatively 30%.
@vbuterin feel free to copy this into the thread head-post.