Rollups broke Ethereum, but we can fix it. Introducing the EEZ

Transcript

Ah, fantastic. Cool. Can I start? >> Yeah. >> Cool. Hey, uh welcome here. Um uh we will give a talk today called Rollups Broke Ethereum, but we're here to fix it, and it will be a joint talk between myself, Friederike, and Jordi, the founder of Zisk, and Edu, um who will give a demo. So, the way that this is going to work is I'll explain what the problem is. Um uh Jordi will give you the solution, Edu will do a demo, and I will talk about um what this now enables um to end.

Okay, let's talk about the Ethereum dream. Um Ethereum was never just about a blockchain, right? It was about what happens when you make a computer truly permissionless. Um anyone can deploy code, anyone can use it, and once it runs, it just runs. So, you don't need to be a bank to kind of launch a financial product anymore. You don't need to be a broker to distribute it. Um you don't need to uh register a company uh to uh coordinate capital in some way.

You just deploy a smart contract. Um and the way that this was achieved was not by removing the infrastructure. It was by making the infrastructure truly neutral. So, something that belongs to no one, belongs to everyone. And that was the uh secret behind the success of Ethereum. And once the infrastructure becomes completely neutral, something else becomes possible.

In Ethereum smart contracts, they don't live in isolation. They can talk to one another. So, kind of you can have, say, an oracle, stablecoin a market, a DEX. And in isolation, they are all somewhat useful, but the real breakthrough moment happens um when they can connect to one another, when they no longer live in isolation. So, once um they can build on top of they can build on top of one another, plug into one another, um use one another What you actually get is a composite system that is much, much more than the sum of its individual parts.

You get You get a composable, infinitely expansible financial system kind of to boot. And uh this was wonderful. And then Oh, you can't actually see my slides. Sorry. Okay, fantastic. Um Can we fix this? They can't see my slides. They can't see my slides.

Okay, um I'll just go on talking and Oh, there we go. So, kind of a There were slides before this, but kind of like a Okay so uh once everything is neutral, everything can connect to everything else. It was wonderful, and then we broke it, okay? There was a reason for breaking it. Um what was that reason? So, the reason's in this chart. Um so, if you actually look here, um what you what you see is the average transaction fee on Ethereum for the um 7-day rolling average. And you can clearly see that demand went up.

So, kind of you can see the ICO boom in 2017-2018. You can see the DeFi summer. You can see the NFTs. But what's even more notable is Look at how it came down again, okay? So, there's a reason why the average transaction fees came down again, why they're no longer $50. And this is the reason. So, look at the number of L2s kind of on the same time timeline. So, we got the first couple of L2s experimental 2020 and today we have hundreds of L2s. Every 2 weeks a new L2 launches.

And what that actually did was it moved the execution largely off mainnet, okay? So, kind of execution now majorly happens on L2s. This means kind of the the the transaction cost has come down a lot lot again. We solved scalability, but we did it at the cost of the composability that we had beforehand. So, kind of L2s don't talk to each other well, you know this. This is what we're here to solve.

And in this in this chart kind of this kind of drives it home how we actually got here. And then the question is, okay, how do how do we now go about fixing this? The core problem is that when you're on an when you're on a blockchain, kind of the blockchain has perfect understanding of what its own status, it has absolutely no visibility into anything that happens outside of itself. Okay? So, in order for the blockchain to kind of interact with another chain, it needs to understand what the other chain is saying and needs to verify that what the other chain is

saying is actually true. And if you want to do that at the same time, if you want these chains to kind of synchronously compose with one another, you have to do it not eventually, you have to do it right that second. So, um the way um that um uh chains kind of check the other chains' state is typically done by so-called zero-knowledge proofs. So, a zero-knowledge proof is um a proof that a um uh that a computation was executed correctly. And by that, I mean that um um a specific program um acted upon a set of inputs um and yielded a specific

output. Um in the in the blockchain case, um the the program is the state transition function. The set of inputs is the previous state um and the new transactions that you're having included, and the result is the resulting state um of the blockchain. And until recently, constructing these proofs um has taken it it took took time, okay? So, verifying the proof once you had it was always fast, but constructing it was very much not. Okay? So, and this is where um the uh innovation that underpins the easy comes in. We use zero-knowledge

proofs um that are real-time to have one network prove to another network the state it's acting upon. So, let's deep dive into the architecture, and I hand over to Jordi. >> Thank you, Federica. Um Yeah, to learn a little bit because this looks like magic, um how this is actually possible, and uh To To a little bit how this works, we need to have maybe a higher overview of what's the

