Proposal - towards Linea’s decentralization

[Florian]

Special thanks to Simon Brown, Mikhail Kalinin, Roberto Saltini, and Nicolas Liochon for their contributions to the research summarized in this blog post and for their valuable feedback.

Our objective is to make Linea an L2 chain fully decentralized. We present below an overview of some important proposals towards this goal. It is a high level proposal, and the final implementation can possibly (actually is likely to) be different.

L1-Finality & L2-Finality

Blocks that are part of Linea’s canonical chain and whose finality is guaranteed by Linea’s sequencer(s) but not necessarily by the L1 are said to be L2 finalized.

Linea is anchored on L1 via a smart contract to which block’s data and execution proofs are sent. We say of a Linea block that it is L1 finalized if there is a proof that this block and its data have been successfully accepted by this smart contract and that the L1-block in which it was accepted is final.

Decentralization of the block validation

Block validation on Linea uses a distributed Byzantine agreement protocol where any node staking some minimum amount can participate. This means that L2-finality will transition from trusted to proof of stake.

To guarantee fast L2-finality, we use QBFT consensus protocol. Among the different consensus algorithms guaranteeing consensus under partial synchrony, QBFT was chosen to leverage its already existing implementation, cf the github repo /hyperledger/besu. Given QBFT is efficient with a committee that is not too big, we orchestrate the selection and rotation of validators forming the committee amongst all the ones available using a so-called outer protocol.

Any node can join the validator set by staking a sufficient amount. From this validator set, the outer protocol randomly selects a subcommittee which is responsible for running QBFT for a predetermined number of blocks.

The accountability feature of QBFT combined with the validators’ stake guarantees L2-finality. Indeed, from the properties of QBFT, if a node does not follow the protocol, then evidence can be collected to prove it. In such a case, the outer protocol stipulates that a proof containing the evidence is sent to the L2 validator set smart contract via a discard message, allowing to slash the identified Byzantine node. Part of the Byzantine node’s stake is sent to the sender of the discard message and the rest is burnt.

Note that Byzantine nodes could try to censor discard messages on L2. This is not an issue given the subcommittee rotates which guarantees that the discard messages will eventually be included.

Also, given the protocol is permissionless, it could happen that at some point in time, the QBFT committee contains more than a third of Byzantine nodes. In such a scenario, the committee could produce conflicting blocks or even invalid blocks. Note that by design, L1-finality is not impacted in such an event: a Byzantine set can impact liveness but not validity. As this behavior violates the protocol, other nodes can produce a discard message leading to slashing (and hence removing the misbehaving L2 nodes from the validator set) similarly to what is done in Gasper. The proper choice of the committee size and the total amount of stake each validator has to provide is important as it determines the L2-finality and liveness guarantees.

The outer protocol is also responsible to handle potential liveness issues. For this each subcommittee must ensure that the last block they have produced is available on L1. It allows the outer protocol to detect inactivity and to rotate stalled subcommittees.

The outer protocol combined with QBFT provides a permissionless protocol reaching finality in a few seconds in a partially synchronous network and with liveness guarantees as long as L1 is live.

Recovery mode

In the unlikely case where the validator set is empty, or all validators are inactive, the block production on Linea would stop. Linea L1 anchoring smart contract has a safety measure to recover from such a situation. After six months, if no block has been produced, any node can start finalizing. In this scenario, Linea would begin functioning in a manner similar to a base rollup.

Block proposer

In QBFT, each block is proposed by one of the validators which has the role of leader. We propose to externalize this proposer role from QBFT. Instead of assigning the block proposer role to a member of the validator set, it will be assigned to the winner of a dedicated on chain auction.

This mechanism gives the opportunity to any node to propose a block.

The auction is described in detail in ethresear in the post called A design for APS-burn in the context of a Decentralized L2. In a nutshell, it runs as follow:

For each block number n, there is an independent auction consisting of three phases:

• Sealed bid: from slot n-k to slot n-k+t, any node (or node with little stake, not yet decided) can submit a bid to a dedicated smart contract. This bid specifies the address that will propose the block and an amount signed by this address which represents the amount the proposer agrees to burn as part of the block that will be proposed at slot n.
• Buffer period: for a fixed number of slots from n-k+t to n-k+t+b, no bid will be accepted for slot n.
• Reveal: on the block n-k+t+b+1 following the buffer period, bids are revealed. The address in the message which made the highest bid is the only one who can sign a valid block for slot n.

