A retroactive overview of Linea’s biggest upgrade to date.

As we prepare for the next major upgrade to Linea’s L2 network (Alpha v2), it is important to document—especially to foster transparency with the community—to document previous milestones in Linea’s development  roadmap. In this post we provide an overview of the Alpha v.0.2.0 upgrade—Linea’s last major upgrade before launching on mainnet—and highlight the rationale for certain changes implemented in the upgrade.

The information provided in this post is particularly useful for archival purposes, but you can also see it as an opportunity to learn about Linea’s cutting-edge features (if you haven’t already) and how to take full advantage. Particularly, these changes  significantly improve the network’s performance, user experience, and transaction costs and reflect our commitment to building the most scalable, efficient, secure, and user-friendly Layer 2 (L2) rollup for Ethereum developers and users.

The Linea Alpha v0.2.0 upgrade was executed on June 13, 2023 at 12:00 UTC and modified key architectural components of the zkEVM architecture in anticipation of the mainnet launch,which happened on July 11, 2023. Here’s a quick summary of the changes introduced in the Linea Alpha v0.2.0 upgrade:

• Block conflation to reduce fixed (verification) costs for L2 blocks

• New version of Canonical Message Service (“pull” execution → “push” execution model, removal of message deadlines, and reduction/removal of service fees)

• Minimum viable product release of Linea SDK and cross-chain communication system

• New version of Canonical Token Bridge (with support for N-N ERC20 token bridging and reserved/well-known token registry)

• Upgrading the rollup zkEVM contract to use a new outer-proof system (switching from Groth16 to PLONK) and integrate with the new security council system

• Upgrading prover and block production + trace generation components to support the new architecture (especially support for batch conflation)

Now, let’s dive into these upgrades in more detail.

On a zk-rollup like Linea, operating costs are typically dominated by fixed costs (verification of validity proofs on L1 and base fees paid when submitting L2 batches) and variable costs (mostly fees of storing L2 transaction data as CALLDATA). Verifying proofs is computationally intensive and typically costs around 360,000 gas to verify on-chain. Given that we want to reduce costs passed on to users, reducing the cost of verifying correctness of L2 blocks is a critical consideration.

This is where block conflation comes into the picture. Block conflation allows the sequencer to aggregate transactions from a number of consecutive L2 blocks to form a single batch and merge execution traces for intermediate blocks into a single trace. This trace is then passed as input to the proof circuit (as usual) to generate a cryptographic proof attesting to the correctness of the computation that produced the rollup's new state.

Since the merged trace captures the execution of all previous blocks, the generated proof verifies the correctness of all L2 blocks accumulated in the conflated batch. This effectively merges verification for multiple L2 blocks into the verification of a batch (an operation that can be executed in a single L1 transaction).

This feature required some clever engineering, especially with respect to the block production, trace generation, and proving processes. For example, we re-designed specific subcomponents to (a) enable conflation of L2 blocks within a predefined interval (without increasing latency) and (b) ensure traces for sequential blocks could be “glued” together without breaking the proof system’s soundness. We also upgraded the prover to accommodate block conflation.

Block conflation is one of our biggest features yet; instead of proving individual L2 blocks separately on L1, we can amortize proof verification costs across an entire batch. Already, Linea uses data compression techniques (eg. omitting signatures from transaction data stored on L1) to reduce costs and will take advantage of newer upgrades (particularly Proto-Danksharding) to further maximize cost efficiency for users in the future.

The Canonical Message Service is Linea’s native system for enabling secure communication between L1 and L2. Messages can transfer value (e.g. ETH), perform cross-domain contract calls (eg. bridging tokens), or even both! The message service allows developers to build cross-chain applications, while letting users enjoy benefits of atomic cross-chain interoperability.

Like the zk-rollup itself, using the Canonical Message Service requires few trust assumptions from users and developers. For example, a message sent from L1 to L2 can be executed only when it's “anchored” on L2 (preventing the execution of non-existent cross-chain messages).

By anchoring, we mean proof that a message was initiated on the source chain; this is done by Linea placing a hash of the pending message on the target chain and verifying it through the rollup’s validity proof. When claiming the message on the destination chain, all the message data inputted is hashed and compared against the anchored hash.