the how we understand blockchains right now, okay? So, at the beginning blockchains, I mean Ethereum just it was consensus about an execution and put it in a chain, okay? But today, we have this idea of a splitting data and execution. So, modern blockchain is just data. I mean, it's just a ledger where you can put data there, okay? And uh the the queries, I mean, when you are executing when when you have this ledger, this data that's fixed, we can do queries to this data.

Okay? And actually, the result of these queries can be used to use these queries, okay? And this data, it goes together with with a proof that actually verifies that this this is this data is correct and this uh mm computation, this view of this data is the right way. How this apply, for example, normal blockchain? Well, these data are the transactions. We can see if you take all the all the data, all the transactions, just the raw transactions of Ethereum and you put take off the block, this would be the data. And then, we have I mean, we can have a deterministic program that actually process all these data and computes the current state.

Just processing, of course, all these transaction those these transactions. If you had to do that like every block, this would be very expensive because we would have to go to the history of Ethereum and process the same thing again. But the cool thing of uh ZK and recursions in today's days is that we can do recursively. So, actually, we can take the result, so we can take the current state of this block, new a data pairs, we do a new query of the result of new state of this data, and then we get a new we get a new proof. Okay? And we can do that forever, okay? And you can we can understand this like a database, and then with a query, okay? And how this applies to um um uh how this applies to um

synchronous I mean when when when you are talking how this applies to uh rollups. Okay, to synchronous rollups. Well, synchronous rollups, just to be clear, means synchronous rollups means that you are have one smart contract in one chain and you can do a call to another smart smart contract in another chain in the same transaction and get the result and maybe calling another smart contract in a different chain or even a nested call. I mean, this different chain can call you to something in happening in L1. So, you have like a normal single Ethereum so, but this is happens in the same atomic transaction. So, you are just doing one transaction in one chain and this is calling to the rest of the chains. Okay? So, how this works? Okay, imagine that you have all the transactions of all the

blockchains of all the all the rollups, okay, in the data. We can process I mean, actually we can do a deterministic program that actually process these transactions, process all these cross-chain chain transactions and we create a proof that the state or in this case the states of all these chains are correct. Okay? So, composability between rollups and thinking on this model is quite um straight forward thinking in this way. Okay?

Where where is the the where where is the what is the problem? Okay? Well, the big problem is here when we are talking about L1 and L2 composability. Okay? So, if we have only L2s, that looks quite quite easy. Well, it's not that easy because you need to create these proofs. Okay? So, you have you need to get the transactions of different chains and uh aggregate them, so do compose them and actually compute this new state or this new states. Okay? But, it's actually doable assuming that we are able to create these uh proofs really fast. And we will see that actually this is this is possible.

Um So, let's go to the main topic. I mean, how we connect L1 and L2. We want to create a system where people can deploy roll-ups of any kind and should be able to call on L1 or the other way around. I mean, you are calling from L1, you should be able to call on L2 and the other way around. So, how this works? Okay? So, let's go through an example. Okay? This is a it's not a trivial example. It's a little bit complex example, but imagine imagine that we have a user in layer one. We want to call a DAO that's in the in the layer two. And maybe the DAO is calling back to some white list. I mean, who can vote or whatever in the layer one. I mean, it's just an example, but gives you a sense of how it is would

work. User A would call the DAO, the DAO would call the white list, the white list would maybe return if this user can vote or not. They would execute the voting there and then finally they return the result in user A, which maybe just maybe just pay some fees or whatever. Okay? So, this is an example. Okay? So, how this would work? Well, the first thing that we do is how do we emulate the calls? Because we don't want to build a new Ethereum. I mean, this should work in the current Ethereum. Okay? So, how do you call to a roll-up to to a to to a smart contract that's in another chain? Well, here we introduce this idea of a proxy contract.

Proxy contract is when we have a DAO that's running in the layer Actually, what we build a contract that's the representation of the DAO in the layer one. So, the idea is that if you are calling to the DAO, it's equivalent is the same. I mean, this is a way of calling the DAO in the layer in the layer two. And the other way around. I mean, if you are doing a transaction in a in in in layer two and you want to call something in the layer one, contracts in L1, they may have representation in L2. So, doing a call is just doing a normal a normal call. Of course, the address it will not be different it will not be the same, but it would be a deterministically computable. I mean, it would be one representation of the other. We can compute we will see in the demo how this

