Skip to content

Commit bc9f46b

Browse files
laviniat1996laviniat1996
committed
add consensus doc
1 parent 9cafb91 commit bc9f46b

File tree

1 file changed

+222
-2
lines changed

1 file changed

+222
-2
lines changed

‎ton/consensus.mdx‎

Lines changed: 222 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,225 @@
11
---
2-
title: "Consensus"
2+
title: Consensus in TON
3+
description: Deep technical overview of the consensus protocols in the TON Blockchain, including Catchain, Block Consensus Protocol, validator elections, incentives, and fault tolerance.
34
---
45

5-
Stub
6+
## Introduction
7+
8+
The TON Blockchain achieves consensus through a layered Byzantine Fault Tolerant (BFT) protocol designed for **high throughput, low latency, and security against up to one-third malicious validators**.
9+
10+
The system combines two protocols:
11+
12+
- **Catchain Protocol** – a reliable broadcast mechanism that ensures consistent message delivery and fork detection.
13+
- **Block Consensus Protocol (BCP)** – a three-phase commit protocol built on top of Catchain that finalizes blocks.
14+
15+
This separation allows TON to finalize blocks in **3–6 seconds** with **hundreds of validators** across the globe.
16+
17+
---
18+
19+
## Consensus Model
20+
21+
### Byzantine Fault Tolerance
22+
Let:
23+
- `n` = number of validators,
24+
- `f` = number of faulty or malicious validators,
25+
- `q` = quorum size.
26+
27+
Conditions for TON consensus:
28+
29+
```
30+
f < n/3
31+
q ≥ 2n/3
32+
```
33+
34+
These conditions guarantee:
35+
- **Safety** – no two conflicting blocks can both be finalized.
36+
- **Liveness** – as long as ≥ `2n/3` validators are responsive, some block is always finalized.
37+
38+
---
39+
40+
## Catchain Protocol
41+
42+
Catchain provides the secure communication foundation for BCP.
43+
44+
### Validator messages
45+
Each validator `v` generates a sequence of signed messages:
46+
47+
```
48+
m(v, h) = (id = v, height = h, deps[], payload, sig)
49+
```
50+
51+
- `height`: strictly increasing local counter.
52+
- `deps[]`: references to previous messages (DAG edges).
53+
- `sig`: cryptographic signature binding the message.
54+
55+
### DAG structure
56+
The global state of Catchain is a **Directed Acyclic Graph (DAG)** where:
57+
- Vertices are messages.
58+
- Edges represent dependencies.
59+
- Every message must reference known predecessors.
60+
61+
This enforces causal ordering: a message can only be processed when its entire dependency cone is available.
62+
63+
### Fork detection
64+
Forking occurs when:
65+
66+
```
67+
∃ m1, m2 : m1.id = m2.id, m1.height = m2.height, m1 ≠ m2
68+
```
69+
70+
This is undeniable evidence of equivocation.
71+
A **fork proof** = `{m1, m2}` can be submitted to the Elector contract, leading to validator slashing.
72+
73+
### Guarantees
74+
- **Consistency** – all honest validators eventually converge on the same DAG.
75+
- **Integrity** – equivocation is always detectable.
76+
- **Foundation** – BCP builds on this consistent DAG to safely finalize blocks.
77+
78+
---
79+
80+
## Block Consensus Protocol (BCP)
81+
82+
With Catchain providing reliable messaging, BCP ensures validators agree on block finalization.
83+
84+
### Phases
85+
BCP is structured as a **three-phase commit**:
86+
87+
1. **Proposal** – a leader proposes a block candidate.
88+
2. **Validation** – validators verify correctness (transaction validity, state consistency).
89+
3. **Voting** – validators vote for approved candidates.
90+
4. **PreCommit** – once ≥ `q` votes are collected, validators broadcast PreCommit.
91+
5. **Commit** – once ≥ `q` PreCommits are observed, validators issue CommitSign and the block is finalized.
92+
93+
If no block reaches quorum, a **null block** is finalized, guaranteeing progress.
94+
95+
### Safety proof
96+
Suppose two conflicting blocks `B1` and `B2` are both finalized.
97+
- Each requires ≥ `q ≥ 2n/3` signatures.
98+
- Their signer sets intersect in ≥ `2q – n ≥ n/3` validators.
99+
- Since `f < n/3`, at least one honest validator signed both, which is impossible.
100+
101+
Therefore, conflicting blocks cannot both be finalized.
102+
103+
### Liveness
104+
As long as ≥ `2n/3` validators are online and responsive, some block or null block always gathers enough signatures, ensuring bounded progress.
105+
106+
---
107+
108+
## Rounds and Attempts
109+
110+
Consensus is organized into **rounds** and **attempts**:
111+
112+
- Each round lasts one election cycle (~18h on mainnet, ~2h on testnet).
113+
- Each round is subdivided into attempts of fixed duration (`K ≈ 8s`).
114+
- **Fast attempts** – optimistic, finalize quickly if leader is honest and network healthy.
115+
- **Slow attempts** – coordinator-driven, ensure progress under failures.
116+
117+
Block latency is typically **3–6s**, bounded by attempt timers.
118+
119+
---
120+
121+
## Validator Elections
122+
123+
Validators are selected by the **Elector contract** using an on-chain election.
124+
125+
### Process
126+
1. Validators submit stake transactions.
127+
2. Elector sorts candidates by stake.
128+
3. Up to `maxValidators` are selected.
129+
4. Effective stake is capped to ensure fairness.
130+
131+
### Effective stake formula
132+
```
133+
effectiveStake(v) = min(stake(v), minStake × stakeFactor)
134+
```
135+
136+
Where:
137+
- `minStake` = minimum stake among selected validators,
138+
- `stakeFactor` ≈ 3.
139+
140+
This prevents one validator from dominating with excessive stake.
141+
142+
### Example
143+
If the smallest validator stakes 100k TON, then:
144+
- The largest counted stake = 300k TON.
145+
- A validator staking 1M TON still only contributes 300k TON effectively.
146+
147+
### Set sizes
148+
- **Masterchain** – ~100 validators.
149+
- **Shardchains** – ~23 validators each.
150+
151+
---
152+
153+
## Incentives and Penalties
154+
155+
### Rewards
156+
Validators are compensated with:
157+
- **Transaction fees** (gas costs).
158+
- **Block subsidies**:
159+
- ~1.7 TON per masterchain block.
160+
- ~1 TON per shardchain block.
161+
162+
Average income: ~120 TON per validator per round (varies with network load).
163+
164+
### Inflation and burn
165+
- Inflation rate: ~0.3–0.6% annually.
166+
- Since June 2023, part of the subsidy is burned, introducing deflationary pressure as usage grows.
167+
168+
### Penalties
169+
Validators may be fined for:
170+
- **Inactivity** – not producing or signing enough blocks (lower than 90% efficiency).
171+
- **Malicious behavior** – forks, equivocation, invalid approvals.
172+
- **Standard fine** – ~101 TON per round of misbehavior.
173+
174+
### Slashing mechanism
175+
- Evidence is submitted as fork proofs or efficiency complaints.
176+
- Validators verify collectively; ≥ `2n/3` agreement required.
177+
- Elector contract enforces slashing automatically.
178+
179+
This ensures accountability while preventing abuse by a small minority.
180+
181+
---
182+
183+
## Validator Guidelines
184+
185+
Operating a validator reliably is critical. Recommended practices:
186+
- Run on high-performance, redundant servers.
187+
- Ensure stable, low-latency network connections.
188+
- Use monitoring systems (Prometheus, Grafana, Datadog) to track CPU, memory, disk, and validator efficiency.
189+
- Keep validator software updated to the latest stable release.
190+
- React quickly to alerts about downtime or forks.
191+
192+
Validators unable to meet these requirements may prefer to delegate stake via staking services.
193+
194+
---
195+
196+
## Extended Fault Tolerance Analysis
197+
198+
- **Fault tolerance:**
199+
- With `n` validators, up to `f < n/3` may behave arbitrarily (Byzantine).
200+
- Finalization requires ≥ `2n/3` CommitSigns.
201+
202+
- **Intersection property:**
203+
- Any two quorums of size ≥ `2n/3` intersect in at least `n/3`.
204+
- Since `f < n/3`, intersection always includes an honest validator.
205+
- This guarantees that conflicting blocks cannot both finalize.
206+
207+
- **Efficiency requirement:**
208+
- A validator’s efficiency = `signedBlocks / expectedBlocks`.
209+
- If efficiency is lower than 90% in a round, fines are applied.
210+
211+
- **Liveness bound:**
212+
- Consensus always finalizes within a bounded number of attempts.
213+
- Null blocks prevent deadlock even under heavy network partitions.
214+
215+
---
216+
217+
## Summary
218+
219+
- **Catchain Protocol** – consistent broadcast of validator messages with DAG structure and fork proofs.
220+
- **Block Consensus Protocol** – three-phase commit finalizing blocks with ≥ `2n/3` quorum.
221+
- **Elections** – validator selection via the Elector contract, with fairness enforced by stake caps.
222+
- **Rewards and penalties** – align incentives with network security.
223+
- **Fault tolerance** – safety holds with `f < n/3`, liveness guaranteed with ≥ `2n/3` honest validators.
224+
225+
This architecture enables TON to deliver **fast finality, decentralization, and strong BFT guarantees** at global scale.

0 commit comments

Comments
 (0)