Closed
Milestone
Jan 8, 2024–Mar 15, 2024
Etherlink: sequencers
This is a sub-milestone of %Etherlink: road to Mainnet, dedicated to sequencer efforts.
Most work planned for %Etherlink: road to Mainnet has been carried out. Check the milestone to understand how it's continued.
Work breakdown
Required for Ghostnet (since February 1, 2024)
Tasks
Delayed inbox
-
The sequencer consumes the delayed inbox-
Deposit -
Eth transactions
-
Kernel upgrades
-
Timestamp-activated upgrades on the kernel side -
Sequencer correctly switch to new kernel when necessary -
Sequencer detects when an upgrade will happen, and does not try to produce blueprints if its code is outdated @vch9
Migration for Ghostnet
-
A migration is implemented to introduce a sequencer for Ghostnet instance
Validation:
-
Successful upgrades of the Ghostnet instance with the Sequencer running
Required for March 15th
Delayed inbox
-
Store the “to publish” version to be resilient to rollup node outage -
Timeout period (after X hours max but not before Y blocks) -
Cost model for the delayed inbox -
For Eth transactions -
For deposit
-
-
More resilient delayed inbox-
Unification of executable and publishable blueprints -
More resilient rollup node to EVM node events streaming -
Forward of delayed inbox events downstream to observer nodes
-
Validation:
-
Existing tooling for deposit works with an Etherlink deployment with a single-node sequencer.
Kernel upgrades
-
The sequencer detects when an upgrade is required -
The sequencer and observer nodes support fetching new kernels without downtime (pre-images-endpoint
support) -
The upgrade process is resilient to bugs in the kernel in various stages -
Implement security upgrades logic
Validation:
-
Do an upgrade on Ghostnet using the governance contract
EVM observer
-
Import rollup node snapshot -
Sequencer streams blueprints to clients (stream RPC starting from a given level) -
Observer consumes blueprints -
Observer implements the JSON RPC API-
Everything except forwarding transactions to the sequencer node -
Forward transactions to the sequencer
-
-
The Observer node detects when an upgrade is required
Validation:
-
Explorer works with the observer node -
Etherlink infrastructure on Ghostnet uses an observer as a public endpoint
Leader changes
-
Improve key handling of the EVM node -
Add support for abase-dir
-
Add support for a remote signer !12173 (closed)
-
-
The kernel handles committee changes in the future (timestamp activated) -
The sequencer handles committee changes in the future (timestamp activated) -
Deal with setup for the first sequencer operator -
We can revert back to no-sequencer mode -
The sequencer stops when its period ends
Validation:
-
Leader change on Ghostnet
Fee model
This worksteam is co-owned by construction with the fee model crew.
-
Measure the average gas limit allowing a sequencer node to inject blueprints on the L1 without lagging behind
Observability and monitoring
-
Grafana dashboard -
Logging on par with what the Octez and Rollup node do
Hardening
-
Reproducible build for Etherlink kernel (maybe not part of this crew in practice) -
Resilient enough publication of blueprints -
Reduce the storage failsafe scope at the level of the block -
The sequencer node detects when it goes out of sync with the rollup kernel, and stops publishing blueprints -
Tick model for stage-1 code @picdc -
Realistic scenarios -
Downtime for sequencer -
Sequencer missed delayed inbox -
Leader changes -
Stress-test
-
After March 15th
Hardening
-
Lift current restriction that the sequencer is the only one being able to publish blueprints -
Blueprints are versioned and the sequencer can use the correct version when necessary -
Better logging of the kernel -
The sequencer starts when its period starts
Open questions
- What happen to overdue messages in the delayed inbox? in case a committee member is down for instance.
- What is the complete design of the distributed sequencer / the architecture of the whole system?
- What is the complete fee model (especially regarding the sequencer operators)?
- What are the guarantees provided by the current governance model? (Easy to do it wrong.)
- What is the plan for MEV-protection? What is the actual definition of fair ordering? A proposed plan is outlined here: MEV Protection For Etherlink’s Decentralized Sequencer.
- How to deal with reorgs induced by the consensus used by the distributed sequencer?
- Should we support transaction filter RPCs for observer EVM nodes (also known as RPC nodes)?
-
eth_newFilter
,eth_newBlockFilter
,eth_newPendingTransactionFilter
,eth_uninstallFilter
,eth_getFilterChanges
,eth_getFilterLogs
.
-
- What are the properties expected from the sequencer with regards to the rollup node? How can we convince ourselves that they hold?
- For instance, do we expect that the rollup node can always apply a blueprint produced by the sequencer?