Special credit to Nicolas Liochon who shared the document used as the base of this blogpost.
Blockchains and L2 can be targeted by state-size attackers with the capacity to bribe and blackmail developers, operators or auditors to introduce bugs in the software.
An ethereum client is a complex and ever evolving component. Proving its proper execution is even more complex.
The prover role is central to the security of a rollup. If proving the correct execution of a rollup is the most complex part, it is not the only one: other aspects including data availability, data compression, and L1<->L2 messaging must also be proven.
Centralization is a simple training wheel where the control of key components by a trusted entity provides safety guarantees. However, this is a transient state, and decentralization requires solutions to remove any trust assumptions. Such solutions cannot be exclusively based on economic guarantees as for instance based rollups allow permissionless sequencers with nothing at stake. In this post we explore technical solutions that could be put in place to first have Linea reach stage 2, and second make it even more resilient to attack to its prover.
The multiprover is a well known improvement where each rollup state update is proven by multiple provers, and each one of these provers is efficient, production proven, and uses a specific cryptographic scheme different from the others, in an implementation language also different from the others. This increases security dramatically –a single bug cannot be exploited, you need to find zero-day bugs at the same time on different provers–, as well as availability –a single bug does not prevent state updates–. The zkEVM world is extremely dynamic, and this is not out of reach at all. Linea builds a very efficient EVM arithmetization, and a very efficient prover leveraging lattices. Kakarot has a very different approach, and builds its zkEVM on top of Cairo. Polygon builds the Plonky3 prover, and this prover is used in SP1. Both risc0 and SP1 uses risc-V as an intermediary architecture. If these solutions are in constant evolution and are at this stage moving in real time, proving is still computationally expensive and slow.
While we don’t have everything, we do have some tools available to us:
- Linea supports multiple clients (besu, geth, nethermind, erigon, etc.) that can be used to verify the execution.
- Automata implemented the support of Linea (execution and state) in a TEE (Trusted Execution Environment)
- SP1 can prove Linea execution, and Risc0 plans to support it too.
In this post, we explore some potential solutions to make Linea a stage 2 rollup and increase its security without noticeable impact on its availability, with the following design for rollup state updates.
In a first phase, to provide stage 2 guarantees, we propose the following approach:
- Linea prover as the main component, the state being updated when a proof generated by Linea prover is posted.
- A permissionless solution, to reactively raise soundness alerts with a TEE.
In a subsequent phase, to further increase Linea’s security:
- Linea prover remains the main component. The state cannot be updated without a valid proof from the Linea prover.
- We require two additional proofs from validated mechanisms including TEE proofs, zk proving system or validation committee with proof-of-stake or delegated-proof-of-stake.
This proposal allows to increase Linea’s security while keeping its operational cost low. Indeed, a TEE or a PoS system is very fast and cheap to run. Full zk-provers are more expensive and slower but their performances increase constantly.
Current Finalization process
New blocks are created by Linea’s sequencer. On a regular basis, data required to rebuild Linea’s state is posted on L1, and a finalization proof is computed and as well posted on L1.
This finalization proof is computed by Linea’s prover and validates that the block was produced by the proper sequencer, the state transition was correct as per the EVM specification and that the data posted on L1 matches the data of the block used while generating the proof.
This guarantees that Linea is hard to hack, but against a state level attacker, it can still fall short. In particular, a state could corrupt or blackmail some team members, to introduce a security issue in the proof system and then hack the computers used to sign the online transactions.
Analysis of the proposed security improvements
The proposal covers the finalization part. It’s independent of the block generation process. It is already applicable with a centralized sequencer as is Linea running today.
In the first phase, we enhance the finalization process, with
- Linea’s prover;
- A TEE;
The state is immediately updated when Linea’s proof is posted on L1.
TEE proof is posted when it diverges with Linea’s proof, with the effect of pausing the rollup.
Compared to the current solution, it ensures that the only updates to the rollup are either properly announced in advance or updates to fix bugs, decreasing the risk of security issues being intentionally added and exploited by malicious actors.
This will also allow Linea to become stage 2.
Once Linea becomes type 1, in a second phase, we upgrade the multiprover architecture with
- Linea’s prover;
- A TEE;
- A validator set, with 5 nodes, and a 3 out of 5 policy. Each validator runs a different client (besu, erigon, nethermind, geth, reth).
- A zk proving system
To update the state immediately, we require:
- a proof from the Linea prover (always required);
- two proofs out of the three other provers
The state is updated after a configurable delay if we have:
- a proof from the Linea prover (always required);
- and one proof out of the three other provers.
- No diverging proofs
Technically, the Linea operator continues to update the state. The other validators call the smart contract once the state is updated to confirm the data is available and the state is correct.
In case two validators disagree, the state update is paused until all the validators have posted their proofs and that three out of four are matching.
Compared with traditional N out of M consensus schemes, the linea prover has a specific status and is always required, all the other (“secondary”) provers/validators are necessary for an immediate update (like if N == M) and finally if two of the “secondary“ provers is missing the liveness impact is bounded in time.
Rationale
Our staged proposals allow us to incrementally improve Linea’s security guarantees while keeping the costs and the latency under control.
The different phases will allow onboarding the new mechanisms in the finalization process as they mature both in terms of cost and time efficiency.
Waiting for Linea to be type 1 also limits the customization of the proving system, hence reducing the cost of development.
A guiding principle is to have a pragmatic approach that will allow added security in the short term hence delivering value for Linea’s users. TEEs state validation is implemented, lowering the risk of a safety issue at the implementation level. Adding a validation committee is easy, and we could leverage Linea multi-client capabilities. The validator set can be permissionless with staking and leaking. In other words, this mechanism can become the first component of the future sequencer’s decentralization. This will allow anyone to participate in Linea’s validation.