The objective of having a sealed bid auction and a buffer period is to mitigate concerns around multi-block MEV. The parameter t used to determine the duration of the sealed bid phase has to be chosen large enough to avoid censorship of the bids.

Nodes can be block proposers with no or little stake which should favor decentralization and inclusivity, but these nodes might not be incentivized enough to wellbehave. We put the following safeguards in place to prevent block proposer to play timing games:

• all the proposals for a block height must be unique. Any proposal will be ignored by the QBFT subcommittee if a given proposer proposes multiple blocks.
• QBFT subcommittee can vote on an empty block if it does not receive a proposal on time from the auction winner.
• in case there is no bid, the leader of QBFT is the block proposer.

Note that the effect of this auction mechanism is to capture part of the MEV that block proposer plans to get by burning some amount of token. Burning these tokens has a deflationary impact.

As a potential alternative to this mechanism to select block proposers, we still look at the progress of concurrent multi block proposals eg. the one described in the bitget post called Ethereum’s road to anti-censorship: BRAID and FOCIL, which one is better?

Finalization of Linea’s blocks on L1

The guarantees of the rollups properties are ensured by the use of ZK proofs at the time of Linea’s blocks are posted (process to which we refer to as finalization) on L1 whose high level process is as follow:
On one hand, multiple consecutive blocks are aggregated and posted on L1 using Blobs, and on the other hand execution, compression and aggregation proofs are generated and posted on L1. In order for the whole process to be cost effective, the blocks handled at once are selected so that once compressed they fit in one or multiple groups of up to 6 blobs.

This highlights that finalization cost is split in two categories: one for data availability which is driven by the cost of posting blob’s data on L1, and the other related to generating the proofs. On top of selecting the node responsible for handling finalization, the protocol allows to fairly determine how both categories contribute to the total cost.

To cover the future costs associated with finalization, each block proposer is required to provision some token at the time of block creation. Once the block is finalized, the actual price of data availability and proof generation are known and the provision associated with each block is used to cover the fees. Any leftover is refunded to the block proposer.

In order to select a node to perform the finalization at a fair price, a reverse auction is performed. This reverse auction happens on-chain and is handled by a dedicated smart contract. Any node can participate as long as it provides some stake. Participants bid for the price they propose to charge for the finalization. The winner of the auction is the participant with the lowest bid.

The scope of the finalization is the set of consecutive blocks that once compressed can fit in X6 blobs for some fixed parameter X (which is to be determined to balance latency and cost). In order to make the scope deterministic and to eliminate any potential dispute, each block proposer broadcast the blocks in their compressed form. The reverse auction terminates when the newly produced L2 block does not fit in this 6X blobs. The winner is the one who posted the lowest bid, and it becomes responsible for posting the blocks on L1 as well as performing the actual finalization.

Note that the winner can delegate proof generation to other actors. This part is not regulated by the finalization protocol.

In case the node which won the reverse auction does not post data or proofs in a timely manner, any other node can perform the finalization on his behalf. The first node completing it will get the reward. The stake of the faulty node is used to cover extra fees or burnt.

Once finalization happens, the real cost of data availability and proof generation is determined by taking into account the actual fees the node has paid to post data on L1, and the rewards it gets (which amount to its bid).

Note that given a ZK proof is either valid or invalid, for the protocol to be Sybil resistance, it is sufficient it provides liveness guarantees.

Reward allocation

To allow reward allocation to be decoupled from the consensus protocol, the validators are required to build a consensus state Merkle tree representing the different actions each participant has made, including votes and block proposals.

This Merkle tree keeps track of all activities validators are required to perform, and hence we can leverage it to compute the reward each of them is entitled to receive.

Each validator can then claim their reward asynchronously by providing some proofs on the activities they performed, the validity of their claims being checked against the consensus state Merkle tree.

One advantage of this approach is that no logic related to reward allocation needs to be added to the consensus layer or the execution layer.

[ivokub]

Very interesting proposal, thanks for writing it up!

As far as I understood the finalization flow, it would be something like this:

1. QBFT consensus chooses a committee for an epoch of many blocks
2. auction for producing a block within a committee
3. winner/committee leader(when no one bid) builds a block
4. block producer posts a reserve for L1 finalization (no bid yet, so need to use some default value)
5. finalization auction starts based on the block
6. finalization bids come in
7. at a cut-off the finalization auction winner is confirmed
8. finalization winner proves and posts blobs on L1.
9. upon confirming proof acceptance from L1 smart contract can post it to L2 finalization auction smart contract to receive the winning bid amount of funds
10. block producer receives the rest of reserve

