Skip to content

Commit ade0763

Browse files
will-break-itwill-break-it
committed
docs: merged main
2 parents 2692d24 + 1341e40 commit ade0763

File tree

12 files changed

+1495
-181
lines changed

12 files changed

+1495
-181
lines changed

‎docs/workshop/day-3-recap.md‎

Lines changed: 38 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -60,8 +60,11 @@ The above diagram displays a more realistic picture of different IBs referencing
6060

6161
The EB reference approach offers a middle ground between security and latency. Certified EBs (those that have received votes from a majority of stake) provide security guarantees with lower latency than the [RB-reference approach](#rb-reference-approach), as they indicate that enough nodes have seen and validated them. Several core variations of the EB reference approach were discussed:
6262

63-
##### 1. **IB-to-EB-to-RB Reference**: IBs directly reference certified EBs, which themselves reference an older RB.
64-
![EB Reference Approach](eb-reference-01.svg)
63+
##### 1. **EB Reference**
64+
65+
IBs directly reference certified EBs, which themselves reference an older RB.
66+
67+
![EB Reference Approach](eb-reference.svg)
6568

6669
Different to the [IB-to-RB referencing](#ib-to-rb-reference-approach), this approach has IBs reference an EB instead which itself references an RB.
6770

@@ -70,24 +73,48 @@ We briefly discussed an alternative design choice, in which IBs reference an EB
7073
In this design, one gets a ledger state for each RB which gives a ledger state for each EB to be reused and IBs are validated with respect to that same state. On the contrary, due to EBs referencing an RB, there is still the same trade-off to be made as in the [IB-to-RB reference approach](#ib-to-rb-reference-approach) - having to chose more or less stable RBs for EBs resulting in higher latency or higher loss in EBs.
7174

7275

73-
##### 2. **EB Chain/ IB-to-EB(-to-EB)*-to-RB**
76+
##### 2. **EB-Chain**
7477

7578
In this approach IBs reference an EB which itself may reference another EB, which creates this chain of EBs that anchors on some older RB reference. Thus, EBs may have an RB reference or another EB reference of an EB that has not made it into an RB yet (full Leios variant). RBs on the other hand can only exactly reference one certified EB. IBs reference one of these EBs.
7679

77-
This approach allows for more recent state references while maintaining security through the chain of certified EBs, and handles edge-case scenarios, where multiple EBs have been produced:
80+
As a downside of this approach, it doesn't allow for EBs to reference one or more EBs. Therefore, it still has the same trade-off from the previous [IB-to-EB-to-RB](#1-ib-to-eb-to-rb-reference) approach, since these chains of EBs are anchored to RBs, which comes with this disadvantageous property of high latency, older stable RBs vs low latency, less stable RBs.
81+
82+
![EB Chain Approach](eb-chain.svg)
83+
84+
##### 3. **EB-DAG**
85+
86+
The EB DAG approach represents a sophisticated approach that leverages a directed acyclic graph (DAG) structure of Endorsement Blocks (EBs) to achieve both low latency and strong security guarantees. In this design:
87+
88+
![EB Chain Approach](eb-dag.svg)
89+
90+
- EBs can reference one or more older EBs that haven't been referenced by other EBs yet
91+
- Ranking Blocks (RBs) reference exactly one EB
92+
- Input Blocks (IBs) reference one of these EBs
7893

79-
- from different pipelines in parallel (see EB ordering below)
80-
- from the same pipeline
94+
**Key Advantages:**
8195

82-
![EB Chain Approach](eb-reference-02.svg)
96+
1. **Low Latency with Security**: By allowing EBs to reference other EBs directly, the system achieves low latency while maintaining security. This is because EBs don't need to wait for RBs to be produced, creating a more efficient validation pipeline.
8397

84-
**Extensions and Implementation Details:**
98+
2. **Strong Inclusion Guarantee**: With EBs referencing other EBs, there's a strong property that EBs almost always make it into the chain, assuming the EB rate is approximately 1.5x that of RB rate.
8599

86-
- **Minimum Age Requirement**: A constraint where EBs must reference an RB that is at least a certain age (e.g., 5 minutes old) to ensure it's widely available in the network.
100+
3. **Efficient State Management**: Despite allowing multiple EB references, the system maintains computational efficiency. When computing ledger states for EBs in a chain, nodes can reuse the ledger state from referenced EBs and only replay the IBs in the current EB.
87101

88-
- **EB Ordering by Slot**: In the Leios protocol, multiple pipelines run in parallel, each ideally producing one RB. With parameters set for 1.5 EBs per stage (with randomness via VRF functions potentially producing more), there may be multiple EBs to choose from for inclusion in an RB.
102+
4. **Complete History**: EBs form a chain back to genesis, with the first EB referencing an RB, and subsequent EBs referencing only other EBs. This creates a complete and verifiable history of the chain's state.
89103

90-
- **EB State Reuse**: An optimization technique where, when computing ledger states for EBs in a chain, we reuse the ledger state from referenced EBs and only replay the IBs in the current EB, reducing computational overhead, especially important when dealing with multiple pipelines and stages.
104+
5. **Deterministic State Count**: The number of ledger states a node needs to maintain is exactly equal to the number of EBs, providing predictable resource requirements.
105+
106+
**Implementation Details:**
107+
108+
1. **EB Ordering**: The system handles multiple pipelines running in parallel, each producing one RB. With parameters set for 1.5 EBs per stage (with randomness via VRF functions potentially producing more), there may be multiple EBs to choose from for inclusion in an RB.
109+
110+
2. **State Reconstruction**: When computing ledger states, nodes can efficiently reconstruct the state by reusing states from referenced EBs and only replaying new IBs, preventing computational overhead.
111+
112+
**Limitations:**
113+
114+
1. **No Transactions in RBs**: A notable limitation of this scheme is that RBs cannot contain transactions themselves, as they serve primarily as ordering mechanisms for the EB DAG.
115+
116+
> [!Note]
117+
> [Here](./eb-dag-detailed.svg) is a version of the EB-DAG including IBs.
91118
92119
#### IB Reference Approach
93120

‎docs/workshop/eb-chain.d2‎

Lines changed: 175 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,175 @@
1+
...@styles
2+
3+
title: {
4+
label: "EB-Chain"
5+
near: top-center
6+
style.font-size: 24
7+
style.bold: true
8+
style.fill: "#ffffff"
9+
style.stroke: "#ffffff"
10+
}
11+
12+
volatile: {
13+
label: "Volatile chain suffix"
14+
class: container
15+
16+
RBs: {
17+
class: rb_stacked
18+
label: "[RB]\n(tip-k, tip-2)"
19+
}
20+
21+
RB1: {
22+
class: rb
23+
label: "RB\n(tip-1)"
24+
}
25+
26+
RB: {
27+
class: rb
28+
label: "RB\n(tip)"
29+
}
30+
}
31+
32+
RB0: {
33+
class: rb_unconfirmed
34+
label: "RB"
35+
}
36+
37+
# EB Chain Example 1 - Simple chain with older RB reference
38+
eb_chain1: {
39+
label: "EB Chain Example 1 (Older RB Reference)"
40+
class: container
41+
42+
EB1: {
43+
class: eb
44+
label: "EB1"
45+
}
46+
47+
EB2: {
48+
class: eb
49+
label: "EB2"
50+
}
51+
52+
IB1: {
53+
class: ib
54+
label: "IB1"
55+
}
56+
57+
IB2: {
58+
class: ib
59+
label: "IB2"
60+
}
61+
}
62+
63+
# EB Chain Example 2 - Multiple EBs from different pipelines with recent RB reference
64+
eb_chain2: {
65+
label: "EB Chain Example 2 (Recent RB Reference)"
66+
class: container
67+
68+
EB3: {
69+
class: eb
70+
label: "EB3\n(Pipeline A)"
71+
}
72+
73+
EB4: {
74+
class: eb
75+
label: "EB4\n(Pipeline B)"
76+
}
77+
78+
EB5: {
79+
class: eb
80+
label: "EB5\n(Pipeline A)"
81+
}
82+
83+
IB3: {
84+
class: ib
85+
label: "IB3"
86+
}
87+
88+
IB4: {
89+
class: ib
90+
label: "IB4"
91+
}
92+
}
93+
94+
# Links
95+
96+
# Volatile chain suffix
97+
volatile.RB -> volatile.RB1: {
98+
class: to_rb_arrow
99+
}
100+
101+
volatile.RB1 -> volatile.RBs: {
102+
class: to_rb_arrow
103+
}
104+
105+
RB0 -> volatile.RB: {
106+
class: to_rb_arrow
107+
style: {
108+
stroke-dash: 7
109+
}
110+
}
111+
112+
# EB Certificates
113+
RB0 -> eb_chain1.EB1: "Contains\nEB Certificate" {
114+
class: eb_cert
115+
}
116+
117+
RB0 -> eb_chain2.EB3: "Contains\nEB Certificate" {
118+
class: eb_cert
119+
}
120+
121+
RB0 -> eb_chain2.EB4: "Contains\nEB Certificate" {
122+
class: eb_cert
123+
}
124+
125+
# EB Chain 1 - Simple chain with older RB reference
126+
eb_chain1.EB1 -> eb_chain1.EB2: "EB Ref" {
127+
class: to_eb_arrow
128+
}
129+
130+
eb_chain1.EB2 -> volatile.RBs: "Ledger Ref" {
131+
class: ledger_link
132+
}
133+
134+
# EB to IB references for Example 1
135+
eb_chain1.EB1 -> eb_chain1.IB2: "Ref" {
136+
class: to_ib_arrow
137+
}
138+
139+
# IB validation references for Example 1
140+
eb_chain1.IB1 -> eb_chain1.EB1: "Validated against" {
141+
class: ledger_link
142+
}
143+
144+
eb_chain1.IB2 -> eb_chain1.EB2: "Validated against" {
145+
class: ledger_link
146+
}
147+
148+
# EB Chain 2 - Multiple pipelines with recent RB reference
149+
eb_chain2.EB3 -> eb_chain2.EB5: "EB Ref" {
150+
class: to_eb_arrow
151+
}
152+
153+
eb_chain2.EB4 -> volatile.RB: "Ledger Ref" {
154+
class: ledger_link
155+
}
156+
157+
eb_chain2.EB5 -> volatile.RB1: "Ledger Ref" {
158+
class: ledger_link
159+
}
160+
161+
# EB to IB references for Example 2
162+
eb_chain2.EB3 -> eb_chain2.IB4: "Ref" {
163+
class: to_ib_arrow
164+
}
165+
166+
# IB validation references for Example 2
167+
eb_chain2.IB3 -> eb_chain2.EB3: "Validated against" {
168+
class: ledger_link
169+
}
170+
171+
eb_chain2.IB4 -> eb_chain2.EB4: "Validated against" {
172+
class: ledger_link
173+
}
174+
175+
direction: left

0 commit comments

Comments
 (0)