Introduction to Validating Bridges and Layer-2 Protocols with Patrick McCorry | a16z crypto research

Transcript

Um so welcome everyone to today's research seminar on A16z crypto. I'm very pleased to introduce Patrick McCorry of ConsenSys / Infura who's been in the space for a long time speaking about a topic he's thought a lot about. It'll be really fun to hear him talk about layer two and bridges. Awesome. Hi everyone. So what I want to talk about today is an introduction to layer two and bridges. So my goal is to really So this is like a slide deck that I've been iterating on for about three years. It is not necessarily deeply technical, but there are some technical parts to it. It's mostly to help people work the mental model of how to think about layer two protocols and bridges and how everything ties together. And of course, what the

problem people are trying to solve and the threat model around that. So without further ado, most people here are aware cryptocurrencies do not scale. You know, Bitcoin supports in the magnitude of 10 transactions per second and Ethereum's about 15 transactions per second. And the issue is that when the you know, when we go above you know, the transaction throughput, you know, we go to 16 transactions per second, 20 transactions per second, the fees skyrocket. So I used to make a joke back in the day the fees would go from a penny to a dollar.

But now they go from a dollar to the $400. So has anyone here ever paid $400 for an Ethereum transaction? Okay, no one here. Maybe someone on the call. I definitely have by mistake. Well, one is like have you been asked to pay $400? Oh yeah, have you had to cancel? Have you been asked to pay $400? Exactly. Have you been asked to pay $400 for a transaction? Uh so clearly you know, no one wants to pay $400 for a transaction. It's just ludicrous under any definition. Um but there's solutions out there that claim to solve the problem. So Solana, you know, they claim to do 65,000 transactions. Polygon claim to do What was it? I I don't I can't see it here you know, about 7,000 transactions per second. And Avalanche, you know, this marketing terms you know, we can go up

to crazy amount of TPS, have low fees and solve the problem. So clearly we don't need layer two. We don't need this talk, you know, we could just go outside and have a nice fancy Manhattan cocktail, maybe some vodka sauce pizza. Uh I'm only joking. Clearly that clearly we haven't solved the problem cuz otherwise we're we're still here. So the reason why we haven't solved the problem really comes down to the phrase you know, decentralization. And decentralization means different things to different people. The way I define it is really this overarching goal, you know, can we have a percentage of the world's population verify transactions in blockchain real time? So regardless if you're in China, India, Libya, Algeria, there should be

some people there who can run a node, download a copy of the database, follow the transactions, and protect the integrity of the network. You know, that's sort of the the bottleneck we're facing here with networks like Ethereum. You know, one aspect of being decentralized. And of course, it's a bit like you know, we put our rings together and we all protect the network. That's Captain Planet. I'm sure you've all seen that as a child. Um but because of this goal of decentralization, it also means that we've we have to artificially constrain the network's resources. You know, so we have artificially constrained the CPU, the storage, and the bandwidth.

And because we've artificially constrained it, what we end up with is a computer from the 1970s. It's slow, it's expensive, and everyone has to share it. So this is a picture of baby Vitalik with his little computer, and it's probably more powerful than Ethereum. Uh so what does scalability mean in this context? So typically when you think about scaling blockchain networks, the goal is really to you know, increase the transaction throughput while still adhering to the same set of resources. You know, so given the same set of resources, can we increase the TPS?

So that's how people have tried to scale the network and you know, it's a very difficult problem to solve. So the goal of a layer two protocol or an off-chain protocol is really a different take on how to scale the network. The goal is really you know, instead of transacting on Ethereum, can you take the assets on Ethereum, move it to another network or a system, and simply transact there? But at the same time, can we still retain the security of Ethereum? So you know, we can transact locally amongst ourselves, but still not have to trust anyone. That's sort of the goal for these layer two protocols.

So this brings me to crypto exchanges. You know, I mean you know, I'm not the SEC and I'm not here to dox you, but you know, raise your hand if you've ever bought cryptocurrency before from an exchange. There you go. Yes, there you go. We got some hands up. Always have some crypto talk. Uh but this is important, you know, these cryptocurrency exchanges are basically how we've scaled the network for the past 12 years. You know, and when you really think about what's happened for the past 12 years, one popular way for users to join the network is that they go on Coinbase, they buy their coins, they use Bitcoin, Ethereum, or Tron. I put Tron in here cuz it has more Tether than Ethereum.

They use cryptocurrencies as an interoperability layer. Uh but basically cryptocurrencies with this interoperability layer between centralized exchanges. And obviously Ethereum has DeFi now and that's sort of taken off, but for a very long time this was the primary use case of Bitcoin and Tron. But the issue here is that these cryptocurrency exchanges are custodial and they're private. You know, they can freeze, confiscate, lose our funds. You know, that's like Celsius, Voyager, BlockFi, and all of these crypto lenders that have now lost their funds. And they're not auditable. You know, there's no proof of reserves. We have no idea if their assets can cover their liabilities. You know, we can't

access the you know, the database of Coinbase and check its integrity. But what's the type So that's a stepping back a bit, you know, if this is how we've scaled the network, you know, what's the interaction what's happening here? You know, how we interacting with these exchanges? And really all we've been building for the past 12 years are bridges. So bridge engineering, you know, that's basically the focus for the past 12 years of of our industry. And at a very high level, you can imagine we have Ethereum. There's some smart contract on the network, you know, called the bridge contract that holds all of the assets.

And then you have this external you know, authority like Coinbase who are really you know, the single authority, the one you know, the one ring to rule them all. They dictate whether the bridge can deposit or withdraw can withdraw funds from the from the bridge. So at a high level, you know, Alice comes along and Alice is like, Coinbase, I want to withdraw 1,000 ETH from the bridge. And you can imagine the bridge has some functionality deposit withdraw allowance. Then Coinbase will you know, poke the bridge contract and say, Bridge, you're authorized to give Alice 1,000 ETH.

From the bridge's perspective, cuz remember the bridge is holding all of the assets. The bridge is basically you know, has the evaluate and say, is the off-chain database okay? Should I give Alice the 1,000 ETH? How can I trust the database is intact and secure? And in this case it's going to trust Coinbase and say, yep, I trust Coinbase to attest that the off-chain database is okay and well. So then it sends off the 1,000 ETH to Alice. But generically what's happening here? You know, what's happening at a high level? At a high level there's the bridge that holds all of the assets. And there's this off-chain database that records the account balances, the smart contracts, the state. And the off-chain

database is really the liabilities. It records all of the liabilities that eventually have to be resolved by the bridge. And what we really care about here is the trust assumption. How is the bridge aware that this off-chain system is intact before it allows any funds to be withdrawn? And this trust assumption has evolved over the years. So the basic example is the one ring to rule them all, the single authority, the Coinbase, is the Bitstamp, any centralized cryptocurrency service. You know, one with a single authority.

