Relay Network and Fee Market Proposals

The phase 2 design space is large and has seen a number of different proposals for handling execution. Each proposal also brings with it a potentially different way of paying fees, along with a different mechanism for transactions to be relayed from user to block proposer. This section will attempt to provide a concise but nonetheless comprehensive summary of the different proposals and analyze the behavior of the relay network and fee market for each.

Collator-Proposer (Retired)

Early proposals that could lead to phase 2 saw the separation of shard chain block production into three distinct set of actors: proposers, collators, and executors. Proposers would be responsible for collecting transactions into blocks (collations), proposers would be responsible for proposing a particular collation extend the canonical [shard] chain, and finally executors would commit to a new state root based on the proposed collation.

This proposal was never fully fleshed out; as such, research into fee payment mechanisms was not conducted. It was retired as, among other things, the incentives of the system encouraged actors to be proposers, collators, and executors at the same time in order to maximize their rewards.

Phase 1 and Done

The turn of the year 2018 saw the rise of using scalable blockchains as data availability layers, with a base layer providing high-throughput global data availability for second-layer execution engines, such as zk-rollups (and later optimistic rollups). Unfortunately, initial suggestions that Phase 1 (sharding, with data blobs sans any execution) be useful as a data availability layer for e.g., Eth 1.x while waiting for Phase 2 to be deployed, turned out to fall short; a separate execution layer can’t actually access the data (giving Eth 1.x oracle access to all shard data would be equivalent to it having very large data-only extension blocks), and bridging it over would be no different than simply including it in the execution layer in the first place!

This was highlighted by Casey Detrio in his seminal post Phase One and Done: eth2 as a data availability engine. The post notes that shards in phase 1 can be used for bridged data availability without state sharding, by adding only minimal execution sharding. In this scheme, shards can 1) authenticate data (i.e., insert a list of transactions into an authenticated data structure such as a Merkle tree) and 2) perform simple stateless execution, such as verifying a zero-knowledge proof against authenticated data.

Defining the programs that would be used to process the data blobs is done by uploading contracts (which would later become “precompiles” and then “execution environments”) to the beacon chain. Contracts would presumably be client-interpretable bytecode, the exact choice of which is orthogonal to the whole of the proposal.

This “phase one and done” mostly sidestepped the fee payment challenge, as it was a challenge with previous proposals and remained a challenge for subsequent proposals, instead choosing to focus on laying out the minimal changes needed to make Eth 2.0 sustainably useful in as short a timeframe as possible. There was one suggestion in passing to pay fees using a contract on Eth 1.x (i.e., have the rollup contract pay shard block proposers on Eth 1.x for including a data blob on Eth 2.0 with bridged processed data availability). While certainly doable, this would inextricably tie Eth 2.0’s usability to Eth 1.x’s survival in perpetuity.

Phase 2 Proposal 1

Following Detrio’s “phase one and done” proposal, Vitalik Buterin revealed a new concrete proposal for phase 2 in his phase 2 proposal 1. In this proposal, execution scripts (initially called “beacon chain contracts”) live on the beacon chain. Ether never leaves the beacon chain, instead being deposited into execution scripts (in order to pay fees). Each shard has its own completely independent state and execution.

Note that contrary to what their name would suggest, execution scripts define the virtual machine with which to execute transactions, and are not smart contracts as we’ve seen deployed on Ethereum to date. The data model and opcodes must be fully defined by the execution script in some client-interpretable, metered, code (e.g., ewasm).

For the purposes of fee payments, each execution script is essentially a layer-2 system, with their own internal fee-paying mechanisms that shard validators don’t “understand.” This obliviousness is Actually a Feature™, as requiring shard validators to be able to parse and account for a different fee mechanism — and potentially a different currency — would lead to enormous implementation and economic complexity along with exploitation vectors, to the point of being unusable. In large part, the same arguments against economic abstraction hold against execution script-specific fees.

As validators can’t collect fees from within an execution script, they need to be paid externally to it. This is accomplished with a special (i.e., enshrined) execution script, in which anyone may post a transaction to the effect of “if this data blob for this execution script on this shard at this slot is included, I’ll send the includer a payment.” These actors are relayers (originally called “operators”), and are responsible for collecting user-transactions for the non-enshrined execution scripts, each paying them an execution-script-specific fee, and paying shard block proposers (producers) for including this blob through the enshrined execution script.

An excellent summary of phase 2 proposals up to this point was compiled by William Villanueva in his post: A Journey Through Phase 2 of Ethereum 2.0.

Phase 2 Proposal 2

Drawing inspiration by Detrio’s earlier work, Buterin’s second proposal for phase 2 further simplifies the first proposal by removing state from shards and instead using the beacon chain to keep track of shard-specific, execution environment (EE, previously execution script)-specific state roots.

