Becoming stage 2 and adopting multiprovers - a proposal

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.

25 Likes

i agree and i believe in this

2 Likes

wonderful, i keep bullieving

1 Like

I concur. Becoming a stage 2 zkEVM will allow Linea be more secure and comparable to Layer 1, help us achieve near-full EVM compatibility, and the ability to use existing developer tools and infrastructure, incluing faster prover times. I’m all for it. GLinea-BIS

1 Like

all of the above doesn’t look bad

I agree with Linea becoming stage 2. However, I think the validator set of 5 nodes is too lean for full Decentralization.
Well done.

1 Like

i agree and i believe in this

1 Like

This is a solid, practical roadmap. First, we shore up security with our main prover and a responsive TEE check, so any bad proof instantly pauses the chain. Then we layer in a diverse 5-node validator set plus a zk-prover, requiring multiple confirmations before finalizing. I think this is a stepwise plan that tightens safety without killing performance, and it paves the way for true decentralization. Great work Guys! :+1::+1::+1:

2 Likes

I am all for it. Make Linea the best it can possibly be. Thanks, appreciated.

retaining a 6-of-8 multisig threshold (or stricter)

1 Like

To enhance the security and decentralization of Linea, particularly in the second phase, it is proposed to complement the multiprover architecture (Linea prover, TEE, validators, zk-proofs) with a hybrid system for validator monitoring and management. This system will combine:

A reputation model to assess the reliability of validators.

A transparent validator selection protocol using random selection and staking.

A public audit mechanism to track validators’ actions and detect anomalies.

2 Likes

The proposed security improvements to Linea are both pragmatic and forward-thinking, addressing the critical need for robust security without compromising operational efficiency. By adopting a phased approach, the proposal carefully balances enhanced protection with cost-effectiveness, which is essential for maintaining Linea’s usability and reliability.

The introduction of the multiprover architecture significantly strengthens the security of the rollup by leveraging diverse cryptographic schemes and implementation languages. This diversity ensures that a single bug or vulnerability does not jeopardize the entire system, thereby minimizing the risk of state-size attacks. Moreover, the combination of different proving systems (e.g., zkEVM, TEE, validator sets) fosters resilience by distributing the burden of verification across multiple independent entities.

The inclusion of TEE-based soundness alerts in the initial phase is particularly commendable. It provides a low-latency, cost-efficient mechanism to detect anomalies without impacting availability. This proactive measure serves as an early warning system, enhancing trust and transparency among Linea users.

In the subsequent phase, the introduction of a validator set with multi-client support and the use of a zk proving system reflect a strategic commitment to decentralization and long-term sustainability. This design not only fortifies security but also lays the groundwork for gradual decentralization by allowing permissionless participation from a diverse validator set.

Finally, the proposed approach maintains a clear focus on cost management and operational feasibility, leveraging fast and economical solutions (like TEE and PoS) while progressively integrating more computationally intensive proving mechanisms as their performance improves.

In summary, the proposal demonstrates a thoughtful, layered approach to enhancing Linea’s security, prioritizing both immediate protection and long-term decentralization. This balance between security, cost-efficiency, and gradual adoption of advanced proving technologies makes the proposal highly viable and beneficial for the Linea ecosystem.

1 Like

Hi Florian,

First of all, thanks for sharing this multiprover roadmap in such detail.

TL;DR
Instead of stopping the rollup indefinitely when a faulty proof appears, have the bridge contract run a simple log₂(T)-round bisect game plus a single-step checker to automatically determine which side is correct; slash the losing party’s bond and finalize the correct state root.

At the initial stage, the chain is updated instantly with the Linea prover’s proof; the TEE, validator set and secondary zk-prover only sound an alarm when they detect a mismatch. When that alarm is raised the entire system stops and waits for human scrutiny. Although safety is not compromised, the long wait damages user experience and turns the question “who is right?” into a social debate.

To remove this uncertainty I propose adding to the bridge contract a very small dispute game that advances in logarithmic steps. Even if this mechanism does not ship with Stage 2, it is a natural candidate for the very next upgrade. The party that submits a different root puts up a bond; the contract then forces the two sides to narrow the interval in turn until it identifies the exact step in the transaction list where they diverge. At the final step a miniature execution circuit—specifically a micro-slice of the existing gnark circuit that verifies only that single transaction—computes the correct post-state. The faulty proof is exposed automatically, the loser’s bond is slashed, the correct root is finalised and the system carries on.

This addition does not alter the chain’s security model it strengthens liveness instead. Even in the worst case any outage is limited to minutes and no manual decision is needed. The extra code is confined to three or four functions, and the checker reuses logic already present in the provers, so no new trust assumption is introduced.

There are, of course, considerations to keep in mind. If starting a dispute is too cheap it could be abused for gas spam, so the bond must be high and a dispute should be accepted only when it is backed by a secondary proof. The gas cost of the single-step checker must be measured in advance; for large batch sizes it must not exceed a reasonable fraction of the block gas limit. The circuit should be continuously cross-tested against the TEE and at least one independent client so that no interpretational drift arises between them. To prevent a malicious actor from deliberately stretching response times and stalling the system, the time allowed in each round should be progressively shortened and silence should be treated as defeat.

The safest rollout is to activate the dispute game in “shadow mode” alongside the Stage-2 upgrade, gather real conflict data and tune the parameters in the field. When the rate of disagreements approaches zero the mechanism can be made mandatory. If the bond size is chosen as a meaningful percentage of total bridge value and the timeout windows are set dynamically according to L1 block-time volatility, the chances of wrongful slashing or unnecessary pauses fall to an absolute minimum.

Linea Stage 2 - Cool!

When on L2Beat? :]

great! keep build

good read!

Awesome!!!

Quite Awesome.

linea is recruiting for two key positions in preparation for the upcoming TGE.