Then we tried to evolve from that. So you know, it's really easy for one authority to get hacked. So why don't we have a multi-authority? Why don't we trust five out of nine validators to protect the funds in the bridge? And then we sort of moved away from that as well and thought, well, why what about a crypto-economic bridge? And really when you look at something like Polygon and these multi-authority bridges, the only real difference is you know, how do we appoint who's a validator? You know, how do you become a validator to protect the funds in the bridge? So if you look at Polygon, this is from 2021, the top six validators on Polygon represented 85% of the stake. And so it's really just a multi-authority bridge. You know, I lock up MATIC tokens, I become a validator. I'm one of

six people. If we all collude, we can steal all the funds in the system. You know, very very straightforward. The only difference is that I have skin in the game. If I steal the funds, then my MATIC will go to zero. So you know, you like to think that would keep them honest. And so far it has, you know, basically. But the issue of all three approaches is that we're always trusting a set of authorities. We're still trusting a set of parties to protect the funds in the bridge. And this sucks. You know, it sort of goes against the whole movement of what Bitcoin was about. You know, in the you know, in the actual white paper of Bitcoin it's they you know, maybe it was the email or the white paper, but the problem they're trying to solve is all the trust that's required to make

this work. And now we've just reintroduced trust to make everything work still. And you know that's not an ideal scenario. But even the trust like an ideological perspective, we should remove intermediaries. But there's also a practical reason for why this is bad. And it's because exchanges just keep getting hacked. And they're not you know these exchanges aren't malicious. They don't want to steal your funds. They don't want to lose your funds. You know Celsius for example, why would they want to blow up and lose all of their customers deposits? They want to make money. They want to offer a service. But of course it's very difficult to do this. So for example Mt. Gox lost 850,000 Bitcoin which later became 650 K Bitcoin. That's nearly 5% of all

Bitcoin assets got stolen in a single hack. We sort of just put it under the rug and pretend it never really happened. You know that's sort of other state we're at now. And there's this wonderful spreadsheet by Tealer. She's recorded all of these hacks for the past 6-7 years. This is a great great data sample. But but the point I make here is that the security of these assets rely on human processes. If you want to run a cryptocurrency service today, you have to hire a security team who implement a set of human processes to protect a private key with access to all of the funds.

And what we're really telling companies is that okay, you want to run a crypto service, take these human policies or processes, implement it for your company, and then you'll go protect billions of dollars. And one that liability is crazier in seeing you know who wants to have you know one 10 billion dollars under custody, but the second part is that humans don't scale. We're not very good at scaling as a species. You know software scales, human don't. And that's why they keep getting hacked. Um so what about multi-authority bridges? We think oh well, let's just throw more people at the problem. And obviously that doesn't really work either. So the Ronin bridge was a great example. They lost 600 million dollar worth of ether at the time.

And when you look into it, it really wasn't a multi-authority bridge. It was five out of nine validators got compromised. Four validators belonged to the same company. Those four that company had pseudo access basically to another validator. And basically you know had admin control over everything. So they lost all the funds. But you know but still an example of a multi-authority bridge getting hacked. And there's also these crypto-economic hacks, but I haven't got a good example yet. My best example's Been stalked farm. They the the attacker took a a flash loan to take over the governance process to steal all the funds in the system.

Of course you know if you implemented it well, you could at least get rid of the flash loan issue. But still you get enough funds, you can steal everything in the system. And that's also not a great a great outcome. So I feel like as a community we've sort of forgotten about this old school motto in the Bitcoin community, you know not your keys, not your coins cuz we keep giving our coins away to other people. And we should sort of bring this back as a philosophy for the next for you know for the next couple of years. So the question is you know can we transact on an off-chain system while still allowing users to maintain self-custody of their funds? So not have to trust the off-chain system.

And this was the goal of the original sidechain paper in 2014. So they didn't use the word bridge, but it was a two-way peg. The idea was that I could take my assets that are on Bitcoin, lock them up, release them on an you know experimental sidechain, transact there, and then bring my funds back to Bitcoin. That was the goal of the sidechain paper, this two-way peg, no human intermediary that we don't have to trust. Um and if I were going to call this a new name today, I would call it the consensus bridge. You know I lock my funds up on Ethereum for example, unlock it on this other network. I trust the consensus protocol, you know the stay alive, make progress, and eventually lock my funds here and get them back on

Ethereum. Um you know that's the basic concept. And then on Ethereum what you would receive is maybe like block headers from the other network, maybe Bitcoin block headers. Maybe there'll be a you know eventually I could say here's a block in Bitcoin, here's a transaction where I destroyed the coins, and I can unlock them back to Ethereum. You know that's the typical sidechain goal. But what is a consensus decision? You know if you think about what is consensus, it's a judgment of a set of parties. You know we have a consensus protocol. We rely on an honest majority to make a decision in order to you know decide which transactions should be accepted. It's a very maybe trivial naive way to explain it, but that's

in basically what a consensus decision is. And so actually we're still trusting a set of external parties. In this case we're trusting the external consensus protocol to protect the funds in the bridge. So a really good example of this would be let's say Bitcoin was a the experimental blockchain, and the bridge relied on you know the consensus protocol on Bitcoin to agree that this is indeed you know a transaction that should be processed. If I were the attacker, I would create six fake blocks on Bitcoin, send the blocks to Ethereum with the invalid transaction in there, and then I would use that invalid transaction to steal the funds from the system.

You know you're relying on the consensus protocol of the external system. The bridge has to follow and trust the judgment of this external consensus protocol. Now what's the issue with this? So safety you know, can we trust if the sidechain blocks are valid? You know we could solve it with cryptography. You have validity proofs. You have these zero knowledge proofs. You prove that a block's valid and there's no invalid state transitions. But the real problem with the sidechain paper was liveness. If that consensus protocol goes offline for whatever reason, your funds get stuck on the experimental blockchain. Cuz you can't create a new block. You can't say I want to withdraw my funds. And then you can never prove that to the bridge. So the real issue there was this liveness. You know you

have to trust the consensus protocol to remain alive and well in order to get your funds back to the bridge or out of the bridge I guess. And that's how the Rainbow bridge works, the Near Rainbow bridge. So when Near and the Ethereum smart contract it relies on a set of signatures from the validators. You know on the Near blockchain the validators signing blocks. That gets sent to Ethereum, and then you could just prove there was a transaction processed and you get your funds out. It's just relying on the signatures of the validators. So they've implemented what was basically the sidechain paper but for uh Near and Ethereum.

So obviously the issue there is if the consensus protocol breaks, my funds get stuck. So we still haven't really solved the problem. We have to trust this external system to stay alive. So can we really build a bridge that protects us from an all-powerful adversary? So even if the operators go offline, I can still get my funds back out. You know that's the goal. And this was the goal of Plasma. You know this was the 2017 paper about Plasma. You know it was really exciting because it solved the liveness issue or at least we thought it did.