works, but it's just a representation on on the other. Okay? So, and then oh, how this would work, okay? Well, if you see the execution here, actually I mean you you are starting from the beginning you are you user A, the user A call something to the layer two, the layer two is calling another back to the layer one, the layer back is returning to the layer two, and the layer two is returning to the layer one. Okay? So, we have like two chunks that are happening in a layer two that are in that are not executing in a layer one. They are executing in layer two. So, what do we do? Okay.

Let's build a table actually what we do is we do we build a table of these executions that happen of outside the chain which outside the layer one. The table is the one that we see before. And this table what what says? Well, it says if the roll up one is in the state 0x1111 and you do a call with these parameters, the new state is going to be 0x22 whatever it is, and the result will be a result or in this case it will be another call. So, you will have to do another call.

Okay? And the other way, so if I need this a state 0x2 is 0x22 and I do a return, so I return the call, then what happened is that the result of this the new state will be this and we return this one. Okay? This table I can just build this table. I can build a zero knowledge proof of all these transitions of all these actions that happen outside L2 and a proof that they are correct. Okay? And I can push it So, I can have mention a transaction that happens at the beginning of each block where I put all these executions in the other layer twos, proven executions that happens in there.

So, how this would work? Well, when the user A is calling to the DAO proxy in this case, well, the DAO proxy what we'll do, we will do a look up to this table. It will check that the current state of the L2 matches with the current state of L1. It will apply the new state. So, this is equivalent to executing the transaction because this is what is deterministically what happened and will return what actually was proven that when you when you this call returns. Okay? In this call, it will not return.

In this call, with what we do, it will do another call. So, it will do another call to an L1. The L1 will execute the code what happens in L1, okay? And at some point will return. And the the return, I mean, the this proxy smart contract will take this return, will look again to the to the look up table. It will take the the second and say, "Okay, if if you apply a return, the the state changed in this way and then you return back to user A." So, actually, what you see what the user sees in in the layer one, it's it sees a synchronous call that that happens and this the the call is happening in both sides because you are updating in L1 the

state of the L2. So, this is the main idea of how the system of how the system works. Okay? So, how this would work a little bit in a practical way? Well, the practical way would be a call it a composer. It's like part of it would be like part of a block building. So, in the in L1 block building, actually, you will take all these transactions, will do will compute all these things, will compute all the proof. And what are the steps that we'll do? Well, maybe in the first step, maybe we'll create all these proxy contracts that you need in this execution.

The second part, you would create these these So, this is this state transition functions. So, all these all these executions that happen outside, you would create this table, compute of course the proof, which is you will see that's a critical part. We'll put it on chain. Okay, but this is just store on chain. Then we will do the actual Then we will do the actual uh uh um uh executions. We'll do the executions. And these executions, when they are calling the proxies, they will emulate these calls.

So, everything will happen. Okay? And maybe finally, of course, they are rollups. So, if there are transactions that don't touch L1, I can just with a a single a single uh state transition, I can process many transactions at a time. And this is how rollups scales. When you're doing transactions that don't affect L1 in this case. Important to say that these transactions can be L2 to L2. That can be really fast, too. But this is a little bit for another day. Okay?

Um Things that I want to highlight here, okay? Um rollups, they don't need to be EVMs. It could be uh native rollups that they follow the rules of EVM. They cannot change to They can be very native rollups. But this system allows you to create any smart any uh chain, maybe a WASM EVM, or maybe uh uh dapp uh chain, or a privacy chain. So, and we will see a lot of examples, but it's any can create any chain. The only way that So, the only thing The only So, the single way that connects is via calls. So, this chain needs to support to receive some calls, or maybe to do some calls to L1, or to the other

to the other chains. And I think this is something that's very useful because this allow the people to extend Ethereum. So, Ethereum is not going to be fixed to maybe an EVM. You will each one should be able to create in a permissionless in a chain and run and execute it and connect all these in a synchronous in a synchronous way. One word about um um preconfirmations, is orthogonal to the system. Can build preconfirmations in L1. This would help a lot. This would help latency. This may help a lot, but you can build the system without preconfirmations and still and still works.

Okay? So, the last things um So, we are I mean, here we are creating this uh easy I'm very excited on that. And the main enable is the zero-knowledge proof. This is what we have been talking here. That in the last month I'm talking in the last month, literally. This has advanced a lot the performance. Okay? So, in Zisk, so well, Zisk we are able to prove blocks in real time. Proof And of course, with all the security 128-bit to be security, quantum quantum computer quantum resistant. We are fully open source. So, we have been working and we are very committed to uh keep working on that part.

