# ZK: Accelerating DA Interop

- Channel: [ETHBerlin](https://streameth.org/ethberlin)
- Date: 2025-06-16
- Duration: 23:55
- Watch: https://streameth.org/watch/685045644ac43bf73d4f2117

## Description

In this presentation, I’ll walk you through the Lazybridging protocol, a solution designed by engineers at Celestia Labs to natively support bridging across EVM rollups through Zero-Knowledge proofs.

## Transcript

I'm Nina and I'll be talking about CK Accelerating LTA Interval. Who am I? As I said, I'm Nina, I'm a car engineer at Celestia Labs. I work on consensus and the state machine and most recently I've been working on the Lazy Bridging Protocol, which is our native interop solution. And before then I worked at Celo as a smart contract engineer. Now I would like to actually go into the title of my talk and explain a little bit what these things even mean. What is, what even is CK Accelerating LTA Interval? These words can be kind of overused in the space and could mean a million different things. So the way I'm defining them right now is the way I'll be using within the context of this talk. So what is AltDA? AltDA is interoperability between rollups that use non-monolithic DA layers, where transactions are published and ordered separately from how they're executed and settled. To break this down even more, I'll be talking about interoperability between rollups that use a shared DA layer like Celestia and they rely on this DA layer to publish their transactions. Now let's define what DA actually is, or at least how we think about DA at Celestia. DA is a widely misunderstood term where people assume that it means permanent storage, but that's not how we think about it at Celestia. As I said, the DA just means how transactions are serialized and made available long enough for light nodes to be able to sample and reconstruct the change state. And when it comes to the CK part of this, CK is just a tool that allows us to have verifiable interoperability between different virtual machines that do not share the same execution environment like the SDK and the EVM. Now the status quo. I want to preface this by saying that I'm no expert in CK or bridging, and this is just how I think about bridging in general and a bit of a backstory on how I even got here. So when I joined Celo in 2021, which was my entry to the space, I was working on stable assets as a smart contracts engineer, and we already had a team at Celo working on bridging. And at the time, it felt super exciting to me having different chains like layer ones and layer twos, being able to talk to each other, pass messages, make transfers, share data, felt really exciting. And it really felt like the thing that could unlock the next level, the adoption that we were all hoping for. But then, obviously, bridging is really complex. It's a very hard problem to solve. And in the first iterations of the bridging protocols, we often prioritize connectivity over security. And then soon after that, we just started getting hacked. People lost trust. And then I joined Celestia Labs and was asked to work on a bridging solution to make bridging, at least within the Celestia ecosystem, a little bit more secure. I was super excited, but also cautiously optimistic because of all the high profile hacks that happened before and trust assumptions are buried very deep in the architecture that's very hard to crack. So after this, I want to go into, I would like to define the problem of what lazy bridging is solving and maybe walk you through a little bit of what the different trust assumptions are in bridging. Here we don't have a bridge. Let's just cover a base case where you're transacting on an L1. And transactions here inherit base level security assumptions where you have a proof of stake network with presumably large validator sets. And the security is tied to economic stake and honest majority assumptions of these validators. So pretty known use case. We all know and done this. Next here, I would like to cover bridging between two layer ones. Now here we have Celestia and Osmosis as an example. They're both proof of stake networks. They share execution environment. They're both Cosmos SDK chains and they have IPC-like clients deployed on them. Celestia is tracking Osmosis, Osmosis is tracking Celestia, and these chains both have their own constraints and proof systems. So as long as two-thirds of the validators have signed the blocks and confirmed the validity of the block header, the IPC-like client will update the state. Now we have a scenario where our circles have grown. We have three circles now. We have two roll-ups talking to each other that share a DA layer. And the biggest difference you would notice is that these roll-ups have attestor sets. So attestor sets are much smaller. They're not proof of stake networks. They rely on Celestia to publish their blocks, so for consensus. And the main thing that Celestia offers, or like one of the main things, is that you don't need your own validators. You just need nodes that are able to execute the roll-up state and sign over it. And this is what these attestors do. But the main problem here is that attestor sets are much smaller in size, where you would have three to five people on a multisig, where in a proof of stake network like Celestia or Osmosis, you would have at least 100 validators validating the blocks. So this is where the trust assumptions come in. You have no way to hold these unbonded attestor sets accountable, because they have no economic stake on the network. So if a user on roll-up A wanted to bridge across roll-up B, the user would be trusting roll-up A's attestor sets. The user would also be trusting that the DA layer is actually making those blocks available, the roll-up blocks. And the user would also be trusting roll-up B's attestor sets. So these are too many systems to trust. And I think we can all agree that this is not perfect and needed to be changed. So this is kind of high level, on the high level, what we're trying to solve here. Now we have two layer twos talking to each other, the same setup. But the main difference is that these roll-ups now have CK execution proofs on top of them. Everything's the same. They're posting blocks on Celestia. They have attestor sets. But now, instead of trusting these attestor sets, we can actually verify that they're signing over the right roll-up state. And how we do that is that we take some previous state, apply some set of inputs, and we make sure that the output, that the state that was computed was correct. So now, if the user is bridging from roll-up A to roll-up B, those transactions would come with an execution proof. So you no longer need to trust that these attestor sets behave, but you can now cryptographically verify that they did. And another important distinction to make here is that every time we bridge from a Celestia roll-up to another Celestia roll-up, this transfer would need to go through Celestia because, again, they rely on Celestia for consensus. And this is lazy bridging on the high level, by the way. And now, with the two circles gone, which means that we eliminated the two trust assumptions, and we're left with a single trust assumption, which is the DA layer itself. And now I would like to go into the lazy bridging protocol itself. I won't be able to go too deep into the proof systems because we don't have time, but hopefully I'll be able to explain a little bit on a deeper level how the ZK-IBC transaction flow actually works and how we verify these execution proofs. And you can see a diagram here. And I would also like to go into how you can follow this diagram in a way that makes sense. You can see different containers. We have the Cosmos SDK side and the roll-up side. The flow is numbered, so you can go 1, 2, 3, ABC and follow the flow. I'll try to mention where I am in the flow so you don't get lost. And let's define the systems on the high level. On the high level, we're transferring tokens between CMAP, which is a Cosmos SDK chain mimicking Celestia. We have a ZK pluggable EVM chain via IBCv2, formerly known as IBC Eureka, and IBCv2 solidity contracts, which are basically what Celestia also has as IBC modules. But in order to make them compatible, they have to be in solidity because this is an EVM roll-up. And when it comes to proving, we use S2SYNC's FP1 framework, where we define custom stack-based circuits in Rust. These proofs are later compressed into a Rust 16 proof to reduce the size and enable fast on-chain verification on the EVM side. Now, let's get into the demo itself. And before we start, we won't be demonstrating how we bridge across two roll-ups. I will be telling you about how we go from the DA layer to the roll-up and back. And the flow would be the same if you wanted to go from roll-up A to roll-up B. Once we understand the proof system, I hope it will make sense. So, we start the transaction flow by users submitting a message transfer to Celestia. Celestia will process this transfer and write a commitment to its state, which is like a verifiable receipt that the transfer was actually executed. We have a relayer here, which will be listening to the events that Celestia emitted. And once it sees that a cross-chain transfer was executed, it will take this transfer and check what the destination is, what the source is. In this case, it's the EVM roll-up, so we will relay this transfer to the EVM node. Now, how do we prove to this EVM roll-up that CMAP has executed this transfer successfully, actually saved the commitment in a state, and the state of Celestia has transitioned from one state to another? This happens in two ways. So, a relayer will ask Celestia Prover Service, which is a service that's responsible for generating proofs based on the circuits that we have defined here. And the flow is split in two parts. First, we have to prove successful state transition, and then state membership. So, when it comes to state transition, since this is a Celestia, and it's a proof-of-stake network and has large validator sets, the circuit will perform skipping verification. And as long as two-thirds of the validators have signed over the header, it will deem this as valid, and deem the proposed state valid, and generate the state transition proof. Then the relayer will take the state transition proof and submit it to the roll-up node as message update client. The roll-up node will execute that and apply this proposed state to the last trusted state it was tracking from CMAP. So, now we have proven to the EVM that CMAP has actually updated its state, but we still have to do the second part, which is proving the commitment membership in this state. Now, Cosmos SDK uses IVL Merkle trees in the state machine, and this is where commitment will be saved. So, what the prover does is that it will just check that this commitment is a valid leaf in the IVL Merkle tree. And once we have this proof, the relayer will take it and submit it as message receive packet. I already had a flow detailing some of the inputs and outputs, but I didn't want you guys to get distracted with it, because it doesn't really mean much unless you know how IDC works and how Celestia works on a deeper level. So, I wanted to explain it first, and then if out of curiosity you wanted to look, here it is. So, yeah, last one was the state transition. Now, this one's membership. These ones are pretty simple, because as I said, we're going from a proof-of-take network to a roll-up. Now, we're actually... So, once the transfer is executed on the EVM roll-up site, the EVM will produce an acknowledgment and save in the state that the transfer was actually executed, and it's transfer was executed, and it minted the tokens to the receiver, et cetera. So, now we need to take this acknowledgment and relay it back to Celestia, which is where the interesting proving parts come in. The flow is the same, even though the execution environments are different. We need to prove valid state transition, and we need to prove valid state membership. And how this happens from the EVM side is that, as I already said, EVM has attester sets, Celestia has validator sets. So, here we cannot perform anything like skipping verification, because we do not trust the signatures of these attesters, and that's not enough to be sure that the execution is valid. So, if we want to transition from trusted state 10 to, for instance, 15, we would have to validate every single intermediate block. So, how that flow goes is that we will check that the roll-up has been successfully posting these blocks to Celestia, and we do that by getting the block commitment and the DA inclusion height, then we can actually deploy the blob, which is the roll-up block itself in the Celestia namespace. We will check that the blob is part of the data route at the specified roll-up namespace, and once we have this blob, we will apply some sort of fork choice rule and check that maybe it was signed by the right sequencer. And after that, we will execute the blob, and we will check some execution invariants and the state routes against what the attester claims it to be. We will repeat this process for each of these roll-up blocks, and once we are done with this, we will take these stark proofs, and we will aggregate them into a single GROSS16 proof, and then we, yeah, we compress them into a single proof. And we will do the same thing, we will submit this as message update client to CMAP, and once the CMAP has updated the state, then we will need to prove that acknowledgement is part of the state that CMAP just updated to. This is very simple, this is not even ZK proven actually in this instance, because ZK proved, because it was kind of outside of the scope of the demo, but this can be done in the future. The priority here was verifying the execution of the block, so this is just a plain good old Merkle-Patricia tri-proof, and we're just checking that acknowledgement is part of the state route at the specified storage slot. So once we have this, we will submit this, the relayer will submit this as a message acknowledgement to CMAP, and CMAP will check that acknowledgement is part of the newly updated roll-up state, and once that's done, CMAP will discard the receipt, and just keep the acknowledgement in state, and will release the funds from the escrow account. Here I had more stuff about the state transition, the membership itself, but I didn't want you guys to be distracted with this either. Here we can see on the high level how the flow actually works, you have different Celestia state routes, data routes, and then we check the inclusion like I already mentioned, and this is just a plain Merkle-Patricia tri-proof. And now when it comes to challenges, the proof generation is slow, costly, and resource networks like SB1, it's still challenging to generate, because it's a lot of computation, so it's very challenging and slow to generate this proof. We also do the proof generation on request, where every time we transition from one state to another, we generate all these proofs all at once, which becomes incredibly slow. We could do this in parallel, where every time a new roll-up block is executed or committed to Celestia, we will generate the proof already, so in case we want to update the state that we can use that directly. And overall, I would say that this tech is pretty complicated, it's a high barrier of entry, and yeah, I think that's it, and we're done with the transfer flow and the demo. Thank you. Do we have time for questions? I mean, I wanted to close it out by saying, yeah, and Nina, you can find me on GitHub, as Nina Barbek has the same on X. And if you're interested in diving deeper into the prototype repo and how these proof systems work on a super deep level, here is the link of the repo. And if you have any questions, please feel free to come to me directly, and I'll try to answer them to the best of my ability. So just to remind, if you have any questions, you can scan this QR code at the top right, and there is actually already a few questions here. One of them is concerning the upgradability of the ZK circuit. They ask, what if you need to update the verification key of the SP1 ZK circuit? Who has the control over upgrading that? So I have not actually thought about this too much, because this is just a proof of concept, and this was just for us to have a mental model on how these things actually work. My team is actually already working on productionizing this, and I think they're still deciding on how upgradability is going to work, how we're going to verify proofs in our state machine, because we don't want to enshrine anything into our state machine that would require some sort of a hard fork. So it's a good question, but I would say that this is to be decided. Gotcha. And then another question here. Wow, there's so many questions. This is actually the wrong screen from the spicy anime previously, but there are actually multiple questions here. They're asking, isn't generating the proofs on demand a potential vector for DDoSing? Probably, but no one will DDoS this because this will not be deployed on mainnet or even on testnet, so we can be cowboys here. And one final question. Can proofs be shared across smart contracts from different projects, or do apps need to generate their own? Wait, can you repeat the question? Can proofs be shared across smart contracts from different projects, or does every app need to generate their own? Maybe. I mean, the proofs, you mean the verification of the proofs? Can proofs be verified across different smart contracts? I don't really understand. I guess they're asking who is generating these proofs for the state transitions. It's a separate process. You will have a circuit, and you feed some inputs to it. It will do the computation, and it will commit over the computation and return out the proof with the public output and et cetera. So this is universal, and all of these things are written in different languages, like Celestia, Consensus, Estate Machines, and Go. Obviously, we have Solidity. Then we have circuits written in Rust. So yeah, this is sort of modular and pluggable. Okay, perfect. Thank you for answering those questions. Can we get one more round of applause for Nina?