Um has anyone here tried to read the Plasma paper? How did you find it? You forgot it. It's the most it's just like the lightning paper. So Joseph Poon has a wonderful style of writing. It's in very difficult to read, very difficult to understand. For this one I didn't actually really try to read it. I glanced and gave up. But you can see here you it's the whole idea is that you're there's a sidechain, and the bridge is verifying everything about the sidechain. You know it's that's the goal of Plasma.

But the problem with Plasma was that no one really understood the design space. Both in terms of integrity of what you're proving or what you're trying to convince the bridge about, and also about making data available. And we'll go into that in a bit. But they led to all these crazy designs. None of them were practical. It sort of felt like we wasted two years trying to design these and none of them really worked. But what you know what Plasma was trying to build is what I would call a validating bridge. And it's very straightforward. You know it's a very different mental model to what we've had so far.

So ideally there's still you know an operator what that we could call the executor. And the executor wants to update this off-chain database. You know it takes a list of transactions. It wants to update the database. And then of course convince the bridge that this is the new state of the database. So I got this wonderful little animation here of the update. And then the executor will propose an update to the database to the bridge. Now the difference is that the bridge will not blindly trust the executor. The bridge will say, you've given me an update. You have to convince me that this is valid.

And how do we do that? You submit convincing evidence. So as we'll see that could be the fraud proofs or the validity proofs. You have to convince the smart contract that this update is valid before it gets processed and accepted. And the maybe the thing to highlight here is that very so unlike a layer one blockchain, when you think about layer twos and rollups, the only thing that matters is the bridge. It doesn't matter you've got a peer-to-peer network or I don't know crazy you know ways to propagate data.

The sole decision maker is the bridge. If the bridge receives an update and it gets accepted, that's it. It gets processed. It's final. Funds get out. We don't rely on an honest majority. We just rely on the bridge to make the correct judgment. And that's very different to how you design a layer one blockchain. You know on a layer one blockchain you're making this peer-to-peer network, consensus protocol, honest majority. We have none of this for layer two. It's just a bridge. And that's very different mental model between the L1 and the L2. And of course, you know, the bridge will say, "Is the database safe and alive?

Follow data, it's all accepted." And this is what the roll-up projects are trying to build, you know, the Loopring, Optimistic Ethereum, ZK-SNARK, Arbitrum. They're all trying to build a validating bridge. They've all got very funky names for them, but this is ultimately what they're trying to build. And ultimately, if this works, that would imply that the layer one blockchain is protecting you. And that's sort of like this little boxing match. I don't really know who Mayweather's punching there, but you know, if the adversary tries to censor your transaction, you'll punch the Ethereum doesn't allow that to happen. They try to include an invalid transaction, nope, we don't allow that to happen. They try to withhold data and they don't allow

you to recreate the database, nope, Ethereum does not allow that to happen. You know, Ethereum's protecting you and your funds on this off-chain system. And it's really the marvels of engineering. I just saw this article somewhere and thought it was really relevant. All the bridges people are trying to build are crazy and they have the wacky design, the most famous bridge, the tilting bridge. When you look at the smart contracts, they're all very weird bridges that they're building. This all sounds really cool. But how does it work? You know, it sounds a bit too good to be true. And it is slightly too good to be true, as we'll get into it.

So, what I want to define now is the environment, you know, here are the players. At a high level, how does this work? And what's the threat model and the security properties? Then hopefully some interesting research questions as well. Uh so, here are the agents. There's typically three. There's the honest user. That's us, you know, we like mooncats. I have a mooncat. I want to check my mooncat on the system. There's the sequencer. The sequencer's only job is to take a list of transactions, order them for execution, and then pass them on. So, it's an ordering service.

Then afterwards, you have the executor who takes the ordered transactions, executes them, and proposes a new state of the database to the bridge. So, at a high level, as I mentioned, the sequencer is a transaction ordering service. Alice comes along and Alice wants to use the layer two system. So, deposit funds into the bridge, and this will be reflected on the on the layer two system. Then Bob comes along. Hi, Bob. And Alice wants to send coins to Bob.

So, Alice will send a transaction that gives one coin to Bob. Now, the sequencer could optimistically tell Bob, "Bob, your transaction's going to get ordered for execution." But it's not yet ordered. It's just a promise. Then the sequencer waits around for a while for more off-chain transactions. There's no more transactions. And then eventually, the sequencer will post this list of transactions to the bridge. Now, not every roll-up works this way, but uh you know, this is roughly what's happening.

So, the list of transactions get hit to the bridge, and the bridge can order this for execution. Now, they're ordered, but they're not yet executed. And then eventually, the executor comes along, and the executor will take the list of pending transactions, execute them, and then propose an update to the bridge. So, again, my 1990 on a mission. And then the executor will post a checkpoint to the bridge to say, "Bridge, here's the new state of the database." And this is again a continuous process.

We order transactions, we execute transactions, we order transactions, we execute transactions. And what's really nice actually is uh because the transactions can be ordered first, as long as your transactions are ordered for execution and this is final, the act you know, we can all verify how it's going to be executed. So, the execution can actually come later. So, we just care that it's ordered first, and then eventually, the system catches up and executes it. That's really important for the optimistic roll-ups. But anyway, the whole point is that eventually, an honest user like us, we could take all the data from the blockchain and compute a copy of the database ourselves. We can independently verify that the database is also

correct. So, what's the threat model? You know, what is the adversary here we're trying to protect against? So, there's two things to consider. One is the message flow. We just assume that an honest user can transact with the bridge and the layer one blockchain. Any messages on the layer two system could be viewed, reordered, or just dropped by the adversary. So, we we have no guaranteed message delivery on the layer two system at all. We also assume the adversary can corrupt nearly every single party. We assume the adversary simply cannot corrupt the layer one blockchain and one honest party that could also be the user. We assume this is a one honest party

assumption outside of the system. But everyone else can basically be corrupt. So, this is a very powerful adversary. You know, they can they can, you know, drop all the messages, corrupt nearly everyone, and obviously, they can't break cryptography. And as you'll see over the next year or two, not every roll-up has the tools to fully constrain this beast. And there'll be some roll-ups that are deployed that cannot that aren't really a roll-up cuz they can't, you know, satisfy the threat model. But we won't talk about that right now.

Um but I do want to highlight though is that back in 2019 when we were discussing this, Georgios had this wonderful tweet to say, "Layer two security should equal equal layer one security." I'm a believer. I mean, I I At the time, I thought that was too ambiguous. You know, layer two can never be layer one. What we're really debating is how close we can get to layer one security. It was that closeness that we're really debating. Because obviously, layer one, your funds can never be stolen. Layer two, there's still always a chance that it could be or your funds get frozen. So, it can never be the same. But how close we get is what we're debating.

