Outline of the Spacemesh VM Design

Note: This design is still a work in progress, and will be subject to changes and refinements in the future. 

Design Goals

1. separation between core consensus role and VM execution role 
2. built-in rollup to improve on existing solution 
3. due to resource constraints, we prefer not to write our own vm

Separation between core consensus and VM execution

It’s better that full-node miners aren’t forced to perform the demanding smart contract VM execution, and this job is done only by “executors” who want to be rewarded for the VM execution work:

• This is particularly important with mesh and spacetime, which already make the core consensus job more demanding relative to chain and PoW/PoStake

• Transaction fees are paid only to the current set of miners that include the transaction into the network, but the cost was borne by the entire network long-term

  • The current set of L1 miners may tend to accept transactions at low cost to maximize their short-term revenue
  • But future L1 miners also need to endure these transactions’ execution cost

• It’s better that L1 miners neither execute nor get rewarded for VM execution

• End-users who wish to perform only simple coin transfers (non-VM transactions) won’t need to bear the cost of rewarding the executors

Not From Scratch

We prefer to use existing off-the-shelf components (e.g., EVM), both for compatibility with popular ecosystems and because we lack the time to develop this in-house.

Built-in Rollup

Since we are building from the ground up, we have the opportunity to improve upon three main problems of current L2 rollups:

1. centralized sequencer
   • All existing, production-ready rollup solutions use a centralized sequencer - a single party that everyone sends the transaction to. Though this sequencer cannot fabricate transaction data (because the L1 smart contract enforces the rollup rules) there are inherent problems with censorship and being a single point of failure w.r.t. blockchain liveness.
2. shardedness (loss of composability)
   • in the current L2 ecosystem, each rollup writes their own sequencer and lives in separate universes. each sequencer has its own internal state. one app in one shard/rollup cannot easily communicate with another app in a different shard/rollup. communication between these centralized sequencers are inefficient and costly, costing them network effect.
3. costly and slow to move funds in and out of rollups

One major property of our built-in rollup approach is that each VM transaction by a user is added directly into the L1 ledger (a.k.a. mesh) and the L1 miners earn a small fee (paid by the user) just for the storage cost of the transaction.

• By contrast, in L2 rollup the user’s transaction is broadcast to a separate L2 network and later some L2 sequencer will need to batch these transactions and add all of them to L1 (if it’s fraud-proof rollup), or at least add the delta of the state update (if it’s validity-proof rollup, unless the L1 data availability guarantee is sacrificed)
• This batch is an unnatural way to make use of L1, because the L2 sequencer needs to pay a large fee to L1 miners for the batch, which entails a rollup design in which the users pay extra fees that are passed on in order to reimburse the sequencer.
  • Because the L1 gas cost is volatile, the users are highly likely to be overcharged
• Non-naive L2 network (that doesn’t rely on a centralized sequencer) needs to run its own consensus protocol that’s incentive-compatible, so that the sequencers will indeed include valid transactions of end-users.
  • Such a rollup needs to support L1 forced transactions, otherwise users’ funds may remain locked at the mercy of the L2 sequencers.
  • Our approach doesn’t involve a separate consensus protocol for the rollup, nor forced transactions, because all transactions are added directly on L1.
• The rules of non-built-in L2 rollup must be enforced by the L1 VM rather than the L1 consensus layer (because L1 is unaware of L2).
  • This means that the cost of executing these rules is amplified.
  • For example, if the sequencer needs to provide VRF eligibility proof to show that it’s her turn to submit a rollup batch, then the VRF unique signature (ECVRF or BLS) needs to be verified via VM instructions of the underlying L1 system.
  • Some rules may need to be enforced only in an unhappy flow, i.e., when there are no disagreements in the separate L2 network.
    • Still, there can be griefing/rational attacks by competitors.
      • Especially if the L2 rollup market cap is high.
    • This is likely to imply insurance fees that are passed on to the end-users.

Proposal

we want to separate the selection of transactions and the cost of storage from the cost of executing these transactions and calculating the correct state after the execution, so that 

miners can just analyze the storage cost without having to perform the execution. This is a little similar to existing rollups that take a large batch of transactions and commit it to the blockchain as an opaque data blob with some kind of succinct proof or commit hash, while leaving it to the blockchain to handle the storage (data availability).

Our approach is to have one canonical “enshrined” rollup with decentralized sequencers who decide which transactions to put into the blocks. We describe this as “L1 with rollup”, meaning that the rollup is built into the core consensus protocol:

• the input transactions for the rollup are decided by the same miners/sequencers that select non-VM transactions
• the VM execution is done by separate executors who earn gas fee per VM instruction that gets executed
• The result of the VM execution can be easily parsed by all the L1 miners   

Roles

we propose 2 separate roles in the network

• miners/sequencers 
  • transaction selection based on conservative state
  • security requires honest majority