How is the reserve what the block producer reserves for paying for the finalization cost (blob posting + computation) estimated? If the block producer can choose it arbitrarily, then it can choose it in a way that no one would bid for block finalization, effectively halting L1 finalization?

It would work if the initial default posted reserve would be high enough. Maybe we could have a finalizer-of-last effort who always posts a fixed finalization bid and hope there are more efficient finalizers driving down the cost.

Does the block producer also gather the transaction fees from the block or only the MEV? Are we certain that MEV fees are sufficient to cover the finalization costs?

And there is also the issue that the finalization auction contains many L2 blocks such that they fit into a L1 blob. This also means that the finalization bid must be distributed between many block producers, but as different transactions have different proving costs, then it would be difficult to distribute fairly between the block producers.

[Florian]

Hi,
Thanks for your interest in the post and your comments.

Your description of the flow is correct.

Regarding the reserve, you are correct, we need to have some initial value. It could be set by the DAO. The suggestion of a finalizer-of-last effort is also a good one as it would link the reserve value to an actual entity that could do the job.
This reserve value being high is not too much of a concern as in the end, the block proposer gets the unused part refunded.

Regarding the transaction fees, the protocol does not enforce anything. By decoupling the allocation reward from the block production, the reward policy can be set to give the fees to the block producer, or to another entity, or to them split them among multiple parties.

Regarding your last point, the finalization auction ends on the block just before the block which cannot fit in the X groups of 6 blobs. In order to compute the space each block needs, an idea is to have them propagated on the network under the format in which they will be stored in the blobs. This way there is no difficulty or ambiguity to know when the finalization auction ends.

Finally, regarding the cost to charge to each block proposer, one need to differentiate data availability cost and proving cost. In Ethereum roadmap there is a plan to align gas cost with the cost of proving. When (if?) this will be able to use it to estimate proving cost of each block by looking at the total gas of the blocks, data availability cost being charged based on the size of the block.

[ivokub]

Makes all sense, thanks.

Finally, regarding the cost to charge to each block proposer, one need to differentiate data availability cost and proving cost. In Ethereum roadmap there is a plan to align gas cost with the cost of proving. When (if?) this will be able to use it to estimate proving cost of each block by looking at the total gas of the blocks, data availability cost being charged based on the size of the block.

On this I would be a bit cautious, I wouldn’t be sure the gas cost would completely align with the proving cost. For some of the opcodes/precompiles the discrepancy currently is imo too big to align even with the current best state of art proving backends.

[Florian]

Indeed, current gas cost are not aligned with proving costs and we can’t use them as is. But if they evolve and get aligned, we will use them.

If it does not happen, we’ll have to introduce a pricing mechanism that reflects the actual costs. The challenge will be to make it simple enough and to preserve client diversity.

[drdnero]

Thank you for this. There are however, some areas I feel need more clarification or some improvements.

1. Validator Selection and Committee Size:

• More clarity is needed on how the committee size and validator stake amounts will be determined to balance finality, security, and liveness. What safeguards will be in place to prevent malicious actors from controlling more than one-third of the validator set?

2. Auction Mechanism and MEV Concerns:

• While the auction mechanism can reduce MEV manipulation, it may still lead to inefficiencies or over-reliance on wealthier participants (high bidders). Some additional checks or balances, like dynamically adjusting the sealed bid phase duration or considering alternate auction types, could mitigate potential exploitation or centralization.

3. Recovery Mode:

• The six-month inactivity period seems too long for the recovery mode to be triggered. Consider reducing this period or introducing more proactive measures to prevent an empty or inactive validator set before resorting to recovery.

4. Impact on Smaller Validators:

• Smaller validators might be less incentivized to participate given the high requirements (staking, block proposer auctions). While permissionless, the protocol might still indirectly favor larger players unless specific incentives or mechanisms are added to balance power disparities.

5. Governance and Upgrades:

• The proposal outlines how decentralization and block finality will work, but it lacks details on governance and how the community or validators will handle upgrades or changes to the protocol. Who gets to decide on upgrades, and how will disputes around governance be resolved?

6. Data Availability Costs:

• The proposal touches on managing costs for data availability and proof generation but leaves some uncertainty about the exact cost distribution. This might need further refinement to ensure long-term economic viability, especially as the network scales

Thank you and I hope to get a positive response.

[andreolf]

This is a well-written and comprehensive overview of the decentralization goals and mechanisms for Linea. I especially appreciate the detailed explanation of L1 and L2 finality, the use of QBFT for fast finality, and the outer protocol handling the validator set and subcommittee rotations. The mechanisms to ensure security, like slashing Byzantine nodes and the block proposer auction, provide a solid framework to minimize MEV and incentivize good behavior, which is critical in a permissionless system.

It’s also interesting to see the consideration for liveness guarantees, especially the fallback options in case of validator inactivity or malicious behavior. The recovery mode and finalization process provide a robust safety net for ensuring the protocol remains functional even in edge cases.

The finalization process using reverse auctions for selecting nodes to handle data availability and proof generation is another compelling aspect that highlights the effort to balance cost and efficiency.

Great job to @Florian, Simon, Mikhail, Roberto, and Nicolas for contributing to these advancements! It will be exciting to see how these proposals evolve and get implemented over time.

[3lixbt]

Firstly, I’d like to commend the team for this detailed and forward-thinking proposal aimed at fully decentralizing Linea. The integration of QBFT consensus with an outer protocol for validator selection is afaik an innovative approach that addresses many challenges in achieving security and scalability in a decentralized L2.

After conducting extensive research on QBFT (including reviewing the Hyperledger Besu implementation and ConsenSys documentation) and studying related materials on APS-burn designs in decentralized L2 contexts, I have some questions and comments that I could help clarify certain aspects of the proposal (for me at least):

1. Validator Selection and Committee Size:

• Stake Requirements and Committee Composition:
  • While the proposal mentions that any node can join the validator set by staking a sufficient amount, I couldn’t find specific details on how this minimum stake is determined. Is there a formula or mechanism for calculating the required stake based on network conditions or the total number of validators?
  • Considering QBFT is most efficient with smaller committees, how does the protocol plan to balance committee size with the need for decentralization? Is there an optimal committee size that has been identified, and what factors influence this determination?

2. Randomness in Validator Selection:

• Randomness Generation Mechanism:
  • The proposal states that the outer protocol randomly selects a subcommittee from the validator set. Could you provide more details on the randomness generation method used to ensure unbiased and secure selection? For instance, does it utilize Verifiable Random Functions (VRFs), randomness beacons, or another approach?
  • How does the protocol protect against potential manipulation of the randomness source to prevent collusion or predictability in validator selection?

3. Parameters of the Block Proposer Auction:

• Determination of Auction Timing Parameters (k, t, b):
  • The auction mechanism involves parameters k (offset for bidding on future slots), t (duration of the sealed bid phase), and b (buffer period). How are these parameters set initially, and is there flexibility to adjust them based on observed network performance or security considerations?
  • What factors are considered in choosing these durations to balance responsiveness with security, especially in mitigating multi-block MEV and censorship concerns?

4. Mitigating Censorship and Ensuring Fairness:

• Preventing Censorship in the Auction Process:
  • In the context of on-chain auctions, there’s a risk that current block proposers might censor bids from other participants. How does the protocol address potential censorship during the bidding phase, especially given that bids are submitted on-chain?
  • Are there mechanisms such as inclusion lists, multiple concurrent proposers, or cryptographic techniques (e.g., threshold encryption or VDFs) to mitigate censorship and ensure all bids are fairly considered?

5. Finalization Cost Estimation and Provisioning:

• Calculating Provisioned Tokens for Finalization Costs:
  • The proposal mentions that block proposers must provision tokens to cover future finalization costs, but it’s not entirely clear how these costs are estimated upfront. Given the variability in data sizes and proof generation complexities, is there a model or formula used to calculate the required provision per block?
  • How does the protocol ensure that the provisioned amount is sufficient to cover actual costs without being excessively burdensome for proposers?

6. Delegation and Incentivization in Finalization:

• Mechanisms for Delegating Proof Generation:
  • Since the finalization winner can delegate proof generation to other actors, are there standardized protocols or frameworks in place to facilitate secure delegation? How does the protocol ensure that delegated parties perform their tasks reliably, and are there any incentives or penalties involved?
• Incentives for Participation in the Reverse Auction:
  • What incentives are provided to encourage nodes to participate actively in the reverse auction for finalization? Is the reward structure designed to attract a diverse set of participants and prevent centralization of finalization duties?