So, what about the security properties? You know, what does it mean for a roll-up to actually be secure? Cuz I keep saying it's secure, but what does that actually mean? So, at a high level, the way to think about it is that there's this off-chain database, and the bridge's only goal is to protect its safety and liveness. And there's three sub-goals to this. One is data availability. How does the bridge guarantee that all data is publicly available so that one honest party can get a copy of the database?

Two, state transition integrity. How is the bridge convinced that a proposed update is valid or correct? You know, how all the transactions are processed correctly. And three, censorship resistance. So, if the entire system goes offline, how can we guarantee a user can still get their funds out of the system eventually? So, the data availability problem, let's talk about that first. And there's three questions to ask, you know, why does the data need to be publicly available? You know, that's clearly a good question.

What data needs to be publicly available? And how do we guarantee that it is publicly available? So, why do we need the data to be available? So, this is sort of the L1 versus the L2 dilemma. When you think of an L1 blockchain like Bitcoin or Ethereum or Solana or whatever else, the database is the assets and the liabilities. You know, in the you know, basically, you cuz the database represents everything, and we rely on an honest majority of the consensus protocol, we can always guarantee it's available and that everyone can get a copy of it.

It's not dependent on another system. The database is the root of trust. Where for a layer two system, it's very different. The database is just the liabilities. And only And what really matters is the bridge. The bridge has all of the assets. It's external to the system. It has not, you know, it's not connected to the layer two system. And the the bridge needs to guarantee that one honest party can get a copy of this database. So, that's why it needs to be publicly available. The bridge needs to guarantee there's one party out there who can get the database and eventually propose an update to the database.

So, it's a very different, you know, mental model of L1 v L2. I also wrote a blog post on this. If you want to read the blog, I can send the link cuz I think that mental model's really important. But why does the data need to be publicly available? As I mentioned, the you know, the roll-up should really have a one honest party assumption, and it's really an assistant. You know, the the honest party is assisting the bridge. The bridge makes the sole decision, but it has an assistant to help it make that decision. And there's, you know, the real reason is to guarantee that one honest party can propose an update. So, we can enable liveness for the system.

Other reasons may be you want to audit the database. You know, maybe you don't want to put your funds in the Arbitrum unless you can independently verify the liabilities cover the assets. And also, maybe to withdraw your funds. If I want to withdraw my mooncat from the system, I should probably check my mooncat is on the system before I withdraw it. Very, very straightforward. And of course, what if the data wasn't available? What's the danger here? The danger is the adversary could freeze the funds in our system. You know, the issue there is that if if only the adversary has a copy of the latest update, the honest party can't get the latest update. So, the honest party can't get a copy of the database, and so they just can't propose an update.

So, if the honest party can't get a copy of the database, your funds can get frozen forever. That's, you know, a pretty bad problem. Two, if it's a fraud proof via system, as we'll see, they could also potentially steal your funds. They could propose an update that includes an invalid transaction that steals all of our funds, and that's also not great. They could also trick us about entries in the database as well. You know, they may tell you you have less or more money than you actually do. So, what about the data? What is actually posted? And there's two flavors for this.

One approach is that you send the transaction data to the bridge. If you send the list of transactions to the bridge, the bridge can order this for execution, and then later on, you just post a little checkpoint to say, you know, this is the new state of the database given how these are executed. This is what Optimism and Arbitrum do. They post the the list of, you know, list of transactions. Where the validity rollups, like, you know, StarkNet or zkSync, well, I guess StarkNet was primarily the ones last year. I don't know if zkSync is actually doing it yet. But StarkNet posted a state diff.

So, the ordering of transactions happened off-chain. Now, you give it to the sequencer, they pass it to the executors, they create a validity proof and a state diff of the database. They post a state diff to Ethereum, and then as, you know, an honest party, I can just pick up the state diff, apply it to my database, and I have applied the update. And the state diff is just, you know, here's the you know, the storage slots that you have the update, and here's the new value for the storage slot. What's interesting there is that the transaction details are not public.

You only see the effect of the transactions. So, a good example of this is that you could have 1,000 trades, you know, buying and selling the same asset, but given those 1,000 transactions, you just have to update two storage slots, or maybe some of the account balances, but you know, you update this is the new balance of the of ETH relative to DAI, maybe. So, you just post the the you know, the result of the transaction, and not the transaction details. I'm a believer that the ideal bridge would have both, you know, but we can talk about that later. Right now, every project picks one or the other.

So, you could imagine validity-based rollups doing the first approach, right? Yeah, you could, yeah. But the point is, I guess, like, the K in the SNARK kind of allows you to get away with the second approach. Yeah, and you can aggregate the the data as well. But so, what's missing right now is, and I don't know if StarkNet have done it yet, but I've spoke to them a a few times about it, is to really compare the data cost of both of these. Is it cheaper just to do transaction history, or is it cheaper to do a state diff? And to my knowledge, I still don't have a good answer for that. You know, there may be application-specific reasons why you would do one or the other. Yeah, it seems like they're variable like with how many accounts transactions typically touch, right? Yeah, exactly, and that's

the very much missing piece of work. Right now, people are simply assume the state diffs are better. Uh but, you know, it's I think it's still out there what what the real answer is. Yeah. Oh, the transaction data is the public plain text of the data. I think she said the right hand side. Oh, the right hand side. It would be part of the the hash, I guess, but you know, the checkpoint. I would assume what they do is, you know, it's a tree, a part of the branch would be the list of transactions, the other one would be an update to the database.

But even then, you may you you wouldn't post the you don't have to post yet the transaction data to be a commitment. I'd assume. I'm I don't know the exact details of how they've done it. Um Any other questions? Is everyone happy? I should have asked earlier if there was any questions. Okay, safu safu. So, how do we guarantee the data is actually publicly available? That's a big question. So, back in Plasma, the initial approach was an on-chain challenge. The operator would send the you know, the checkpoint to the blockchain and say, here's a checkpoint, I attest to the fact that this is public.

Then any honest user could come along and challenge the bridge to say, bridge, I can't find the data, can you make the operator reveal this on the blockchain? Now, this has a something called the fisherman's problem that we can talk about later, where the smart contract can't describe who's at fault. But this was the single issue that broke Plasma. They just couldn't solve the data availability problem, and on hindsight, I would argue it's because they didn't really understand what they were challenging. Do you challenge the update, or a specific value in the database? But again, we can talk about those design issues.

Um The other approach is to rely on a trusted committee. So, this is the Validiums, the Anti-Trust. The idea is that there's a committee that will sign off and attest to the fact that the data was made publicly available. And then the bridge will just assume that this is correct. Uh there's also this trade-off between liveness and safety. So, in Arbitrum, they assume as long as two parties are honest, the data will always be available, otherwise you default back to your rollup and just post the data as a rollup or on-chain. Which brings us to a rollup. The way a rollup solve the problem, and this is thanks to Barry Whitehat, you take all the data, and you just post it to Ethereum.