Based on feedback from early testers and partners, we overhauled certain aspects of the message service to improve usability, flexibility, and efficiency. This includes:

• Removal of Message Deadlines

  The first iteration of the message service allowed messages to be invalidated and returned after a preset time threshold. This design provided some benefits such as guaranteeing message uniqueness and preventing adversarial attempts to replay old messages. But it also forced protocol developers to implement mechanisms for reverting old messages routed through the message service. We have since scrapped the deadline system and adopted alternative measures to guarantee message uniqueness, including using a unique per-message value (a nonce) as input when hashing messages. Removal of deadlines, coupled with the new two-step process of sending and claiming messages (more on this later), provides stronger guarantees of atomic execution of cross-chain messages. Suppose a message cannot be delivered on the destination layer immediately—for example, because of an incorrect contract state. In this case, the sending user or smart contract can always attempt the message's re-execution at a later time (provided it has been anchored successfully).

• Changes to Messaging Workflow

  Previously, the delivery of interchain messages was handled exclusively using Linea’s contracts and services. Cross-chain messaging happened in the same transaction and required setting a gas fee that could cover sending the message on one layer and delivering it on the other layer.

  This placed a burden on the Canonical Message Service (and Linea) to manage setting of fees for message delivery and ensure successful execution of interchain messages. It also tightly coupled finalization of blocks with execution of messages and required restrictions on gas limits for messages to constrain execution costs.

  Conversely, the new upgrade removes the delivery/execution of messages from the purview of the message service (it only needs to ensure the validity of cross-chain messages). It also splits the messaging process into two distinct parts:

  Sending: Smart contracts and EOAs call the message service to place a cross-chain message request.

  Claiming: After the hash of a pending message is placed on the destination layer, anyone can "claim" the message (triggering its execution and paying the required gas fees).

  Note that Linea no longer exclusively controls message delivery, and anyone (including dapps and users) can independently assume the delivery and execution of cross-chain messages. The immediate benefit is that users and dapps have more flexibility when sending messages between L1 and L2. For example, a user can set the _fee field in a message transaction to zero, so that a dapp/third party can pay for the message's delivery at the destination.

  Another advantage is that users are no longer constrained in terms of how much gas a message's execution at the destination can use (reducing problems around failed execution due to out-of-gas errors). Particularly, third-party relayers (Postmen) will specify upfront a maximum gas limit for message delivery and charge appropriate fees to cover execution costs.

  If you want to read more about the messaging service’s design, you can read the documentation on Linea’s message service architecture.

During the initial testnet phase, users relied on third-party bridges to bridge funds between Ethereum and Linea. Third-party bridges have significant benefits, such as higher liquidity and a simpler UI (user interface), and we do encourage regular users to use third-party bridges whenever possible.

But we also found several reasons to build a Canonical Token Bridge to complement existing liquidity bridges and improve cross-chain asset transfers on Linea, especially for bridge operators and dapp developers. For instance, the existence of different bridges could cause friction—especially in cases where each protocol issues a different representation of the same L1 token on L2. It also increases the barrier to entry for new dapps since developers must either coordinate with bridge operators to list tokens, or build custom bridges to bootstrap on-chain liquidity before deploying dapps.

By bootstrapping our own Canonical Token Bridge, we aim to unify liquidity for tokens on L2 (big W for DeFi!) and reduce friction/trust assumptions for anyone bridging assets between Linea and Ethereum (and in the future between Linea and other L2s). Like the message service, the correctness of operations involving the Canonical Token Bridge, including deposits and withdrawals, is guaranteed by a validity proof. We consider this an important feature for users, given how much the industry has lost to bridge hacks in recent years.

The Alpha v0.2.0 upgrade introduced the new canonical token bridge which allows for bridging of ERC20 tokens between L1 (Ethereum) and L2 (Linea) tokens to and from Linea. The bridge uses the standard lock-and-mint model of transferring assets and relies on the Canonical Message Service to relay information about token deposits and withdrawals. For more details, read the walkthrough on bridging ERC-20 tokens between Linea and Ethereum.

Importantly, bridging is permissionless: if a token is deposited in the bridge for the first time, and it doesn’t currently exist on L2, the deposit triggers the creation of an identical representation on Linea. The new token bridge design also integrates a token registry, which will serve as the source of truth for canonical addresses of tokens deployed on Linea and prevent the proliferation of “copycat tokens”.

