Tezlink: prototype two Etherlink chains on the same rollup

Context

This milestone is about exploring the possibilities to host a second L2 chain on the same rollup as Etherlink. To focus on the multi-chain aspect and keep interoperability questions for later, the second chain will also be an Etherlink chain.

The main takeaway we expect from this milestone is a better understanding of the design tradeoffs related to having a multi-chain rollup.

Currently, Etherlink runs on a technical stack composed of:

the EVM node which offers an Ethereum-compatible RPC view of the chain and implements the sequencer logic,
the rollup node, which publishes on the L1 and defends commitments,
the Kernel, which implements in Rust the validation and application of L2 blocks,
the WASM PVM, which makes kernel execution refutable.

When moving to a two-chain rollup, two extremes of the design space are full separation and full sharing of the technical stacks.

Full separation (Virtual rollups)

Full separation of the stack consists in defining a new kind of PVM in the protocol, in addition to the arith, WASM, and Risc-V PVMs we would have products of PVMs which can be used to host several guest rollups running on their own PVMs. The semantics of the product of PVMs A and B is to execute alternatively A and B; A is called on even ticks and B is called on odd ticks. The product PVM also handles message passing between the two PVMs (the outbox messages produced by one guest rollup and targeted at the other one are redirected to the inbox of the next L1 level). To run a rollup for a product PVM, one would need 3 rollup nodes; one for each guest rollup plus one for the host rollup. In our case, we would run a product of two WASM PVMs and on top of each WASM rollup node we would run a network of EVM nodes knowing almost nothing about the other chain.

In this setting, each Etherlink chain has its own governance and sequencer. The chains progress at independent pace. Communication between chains requires to wait for next L1 level.

Full sharing

Full sharing on the opposite consists in sharing as much as possible between the technical stacks; we would have a single PVM (the WASM PVM), a single kernel, a single rollup node, and a single network of EVM nodes. The component which needs to be aware of the existence of several chains are the kernel and the EVM node. There is a single sequencer for the whole rollup, we change the format of blueprints to group the operations by chain.

In the kernel, the distinction already exists in the storage (the /evm/world_state/ directory contains the chain-specific information and nothing more). Stage 0 and stage 1 are only about rollup features, only stage 2 must be adapted to make both chains progress. More precisely, the adaptation happens when turning a blueprint (a rollup notion) into a block-in-progress (a chain-specific notion). Currently, the main loop of stage 2 checks if a block-in-progress is stored and if not it builds one block-in-progress from the oldest available blueprint; with the adaptation, consuming a blueprint leads to the creation of one block-in-progress per L2 chain and this is done only when no chain has a block-in-progress in its storage.

In the EVM node, the configuration is reorganized to configure each chain independently. We launch one tx-pool worker and one RPC server per chain and to produce a blueprint, the sequencer iterates over all tx-pools.

In this setting, the resources (bandwidth, memory, CPU) of the EVM node and the rollup node are shared between the chains. Communications between the chains happens at the boundaries of L2 blocks.