And that's how you guarantee it's available. Now, what's interesting is that the guarantee for this availability is very subtle. It doesn't guarantee that all historical data is available. A layer one blockchain like Ethereum only guarantees that recent data is available, you know, probably the past 10 blocks or whatever. So, anyone who's online at that given time can fetch the data. It doesn't actually guarantee you can fetch all the historical data. The peer-to-peer network just gives us that today. You know, if you you right you know, you get an Ethereum node, you run it, you connect to the network, you download all the historical blocks, you catch up, then you start getting the recent, you know, decisions from the consensus protocol.

That first part, the historical part, it's nice the peer-to-peer network does that, but there's no reason why it has to do that. You know, you could really get that data from elsewhere. So, the subtle guarantee is that it the peer-to-peer network only guarantees that recent data is available. And based on that insight, that's sort of what's behind EIP-4844 and the roadmap of eventually expiring data, you know, allowing data to eventually get deleted. So, maybe you join the network, and you don't have all of the history. You just get the recent blocks and, you know, a copy of the actual database, and you check that's correct. So, it's a very subtle very subtle guarantee.

And is the idea that like there should be some library of Congress which is not necessarily like running consensus or execution, but nonetheless storing the entire history since genesis, or is the idea more like, you know, if it's more than a month or a year old, like, too bad. I think I think it's the the latter there. It's more like weekly subjectivity. Basically saying that the history eventually doesn't matter. We've all reached social consensus that the database is correct up to this checkpoint. Yeah, so it says weekly subjective. I'm a proof-of-stake have that property anyway, so you may as well leverage it to get rid of the historical data. But in Bitcoin, they want to remain objective, so they try to enforce history to always be fetched.

But bingo, you know, this is the rollups, this is why everyone got excited. The reason why this is significant is because back in the Plasma days, they're trying to solve data, they're trying to solve integrity, then Barry Whitehat comes along and just gets rid of one of the problems. You know, data availability is no longer an issue, you just post it to the blockchain. So, from 2019, 2020 onwards, people could just focus on how to guarantee integrity, you know, the state transitions. And that actually you know, it just simplified the entire design space. Which again, in hindsight, seems obvious.

Um So, what about the state transition integrity problem? So, it's very straightforward, you know, we're posting these little checkpoints to say, here's the new state of the database. We want to protect against an adversary who would say, you know, they would say, here's a checkpoint, but the database included an invalid transaction and sent them all the money. Um so, this is probably the most interesting thing that everyone likes to talk about, but I'm not actually going to allude on it too much. This is the optimistic versus the ZK, the fault proofs versus the validity proofs.

Um this is what everyone talks about because it's a very interesting problem to solve, but I'm actually going to miss most of it today because I think other problems are more interesting and more important. Uh but of course, we can talk about this if you want. Um I I I always tell the rollup projects that they should focus less on this problem. And then they guess they never listen. They never listen to me, exactly. That's why they're not censorship resistant, which brings me to this slide. Censorship resistance. Um so, the idea here is that what if the sequencer doesn't cooperate? You know, I send I give my transaction to the sequencer, and the sequencer is like, haha, no party, you can't get your moon cat out. Well, that would suck, wouldn't it? You want to get your moon cat out.

So, how do you solve this problem? So, the insight here is that there's two parties. You have the sequencer and the executors. Now, what's really nice is that the sequencer has absolutely nothing to do with censorship resistance at all, and we're going to see why in a sec. What really matters is that there's one honest executor, which could be anyone here who could take the list of transactions, execute them, and propose a an update. Once the transactions are ordered, then anyone can execute that. So, what we really have to focus on is how the transactions get ordered.

So, there's two ways to solve this problem that have emerged over the years. One is an on-chain exodus, and the other is called forced inclusion. And they're they're quite similar. So, let's talk about on-chain exodus. This is how the V1 rollups did it, the StarkEx and the zkSync. So, the idea is that Alice can send her withdrawal transaction to the bridge. And the bridge will say, you know, "Executor operator, you have to process this transaction by a deadline. If the transaction does not get processed, I'm going to freeze the entire system and allow everyone to withdraw their funds."

And obviously that's how it works, you know, so the executor will post a checkpoint. It does not include the sent transaction and eventually Alice can then send a transaction that freezes the entire system. Now, that's great. Well, it's not as great on board. It's great in the sense that the entire system will be frozen and then everyone can just withdraw their funds from the system. The bad part is that uh these type of systems can only support transfers or swaps. You need to make sure that the every user has an account balance and the funds are not stuck in a smart contract. If your funds are stuck in a smart contract and the system gets frozen, well, you can't get your sitting you can't process the transactions. So,

they only works for payments or swaps. What is this you know on layer two? On the layer two, exactly. Yes, yeah. Only the layer two can support transfers and swaps. So, that's the case saying can start X. They can only support state, you know, basically single state transitions. Um So, you disable the entire off-chain system. Very extreme. That's what they've implemented and so far they've not been frozen. So, this restriction is somehow like I often thought of a restriction to payments is just making sure you only have to approve relatively simple statements. Yeah. But you're I mean this is this is a completely different sort of architectural payoff you have with that restriction.

Yeah. Right, which is interesting. Yeah, so what the next one is uh forced inclusion. So, obviously we want to have smart contract enabled off-chain systems cuz that's more interesting than just payments. So, the guarantee has to be that the system always remains alive. It can never be frozen and it can never be stopped. So, again Alice will send her transaction directly to the bridge. The difference is that the bridge will force all transactions to be executed in order.

They got the subtle difference. So, the executor could test this and say, "Okay, I'm going to test the bridge and try to exclude that transaction that was ordered." You know, they post a checkpoint without Alice's transaction. The bridge will get angry about this and reject the update and obviously slash the executor, you know, give or take. Uh so, basically you get punished. You get your head chopped off if you try to censor someone's transaction. So, that's the forced inclusion part. Now, that you know, the the trade-off here is that I mean there's a lot of nitty-gritty details here that are not well explored.

There's a lot of various conditions. You know, what if the adversary can always get their Actually, I have a I think I have another slide so we can talk about that in a bit. But basically forced inclusion is the best way to solve censorship resistance, but it requires a system remain online and for one honest executor to eventually process your transaction. But again, there's lots of nitty-gritty details that people don't talk about. But if we can solve all three problems, you know, data One story would be like ideally you could yourself even if you're a user you yourself could provide that update. Yeah, exactly. Yeah, yeah.

Yeah, so that would be the ideal goal, but um so so one good example there would be if you're an honest party on Arbitrum, you would have to stake funds, become a state defender, and then get your checkpoint in before everyone else. So, there's this barrier in terms of just how much do I have to stake to become an executor. If I have to stake a million dollars, then you know, I'm not going to be able to do that anyway, so you know, it's not censorship resistant for me in that regard. If it was StarkNet for example, well, the prover is closed source, so I can't actually produce a block cuz I can't prove a block.

