# Simplex Consensus in TON
Simplex is a leader-based consensus protocol. Validators take turns
proposing blocks and then collectively vote on them. The protocol produces a single, ever-growing
chain of finalized blocks that every honest validator agrees on.
Simplex proceeds in slots, each representing a designated opportunity to propose a block. For
every slot, a validator is selected as the leader responsible for proposing a candidate block. The
leader broadcasts its candidate, every validator checks it, and if validation succeeds, casts a
notarization vote. Once a validator sees notarization votes totaling ≥2/3 of stake, it casts a
finalization vote. A quorum of finalization votes irrevocably commits the block to the output
ledger, and the protocol moves on to the next slot.
If the leader is offline or malicious, the slot eventually times out and validators cast skip votes
instead. A quorum of skip votes lets the protocol move on without producing a block for that slot.
An honest validator never both finalizes and skips the same slot, and never notarizes two different
candidates for the same slot. Because any two quorums overlap in at least one honest validator,
these per-validator constraints lift to global guarantees: at most one candidate can be finalized
per slot, and a finalized slot can never be skipped. This is the core of safety.
Multiple notarized but non-finalized chains may temporarily coexist if, because of network
conditions or leader misbehavior, a sequence of slots is both skipped and has valid candidates. Such
forks collapse as soon as the next finalization quorum is achieved, since any candidate in the later
slot must necessarily be a descendant of a slot that was not skipped. Honest validators thus commit
a candidate to the ledger once it has a finalized descendant.
The rest of this document rigorously develops the flavor of the protocol used in TON and is organized as follows:
-
Section 1 formally defines the ledger model and the voting rules that honest validators must
follow to guarantee safety.
-
Section 2 proves safety: finalized chains are always consistent, regardless of network conditions
or adversary behavior.
-
Section 3 refines the rules into a concrete protocol by adding candidate generation
rules, formalizing timeouts, and describing mechanisms required for operation in a lossy network.
We then prove that the resulting protocol achieves liveness: with probability 1, the output log
grows without bound.
-
Section 4 covers practical considerations that do not affect safety or liveness but improve
throughput, and maps concepts from this document to their counterparts in the C++ implementation.
# 1. Model and Definitions
# 1.1 System Model
We consider a system of n validators V={v1,…,vn}, each with a positive
integer weight wi. Let W=∑iwi. At most f<W/3 total weight of validators may be
Byzantine. Define the quorum threshold q=⌊2W/3⌋+1.
Each honest validator holds an EUF-CMA-resistant signing key pair; each validator’s public key is known to all. No assumption is made about Byzantine validators’ keys beyond possession of a public key.
# 1.2 Ledger Validity
Let D denote the set of all possible block payloads. We assume an external predicate ValidSeq:D∗→{true,false}, which determines whether a sequence of payloads represents a valid ledger state. The predicate satisfies the following properties:
- Genesis validity. ValidSeq(∅)=true.
- Extendability. For every valid sequence (d1,…,dm), there exists some d such that ValidSeq(d1,…,dm,d) holds.
A sequence (d1,…,dm) is called valid if ValidSeq(d1,…,dm)=true.
Consensus does not depend on the internal structure of payloads beyond these properties.
# 1.3 Protocol Objects
Slots. Slot number is a discrete index s∈N0. Slots are grouped into leader windows of size L. Window k covers slots [kL,(k+1)L) with an associated leader v(kmodn)+1.
Candidates. A candidate is a tuple (s,d,sp,hp,σ) where
- s is the slot number,
- d∈D is the block payload,
- (sp,hp) is a parent reference: either (−1,∅) or a pair with sp<s,
- σ is a valid signature by the leader of the window containing s over (s,d,sp,hp).
For a candidate (s,d,sp,hp,σ), define h=hash(d,sp,hp). The pair (s,h) uniquely identifies the candidate.
Chains. A chain ending at (sm,hm) is a sequence of candidates where each candidate’s
parent reference points to the previous candidate in the sequence. Formally, it is a sequence of
candidates (s1,d1,sp1,hp1,σ1),…,(sm,dm,spm,hpm,σm), identified by
(s1,h1),…,(sm,hm), such that:
- the first candidate has the genesis parent: (sp1,hp1)=(−1,∅), and
- each subsequent candidate references the previous one: (spi,hpi)=(si−1,hi−1) for i∈[2,m].
The slot set of a chain is {s1,…,sm}.
The associated sequence (d1,…,dm) is called the chain state.
A candidate (s,h) is called valid if there exists a chain ending at (s,h) with a state that is valid.
Votes. At any point, a validator may cast a vote signed by its signing key certifying some statement S. Votes can be sent over the network.
Certificates. A certificate for a statement S is a set of votes for S from distinct validators with total
weight ≥q.
We say that S is reached in the network if a certificate for S can be produced by an oracle that knows all cast votes. We say that S is observed on validator v when validator v receives enough votes to
construct a certificate for S (possibly by receiving an already constructed certificate). Note that a statement can be reached without any single validator knowing it.
# 1.4 Statements
We implicitly set the statements Notar(−1,∅), Final(−1,∅) to be reached.
A particular validator v may cast votes certifying the following statements:
-
Notar(s,h). Validator v has not cast a vote for Notar(s,h′) for h=h′, and there exists a candidate (s,d,sp,hp,σ) identified by (s,h) such that:
- Notar(sp,hp) is reached,
- for each slot sp<s′<s, the statement Skip(s′) is reached,
- the candidate (s,h) is valid.
-
Skip(s). Validator v has not cast a vote for any statement Final(s,h).
-
Final(s,h). Notar(s,h) is reached, and validator v has not cast a vote for Skip(s).
Honest validators cast votes only when they can verify that the corresponding conditions hold. They are not required to cast votes immediately when the conditions become provable.
# 2. Safety
Lemma 2.1 (Final–Skip exclusion). For any slot s and hash h, the statements
Final(s,h) and Skip(s) cannot both be reached.
Proof. Suppose both are reached. Each certificate has total signing weight ≥q. Since
2q=2(⌊2W/3⌋+1)>4W/3>W+W/3>W+f, the honest overlap is positive: some
honest validator v voted for both Final(s,h) and Skip(s). But Section 1.4 requires
that a Final voter has not voted Skip, and a Skip voter has not
voted Final. Contradiction. □
Lemma 2.2 (Unique notarization). For any slot s, at most one h can have
Notar(s,h) reached.
Proof. If Notar(s,h1) and Notar(s,h2) are both reached with
h1=h2, the same overlap argument yields an honest validator that voted for both,
contradicting the local uniqueness constraint on Notar. □
Lemma 2.3 (Finalization implies notarization). If Final(s,h) is reached, then
Notar(s,h) is reached.
Proof. The certificate for Final(s,h) has honest signing weight >0 (since
q>f). Each honest signer verified that Notar(s,h) is reached before
voting. □
Lemma 2.4 (Unique finalization). For any slot s, at most one h can have
Final(s,h) reached.
Proof. Suppose Final(s,h1) and Final(s,h2) are both reached with
h1=h2. By Lemma 2.3, Notar(s,h1) and Notar(s,h2) are reached. This contradicts Lemma 2.2. □
Lemma 2.5 (Chain notarization). If Notar(s,h) is reached, then for every
(s′,h′) in the chain ending at (s,h), the statement Notar(s′,h′) is reached.
Proof. By induction on chain length. For the head, Notar(s,h) is reached by
assumption. For the parent (sp,hp), the Notar(s,h) conditions require
Notar(sp,hp) to be reached. Apply the inductive hypothesis to
(sp,hp). □
Theorem 2.6 (Safety). If Final(sa,ha) and Final(sb,hb) are both
reached with sa≤sb, then the chain ending at (sa,ha) is a prefix of the chain ending
at (sb,hb).
Proof. If sa=sb, then by Lemma 2.4, ha=hb.
Otherwise, let Cb be the chain ending at (sb,hb) with slot set Sb. Suppose
sa∈/Sb. Since sa<sb, the chain Cb must skip slot sa: there exists a candidate
(sc,dc,sd,hd,σc) identified by (sc,hc) in Cb with sd<sa<sc. By Lemma 2.3, Notar(sb,hb) is reached; by Lemma 2.5, so is
Notar(sc,hc). The notarization conditions for (sc,hc) require Skip(sa) to be reached. But
Final(sa,ha) is also reached, contradicting Lemma 2.1. □
Let (s∗,h∗) be the candidate identifier with the largest slot s∗ such that v has observed
Final(s∗,h∗), or (−1,∅) if no finalization has been observed. The output
log of v is the chain state of the chain ending at (s∗,h∗).
Corollary 2.7 (Consistency). Any two honest validators’ output logs are such that one is a
prefix of the other.
Proof. Let (sa∗,ha∗) and (sb∗,hb∗) be the latest finalized identifiers observed by
validators va and vb respectively. WLOG, sa∗≤sb∗. Both Final statements
are reached (since they were observed). By Theorem 2.6, the chain ending at (sa∗,ha∗) is a
prefix of the chain ending at (sb∗,hb∗), so the output log of va is a prefix of the
output log of vb. □
The permission for Notar(s,h) and Skip(s) to coexist means non-finalized
histories may fork (a slot that is both skipped and notarized can be included or excluded by later
candidates), but Theorem 2.6 guarantees that finalization collapses any such forks into a single
consistent chain.
# 3. Liveness
Safety holds unconditionally but says nothing about progress. The voting rules in Section 1.4 are
compatible with validators never casting a single vote. To prove liveness, we need to specify when
honest validators actually vote, how leaders produce candidates, and how the network delivers
messages between validators. This section provides those operational rules (Section 3.1), introduces a
probabilistic network model (Section 3.2), and then proves that, under these rules and this model,
finalization happens infinitely often with probability 1.
# 3.1 Honest Validator Rules
Fix parameters T0 (skip-timeout scale), Ts (standstill period), and α>1
(skip-timeout growth rate).
An honest validator v maintains per-slot voting state (which Notar,
Skip, and Final votes it has cast) and a local frontier Fv
(Rule 1). In all cases, “broadcast” means sending the message to every other validator.
Rule 1 (Frontier tracking). A slot s is cleared for v if v has observed
Notar(s,⋅), Skip(s), or Final(s′,⋅) for some
s′≥s. The frontier Fv(t) is the smallest slot that is not cleared for v.
Initially Fv=0.
When Fv crosses a window boundary kL, window k becomes active for v.
The next two rules describe how validators obtain and produce candidates.
Rule 2 (Candidate resolution). Honest validators store candidates they have voted
Notar for. Validator v can obtain a notarized candidate identified by
(s,h) by requesting it from a uniformly random peer and retrying after an exponentially
increasing timeout. When v receives such a request for a candidate it has stored, it
replies.
Given a certificate proving that Notar(s,h) is reached, a node can resolve the
state of the chain at (s,h) (or simply, resolve the state at (s,h)) by following
parent links and recursively requesting missing candidates from other nodes.
Rule 3 (Leader duty). When window k becomes active and v is its leader, v
chooses any base (sp,hp) for which it can prove all of the following:
- sp<kL,
- Notar(sp,hp) is reached,
- Skip(s′) is reached for every sp<s′<kL.
Validator v then resolves the state at (sp,hp) and produces a valid
candidate (kL,d,sp,hp,σ).
The candidate is broadcast to all validators.
The following three rules govern how validators vote on candidates and handle leader failures.
Rule 4 (Notarize). Upon receiving a candidate (s,d,sp,hp,σ) identified by (s,h),
validator v starts state resolution for (sp,hp). It votes Notar(s,h) and
broadcasts the vote as soon as it can prove all of the following:
- v has not previously voted Notar(s,⋅) for any candidate at slot s.
- Notar(sp,hp) is reached.
- For every slot s′ with sp<s′<s, Skip(s′) is reached.
- Candidate (s,h) is valid.
Rule 5 (Finalize). Validator v votes Final(s,h) and broadcasts the vote
as soon as it can prove all of the following:
- v has voted Notar(s,h),
- Notar(s,h) is reached,
- v has not voted Skip(s).
Rule 6 (Skip). For each window k, after the window becomes active for v, and for
each slot s in the window, there is a finite timeout Tskip(s)≥T0 after
which v votes Skip(s) (unless it has already voted
Final(s,⋅)), and broadcasts the vote.
Let k∗ be the window containing the largest slot s∗ such that v can prove
Final(s∗,⋅) is reached at the moment window k becomes active. Then Tskip(s)≥T0⋅αk−k∗−1
for every slot s in window k.
The final two rules handle certificate propagation and recovery from stalls.
Rule 7 (Certificate formation and rebroadcast). When v has received votes for a
statement S with total weight at least q, it forms the corresponding certificate.
Upon forming or receiving any certificate, v broadcasts it.
Rule 8 (Standstill resolution). When v has not observed any new finalized blocks
since time t0, the j-th standstill-resolution attempt (j∈N0) occurs
at time t0+(j+1)Ts. Each standstill-resolution attempt is a broadcast that sends:
- the certificate for Final(s,⋅) with largest slot s that v has
observed (unless s=−1),
- all certificates v holds for slots >s,
- all votes cast by v for slots >s.
# 3.2 Network Model
We consider the following two-phase network model:
- Adversarial phase (t<TGST). The adversary controls message delivery
between all pairs of validators: it may delay, reorder, or drop messages arbitrarily.
- Good phase (t≥TGST). Each message sent by an honest validator to
another honest validator is an independent trial: it is delivered within time δ
with probability 1−r and lost otherwise. Here r∈[0,1) is the drop rate.
Unlike the standard GST model, which assumes perfect delivery after stabilization, we retain
independent message loss after TGST. This forces the liveness proof to account
explicitly for the operational mechanisms (standstill and candidate resolution) that a real
implementation needs anyway.
Assumption 9 (Vote and certificate delivery). Each vote or certificate sent from one
honest validator to another after TGST is an independent trial that arrives
within δ with probability at least psdeliv>0.
Assumption 10 (Candidate broadcast delivery). For any slot where the designated leader
is honest and broadcasts a candidate after TGST, independently of other slots,
some adversarially chosen set of honest validators with total weight at least q receives
that candidate within Δbcast with probability at least
pbcast>0.
Assumption 11 (Candidate resolution success). Each candidate-resolution request sent to
an honest validator after TGST is an independent trial that returns the
candidate within Δresolv with probability at least presolv>0.
# 3.3 Almost-sure Liveness
Let H be the set of honest validators.
Let t0≥TGST, and let sf be the largest slot such that
Final(sf,⋅) is reached by time t0. Consider the event
E0:={no slot s>sf is ever finalized after t0}.Lemma 3.1 (Eventual dissemination of honest-held data). Condition on E0. Then, with probability 1, every vote cast by an honest validator for
a slot >sf, and every certificate for a slot >sf that is observed by an honest
validator, is eventually delivered to every other honest validator.
Proof. Under E0, no honest validator ever observes a new finalized block after time
t0. By Rule 8, every honest validator therefore performs standstill broadcasts forever,
once every Ts time units. Each such broadcast contains all certificates the validator
holds above its latest observed finalization, as well as all of its own votes above that
finalization.
Fix u,v∈H and a specific object X for a slot >sf, where X is
either a vote cast by u or a certificate observed by u. By Rule 8, validator u
retransmits X infinitely many times. By Assumption 9, each retransmission reaches v
within δ with probability at least psdeliv>0. Hence
Pr[v never receives X]=m→∞lim(1−psdeliv)m=0.Since the set of honest sender-receiver pairs is finite, this holds simultaneously for all
of them with probability 1. □
Lemma 3.2 (Every slot is eventually cleared under an infinite standstill). Condition on E0. Then, with probability 1, every slot s>sf is eventually cleared
for every honest validator. Consequently, Fv(t)→∞ for every v∈H as t→∞.
Proof. Proceed by induction on s>sf.
Assume that every slot s′<s is eventually cleared for every honest validator. Then,
for every honest validator v, the local frontier Fv eventually reaches at least s.
Hence the window containing slot s eventually becomes active for every honest validator.
Now consider slot s. There are two cases.
-
Some honest validator eventually observes Notar(s,h) for some h.
By Lemma 3.1, every honest validator eventually observes the same notarization
certificate. Therefore slot s is eventually cleared for every honest validator by
Rule 1.
-
No honest validator ever observes any Notar(s,⋅).
It can be shown that in this case no honest validator can ever prove that any
Notar(s,⋅) is reached. (Broadly, if no honest validator observes a
particular certificate, no honest validator can prove the existence of such.)
Therefore no honest validator ever votes Final(s,⋅), because Rule 5
requires proving that some Notar(s,⋅) is reached. Since the window
containing s is active and Rule 6 gives a finite skip timeout, every honest
validator eventually votes Skip(s).
The total honest weight is W−f≥q, so honest skip votes alone suffice to reach
Skip(s). Each honest validator includes its own skip vote in every
subsequent standstill broadcast, so by Lemma 3.1 every honest validator eventually
receives enough honest skip votes to observe Skip(s). Thus slot s is
eventually cleared for every honest validator.
In both cases, slot s is eventually cleared for every honest validator. This completes
the induction. □
Lemma 3.3 (Locally provable eligible bases in sufficiently late active windows). Condition on E0. Let kf be the window containing slot sf. Let
v∈H, and let k>kf be a window that is active for v. Then, at the
moment window k becomes active for v, there exists at least one base for Rule 3 that
v can already prove is eligible. Moreover, any chain ending at such a base has length at
most kL.
Proof. Fix such v and k.
If v has observed some Notar(b,⋅) or Final(b,⋅) with
b<kL, let b be the largest such slot. Otherwise set b=−1, using the implicit
genesis base.
Since window k is active for v, every slot s<kL is cleared for v. Also, because
k>kf, no slot s≥kL is ever finalized on E0. Therefore, for every slot
s with b<s<kL, clearing cannot come from any observed finalization at or above
s. By maximality of b, it also cannot come from any observed notarization or
finalization at a slot in (b,kL). Hence each such slot must be cleared by an observed
skip certificate. Thus v can prove Skip(s) is reached for every
b<s<kL.
If b=−1, the genesis base is eligible by the implicit
Notar(−1,∅). If b≥0, then
the observed notarization or finalization certificate at slot b, together with the skip
certificates for all slots in (b,kL), gives v a proof that (b,⋅) is an eligible
base for Rule 3. This proves existence.
Finally, any chain ending at a base with slot b<kL contains strictly increasing slot
numbers, so its length is at most b+1≤kL. □
Lemma 3.4 (Tail bound for state resolution). There exist constants Cres>0 and β>0 such that the following holds.
Let m≥1. Suppose an honest validator needs to resolve the state of a chain whose
length is at most m. Then for every T>0,
Pr[resolution is not completed within time T]≤Cresmβ+1T−β.In particular, for a base in window k one may take m≤kL, so
Pr[base state is not resolved within time T]≤Cres′kβ+1T−βfor a suitable constant Cres′>0 depending only on L and the protocol
parameters.
Proof. Consider one missing candidate on the chain. Because the chain is certified
slot-by-slot, at least one honest validator stores that candidate: honest validators store
all candidates they vote Notar for, and every notarized or finalized slot has
positive honest overlap.
A single resolution request chooses a uniformly random peer. The probability that the
request is addressed to an honest holder is at least 1/n. Conditioned on that event,
Assumption 11 implies a reply within Δresolv with probability at least
presolv. Hence one request attempt succeeds within
Δresolv with probability at least a:=npresolv>0.
By Rule 2, retries use exponentially increasing timeouts. Therefore there exist constants
B,B′>0 such that by time T at least ⌊B′ln(T/B)⌋ request attempts have been made whenever T≥B. Hence
Pr[one fixed candidate is still unresolved after time T]≤(1−a)⌊B′ln(T/B)⌋.Setting β:=−B′ln(1−a)>0, the right-hand side is bounded by C0T−β for a suitable constant C0>0.
Now let the chain length be at most m. Resolve candidates sequentially from the base
upward and allocate time T/m to each candidate. Let P be “some candidate on the chain is not resolved within its allotted time”. By the bound above and a union bound,
Pr[P]≤m⋅C0(T/m)−β=C0mβ+1T−β.This proves the claim with Cres=C0. The window-k specialization follows
from Lemma 3.3. □
Lemma 3.5 (Uniform positive chance of finalization in late honest windows). There exist constants k0>kf and ε>0 such that the following holds.
Let k≥k0 be a window whose designated leader is honest, and let ak be the time
when window k becomes active for that leader. Condition on any execution history up to
time ak in which no slot larger than sf has been finalized by time ak. Then the
probability that slot kL is finalized before the skip timeout in that window is at least
ε.
Proof. Fix such a window k, and let u be its honest leader. Let τk:=T0αk−kf−1, the lower bound from Rule 6 for skip timeouts in window k.
Let (b,hb) be the base chosen by u under Rule 3. By Rule 3, at the moment of choice,
leader u already has a local proof that (b,hb) is eligible: one certificate proving
Notar(b,hb) is reached, together with certificates proving
Skip(s) is reached for every b<s<kL. By Lemma 3.3, such a base exists in
every active window k>kf.
We will show that, for all sufficiently large k, there is a uniform positive
probability that:
- u resolves the chosen base and produces the candidate quickly,
- the candidate reaches a quorum-weight honest set Hk,
- the leader’s proof of eligibility reaches every validator in Hk via standstill
broadcasts,
- every validator in Hk resolves the base state quickly,
- notarization and finalization votes are exchanged quickly enough.
We treat these steps in order.
First, the leader must resolve the chosen base state and produce its candidate. Since any
chain ending at a base with slot b<kL has length at most kL, Lemma 3.4 gives
Pr[leader does not finish this within time τk/4]≤C1kβ+1τk−βfor some constant C1>0.
Second, once the candidate is produced and broadcast, Assumption 10 implies that with
probability at least pbcast some honest set Hk⊆H with total weight at least q receives the candidate within
Δbcast.
Third, the validators in Hk must receive enough certificates to prove Rule 4(2) and 4(3)
for the leader’s chosen base. Let Pk be the set of certificates needed for that proof:
one certificate for the base, and one skip certificate for each slot between b and kL.
Thus ∣Pk∣≤kL+1.
As long as no new finalized block is observed, Rule 8 makes the leader rebroadcast all of
these certificates every Ts time units. Over any interval of length τk/2, there
are at least
Mk:=⌊2Tsτk⌋−1standstill attempts once k is large enough. For any fixed certificate
C∈Pk and any fixed validator w∈Hk, the probability that none of those
Mk transmissions from u to w arrives within δ is at most (1−psdeliv)Mk.
Let P′ be “some validator in Hk is still missing some certificate in Pk after time τk/2”.
A union bound over all certificate-recipient pairs shows that
Pr[P′]≤n(kL+1)(1−psdeliv)Mk.The right-hand side tends to 0 exponentially fast in τk.
Fourth, each validator in Hk must resolve the same base state before voting
Notar(kL,⋅). Applying Lemma 3.4 and union bounding over at most n
validators,
Pr[some validator in Hk fails to resolve within time τk/4]≤C2kβ+1τk−βfor some constant C2>0.
Fifth, the resulting notarization and finalization votes must be exchanged quickly enough.
Choose some collector ck∈Hk. Let Evote be the event that:
- every validator in Hk delivers its notarization vote to ck within δ;
- ck delivers the resulting notarization certificate to every validator in Hk
within δ;
- every validator in Hk delivers its finalization vote to ck within δ.
This involves at most 3n point-to-point deliveries between honest validators. By
Assumption 9,
Pr[Evote]≥psdeliv3n.Now define the success event Ek as the conjunction of the following:
- the leader resolves the chosen base and produces the candidate within τk/4;
- the candidate reaches an honest set Hk of total weight at least q within
Δbcast;
- by time τk/2, every validator in Hk has received all certificates in Pk;
- by time τk/2+τk/4, every validator in Hk has resolved the base state;
- Evote occurs.
On Ek, by time τk/2+τk/4 every validator in Hk has all information
needed to prove Rule 4(2)–(4). Moreover, because the leader is honest and produces
only one candidate per slot, no other properly signed candidate for slot kL exists,
so no validator in Hk can have previously voted Notar(kL,⋅) for a
different candidate, satisfying Rule 4(1). Thus all validators in Hk vote
Notar(kL,⋅). The collector forms the notarization certificate and
rebroadcasts it. Since all of these validators have not yet skipped slot kL, they then
vote Final(kL,⋅), and the collector receives finalization votes of total
weight at least q.
The total time used on Ek is at most 2τk+4τk+Δbcast+3δ.
Because τk grows exponentially in k while Δbcast and δ
are constant, there exists k0>kf such that for all k≥k0, Δbcast+3δ≤4τk, and simultaneously
C1kβ+1τk−β+C2kβ+1τk−β+n(kL+1)(1−psdeliv)Mk≤21.For such k, the chain rule gives
Pr[Ek]≥21pbcastpsdeliv3n.Set ε:=21pbcastpsdeliv3n>0.
Finally, on Ek the finalization certificate for slot kL is formed before time
τk, hence before any honest validator’s skip timeout for that slot expires.
Therefore slot kL is finalized before timeout. Thus every sufficiently late honest-leader
window succeeds with conditional probability at least ε. □
Theorem 3.6 (A later finalization occurs almost surely). Fix any finite execution prefix ending at time t0≥TGST, and let sf be
the largest slot finalized by time t0. Then, conditioned on that prefix, with
probability 1 some slot s>sf is eventually finalized.
Proof. Let E0 be the event that no slot larger than sf is ever finalized.
By Lemma 3.2, on E0 every honest validator’s frontier tends to infinity. Therefore
every sufficiently late window eventually becomes active for every honest validator. Since
leader windows rotate cyclically and the honest stake is positive, infinitely many of
those active windows have honest leaders.
Enumerate, on the event E0, the honest-leader windows with index at least k0 from
Lemma 3.5 as K1<K2<⋯.
For each i, let Ai be the event that the leader slot of window Ki is finalized
before its skip timeout.
Lemma 3.5 states that for every i, Pr[Ai∣Fi]≥ε, where Fi is the full execution history up to the activation time of window
Ki, under the condition that no slot larger than sf has been finalized before that
activation time. Hence, by the chain rule,
Pr[i=1⋂mAic]≤(1−ε)mfor every m≥1.But on E0, all of the windows Ki exist and all of the events Ai fail. Therefore
Pr[E0]≤Pr[i=1⋂mAic]≤(1−ε)mfor every m≥1.Letting m→∞ yields Pr[E0]=0. Thus, conditioned on the execution prefix
up to time t0, some later slot is finalized almost surely. □
Theorem 3.7 (Infinitely many finalized blocks). With probability 1, infinitely many slots are finalized.
Proof. Define a sequence of random slots (Sj)j≥0 recursively by S0:=−1, and for each j≥0, let Sj+1 be the smallest slot strictly larger than Sj
that is finalized, if such a slot exists.
Theorem 3.6 applies after any finite execution prefix. In particular, on the event that
Sj exists, condition on the history up to the time when Sj is finalized. Then, with
probability 1, some later slot is finalized. Equivalently,
Pr[Sj+1<∞∣Sj<∞]=1for every j≥0.By induction on j,
Pr[Sj<∞]=1for every j≥0.Hence, with probability 1, the sequence (Sj) is defined for all j, which means
that infinitely many slots are finalized. □
Theorem 3.7 establishes almost-sure liveness. Under the operational rules of Section 3.1 and the
probabilistic post-TGST network model of Section 3.2, the protocol finalizes blocks
infinitely often with probability 1. Combined with the safety theorem from Section 2, this
implies that honest validators’ output logs form a single ever-growing chain.
# 4. Implementation Notes
# 4.1 Concept-to-Code Map
In the C++ node, the implementation lives in validator/consensus/. The following table maps
protocol concepts to their code counterparts:
| Protocol concept |
Code |
| Slot |
CandidateId::slot (types.h); per-slot state in ConsensusState::slots_ (simplex/state.h) |
| L |
slots_per_leader_window in NewConsensusConfig::Simplex |
| Leader rotation |
SimplexCollatorSchedule::expected_collator_for: ⌊s/L⌋modn (simplex/bus.cpp) |
| Candidate |
struct Candidate (types.h): id, parent, block data, leader signature |
| Notar/Skip/Final votes |
NotarizeVote, SkipVote, FinalizeVote (simplex/votes.h) |
| Certificates |
Certificate<T> template (simplex/certificate.h); aliases NotarCert, SkipCert, FinalCert |
| Frontier Fv |
PoolImpl::now_ (simplex/pool.cpp): smallest slot not yet notarized or skipped |
| Rule 1 (frontier tracking) |
PoolImpl::advance_present advances now_; ConsensusState::notify_finalized prunes old slots |
| Rule 2 (candidate resolution) |
CandidateResolverImpl (simplex/candidate-resolver.cpp): random-peer fetch with exponential backoff (0.5 s initial, 1.5$\times$, 30 s cap) |
| Rule 3 (leader duty) |
BlockProducerImpl::generate_candidates (block-producer.cpp): produces L candidates per window |
| Rule 4 (notarize) |
ConsensusImpl::try_notarize (simplex/consensus.cpp): async pipeline of parent wait → state resolve → validate → vote |
| Rule 5 (finalize) |
ConsensusImpl::try_vote_final (simplex/consensus.cpp) |
| Rule 6 (skip) |
ConsensusImpl::alarm (simplex/consensus.cpp): fires after first_block_timeout_s_ per window |
| Rule 7 (cert formation/rebroadcast) |
PoolImpl::handle_vote (simplex/pool.cpp) forms certs at quorum; PoolImpl::handle_our_certificate rebroadcasts obtained certificates |
| Rule 8 (standstill) |
PoolImpl::alarm (simplex/pool.cpp): fires every 10 s, broadcasts all held certs and own votes |
Communication uses a private validator overlay (simplex/private-overlay.cpp). Votes and
certificates are sent individually to each peer. Candidates are broadcast using two-step FEC
erasure coding (overlay/broadcast-twostep.cpp), where the data is split into k≈2n/3
symbols and each peer receives one symbol.
# 4.2 Deviations from the Rules
Rule 3 only requires the leader to produce one candidate per window. The implementation produces
L: generate_candidates loops over all slots in the window, producing one candidate per slot
with each referencing the previous as its parent. Later candidates in the window begin generation
immediately without waiting for earlier ones to be notarized, since the leader already knows the
only possible parent — it just produced it.
The implementation sometimes suppresses votes that the Section 3.1 rules would require. None of these
affect liveness, since in all such situations the suppressed vote would not lead to formation of
a new certificate for a non-finalized slot.
Rule 6 requires Tskip(s)≥T0⋅αk−k∗−1, where k∗ is
determined by the last finalization that was reached. The implementation currently resets the
timeout upon seeing a leader window without skip votes — this is a bug and will be fixed. We
additionally cap Tskip(s) at 100 s, in the expectation that any reasonable consensus
synchronization will not require longer skip timeouts. Regardless, a mechanism to manually
increase first_block_max_timeout_s is planned.
# 4.3 Network Model Discussion
Assumptions 10 and 11 require bounded delivery times Δbcast and
Δresolv. This is justified because the implementation caps candidate
payload size at a constant Cmax, so delivery time is
δ+Θ(Cmax) for both broadcast and resolution.
The egress induced by the protocol is currently unbounded. In particular, a sufficiently long
period of asynchrony (or a bug) can induce a state whose synchronization saturates link capacity,
causing unsynchronized state to only grow further — a death spiral. We plan to address this with
better timeout tuning and optimizations to the standstill resolution mechanism.
The two-step FEC encoding uses k≈2n/3 data symbols distributed one per peer.
Reconstruction requires any k of the n symbols, tolerating at most n−k≈n/3
losses. This is a count threshold, not a weight threshold. We consider this acceptable since we
do not expect the number of Byzantine validators to significantly exceed their share of total
weight.
The network model requires drop probabilities to be independent across packets. In practice,
QUIC is more likely to drop packets after a burst of high momentary egress, even when it could
have spread the load over time. We plan to address this by more precise tracking of the moment
each message becomes irrelevant for the protocol, allowing earlier cancellation and reducing
unnecessary egress.
# 4.4 Empty Candidates
The leader sometimes produces an empty candidate — one that references an existing block by
its BlockIdExt rather than carrying new block data. Empty candidates participate in consensus
normally (they are notarized, finalized, and form chains) but do not advance any user-visible
blockchain state.
Empty candidates are generated in two situations, both driven by constraints external to
consensus:
-
A shardchain leader generates empty candidates when the masterchain’s last finalized seqno
falls more than 8 blocks behind the shard’s current tip. This is a legacy validation
requirement that prevents the shardchain from building an arbitrarily long tail of blocks
that the masterchain has not yet acknowledged.
-
A masterchain leader generates empty candidates when the next block to produce would be more
than one seqno ahead of the last consensus-finalized block. This ensures that every
masterchain block eventually receives finalization signatures, which all non-validator nodes
depend on.