diff --git a/docs/infographics/3sf-mini-infographic.html b/docs/infographics/3sf-mini-infographic.html new file mode 100644 index 0000000..017bef4 --- /dev/null +++ b/docs/infographics/3sf-mini-infographic.html @@ -0,0 +1,768 @@ + + + + + +3SF-mini Consensus — ethlambda + + + + +
+ + +
+
ethlambda consensus
+

3SF-mini

+

A slot-level finality protocol that concentrates validator votes through justifiability backoff, enabling fast finalization under good conditions and graceful degradation under adversity.

+
+ + +
+
+
1
+

Slot Structure: 4 Seconds, 4 Intervals

+
+

Each slot is divided into four 1-second intervals. Validators perform specific duties at each interval, orchestrating block production, attestation, and fork choice updates.

+ +
+
+
0s
+
+
+ INT 0 + Proposer: accept pending attestations → run fork choice → build & publish block +
+ +
1s
+
+
+ INT 1 + All validators: produce attestations (head, target, source) → gossip to network +
+ +
2s
+
+
+ INT 2 + Safe target: run fork choice with 2/3 threshold → update target for next attestations +
+ +
3s
+
+
+ INT 3 + Accept: promote accumulated attestations → update fork choice head +
+
+
+
+ + +
+
+
2
+

Justifiability: Which Slots Can Be Justified?

+
+

Not every slot is eligible for justification. The distance (delta) from the last finalized slot determines eligibility through three rules. This backoff creates fewer targets over time, concentrating votes to reach the 2/3 supermajority threshold.

+ +
+
+
+

Rule 1: Proximity

+
δ ≤ 5
+
0, 1, 2, 3, 4, 5
+
+
+

Rule 2: Perfect Square

+
δ = n²
+
1, 4, 9, 16, 25, 36, 49 …
+
+
+

Rule 3: Pronic Number

+
δ = n(n+1)
+
2, 6, 12, 20, 30, 42, 56 …
+
+
+ +
+
+
Finalized (slot 0)
+
Justifiable
+
Unjustifiable
+
+
+

Delta from finalized slot 0. Hover for rule. Note how gaps widen — forcing vote concentration.

+
+
+
+ + +
+
+
3
+

Attestation Pipeline

+
+

Attestations flow through a two-stage pool before affecting fork choice. This batching prevents attestation-by-attestation recomputation of the head.

+ +
+
+
+
📡
+

Gossip

+

Validator signs & broadcasts attestation via P2P

+
+
+
+
+

Pending Pool

+

new_attestations
Awaiting promotion

+
+
+ → + int 0 / int 3 +
+
+
+

Active Pool

+

known_attestations
Fork choice active

+
+
+
+
🌳
+

LMD-GHOST

+

Greedy heaviest subtree → head selection

+
+
+
+
📦
+

In Block

+

Proposer includes aggregated attestations

+
+
+
+
+ + +
+
+
4
+

Fork Choice: LMD-GHOST

+
+

Starting from the justified root, greedily descend the block tree always choosing the child with the highest attestation weight. Ties are broken by block hash.

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + Justified Root + weight: 10 + + + + Block A + weight: 7 + + + + Block B + weight: 3 + + + + Block C + weight: 2 + + + + Block D ★ + weight: 5 ← HEAD + + + + Block E + weight: 3 + + + Root → A (7 > 3) → D (5 > 2) · Greedy descent selects heaviest leaf + +
+
+
+ + +
+
+
5
+

Justification & Finalization

+
+

A slot becomes justified when ≥2/3 of validators attest to it. It becomes finalized when two consecutive justifiable slots are both justified with no justifiable gaps between them.

+ +
+ +
Step 1: Genesis
+
+
0
+
1
+
2
+
3
+
4
+
5
+ Slot 0 is both finalized and justified +
+ + +
Step 2: Slot 1 justified (δ=1, ≤5)
+
+
0
+
+
1
+
2
+
+ 2/3 attested source:0 → target:1. No justifiable gaps → slot 0 finalized! +
+ + +
Step 3: Votes scattered across slots 2-15, no slot reaches 2/3
+
+
1
+
2
+
3
+
+
15
+ Votes too spread out — no justification +
+ + +
Step 4: Slot 16 justified (δ=16 from finalized=0 → 16=4²)
+
+
1
+
+
+
16
+ Justifiable gaps exist between 1 and 16 (slots 2,3,4,5,6,9,12) → slot 1 NOT finalized +
+ + +
Step 5: Slot 20 justified (δ=20, pronic: 4×5) with source=16
+
+
16
+
17
+
18
+
19
+
+
20
+ No justifiable slots between 16 and 20 → slot 16 finalized! +
+
+ +
+
+
💡
+
+

Why unjustifiable slots matter:

+

Under network stress, validator votes scatter across many slots. By making most slots unjustifiable, 3SF-mini forces votes to concentrate on fewer eligible targets. The backoff pattern (close → squares → pronic) ensures rapid finalization in good conditions, while the widening gaps in bad conditions still eventually funnel enough votes to reach 2/3 supermajority.

+
+
+
+
+ + + + +
+ + + + +