Zero-knowledge proof is very linear. Uh it's very linear in uh it scales very well. I mean, if you want to prove more transactions, you just put more hardware. Okay? And uh it scales very well. Okay? Where is the the point? I mean, the critical point. And this is where in Zisk we have been working a lot and we still have some margin to improve, but it's working a lot. So, in the case of um synchronous um composability, so when you are building a block, it's okay, you have this block building or the composer part. Okay? So, you are building the block naturally. But you need to build the proof. So, actually, you probably will start building the proof at the same time that you are already building the block. So, you kind of pipeline these things, okay? But, the problem is

this gap. I mean, when you are finishing of building the block, I mean, what's the time that you have the proof of arrival? This needs to be very fast. If it's less than 12 seconds, then you you will miss the block, okay? So, currently, we are around 3 seconds, even less, and we have margin to improve that. And this is what really enables this technology. I mean, this is not only the the way that that we can that we can scale the quantity of transactions by just putting more GPUs. Is that the latency of finishing these proofs, so of having this proof in real time. I mean, just when you finish to build the block, having the proof, this is this time is the critical one, and this is where in

this we are already there, and we have a still some margin to improve. Okay? So, now I just give the word to to to Edu to we do a a demo about the about what we are already building right now. >> Wait. So, maybe I need some help here.

Okay. I'm fine, I guess. Yeah, I don't know. Sorry. Can you help me here for a second? Ah, here. Okay, okay. It's fine. Thank you. Um so, hello everyone. I'm here to to try to make a a demo and try to put some light to the explanation that we just got from Jordi. So my intention is to make this real. Um so first thing's first, what I'm going to try to do today.

So in one side I have L1 and in the other side I have L2. So mainly the idea is that I want to make an atomic transaction between both chains. Um I have a very basic example, a hello world example. So mainly the idea is that I want to try to change a word between L1 and L2. Um yeah, that is the the main thing that we are going to try to do today. Uh so I have um two browsers. I have uh Chrome using uh connected to L2 and I have Brave connected to my L1. So the first thing is to deploy a contract in in L2. That is the first step that we need to do.

So for that um I'm going to try to ask a word from the public. For that, any suggestions what word I should use here? Sorry? Nosis? Okay, let's do it nosis. Why not? Okay. So as you can see here, um very basic a smart contract. Um the constructor the constructor set a word and I have a function that is get and set a word. That's it. So now let's deploy this on on L2. Um so yeah, that's it. From the point of view of L2, um that is all the thing that I need to do. I only need to deploy a smart contract. Now that I only need the

address of this contract on L2 in order to be able to use that on L1. So now we have this um address. I mean we have the transaction here. Okay. Okay. So yeah, we have the player contract. Nothing great to hear right now. So, now it's time to move to L1. Mhm. Yeah. Yeah. So, here is um um this remix is connected to L1. So, the first thing that we need to do here is to deploy a proxy. As Jordi has explained it, proxy is a representation of a smart contract in another roll-up.

So, now I need to deploy this proxy in order to be able to communicate L1 and L2. I am deploying because of uh I would like to explain that, but theoretically we can do that um behind the scenes. So, it's more about to explain how this work. So, for that uh yeah, I need the API. And then I need to um connect to the roll-ups um contract that we have deployed on L1. Mainly this uh this contract is in charge of posting the batches, creating the proxies.

So, yeah. Uh let's connect to this contract. So, here I have a function that is create cross-chain proxy. Mainly it takes two arguments. It takes the original address, the one that I want to use in L2, and the roll-up ID. In this case, I only have uh L1, and I have just one roll-up. So, the original roll-up ID is one. Then I need to get the address from L2. And deploy this proxy contract.

So, yeah. The thing is what we what we have done so far, again, we deploy a contract in L2. Now, we are deploying the proxy on L1, that is the representation of this contract on the one and at the moment that I have this proxy like now I can start to use it directly this proxy on the one on my own contract and that's the next thing that we are going to do. So, here yeah, we have the address of the proxy. So, now time to do the real thing.

We have another basic very basic uh contract on the one. Mainly is a function that I set the proxy that we are going to use. Um we give a word because as I mentioned this is an exchange of words. And mainly the thing that is doing is calling the proxy to get the word from L2 and set the new one into L2 and just print the message. So, let me deploy this contract. Okay, one second.