So, there's also lots of practical details around it, but um maybe Let's go back. If you can solve data availability, state transition integrity, and of course censorship resistance, then maybe we can slay the beast and deploy a secure layer two system. And for reference, this is the bear wheel from 2014. That was actually Bitcoin logo that I swapped to Ethereum. It was back when, you know, Bitcoin was crashing to $300, but the traders fought off the bear wheel. It was on the Bitstamp exchange, which is a bit of Bitcoin history. Uh but other problems do arise.

Oh, it's an incomplete slide so we can just move on. Uh but other problems do arise. One is uh MEV. You know, I'm sure everyone here has heard about MEV before. You know, the sequencers in a privileged position. They have all the transactions off-chain. You know, they offer the fast path. They get all the off-chain transactions. They can exploit this to their, you know, whatever they want to do and extract everyone's value from everyone's transactions. Interestingly, you know, the debate now is is this a business model or an outright attack on the system?

You know, should we allow MEV to happen? And there's three takes on it. There's you can try to defeat MEV so you think it's an attack on the system. These are like the fair ordering protocols, the commit and reveals that, you know, remove the sequencers privilege to decide the order of transactions. They sort of come down to like a latency game, but you know, it's or at least for fair orders like a latency game. But you know, they try to defeat it. The other one is to smooth it out. So, instead of saying, you know, we used to say, "Well, MEV is not a bad thing. We just have We need to make sure that other people can get a share of it. It's not just the sequencer." So, this is the block builder proposer scheme. You know, you have searchers here are trying to

extract value. They participate in an auction with the sequencer. So, I say, "No, sequencer, if you include my batch of transactions, you get eight ETH." Someone else comes along and they're like, "Oh, if you include my batch, you get three ETH." The sequencer will take the batch with the has value, you know, eight ETH, execute those transactions, you know, order or put them in that order, then obviously they get eight ETH. The searcher gets whatever profit they they made from that, and you share out the MEV amongst searchers and the sequencer. So, you smooth MEV. That's how they describe it.

Or you could constrain it. So, what's nice about smart contracts is that you can really define how much you're going to allow someone to extract from you. So, an example I could set 1% slippage. What I'm basically saying is that you can extract 1% of my trade for me and I'm still happy. So, we can constrain it to some extent. You know, we're not we're not totally powerless against against MEV. So, you're saying so the smoothing and smoothing MEV, that's that just refers to like searchers taking a presumably sort of small portion of Yeah.

what the block producer would otherwise just extract it all for itself. Exactly. Or at least like That's true without any searchers from the block producer. Yeah, it trickles down, yeah. If If anything, it's um Yeah, it trickles down and it also maximizes MEV cuz searchers are dedicated to the sole purpose of extracting value. So, you're really saying, you know, "Here's a big batch of transactions. There you go, guys. Extract as much as you can. I'm going to share the profits." You know, it's very much the opposite end of defeating it. You're accepting it and fully exploiting it. If it's competitive, won't it eventually all go to the uh proposer?

Well, that's one of the arguments is that it could, you know, they'll only get a small slice. They'll get a tip, but everyone will get the sequencer. I think that's still you know, basically outstanding the thing they're trying to work out. But you would intuitively you would think that yeah, but it's just go straight to the proposer. Or if you're one big searcher and you're better than everyone else, then you know, how you're better you are than everyone else is the profit you can take. You know, if everyone else is going to offer five ETH, but you can offer eight ETH, well, I get the extra three ETH, don't I? Um but I really like I think this scheme is really interesting. I think just generally speaking it's quite an interesting take on MEV. That's I guess that's Hot Stuff in a nutshell.

They've basically implemented a trusted version of this. But you'd want to make it trustless. Another issue is that the sequencer is in a very privileged position. Obviously, they can exploit MEV, but the sequencer, they offer the fast path. You give me a transaction and I promise you this will be ordered and it'll be executed. You're trusting me for that. It also means that they're only party who has a view of the pending database. They have all the pending transactions. It's not necessarily public. And they could lie to you about the state of the database, you know. In the happy case, Alice will ask for us the exchange rate. The sequencer will reply with, you know, back then it was $3,000 per ETH.

Uh but obviously they're lying to us now, aren't they? But if they're going to lie, they could say, "Well, it's $10,000 per ETH." And the user really has no way to verify this because it's the pending state of the database. It's not the previously committed one. You know, you want to make sure you're always transacting on the most up-to-date version of the database. Only the sequencer has access to that. Cuz they dictate the order of your transactions. So, that's also a really annoying issue with the sequencer. I mean, I I ran out of time in my slides. So, let me add a last couple of points.

So, we spoke about sequencer privilege and MEV. Another issue that turns up is fragmentation of assets. So, right now everything's on Ethereum, give or take, you know, if you're Ethereum-centric, it's all on the single blockchain. With rollups, the assets get fragmented across different experimental blockchains. And the question is, you know, will that fragmentation harm adoption? I don't think it will because right now assets are fragmented across cryptocurrency exchanges, so we're quite familiar with this issue anyway. But it is an issue that pops up. But if the issues are So, if the assets are fragmented across different blockchains, what we run into is is cross-chain interaction or logic. You know, let's

say I'm on Arbitrum, and I want to grab an arbitrage opportunity on StarkNet, how do I facilitate this cross-chain transaction? You know, what are the trust assumptions around that? Who puts up the assets? And what happens if it fails? You know, let's say I go from Arbitrum, StarkNet, ZK Sync, Optimism. You know, I'm doing logic in each blockchain. What if one of them fails, like blockchain C fails? How do we handle the failure case there gracefully? You know, we have no longer guaranteed atomic execution of my transactions. So, the whole cross-chain interactions is very interesting.

I think we could let, you know, the basically like the Bitcoin Lightning Network is actually a solution to this problem for transferring assets, is one solution. You have other ones like Nomad that we can talk about later or atomic swaps or other other forms. But, this is quite, you know, this cross-chain interaction is very interesting. You know, how do you trustless trustlessly execute transactions across blockchain, and move your assets across blockchain within a couple of seconds, you know, without going by the bridge. Um another issue is posting data. You know, as we mentioned the data availability problem, we have to post all the data to Ethereum. And that's expensive. The next slide should show that this is what I took last year just to highlight the

data cost. This time last year, if you performed a swap on a V1 roll-up, the gas cost was reduced from 120 K gas to 5 K gas. I think it was 5 K gas to do it on Arbitrum or Optimism or something. But, that's cool, you know, that's 5 K gas, you know, 120 K gas is 20 times more expensive than 5 K gas. You know, so we clearly have a gas saving here. But, the majority of this cost is still data. You know, the data has to hit Ethereum. We have to pay for that data.

So, could we optimistically reintroduce the challenge process? You know, could we take the data, post it elsewhere, maybe with a committee or maybe like a maybe it's a Celestia, or maybe it's just an IPFS. Can we optimistically post it somewhere else? Have this challenge process where we can still force the operator to bring it back to Ethereum in the worst case. And how would that work? And I think that's actually very fairly I think it's more straightforward to do now than it was for plasma, cuz the design space is much more solidified.