This has the benefit of allowing EEs to specify their own accumulator format (e.g., a Sparse Merkle Tree, a red-black tree, a cryptographic accumulator, etc.), rather than needing to enshrine a specific accumulator format as with previous proposals.

The general transaction flow would now look like this: users craft transactions and send them to relayers. Relayers add witnesses (in the form of Merkle branches, if a Merkle accumulator is used) in exchange for fees from users in an unspecified manner, and package multiple transactions together. Relayers would send these packages to block proposers, paying them an in-protocol fee for including this package in the next [shard] block. This in-protocol fee, as with proposal 1, is paid through an enshrined EE that all validators are required to understand.

While this scheme is certainly a step up in terms of ease of being a validator, as only minimal shard state is required, the lack of an in-protocol fee payment mechanism from users to relayers does not alleviate the relay network issue. Firstly, using an out-of-band payment scheme reduces users privacy. Second, it is not obvious how to create an entirely off-chain system (that does not rely on another, external, blockchain) that guarantees that users receive appropriate witnesses and relayers get paid for providing the required witnesses, atomically. Third, the potentially high friction of out-of-band payments and high computational requirements of being a relayer (as relayers must have all state for the EEs and shards they wish to serve, in order to be able to generate witnesses) can be a centralization concern — with only a few “gatekeeper” relayers between the users and the Eth 2.0 network in the worst case.

Bring Back the Mempool

Rather than having relayers pay block proposers conditionally, which would require non-trivial double-commit-reveals schemes to ensure atomicity, a new proposal emerged by Buterin: one fee market EE to rule them all. In this proposal, EEs themselves would have balances. When executing a package of user-transactions, the EE will output a receipt, which can then later be consumed by an enshrined fee-payment EE to transfer Ether balance from the EE to the block proposer. The fee-paying EE would thus be able to “lookback” and previous receipts to process fee payments. Topping up the balance of the EE would presumably be the responsibility of the relayers (or some otherwise interested party).

This proposal has the benefit of not requiring a complex scheme to negotiate payments between relayers and block proposers. However it still does not address how users interact with relayers, instead opting to suggest payment channels be used.

Building upon the original proposal, Villanueva then suggested bringing back the mempool. Here, relayers take on a reduced role as state providers, being responsible only for providing witnesses but not packaging user-transactions. Block proposers (or, more generally, shard validators) maintain a mempool and merge witnesses to create their own packages. Given that each EE could use a different accumulator format, the EE will need to specify a merge method that block proposers can use to merge two or more witnesses together, e.g., multi Merkle branches into a Merkle multi-proof.

As state providers only need to provide witnesses (usually in the form of Merkle branches), there is a group of actors that are perfectly suited to provide this service already: light client servers. By encouraging more light client servers through better tooling and reduced costs, this does a long way towards preserving permissionlessness. However, the use of high-friction payment channels for users to pay state providers remained a pain point.

Alternate Phase 2 Architecture

More recently, Buterin published an alternate phase 2 architecture proposal, which makes shard completely stateless. The key different here is the additional of a full, stateful, expressive, state transition engine (e.g., the EVM) in the beacon chain. This engine acts as a “scheduler,” keeping track of EE state roots. The scheduler also allows for multi-shard execution: it can inspect shards and slots in a deterministic order, ensuring that multiple transactions across multiple shards to the same EE are executed correctly (by weaving pre- and post-state roots, ignoring any shard blocks that are invalid or out of order).

The fee payment mechanism for this proposal is largely unchanged compared to the previous one, though a fee-paying EE is not needed as the scheduler has enough expressivity to handle managing EE balances and consuming receipts natively.

Shard Chain Simplification Proposal

At DevCon 5, Buterin unveiled a major refactoring of the Eth 2.0 sharding architecture, drawing inspiration from Near’s Nightshade “shard chunk” design. In this new proposal, rather than each shard chain maintaining its own separate fork choice rule, with faster blocks and crosslinks being formed in a staggered manner, shard blocks are produced in lockstep with beacon chain block, and all shards are cross-linked every beacon block (in the normal case). To accommodate this increased number of shard crosslinks over the previous architecture, the number of shards was decreased to 64 from 1024 and the throughput of each shard was increased somewhat to keep the overall system throughput close to the same.

Fee markets are made simpler by virtue of a fundamental change in mindset: thanks to the vastly reduced shard count, cross-shard communication is simpler, and it’s no longer an issue for users to hold ether in each shard to pay transaction fees directly to block proposers (again through the scheme of EEs outputting receipts). By removing one half of the fee market issue, only the relayer network (i.e., state provider) challenge remains.