Layer-2 Solutions and Their Clients (4 of 9)

Target audience: Intermediate, Expert

TL;DR

• Rollups enhance scalability by offloading execution from Layer-1 (e.g., Ethereum), but require additional mechanisms for verifiable client interaction.
• Stateless clients extend trustless verification across both layers.
• Verifiability is delayed until rollup outputs are finalized and anchored on Layer-1, especially in optimistic systems with long challenge periods.
• The colibri.stateless client implements a minimal trustless architecture to validate L1 and L2 data without persistent state or trusted RPCs.

1. Introduction

Layer-2 (L2) solutions are protocols built on top of base-layer blockchains (Layer-1) to increase scalability, reduce transaction costs, and improve user experience. They aim to offload computational and storage burden from the main chain while preserving the underlying security guarantees. Prominent examples include Optimistic Rollups (e.g., Optimism, Arbitrum) and ZK Rollups (e.g., zkSync, StarkNet), which bundle many transactions off-chain and periodically submit state updates to Layer-1.

The motivation for L2s is rooted in Ethereum’s scalability trilemma: achieving scalability, security, and decentralization simultaneously remains challenging. While Layer-1s offer robust security and decentralization, they are often limited in throughput and latency. L2s seek to address these constraints without compromising on trustlessness.

Rollups process transactions off-chain but rely on the base chain for data availability and dispute resolution. Optimistic Rollups assume correctness by default and allow fraud proofs within a challenge period, while ZK Rollups submit succinct validity proofs (zero-knowledge proofs) that enforce correctness.

However, introducing L2s raises new challenges in client infrastructure. L2s differ in consensus assumptions, state transition models, proof systems, and data availability strategies. Traditional full or light clients for Layer-1 cannot natively verify L2 data. This creates a gap in verifiability, particularly when applications interact with multiple Layer-2s or require lightweight clients.

To preserve end-to-end verifiability, new approaches are needed — particularly stateless clients that support both Layer-1 and Layer-2 verification. While research prototypes and projects such as Helios explore parts of this direction, most existing clients still rely on persistent state or RPC trust assumptions. Stateless verification across layers remains an open frontier that requires dedicated tooling, standardized proof interfaces, and lightweight client logic. The colibri.stateless client aims to address this gap directly. It is designed as a fully trustless, stateless client for EVM-compatible chains (and others in the future), capable of verifying both execution and consensus proofs without storing any blockchain state. While still in active development, it targets precisely the challenges outlined here: supporting multi-layer verification with minimal resource requirements.

2. Stateless Verification for Layer-2

Verifying Layer-2 data trustlessly requires bridging multiple proof layers. Stateless clients must not only validate Layer-1 consensus and execution but also verify that the Layer-2 state update is valid and originates from a legitimate rollup operator. Legitimacy, in this context, is defined by mechanisms such as the presence of sequencer signatures tied to known keys or the existence of a proof (ZK or fraud-proof) that is anchored and included on Layer-1 via verifiable execution and consensus proofs.

For ZK Rollups, this involves verifying the ZK proof published to Layer-1, which attests to the correctness of a batch of transactions. A stateless client retrieves the ZK proof, verifies it against the expected verification key, and confirms its inclusion on Layer-1 via an execution proof (with consensus proof).

For Optimistic Rollups, state transitions are assumed valid unless challenged. Stateless clients must ensure that no valid fraud proof has been submitted within the challenge window before accepting the result. This means the finality of L2 data is inherently delayed compared to ZK systems.

Importantly, the inclusion of the rollup state update on L1 must also be proven. This is achieved through a standard execution proof that demonstrates the update was included in a canonical Layer-1 block, which is itself verified through consensus.

Thus, the stateless verification stack consists of:

• Execution and consensus proofs for the Layer-1 block
• Inclusion proof of the rollup state update or proof on Layer-1
• Validation of the ZK proof or challenge window status (depending on rollup type)

This model extends the trustless paradigm of stateless clients to multi-layer architectures, enabling verification of both base and rollup chains without state storage or synchronization.

3. Trustless Access to L2 Data

Trustless interaction with L2 systems depends on clients being able to obtain and validate relevant proofs; without access to verifiable data, stateless verification cannot function. Stateless clients rely on execution, consensus, and rollup-specific proofs to establish correctness, making reliable and standardized proof access a core requirement for L2 interoperability. Unlike L1, where standardized Merkle proofs and sync committee attestations exist, L2 ecosystems vary widely in their support for verifiable data.

Some ZK Rollups publish validity proofs to Layer-1, allowing clients to fetch and verify them. Others publish only partial state or require specialized tooling to reconstruct state transitions. Optimistic Rollups introduce additional latency and complexity due to challenge windows and sequencer assumptions.

Clients must retrieve:

• Rollup proof or state root update (typically from Layer-1)
• Inclusion proof of the rollup data in a Layer-1 block
• Consensus proof for the Layer-1 block

Only by combining these elements can a stateless client trustlessly validate L2 outcomes. Inclusion of the rollup proof on Layer-1 must be confirmed via execution and consensus proof, completing the verification chain.