It's very straightforward what data we're talking about. The main issue is really the fisherman's problem. You know, the smart contract can ascribe blame to either the user or the operator or the sequencer. So, how do you like what's the I think what you would really need is an evaluation around the financial cost there to work out how big a problem is it. But, I think that's resolvable. You know, I'm I'm quite bullish on that on that problem. But, um yeah, there's no solution to it yet anyway. Another one is delay attacks. So, what do I mean by this? So, when we think about the censorship resistance idea here, okay, so the user will submit their transaction to the bridge, and it'll be

ordered for execution. So, we know this has to get executed eventually. But, how long is eventually? One way you could think about it is that if the executor wants to censor your transaction, they could just get dummy transactions and stick it in the bridge before you. And then every time they propose an update, they're just doing it on their dummy transactions, and then eventually it hits yours, but that could be, you know, 1 day, 2 days, 7 days in in the future. Um so, how much does it cost an executor or a sequencer to delay the execution of your transaction?

And how does the bridge ensure that a minimum amount of competition was done? So, there's lots of little little pieces there to put together to, you know, to work out how how much does it cost to to delay your transaction. And delaying could be, you know, a big deal. You know, if I can make sure you can't withdraw your funds for 4 weeks, then maybe I'll, you know, lock you into the system long enough so, I don't know, just to stop you interacting with layer one blockchain. You know, maybe you you have to pay me a bribe to get your funds back out. You know, there's clearly going to be problems around that. Um and again, there's no work on delay attacks, you know. No one really understands, you know, if you look at Arbitrum today, how easy would it be to delay transactions there? And again, for the

other networks as well. But, I think mostly Arbitrum cuz they're the only one who's actually implemented that feature. Um also, is there a formal model of the bridge? There's no formal model of the bridge. I think um as I mentioned earlier, the two types of data, transaction data and the state diffs, I feel like you'd want both of those as part of your bridge. Transaction data for the forced inclusion for censorship resistance, and the state diff maybe for just what the executors post. But, there's no model around that of, you know, what is the ideal bridge, what's the ideal functionality, how do you get around those nitty-gritty details that emerge, like the race conditions.

Um I think that's really interesting as well. But, even with those problems, cuz there's still lots of problems that I probably haven't talked about, is it worth it? And as I mentioned, last year the data you know, the cost of a transaction went down about 20 times. I don't know if that's the best way to describe it, but you know, it's significantly cheaper. And costs are still coming down since I had that data. Um yeah, so it's definitely worth it in terms of cost. And in terms of just the mental model of how the system's going to, you know, the ecosystem's going to evolve, I'm a believer that, you know, for the past 12 years, we've scaled these networks with these off-chain systems, you know, the Binance, the Bitstamp, the

Coinbase. But, they're fully trusted. And we don't want to trust them. So, I see the evolution is that these roll-ups are going to not hopefully they'll replace them, but they're going to offer an alternative to the Coinbase, Bitstamp, and Binance. You know, the Optimism, the Arbitrum, the StarkNet. It's really just another centralized service where you don't have to trust the operator. And also like, you know, an open it's like an open database. You can either deploy your smart contracts on a system like Coinbase and interact with all of their users.

You could offer bridging services. You could quickly move your funds from one service to another. Something that just isn't possible today on these trusted exchanges. And I think this offers an off a good alternative to the existing system because custody is a liability. This comes from a blog post by Vitalik back in like 2019 where he basically describes that what's really exciting about web three and cryptocurrency is that we can now deploy systems where we don't have to take custody of users' funds. So, if I'm a roll-up operator, I deploy software, you know, I instantiate software. You lock your money into it, but I don't have custody of it.

And now I can deploy systems without custody. I don't have to take on the liability to protect billions of dollars. And that's just really beneficial. Um so, just to finish up, at the very start of the talk, I mentioned the need for human processes when you have a new cryptocurrency service. Cuz you have to protect the keys. You have to protect billions of dollars. And now, human processes don't scale very well, which is why people keep getting hacked. If one roll-up team can get the software correct and bug-free and easy enough for people to instantiate, then ideally anyone here, you know, you could take the software, instantiate it, and offer

basically the exact same service as what exists today. You know, you could offer an exchange like Coinbase. You could even offer an a service to buy and sell crypto. You give me the money, I give you it straight to your, you know, custody on the roll-up. All the services are very similar, but you just don't have custody. And software scales. You know, anyone could deploy that software and offer it as a service. So, I'm a believer that users don't care about custody. It won't be users that lead the adoption of roll-ups. They just don't care about security. It'll be the operators. It'll be anyone who's going to do a startup today, cuz as an operator, you don't want to take on the liability of custody.

You know, like Coinbase, I think how custody is 10% of all crypto assets. I do not want to have a startup that custody is 10% of all Bitcoin or crypto assets. That's just a huge liability that's hard to get right for the foreseeable future. So, roll-ups solve this problem, the problem of custody. And that's my last slide. So, I hope you all enjoyed the the session. IS THERE ANY QUESTIONS OR I DON'T KNOW. WHEN you say we just need one roll-up team um you touched on how you can have different attitudes towards MEV, liking it or not liking it. Isn't it application specific what your attitude

is? Like, do you see one team giving a solution where depending on your attitude towards MEV? No, yeah, I mean I think um what the one team has to get right is just those basic properties of data, censorship resistance, and state integrity. You know, just guarantee that you have this And what's also really nice is you can have a virtual machine that's not Ethereum, you know, StarkNet's Cairo, for example. So, as long as one team gets the basic, you know, premise right, then everything else is an add-on. Like, how do you deal with MEV? That's an add-on to the bridge. You know, you have this fair ordering protocol. You have a, you know, you just move it out. Those are just add-ons to the basic building block.

But, we just need this building basic building block first before you worry about the add-ons. You know, it's just even to censorship resistance, you know, that's still some of the roll-ups coming out soon will not have that built in cuz if they thought the they thought it was too hard. So, it's still very incomplete. Um Any other questions? I just want to make sure I understood something you said a few slides ago that's something interesting, which is that the optimistic data availability Yeah. Right. So, so we said you said the hard part, the unsolved part is kind of if you have a failure in data availability, there's two possible reasons for it.

One is the sequencer Oh, yeah. ignoring data availability person or there's a data availability person who's gone offline. Is that right? Yeah. Yeah, so I mean the fisherman the fisherman problem is basically the sequencer has attested to the bridge to say, "Bridge, I have made the data available." The user comes along, challenges the bridge to say, "Bridge, I can't find the data." The bridge can't describe blame. It doesn't know if the user's at fault or the sequencer's at fault. So, it's more of a, you know, who's at fault. And so, I think the goals for that would be you'd want to make sure that a user will only challenge this if the data is not available. So, there has to be some cost to the user for doing this. I would The way I thought about it is that the user would have to put out a bond a bound

