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 a base-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?