• executors
  • Not necessarily miners
  • executes VM transactions, calculates state transitions, and generates proofs to this effect.
  • security requires at least one honest executor (1-of-n trust model)

Having a separate executor role that executes the smart contracts transactions, interacts with the core consensus, and determines the state after the execution relieves the miners of the extra work. The miners only need to know that the reported state that’s reached is valid, and not how it’s reached.

Decentralized sequencer/miners also allow us to be censorship resistant:

• Users just need to send the transactions to the L1 miners and pay for the storage and mining fees in order to guarantee that the transaction will be executed
• However, the user must pay executors an extra fee (according to the gas cost of each VM instruction that gets executed), otherwise the decentralized rollup execution will determine that the transaction is aborted and won’t affect the resulting state.

L1 rollup that’s part of consensus:

There are currently two viable rollup designs

• Optimistic rollup
  • lower tech barrier than ZK
  • succinct (just a single hash commitment)
  • interactive fraud proof (with payoff taken from security deposit of sequencer/challenger)
  • Our variant doesn’t rely on finality (it has full self-healing capability, like our L1)
    • Each next rollup state is immediately usable on L1 (no finalization period)
  • Since our variant is built into L1, the job of the executors can be minimal in the happy flow (not more demanding than just executing the rollup transactions) 
• ZK rollup (validity proofs)
  • succinct with trusted setup, not so small otherwise
  • When a zk-proof is generated, the entire history (that it attests to) is guaranteed to be correct
  • proof generation is resource intensive / costly / slow
  • may not satisfy latency requirement
  • more sensitive to VM design (algebraic-friendly VM instructions are preferred)
  • Security deposit to deal with executors that don’t submit zk-proof after committing to a particular state
  • Doesn’t actually offer ZK/privacy (we may do privacy-preserving non-VM non-rollup transactions).

Challenges

Our trust model changes and requires a separate assessment for the rollup executors. In both optimistic and ZK rollups, we rely on at least one honest executor who’s incentivized to run the VM and compute the correct state. This job is demanding, so the protocol design needs to make it profitable for honest executors to participate.

With a ZK rollup, the work that generates the zk-proof has to be done on a high-end, multi-core server, and takes a significant amount of time. This implies that end-users will need to cover the cost of zk-proof generation, and will have to wait longer until their funds are available on L1 (i.e., until proofs are available). However, once the zk-proof becomes available, it is guaranteed to be correct forever (unless the relied-upon algebraic assumptions are broken). 

With an optimistic rollup, the executors’ cost is significantly lower and the transactions are cleared on L1 immediately, but the validity of the rollup output can always be challenged in the future (the confidence that the rollup output is irreversible grows over time, assuming that it’s rational for executors to follow the protocol).

The interaction between the rollup state and the base layer requires non-trivial protocol rules and development work (we cannot take off-the-shelf L2 rollup code for this interaction)

High-level Protocol Workflow

Mempool

at an abstract level, a transaction can be divided to an external and an internal transaction. 

there are two purposes of the external transaction:

• to store data on the chain
• to specify the amount of money to move from base to the rollup layer, if any

the internal transaction is opaque to the miner, and is parsed only by rollup executors.

based on the data of the external transactions and conservative state/balances, a miner selects transactions that can pay gas for storage, sorts them by some criteria, and builds a block proposal.

Hare

The hare protocol proceeds as usual and generates a block that contains transactions for both base and rollup layers.

Block execution

Given a block, miners execute the transactions for the base layer only and leave rollup transactions untouched.

Executors will process the base layer transactions (just like the miners), but also execute the VM transactions of the block, calculating the resulting rollup state, and post a commitment for this state transition. The base consensus protocol enforces rules that let miners determine which rollup commitment is currently respected (these rules are robust w.r.t. dishonest executors). Miners can then confirm withdrawals (from rollup to base layer) efficiently, depending on the rollup commitment that’s in agreement. In the ZK rollup case, the commitment for the state transition is followed by a corresponding zk-proof, which must be submitted before a (lengthy) deadline. Spending withdrawn funds on the base layer is forbidden while the zk-proof is pending.

In the optimistic rollup case, withdrawals to the base layer are available immediately, but prudent users may wish to wait for a higher confidence level regarding the irreversibility of the rollup commitment (their transaction fee will go to waste if a reversal occurs).

Account relationship between layers

The base layer account is controlled by the same identity (secret key) as the rollup smart contract account, though the smart contract address will be different in order to allow receiving funds directly in the rollup layer.

A smart contract transaction uses the base layer address to pay for storage fee with one signature, its calldata/methods are then interpreted on the rollup executors according to the VM spec.

We support a built-in transaction format that allows the user to have a rollup-only account, and enables account abstraction that’s efficient (single signature per transaction) without exposing the L1 miners to any new risks.