Verifying Layer 2 With Layer 1 Light Client
Today, Ethereum has a variety of solutions in its layer 2 ecosystem that have helped reduce network congestion, lower transaction fees, and increase transaction throughput. Among these, rollups have emerged as a popular solution, and they are mainly categorized into two types: Optimistic Rollups and Zero-Knowledge Rollups. For those interested in more information about how rollups work and the broader context of Ethereum's Layer 2 scaling solutions, please refer to the guide on Ethereum's official website.
It is essential for end users to have the ability to trustlessly verify the state of these systems and being able to interact with them in a censorship-resistant manner. This is the fundamental nature of public blockchains, like Ethereum. However, these features are accessible to end-users only if they are willing to run and maintain a full client. This can be a challenging task for many as the client is computationally heavy and requires commitment to ongoing maintenance.
This article examines how light clients can empower users to verify the layer 2 state and interact with it in a censorship-resistant manner, overcoming the two challenges previously mentioned.
What is a light client?
A key distinction between a full client and a light client is reflected in their differing hardware resource requirements. Reducing these requirements involves making a trade-off in the security of the consensus protocol and capabilities. Here, 'security' refers to the guarantee of liveness and finality provided by the consensus mechanism under some safety assumptions. Meanwhile, the set of core functionalities include:
- Reading and generating proofs for account balances or the state of smart contracts,
- Retrieving historical blocks and transactions,
- Submitting transactions to the mempool for transfering ETH from one address to another, deploying smart contracts, or interacting with their functions.
A full client ensures the highest level of security within the consensus mechanism and offers all capabilities mentioned above. In contrast, a light client compromises on security to some extent and may not support all of the capabilities. For a client to be useful, it must be able to track the consensus and retain at least one of the core capabilities.
Verifying Layer 2
A layer 2 solution, such as a rollup, inherits its security directly from layer 1 — the underlying blockchain. Rollups achieve this by utilizing a smart contract deployed on layer 1, which tracks the state transitions within the rollup itself. Since the layer 1 client (full client) stores the state of Ethereum as a Merkle-Patricia Trie, it can create a Merkle proof for any data that is part of the smart contract’s state. This proof of inclusion provides a mathematical guarantee that the data is stored as a part of the whole state.
However, the proof alone does not confirm whether it belongs to the canonical chain. To determine whether the smart contract’s data is part of the canonical chain, the Layer 1 client keeps track of the participation of validators (consensus) in the Beacon Chain. Tracking the consensus is crucial for distinguishing whether the state by the client actually belongs to the Mainnet rather than to another network. The upcoming section will explain how a light client can have this capability with minimal computation.
Sync Committee For Consensus
Ethereum uses the GASPER protocol as the underlying algorithm for its proof of stake mechanism. Each validator is required to run this protocol for tracking the participation of all validators. However, since the Beacon chain has over ~900,000 active validators today, it can be infeasible to run this protocol on devices with limited amount of RAM.
To address this challenge, the Altair upgrade introduced the Sync Committee, a group of 512 validators that is randomly selected for each period, which lasts approximately 27 hours. This committee produces a single aggregated signature for the previous block header on which they agree as part of the canonical chain. Verifying this signature is lightweight in comparison to tracking the participation of the entire validator set because it only involves performing a single operation every slot. Not only is this protocol simple, but it also allows for significantly faster syncing times, providing a better user experience (UX). To learn more about how sync committees work, visit our blog post titled World of Light Clients.
While this method of tracking consensus offers reduced security, it may still be adequate for use cases that require only light verification by the user. Furthermore, for a malicious actor to control the sync committee, they would need to stake a considerable amount of ETH to increase the likelihood of their validators being selected.
Now that the light client has a method for tracking consensus, it needs the ability to store the state. This capability is essential to enable the client to generate proofs for account balances or data related to smart contracts.
Verkle Over Merkle
As mentioned earlier, full clients store the entire state (account balances and smart contract data) in the form of a Merkle-Patricia Trie. Today, the overall size of the state for Mainnet is over 200GB. Additionally, as the amount of data required for verification grows, the size of the Merkle proof increases logarithmically. These limitations are significant obstacles to running a node on a mobile device. However, there exists a much more efficient method for storing the state, which involves the use of a Verkle tree.
A Verkle tree enables constant-sized proofs using Pedersen commitments and elliptic curve group operations. One of the upcoming upgrades to the Ethereum protocol will be the migration to Verkle trees for storing state, effectively replacing the Merkle-Patricia Trie. To keep track of the development efforts for the upgrade, refer to the dedicated Notion page Verkle Trees for Statelessness.
Once the migration is successfully completed, clients will no longer be required to store the complete state and may store only portions of it that they are interested in. This addresses the requirement of having to store the entire state and allows for manageable proof sizes.
Summary
The solutions mentioned above enable a light client to retain important capabilities necessary for verifying layer 2 without the downsides of a full client. This type of light client would use fewer resources in terms of RAM and storage, making it ideal for running on mobile devices.
With the ability to run on a mobile device, it greatly increases accessibility for users who do not want to blindly trust a layer 2 solution before interacting with it. Furthermore, this type of client would be able to submit transactions directly to the mempool. This would allow users to force inclusion of their layer 2 transactions, providing censorship-resistant access.
As layer 2 solutions continue to grow in adoption, users must have flexible options for running clients that allow them to interact in a trustless and censorship-resistant manner. The diversity of these options is expected to expand as the Ethereum protocol advances through upgrades such as Verkle.