Along with the Canonical Message Service, the Linea SDK (Software Development Kit) package is another critical component in Linea’s cross-chain communication infrastructure. The package includes two components: the Linea SDK and Postman service client. While the Postman client is under development, we shipped the Linea SDK as part of the Alpha v0.2.0 upgrade.

The Linea SDK provides custom functions for retrieving message information and status as well as claiming messages routed via the message service. Below is a list of some of the things you can do with the Linea SDK:

• Retrieve contract instances and addresses

• Retrieve message information by message hash

• Retrieve messages by transaction hash

• Retrieve message status by message hash

• Claim cross-chain messages on L1 and L2

We encourage you to check out the Linea SDK tutorial in the documentation for more information on using this feature. In future, we plan to release the Postman service client, which will further streamline the process of delivering and claiming messages exchanged between Linea and other L1/L2 networks.

The Alpha v0.2.0 release upgraded the rollup’s core contracts to support the creation and management of Linea’s security council. The security council is part of our “defense-in-depth” approach to security, which includes bug bounties and rigorous software audits, and comprises a group of individuals (EOAs) with the authority to approve transactions originating from the admin’s multisig wallet.

The multisig account is responsible for executing both routine maintenance operations and emergency actions targeting critical components of the protocol, such as the L1 consensus contract, messaging service, and the token bridge. For example, the security council—via the multisig wallet—can authorize upgrades (without delays) if a bug is discovered in one or more protocol contracts.

As highlighted in Linea’s progressive decentralization roadmap we intend to refine aspects of the security council system over time to improve security and transparency.These measures include subjecting upgrades to longer delays (enforced by a time locker) and rotating the list of members to include more participants outside the Consensys organization and part of the broader Linea and Ethereum community.

As explained in a previous post on Linea's prover architecture, we use an outer-proof system to reduce the cost of verifying validity proofs generated by the Vortex prover on Ethereum. A major change introduced as part of the Alpha v0.2.0 release is switching to PlonK (from Groth16) for outer proofs.

Due to its fast verifier time and constant-sized proofs, Groth16 proved more than enough for generating and verifying proofs cheaply on Ethereum. However, such efficiency comes at a cost: we need to have a new trusted setup ceremony to generate public parameters (used for generating and verifying proofs) each time a change is made to the arithmetic circuit.

In comparison, PLONK produces slightly larger proofs and increases proof generation times—but it works using a universal (updatable) trusted setup. This means we can reuse randomness from during the initial ceremony, even if we update the circuit later. Not only does this reduce operational overhead (trusted setups are hard to coordinate), but it reduces the risk of breaking soundness guarantees.

We’ve covered most breaking changes associated with the Alpha v0.2.0 upgrade in the release notes, but here’s a high-level overview of backwards-incompatible modifications introduced by the upgrade:

Bridge operators using the Canonical Message Service to route messages between L1 and L2 have to subscribe to new types of events based on the message service’s new architecture. This includes events emitted to signal when messages are anchored and eligible for claiming (once the block including the message reaches finality).

Upgrading the token bridge and message service changed the addresses of smart contracts involved in asset transfers and message delivery between Linea and Ethereum.   Hence, bridge operators have to to call new contract addresses with a different ABI scheme (more information about this change is available in the documentation’s release notes).

Since announcing Linea’s mainnet alpha in July, we have seen immense adoption and activity—showing that people loved what we had to offer. In this time, we have onboarded major dapps (including a decentralized social network worth checking out); rewarded users for participating in the Linea Voyage; and even upgraded our documentation to make using and building on Linea easier than ever.

But we’re just starting. With insights gained from months of  stress-testing the network and feedback from users, developers, and partners, our excellent engineering team continues to develop, test, and prototype various upgrades to Linea’s protocol.

Are you excited for the future of Linea? We are, too, and cannot wait to share more updates on the next phase of Linea’s product roadmap!. In the meantime, don’t forget to participate in various ongoing activations, including the newest Voyage Quest and the Linea Entertainment Festival). You can also be sure to keep track of all announcements by following Linea on Mirror, Twitter, Lens, Lineaster, and Discord.