Skip to content

Commit bcd4d55

Browse files
Manav-AggarwalManav-Aggarwal
committed
Add mini blocks ADR
1 parent 301971e commit bcd4d55

File tree

1 file changed

+153
-0
lines changed

1 file changed

+153
-0
lines changed

‎specs/lazy-adr/adr-021-transaction-streaming.md‎

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
# ADR 021: Transaction Streaming via Mini Blocks from Single Sequencer
2+
3+
## Changelog
4+
5+
- 2025-04-28: Initial draft
6+
7+
## Context
8+
9+
Currently, in single sequencer mode in Rollkit, every configured block time, the sequencer produces blocks. This includes constructing a batch of transactions to put in a block, executing them, and producing a header with the updated state root. This process introduces latency between transaction submission and network-wide propagation, as transactions are only shared after full block production. There is desirable to propagate transactions to full nodes as sooner without waiting for execution or state root computation. This ADR proposes a design where the sequencer streams smaller transaction batches in the form of "mini blocks" sooner to full nodes via p2p so full nodes can receive transactions without waiting for execution or state root computation by the sequencer to reduce overall end-user latency and enhance UX.
10+
11+
### Current Architecture (Before)
12+
```mermaid
13+
flowchart LR
14+
subgraph "Block Time (2s)"
15+
Txs[Transactions] --> Seq[Sequencer]
16+
Seq --> |Execute Txs| Block[Block]
17+
Block --> |Compute State Root| Nodes[Full Nodes]
18+
end
19+
20+
style Seq fill:#f9f,stroke:#333,stroke-width:2px,color:#000
21+
style Block fill:#bbf,stroke:#333,stroke-width:2px,color:#000
22+
style Nodes fill:#bfb,stroke:#333,stroke-width:2px,color:#000
23+
style Txs color:#000
24+
```
25+
26+
### Proposed Architecture (After)
27+
```mermaid
28+
flowchart LR
29+
subgraph "Mini-Block Time (200ms)"
30+
Txs[Transactions] --> Seq[Sequencer]
31+
Seq --> MB1[Mini-Block 1]
32+
Seq --> MB2[Mini-Block 2]
33+
Seq --> MB3[Mini-Block n]
34+
MB1 & MB2 & MB3 --> |Stream| Nodes[Full Nodes]
35+
end
36+
37+
subgraph "Block Time (2s)"
38+
MB1 & MB2 & MB3 --> Block[Block]
39+
Block --> |Compute State Root| Nodes
40+
end
41+
42+
style Seq fill:#f9f,stroke:#333,stroke-width:2px,color:#000
43+
style MB1 fill:#ddf,stroke:#333,stroke-width:2px,color:#000
44+
style MB2 fill:#ddf,stroke:#333,stroke-width:2px,color:#000
45+
style MB3 fill:#ddf,stroke:#333,stroke-width:2px,color:#000
46+
style Block fill:#bbf,stroke:#333,stroke-width:2px,color:#000
47+
style Nodes fill:#bfb,stroke:#333,stroke-width:2px,color:#000
48+
style Txs color:#000
49+
```
50+
51+
## Alternative Approaches
52+
53+
1. **Immediate Transaction Broadcasting**
54+
- Broadcast individual transactions immediately upon receipt
55+
- Pros: Lowest possible latency
56+
- Cons: Higher network overhead, potential complex coordination with execution layer
57+
58+
2. **Parallel Block Production**
59+
- Run block production in parallel while streaming transactions
60+
- Pros: Maintains traditional block structure
61+
- Cons: More complex implementation, potential consistency issues on handling transactions with state contention
62+
63+
3. **Variable Block Times**
64+
- Dynamically adjust block times based on transaction volume
65+
- Pros: Natural adaptation to network load
66+
- Cons: Less predictable finality times, more complex coordination
67+
68+
## Decision
69+
70+
The Rollkit sequencer can be extended to support streaming transaction batches as mini blocks to full nodes via p2p. These mini blocks:
71+
72+
- Consist of a batch of transactions received within a short time window.
73+
- Are not executed by the sequencer before streaming (no state root is produced at this stage).
74+
- Are propagated to full nodes as soon as they are formed
75+
- Can be part of a single block header corresponding to a "full block" with an updated state root
76+
77+
Full nodes will receive, and apply the transactions in these mini blocks to their state just like soft-confirmations, but will not treat them as finalized until the full block header is received and the transaction batches are seen on the DA layer.
78+
79+
## Detailed Design
80+
81+
### Systems Affected
82+
83+
- Sequencer node logic (mini block formation and streaming)
84+
- Full node p2p logic (mini block reception and handling)
85+
- Full node batch validation logic (block header linking to multiple batches instead of one)
86+
87+
### Data Structures
88+
- **MiniBlock:**
89+
- `mini_block_id`: Unique identifier (e.g., sequencer address + timestamp or a sub-block height like 1.2 for mini-block 2 as part of block height 1)
90+
- `txs`: List of transactions
91+
- `timestamp`: Time of mini-block formation
92+
- `sequencer_signature`: For authenticity
93+
94+
### Proposed Modifications
95+
96+
#### Sequencer
97+
98+
- Introduce a mini-block time in addition to block time that's much smaller than the block time that controls the rate at which transactions are reaped to produce mini-blocks are produced.
99+
100+
- Reuse the current channel for p2p batch propagation for propagating mini-blocks instead.
101+
102+
- Modify the header produced every regular block to link to all the mini-block transactions applied in that header.
103+
104+
#### Full Node
105+
106+
- Receive mini-blocks instead of one batche per header.
107+
- Apply the mini-block transactions to the execution layer
108+
- Modify batch validation logic to mark a regular block DA included only when all mini-blocks associated to the header are verified as published on the DA layer.
109+
110+
## Status
111+
112+
Proposed
113+
114+
## Considerations
115+
116+
Mini-blocks could be made optional and more opt-in by full nodes as well if we don't replace the existing p2p channel used for batch broadcasting and were to use a separate p2p channel/topic.
117+
118+
### Additional Considerations
119+
120+
1. **Network Impact**
121+
- Bandwidth usage monitoring
122+
- Peer connection management
123+
- Network congestion handling
124+
125+
2. **State Management**
126+
- Memory usage for pending mini-blocks
127+
- Garbage collection of obsolete mini-blocks
128+
- State sync optimization
129+
130+
3. **Backward Compatibility**
131+
- Support for older nodes
132+
- Gradual rollout strategy
133+
- Fallback mechanisms
134+
135+
## Consequences
136+
137+
### Positive
138+
- Faster transaction propagation and improved UX
139+
- No impact on consensus or state safety
140+
141+
### Negative
142+
- Slightly increased p2p bandwidth usage
143+
- Potential for spam if not rate-limited or authenticated
144+
145+
### Neutral
146+
- Requires more sophisticated peer management
147+
- Could impact network topology design
148+
149+
## References
150+
151+
- [Base Flashbots/Flashblocks](https://flashblocks.base.org/)
152+
- [Rollkit Single Sequencer ADR](./adr-013-single-sequencer.md)
153+
- [Solana P2P Shred Specification](https://github.com/solana-foundation/specs/blob/main/p2p/shred.md)

0 commit comments

Comments
 (0)