Earlier this year, the Celestia roadmap was published. An important part of the roadmap is adding ZK verification natively to the Celestia base layer, so that rollups can directly bridge assets via Celestia. In this post, we explore how adding ZK to the base layer unlocks Lazybridging - the Celestia endgame for a frictionless modular user experience.

Lazybridging will enable end-users to interact with assets across multiple rollups and beyond, all with the same experience of interacting with a single chain. We aim to achieve this while keeping the user experience lazy, the developer experience lazy, and the base layer lazy.

Developers love the flexibility and performance of building applications with rollups, but today this often means trading off access to users and liquidity on other chains, due to modular fragmentation. In practice, modular fragmentation means only the most liquid assets (e.g. ETH or USDC) are instantly bridgeable (for a fee) between popular rollups, via solver-based protocols.

Lazybridging aims to eliminate this tradeoff, enabling a unified on-chain experience for end-users while giving developers the best of all worlds: the freedom to build whatever and instant access to users and assets on all other major blockchains.

At the heart of Lazybridging is TIA, which is further reinforced as the easiest token to use for bootstrapping rollups—whether to pay for gas, for sequencer bonds, for collateral, or simply for payments.

Let’s dive deeper into what the ‘lazy’ in Lazybridging means, and how it will work.

A lazy user experience

User experience in crypto remains far from the UX nearly everyone on the internet is familiar with: browsing to a new website or downloading a mobile app, where it feels like a single internet. On the other hand, using an application on a new chain can require multiple wallets and often comes with unexpected latencies and delays.

Lazybridging aims to turn using any onchain application, built with any VM on any chain, into  an experience similar to browsing the web. In particular, Lazybridging aims to aggregate rollups that use different VMs in a way that feels like a single chain to the end-user, with a single wallet. Leap Wallet’s Celestia light node integration provides a first step towards this.

In a single action, users should be able to directly use an application anywhere, regardless what chain their funds are on (e.g. mint an NFT on chain A using tokens from chain B). While this is already possible today in many settings, as you can for example, buy NFTs on Forma using TIA on Celestia directly via Astria, developers are looking for a way to do this in a way beyond local ecosystems.

Celestia is uniquely suited to providing this experience because it has single-slot finality, which means each Celestia block finalizes immediately. Since users experience latency based on the source chain, this means that the withdrawal and deposit of assets on the Celestia base layer can eventually feel instant for end users. Therefore, Celestia is uniquely positioned to take advantage of advances in ZK proving speeds, as ZK rollup proving times become closer and closer to the base layer block time.

Thanks to single-slot finality, Celestia already has a finality time equivalent to Solana. With further technical improvements in the roadmap such as separating sampling from finality, Celestia can eventually reach sub-second finality.

ZK on the Celestia base layer will provide a secure basis for interop abstraction technology such as chain abstraction and intents to build on top of, which when combined with Celestia’s single-slot finality, will enable a fast ‘single-chain’ user experience.

A lazy developer experience

Developers build wherever they can get the most users and liquidity. With Lazybridging, rollup developers will immediately have access to assets not just within the Celestia ecosystem, but outside of the Celestia ecosystem thanks to native IBC support. Developers should be able to connect once and onboard users from any chain.

As Celestia supports IBC, Celestia will be the only rollup ecosystem that has a native way to bridge to chains outside of the Celestia ecosystem, without relying on third party multisigs. For example, rollups on Celestia can have native access to USDC via Noble, which can be bridged in one transaction to those rollups with Packet Forward Middleware which was introduced in the new Celestia Lemongrass upgrade.

Lazybridging can also be used to bridge assets to and from chains that don’t natively support IBC, such as Ethereum, while avoiding third party multisigs. This can be done for example by deploying a light IBC client as a smart contract on Ethereum, connected to a ZK contract on Celestia that runs an Ethereum light client.

Lazybridging will not only support ZK rollups, but optimistic rollups can also be supported by creating ZK proofs of fraud proofs.

A lazy base layer

One of the core values of Celestia is overhead and state bloat minimization on the base layer, which is why Celestia doesn’t have smart contracts. This allows Celestia’s core developer community to laser-focus on scaling to gigabyte blocks. Adding a smart contract environment reduces performance due to increased state bloat, and introduces hard-to-mitigate complexities such as block builder centralization due to MEV.

However, thanks to all the recent progress in ZK technology, it’s possible to extend the functionality of the base layer without executing smart contracts directly on the base layer. Instead, the base layer becomes responsible for only verifying ZK proofs of execution, rather than doing the execution itself.

At the core Lazybridging is the addition of a ZK-based IBC client to the base layer. This will enable rollups to natively bridge with Celestia directly using the IBC protocol.

This is the endgame for the Celestia base layer: a decentralised, minimal base layer that is only responsible for data availability (for security) and proof verification (for bridging).

Progress

A ZK in the Celestia base layer working group has been active since January to address key design questions in the architecture of adding ZK to the base layer, such as which proof systems to support. Notes and recordings can be found in the CIP repo. An early implementation is underway, expected within the coming months.

As architectural work comes to a close, deployment on the base layer is targeted for the first half of 2025.