Settlement
N1's settlement layer provides the minimum necessary functionality to host execution environments and ensure data availability. The new primitive we provide is unordered set replication, with a hybrid storage model that stores both ordered logs and unordered sets. Before explaining what these concepts mean, let's start with an illustrative example. Suppose we want to run a zk-rollup on N1 that provides an Ethereum Virtual Machine (EVM). We also want to be able to bridge assets in and out from N1. To prove to our users that we are acting honestly, we need to, for each Ethereum L2 block:
- Ensure transaction data is downloadable by all users.
- Construct and verify a SNARK proving correct execution of the block.
- Show that asset bridging was done correctly.
To do so, we'll use broadcast primitives provided by the network. The steps taken for each block by the operator are as follows:
Broadcast transaction data
The operator broadcasts the current block's transaction data to the data availability network. The data is erasure coded so that it can be efficiently sharded across the validators. The amount of client bandwidth used is then proportional to the size of the block for maximum efficiency.
Collect data availability proofs
From here on, the network will continuously ensure data availability. During broadcast, the operator constructed a commitment to the data. This commitment binds us to the data and allows for verification and recovery. We include this commitment in our state transition proof. Any other client is able to fetch and verify the data.
Execute the block
We run the block in the zkEVM, which produces a receipt proving that the transition was correct and that the block data matches the data availability commitment. This is important as it binds the receipt of the execution to the data availability from the network.
Verify and sign receipt
The operator again broadcasts the zk proof and requests it be verified and signed by the validators. These signatures are aggregated into what we call a state transition certificate. While verifying, the validators also check the zkEVM's receipt to validate the data availability commitment and ensure the fork choice rule is respected. This prevents the operator from pushing invalid blocks. Only >2/3 of the validators are required to sign the certificate.
Submit certificate to the network
Finally, the operator broadcasts the certificate to the network. Each validator checks the signature against the current validator set, and if it's correct, stores it. This certificate can be fetched and verified by any client. This write has no ordering constraint with writes by any other clients, hence why we say we're writing to an unordered set. The certificate also contains a list of withdrawals. The withdrawals are pushed to the operator's outbox and the operator's account balances are updated accordingly.
This is all that's needed to construct a rollup for the EVM. You'll notice that at no point do the validators need to do the typical 2 phase commit protocol, which has a quadratic number of messages exchanged. Instead, the operator is analogous to the leader and handles the 2 phase commit. The number of messages is linear in the number of validators, and the latency is constant. More importantly, no other client is blocked from making progress. The key primitives we need are various variants of broadcast. Specifically:
- Certifying and store a state transition certificate.
- Ensuring avalability of arbitrary data.
- Bridging assets in and out of an operator-owned account.
The only step that needs full ordering is the last one, for bridging. Given that almost all operations remain within the L2, contention between applications is minimal.
Liveness
In a single-operator setting, how do we ensure liveness? The operator could always go down or refuse to construct any new blocks. The solution lies in the ability to use the L1's blocks as a clock. The L1 can act as an inbox for forced transaction inclusion, and also to enforce that the operator stay live. Governance can be used to take over the operator and force withdraw remaining funds. Additionally, we place no constraints on how the operator is run. It may be run as a decentralized set of nodes as well to provide additional liveness guarantees.
Bridging
The network supports the necessary verification primitives to construct bridges. We provide a native IBC bridge to Solana and Ethereum. Assets are bridged in specifying an operator owned address and VM-specific metadata indicating how to route the asset within the VM. The N1's log holds an inbox of bridged assets that the operator consumes. Similarly, for bridging assets out, the operator pushes messages to the outbox which are enforced by the state transition function.