I think it's compiling. Yeah. So, okay, let's deploy it. Um yeah. And now we have everything. We have the one contract calling a proxy on one that is the one that is going to move this information between L1 and L2. So, now I am ready. I can Okay, let me close this. So, now I need to set the proxy address that is this one that we just deployed.

My word, hi. So, let's send the transaction. So, what is happening here is mainly what Jordi has explained it. So, we send this transaction to the composer. The composer is simulating the call from L1, move to L2, go back, and finally go to go to L1. And And if we settle everything at the same time, is when the magic happen. And something atomically can happen between both networks.

So, as you can see here, uh let me see. Let me open in the in the browser. It's easy to see. Well, we have it here. Incoming message from L2, notices. Let's make this Yes. That's the magic. So, a little more explanation about this, just to give a little more light on on your explanation. So, this is a transaction. Oh, sorry. Okay.

Uh Okay. So, this is the transaction that we just did. Uh this is the block. And in the block we have two calls. We have the hello world L2 world, and we have the post batch. If we take a look to the a look to the batch, here we can see like we are performing L2 execution. And also an important part is that we have post post a batch with the all the state um transition that are happening in the two. If we consume an entry on L1, and it matches with the batch that we just posted, is when we can make all the thing happen at the same time. And here, I mean, it's hard to see, but you have all the table, all the entries. And this is atomically happen or not happen. And

yeah, this is the magic that is behind easy. So now >> Now it's me again. Okay, let's um present this. Um >> See if this is working. >> Oh. Oh, here we go. Fantastic. So, what you just saw um changes what's possible. So, kind of you saw a fundamentally new primitive. Kind of you saw a new demo, a um, a cross network call return a response in a single block. This is fundamentally new. And if you look at kind of what

this now enables is it restores the composability between different networks that we lost when Ethereum scaled via L2s. So, you get to keep all the benefits of the scalability, but now, um, you you can compose again like you could before we had the L2s. Let's look at look at a couple of examples because I understand this was really high-level. Let's look at bridging, okay? So, today, um, say you have, um, USDS on network one, you want to send them to network two. What you do is you go to the bridge contract, um, you deposit your USDS, you lock them, then a message is generated, um,

the message is, um, passed to network two. There's, uh, relayers, uh, finality, um, proof generation in the background, so you wait, um, then your, uh, tokens on network two become claimable, um, that doesn't mean anything yet, so kind of it means, um, a a smart contract, um, on the other network owes you tokens, so you go there, you claim the tokens, and then you have the tokens on the other network. That is how bridging currently works. Um, in the Ethereum economic zone, what you can do is you can just execute a transaction across both networks. So, you touch both states simultaneously, and it's as easy as, um, um, sending, um, a token on the same network. Okay? So, example two,

liquidity. Um, currently, you have the same pools deployed on many different networks, okay? So, here you have an ETH USDC pool and you have it on chain A, B, and C. They have different prices. They have They The liquidity is fragmented. And kind of arbitrage is kind of what barely stitches it back together. In the Ethereum Economic Zone, however, you still have all of these various pools on the various chains, but they stop behaving like separate markets. They become a single market because while the pools are still on the individual networks, your transaction

can actually touch all of them at the same time. So, the liquidity is is global despite the fact that the pools are local. And if you have if you have dapps like CowSwap, they they see where all the liquidity is across all the networks in the EEZ, and they find the best way to kind of settle your trade. And if the liquidity for the token you're trading is better on another EEZ network, kind of it routes it via that network and then kind of loops it back. So, kind of it all happens under the hood. You don't actually have to know about this. It just ensures that the EEZ becomes a single market again instead of a number of loosely coupled markets as

we currently have. Okay. I'll give you more examples. I hope you're ready, okay? So, next example is Composable Finance. Say I have Ethereum. I have ETH on chain A. I want to stake it on another chain. Then I want to borrow against it on another chain, and I want to use that liquidity I just got on another chain still okay? Today, this is a bunch of steps with bridging in between. So, kind of you have a delay and a failure risk at every step, and it'll take it'll take you a long time.

In the Ethereum Economic Zone, Um, you can touch upon all of these states in a single transaction. So, all of this can happen in a single block. And the way that this happens is not by moving the infrastructure from chain to chain. Um, it's having these composable contracts that can touch on all these different states and change them in a uh consistent manner at the same time. Quick. So far, we have looked at things that kind of speed things up or kind of make things um that are subsequent in nature kind of faster or more secure in some way. Um, it also allows completely new mechanisms. So, for instance,