that covers the cost of all the data. Which could be expensive, but you know, they they their upfront cost should be, "I'm going to pay for the data to be made available." But if you just did that one aspect, the issue is that the sequencer then has no incentive that they ever post the data anywhere, cuz the user's always going to pay for the data availability. So, I the way I thought about it is that the users would have to pay for it, but that gets burnt. So, you know, it doesn't pay for the sequencer. But then the sequencer we'd have to have a pot of money that covers data availability. And if that starts getting low, the user would have to, you know, users would be charged in the platform to top up the pot of money. So, the users would pay for it eventually.

And the sequencer doesn't want that, cuz the sequencer wants low fees. So, I think that's how you would do the incentives around it, but that's still an open problem. I think some teams are looking at it now but cuz it would be nice, you know, it would be the ideal world would be you could post it on I mean, I guess it's my promise Celestia. You know, Celestia's great data availability platform. But if you post the data there, you lose Ethereum security. So, the challenge process could give you the best of both worlds. You post it there cuz it's cheaper, but then in the worst case, you have to post it to Ethereum and just default your roll up. So, optimistically, you keep it elsewhere. I think that's a cool problem. And I think the missing part is really is evaluating after natural cost.

And maybe the game theory around, you know, making sure the sequencer has an incentive to keep the data posted up somewhere. Yeah. You're mentioning that there can be a delay between transaction sequencing and transaction execution. Yep. Uh can you explain again why why we need that delay? So, in roll ups is more So, it depends how the roll up's implemented. Not every roll up does ordering and execution. They do that off chain in a way. So, what's nice about the ordering is that if it's an optimistic roll up, an optimistic roll up has a fault proof system. You know, there's a there's a fault proof system.

The fault proof could take 7 days. So, you know, I you're the sequencer, I give you my transaction. Uh you order for execution, then we have to wait 7 days for the execution to be finalized. You know, that sucks. If I have to depend on the execution of this transaction, I have to wait around 7 days before I do the next step of the protocol. So, if you know the transaction's ordered for execution and the ordering cannot be changed, then we can all verify how it's eventually going to execute. So, it can get it can get ordered immediately.

You can verify that it's ordered and it will be executed, and then you could go do whatever action depends on it. Then after 7 days, it gets executed, then you know, it works. So, So, one of good example would be let's just say I want to help you get money out of Arbitrum. There's a there's there's like the the pinnacle example. You have You have let's say you have $1,000 in Arbitrum. And you want to withdraw your funds. To withdraw your funds today, you'd issue a withdrawal transaction. It gets ordered for execution, and then after 7 days, you can take your money out of the bridge.

But you have to wait 7 days, and that sucks. So, if I'm a liquidity provider, if I can see that your withdrawal transaction is ordered for execution and is going to pay me $1,000, then I could just give you the money upfront and say, "Okay, here's $1,000." Cuz I know I'll eventually get refunded after the 7 days. So, now I can offer you this service where I can speed up your withdrawal because I know how the transaction will eventually execute. So, that's why it's important that ordering can come before execution. You know, execution is really just a formality to convince the bridge.

But we can all verify how it's going to execute. So, you can optimistically act upon that as well. I You had a chart over there where you compared like ZK sync and optimistic fast withdrawals, right? Uh one of the costs of withdrawal, like was it like a What's the cost to process a withdrawal transaction? So, in the ZK sync example, they did everything in a batch. So, if they had to process 50 withdrawals, that would all come in a single Ethereum transaction. So, it aggregate out the average cost of 15k gas per withdrawal. Where Arbitrum wasn't Maybe it was Optimism wasn't really well implemented.

So, it would cost 500k gas per user withdrawal on the layer one. Oh, this is on the layer one. Yeah, that's on the layer one. These are all layer one costs. So, you're like aborting the whole your all your funds you want to just take it back. Yeah. Yeah. Yeah, so if you wanted to withdraw your funds from Optimism, you'd have to pay 500k gas on Ethereum. And that's cuz it just wasn't efficient. But why if it's layer one, why is ZK sync so cheap or ZK sync aggregated all the withdrawals. So, basically, they submitted one Ethereum transaction that issued 100 customer withdrawals. So, they were just very smart at how they implemented it.

Okay. Is there any way like if I if I think ZK sync is going offline and I just want to abort the whole roll up and get my funds without any involvement from ZK sync? You would submit your transaction to the bridge, the on-chain exodus, and if they don't act upon it, then the system will freeze. I still have to depend on the bridge though but You always depend on the bridge. Yeah. But you could But if you send it to the bridge, the operator can pick it up from the bridge. So, you don't need a direct connection to the operator. Oh, but what if the operator is offline?

If they're offline, then you submit it to the bridge, you wait out the period, you'll submit another transaction, it will freeze the entire system, and then you can just withdraw your funds through the system. But then assuming that after the freeze everyone has the full state data, like Yeah. Yeah. Yeah, you assume everyone has the full state data. What's also nice is even for the optimistic roll ups with the state defenders or executors, they never have to coordinate off chain. All the data's published published on Ethereum, so they just have to read Ethereum and interact. They don't have to have a peer-to-peer network amongst each other.

You know, they're just relying on Ethereum as a bulletin board. So, when when the freeze happens, the bridge needs to know the final state of the The bridge will have like a It will just revert to the previous checkpoint. You know, the final Okay. Okay. You know, the the on-chain data checkpoint. Yep. And then it'll be a Merkle tree used to say, "I have this balance. You can withdraw it out." So, there'll be some like things that might have looked like they were executed off chain Yeah. that'll be lost forever Yep. And actually like one of the subtle details on Arbitrum, maybe it's still the same, I haven't looked in a while. In their bridge, they have this forced inclusion mechanism. Let me ask you to go back to the slide, this one here, where the user can forcibly include their transaction.

The question is when is that going to ordered? And so, in Arbitrum, the sequencer has a 10-minute window to submit their transactions. So, that's to say you're a user, you submit your transaction for ordering, I'm the sequencer, I now have 10 minutes to get my batch of transactions to be ordered in. After 10 minutes, yours will be prioritized. Now, that's like a subtle detail. It doesn't seem like a big deal, but if you can as a user, you know, if you send me lots of transactions and they're pending, and you can send a transaction in and get it ordered before me, you disrupt my entire pending view.

And if I've been giving people who solve promises in how their transactions executed, I can no longer fulfill that. So, users could front run the sequencer if you're not careful with ordering of transactions. And so, they should really increase that from 10 minutes. They should do like 3 hours, you know, just to make sure the sequencer doesn't end up in a hot hot potato seat. Uh But yeah, they're like subtle details though that the nitty-gritty details people don't talk about. You know, it's like uh Um Any other questions or should we, I don't know, head to the next room?

Get ready for the baseball game. Next question. Awesome. Cheers, guys. Cool.