7. Consensus State Merkle Tree Details:

• Construction and Verification:
  • The proposal introduces a consensus state Merkle tree to track validators’ activities for reward allocation. Could you provide more details on how this tree is constructed and maintained? How frequently is it updated, and how do validators interact with it to claim rewards?
  • How does the protocol ensure transparency and prevent manipulation in the recorded activities within the Merkle tree?

8. Governance and Protocol Upgrades:

• Decentralized Governance Framework:
  • While the proposal focuses on technical aspects of decentralization, it doesn’t elaborate on governance mechanisms. Is there a plan to implement decentralized governance involving validators and the broader community for protocol upgrades and parameter adjustments?
  • How will proposals be submitted, voted on, and implemented to ensure a transparent and inclusive decision-making process?

9. Recovery Mode Activation Threshold:

• Justification for the Six-Month Period:
  • The proposal states that recovery mode is triggered if no block has been produced for six months. Considering the fast-paced nature of blockchain networks, what is the rationale behind choosing such a lengthy period? Would a shorter timeframe enhance network resilience without compromising security?

10. Client Diversity and Security:

• Support for Multiple Client Implementations:
  • Client diversity is crucial for network robustness. Are there plans to support multiple client software implementations for Linea to reduce reliance on a single codebase and mitigate risks associated with software bugs or vulnerabilities?
• Security Audits and Formal Verification:
  • Given the complexity of integrating QBFT, the outer protocol, and auction mechanisms, are there provisions for regular security audits and formal verification to ensure protocol integrity?

I understand that some of these questions might be in areas where details are still being developed or are intentionally abstracted at this stage. I also realize that some answers might already be available, and I apologize if I missed them. Please feel free to point me to any resources or documentation where I can read more about these topics. Any additional information or clarification you can provide would be greatly appreciated.

Thank you for your hard work on advancing the Linea ecosystem. I’m excited to see how these ideas evolve and look forward to further discussions.

[paperlesshash]

Overall, this proposal not only paves the way for a robust and decentralized Linea but also hints at the exciting potential for token-based incentives to play a pivotal role in its ecosystem. Bringing tokens into the fold sooner rather than later could further enhance engagement and participation, making the decentralization journey even more compelling for the community.

[Skipper]

Interesting write up I must say. I guess people are short sighted as most would be. Definitely here for the good times and for a long time 🫶🏾

[don]

Governance will play an essential role in decentralization for Linea Foundation. Ensuring network security will be the most important thing for the ecosystem.

[SolidSnake]

i think so

[macko]

Congratulations to the author for an exceptionally well-thought-out proposal on Linea’s decentralization! The detailed approach to securing the network and implementing mechanisms like on-chain auctions and staking is impressive. One suggestion: consider additional safeguards to mitigate the potential concentration of power among large players in the auction system. Best of luck with the implementation of this ambitious project!

[marta]

my first reply Hi guys

[Chuuqs]

This is one of the most in depth pieces regarding decentralization, finality and all the works that actually caught my attention. The proposal is clear too and not unnecessarily bulky and a good read as well. Look forward to implementation.

[dlord]

Interesting, I agree with moving L2-finality to proof-of-stake and using QBFT for quick finality. The accountability setup and outer protocol for rotating validators make sense to me and should help deal with Byzantine nodes.

But I do have a bit of concern with the block proposer auction. Letting low-stake nodes propose blocks helps with decentralization, but the incentives might not be strong enough to make sure all nodes act well. Even with the safeguards, there’s still a chance that low-stake nodes might focus on short-term gains, which could hurt the network. Maybe it’s worth looking at better incentives or penalties to ensure everyone plays by the rules?

[Florian]

Thanks drdnero for your comments, I will try to add some more details.

Regarding your question on validator selection and committee size. First, keep in mind that committee size and validator stake amount will influence L2-finality, not L1-finality which is guaranteed by the zk proofs. Second, on one hand, a high validator stake amount would limit the number of nodes joining the validator set, and hence decentralization. On the other hand, the committee size is constrained by the performances of QBFT, network performances, hardware used by the nodes, … so there will be a trade-off. The protocol gives the flexibility, what will be used in practice is a complicated question which requires more analysis that will be performed by another team.

Regarding your suggestion to dynamically adjust the durations of the different periods, it is an interesting idea. Thanks!