say you have a protocol like Aave, okay? Today, Aave is deployed on many different networks, um and the Aave deployment always sees the tokens that you have on that network, and you can borrow against them. Okay? So, in it's very it's capital inefficient because Aave doesn't see your entire balance, it just sees what's on that network. Um, and then kind of you can borrow against that specific collateral. In principle, kind of as soon as Aave understands what the state of the other EVM networks is, um you can now borrow against your one collateral base, and whatever kind of if you're underwater, you get liquidated, but kind of it's all possible because

it's synchronicity composable. Another example. Today, you have a safe. So, safe is deployed across 300 EVM networks. Um, so you have a safe, uh and you have associated safes on various other networks. Today, they are independent. So, kind of the configurations of these safes, they can be different, and kind of if you change the configuration of one safe, doesn't mean anything at all for the other safes. So, kind of you get state drift in between your configurations. In this new Ethereum economic zone, what you can do is you can uh you can designate one of your safes kind of the lead safe, and when you rotate a key, for instance, it rotates them automatically on all your

other 300 safes. Or kind of if you set permissions, um the other 300 safes can follow. Okay, but it got goes much further than this. So, kind of uh on on the safe, in principle, you can do this manually. It's not very convenient, but kind of you can do it. Um singleness composability also allows things that we genuinely do not have today. Okay? So, you could have your identity, your private identity on a privacy-preserving chain. Doesn't have to be EVM, because as Jordi said, this is all call-based.

So, kind of you could have it on Aztec or wherever you like. Um and uh you can um verify yourself against a contract on another chain by virtue of this private identity. So, your private identity never leaves um the privacy chain, just the proof that kind of you you are granted access because you fulfill membership criteria, your reputation is enough, or um kind of you have the credentials. Um just the proof as to that leaves the network, and then allows you to access, say, a Fileverse document um in on on an EVM chain.

Um and so kind of so kind of why why kind of your your your capital kind of becomes global, so does your identity. You no no longer need to replicate your identity across every single network, or kind of um uh use a trusted third party. Um and this doesn't only apply to public networks. This also works for private networks, okay? So, if you have a Prividium, um a private chain, um, that is ZK, uh, proven, um, then you can have it interact with Ethereum and public apps on Ethereum, okay? So, when we talk about Prividiums today, we often actually mean consor- so, banking

consortium chains and so on. And I mean, obviously, this is also, um, a viable use case, but I can also see a future where, for instance, nation states kind of, um, deploy their own Prividiums, okay? So, kind of you have, say, you're you're you're you're the German state, kind of like you want to issue your, um, you want to issue um, your citizens with, um, an on-chain identity, but you don't want to do it on a public chain, right? Kind of like you want to have the validators be, I don't know, the branches of the federal bank or something. Um, and, uh, but kind of in order for that to be useful, it needs to be able to compose with public chains, because by virtue of it being a private chain, there's a private permission chain, there's not going to

be a whole lot of interesting things on there, right? So, kind of you give your own citizens a way of having a trusted, state-verified identity on public networks. I can also see states issuing CBDCs on these kinds of, um, chains or, um, or T-bills. Um, so, this is really large concession. So, kind of for the for kind of being a becoming a part of the easy, what's not important is that you are EVM or, uh, or public, um, what matters is that you can prove your state. If you can prove your state, you can compose.

So, this isn't just theoretical, okay? You just saw Edu give the demo where he called um uh, a from a contract on L1, he called a contract on L2 that gave him a word that you you gave him, namely Gnosis, um, and then kind of it reverted back to L1 and kind of completed the loop, kind of yielding this entire face phrase. So, kind of you have seen that it works. And it's not just us so knows and this pushing this. It's a community effort.

So, there's a whole lot um, of ecosystem players who are on board here. So, kind of all the major block builders are on board. Um, that's uh, Titan, Beaver, and Flashbots. Um, all the dapps that you have seen. So, uh, so Cow, Safe, um, uh, uh Aave uh Spark Monerium Xstocks and so on. They are all founding members of this. This will be available from day one and uh, mainnet will be pretty soon, sometime this summer. Um, if you want to learn how to use this for your dapp. If you want to learn how to connect your

L2. If you want to look at the code base, look at this come come to our website easy.io. And uh, thank you so much for coming to our talk. Outside? Okay. If you have questions, you have to go outside, but we'll be there. Thank you. >> I'm done.

It was a pleasure.