Rollups that do not publish sufficient data or rely heavily on centralized sequencers — such as those that do not provide Layer-1-anchored proofs or verifiable state commitments — may prevent full trustless access. This creates similar issues to RPC-based architectures, where clients are forced to trust opaque or unverifiable data feeds. Examples include rollups that publish only partial state information or significantly delay data availability, hindering real-time stateless verification.

4. Challenges and Open Questions

Trustless interaction with Layer-2 systems is possible but introduces new technical and architectural challenges. While stateless clients offer a path toward verifiability, their use with L2s is subject to the maturity and transparency of each rollup system.

To understand the limits and trade-offs of stateless access to rollups, it’s necessary to examine the open challenges around proof timing, finality, and data availability.

Finality and Delayed Verifiability

In both ZK and Optimistic Rollups, state changes on L2 become verifiable only after they are anchored on Layer-1. This means that until a ZK proof is submitted or the fraud challenge window expires (in optimistic systems), clients cannot independently verify the new state. Verifiability is inherently delayed, and fresh data is often unverifiable in real-time. For example, Optimistic Rollups typically define a challenge window of 7 days, during which the posted state can be contested. This means that although a transaction may appear finalized from the user’s perspective on the rollup, trustless clients must wait for the window to close before treating the state as final. In practice, this results in a latency of several minutes to days before a state change becomes provably valid on Layer-1, depending on the rollup protocol.

This stands in contrast to the perceived performance of rollups: although transactions are executed and reflected instantly on L2, trustless verification is only possible with delay. Applications that depend on stateless verification must be aware of this gap and may need to distinguish between “visible” and “provable” states. For instance, a transaction that appears complete on an Optimistic Rollup may still be within its 7-day challenge window, meaning its validity cannot yet be verified by a trustless client. Understanding this distinction is crucial when building systems that rely on real-time verifiability, particularly when data freshness and correctness must be independently confirmed.

Data Availability and Sequencer Centralization

Many rollups rely on centralized sequencers to order and publish transactions. In some systems, transaction data is only made available on Layer-1 periodically. Until then, state transitions are unverifiable. This introduces temporary opacity and potential risks of censorship.

Data availability sampling (DAS), validity-proof chains, or Layer-1-based data publication can help mitigate these risks, but they must be supported at the protocol level.

Proof Compatibility and Tooling Gaps

There is no standard format for rollup proofs, and tooling support varies widely. To ensure robust integration and interoperability, stateless clients must rely on well-defined, standardized interfaces that streamline the fetching, verification, and aggregation of proofs across both Layer-1 and Layer-2 environments. Without this, integration becomes bespoke and brittle.

Conclusion

Stateless verification is feasible for rollups, but strongly depends on protocol design. Not all rollups currently support the required transparency. Until L2s expose provable state transitions in standardized, accessible formats, stateless verification will remain limited to specific ecosystems.

5. Use Cases and Integration

Stateless clients for Layer-2 systems are especially useful in environments where trustless interaction and minimal resource usage are essential.

Mobile and Web3 Wallets

Applications such as non-custodial wallets that wish to interact with multiple L2s benefit from stateless clients. They can verify both L1 and L2 data independently without relying on RPCs or embedding heavy infrastructure.

Cross-Layer Bridges and Aggregators

Protocols that aggregate liquidity or data across L2s and L1 require verifiable inputs from multiple chains. Stateless verification allows them to validate inputs and coordinate state without running full nodes.

IoT and Embedded Applications

Devices that interact with rollup-based services (e.g., smart locks checking access lists on zk-rollups) can use stateless clients to confirm the integrity of data they retrieve — even if offline most of the time.

AI Agents and Smart Agents

Autonomous agents making decisions based on on-chain conditions must not rely on unverifiable state. Stateless verification provides minimal, real-time assurance that an observed state is accurate.

6. Summary and Outlook

Rollups are a critical component of Ethereum’s scalability roadmap, offering improved throughput and reduced costs without compromising the security of the base layer. But the trust guarantees of rollups are only preserved if the client infrastructure evolves accordingly.

Stateless clients close the verifiability gap introduced by L2 architectures. They enable end users, applications, and agents to independently validate both Layer-1 and Layer-2 data — without syncing, storing state, or relying on trusted infrastructure.

The challenges of delayed finality, data availability, and non-standardized proof formats must be addressed. Nonetheless, the trajectory is clear: rollup systems will become more transparent, and proof interfaces will standardize.

In this environment, stateless clients will play a foundational role. They support the vision of permissionless infrastructure where every application can verify what it sees — regardless of the number of layers, chains, or participants involved. Colibri.stateless exemplifies this approach by providing a minimal yet complete client architecture for proof-based access to blockchain data. Its roadmap includes full support for Ethereum and L2 integrations, establishing a reference implementation for trustless interaction in multi-chain environments.

Verifiability must scale alongside throughput. Stateless architecture is how we ensure that the multi-layer future of Ethereum remains trustless by design.

For more information, visit our website or follow us on social media (x, telegram, LinkedIn)

---

Layer-2 Solutions and Their Clients (4 of 9) was originally published in Corpus.Core Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.