Regarding the recovery mode, the proposal to have six-month is because we are still in the early stages.

You also raised some concern regarding the size of the validator set. By splitting the validator role and block proposer role, we create more opportunities for nodes with less funds to participate. Also, large players can always act as a crowd of small power, so it’s not clear what can be put in place efficiently.

For the question related to governance and upgrades this is indeed not covered by this post, which is only focused on the protocol.

Finally, on data availability costs, the proposal allows to determine the price of data availability and proof generation. From this, using compressed data size of each block and gas cost of each block (or another metric that better captures proving complexity of blocks), we can compute a cost for each block.

[Florian]

Thanks @Andreolf for your nice feedback!

[Florian]

Thanks @3lixbt for taking time to read our proposal and post these detailed comments.

Let me try to answer your questions:

Stake Requirements and Committee Composition:
‘I couldn’t find specific details on how this minimum stake is determined.’
’ Is there an optimal committee size that has been identified, and what factors influence this determination?’

Your questions rejoin one of drdnero.
On one hand, we want to limit the stake required to favour decentralization. On the other hand, the size of the validator set will be limited by the performances of QBFT, network throughput, the hardware of the validators set, … This will require more analysis, analysis which will be done by a different team.
Also, your comment seems to suggest adapting the validator set dynamically. Why not, it’s an interesting idea. We could have a threshold that is low when conditions are goods, and high when they are degraded. This threshold could then be used to filter the validators from which the committee is selected and decide its size. It’s an interesting idea, even though it would add complexity.

Randomness Generation Mechanism:

The idea is to use a VRF to choose the committee from the validator set. The random number used as input will be a RANDAO value deterministically taken from L1 to avoid manipulation.

Parameters of the Block Proposer Auction:

Determining the three values k, t and b will require an in depth analysis, and is out of scope of this proposal. Drdnero was also suggesting to have these parameters adaptive. This is a good suggestion to investigate.

@dlord, It also rejoins your concern about low-stakes nodes, which is certainly a valid point. To address this risk, the goal is to make malicious behavior sufficiently costly to discourage them. Requiring a minimum stake, which would allow us to penalize nodes that fail to propose blocks as expected is a possibility.

Mitigating Censorship and Ensuring Fairness

Censorship resistance during the auction is definitely a major concern. The motivation to introduce the three phases is to make the auction more resilient to censorship.
Multiple concurrent proposers and inclusion list are also not ruled out.

Finalization Cost Estimation and Provisioning:

At the time the block is created, the actual cost of finalization is unknown, but we have the best finalization bid so far. From this we can compute an upper bound on what will be the real costs, which is what the block proposers have to provision.
As you point it out, there is a risk the provision is a burden for ‘small’ proposers and could need some refinements.

Delegation and Incentivization in Finalization:

The proposal does not cover delegation of proof generation, and hence does not have any control on the parties performing the delegated tasks. The auction winner has this responsibility. With respect to your question on the existing framework, there are some already like the prover market that could be used.

Incentives for Participation in the Reverse Auction:

The reward mechanism allows a lot of flexibility. The exact mechanism will need a proper analysis and is out of scope of this proposal.

Consensus State Merkle Tree Details:

The committee of QBFT will be in charge of computing this merkle tree. It’s root will be added to the block. It will be updated at every block.
After finalization on L1, the root will have to be bridge to L2. Once it’s on L2, any node will be able to post a merkle proof proving its past activity and get its reward accordingly.
The merkle tree calculation will be proven as part of the finalization.

Governance and Protocol Upgrades:

This post focuses only on the protocol, not on the governance.

Recovery Mode Activation Threshold:

Six months is the current value as we are still in the early stage. The outer protocol will lead to committee rotation much faster and hence this recovery mode activation is really unlikely to ever happen.

Client Diversity and Security:

We intend to keep full compatibility with the existing execution layers. For the consensus layers, any contribution is welcomed :).

Finally, regarding the Security Audits and Formal Verification, you can find more details in this other post: ‘Open source as a key element of Linea’s strategy’

Again thanks for taking time to reply to our post!

[Florian]

paperlesshash, Skipper, Don, SolidSnake, macko,
Thank you all for your interest in Linea and the positive feedback! Welcome, Marta—we’re excited to engage with you further.

Chuuqs, you’re absolutely right—now comes the crucial phase of implementation. Please bear with us as it will take some time to complete !