Gnosis Chain’s Technical Path Into the EEZ

Transcript

Next up, we have another another easy themed talk. Um, I'm very proud to welcome Philip Shamls to the stage. Um, Philillip is the head of infrastructure at Nosis. Um, in most appcons he has the job of coming up and talking about glamorous topics like hard forks. Today he has something even more exciting. He's here to talk about the technical implementation path for Nosis chain with the easy framework. >> Thank you ads. >> So hopefully you got some context about uh easy why we need it and how it is technically possible now with Martins and Jord's talks. Um here we're going to go through a more concrete example like

what happens if we take a live production chain today and make it an easy chain. So we'll go through some context about easy for those who weren't there for Martin talk. Um context about Nosis chain and then how easy works under the hood as well as how it will look like in practice for nosis chain. So let's start with the context. The whole point of easy is to have synchronous composibility between multiple chains. In the simple example here um I have just L1 and L2. So Ethereum for example NOS's chain. Of course, currently uh if you want to interact with a different chain, you have to bridge and that takes some time, right? It can take up to seven days, for example, for um fraud proof rollups.

With easy, all of this becomes one single transaction. So you interact, you read and write on Ethereum and on chain at the same time. One transaction, one block, fully atomic. What is needed for easy is first and foremost that you need to be able to reorg with Ethereum. So when uh I mean you cannot use state that is on the L1 on your own chain if it was removed right if you do a trade trade like you swap some tokens on your L2 if the L1 then reorgs and you don't have the other side of the trade that obviously does not work. So you also have to reorg the same time

then I mean that's necessary for synchronous composibility in any way but for easy it's also best if you integrate with the easy contracts have a composer and run a and use crossing proxies. We'll go over all of those one by one uh and the rest of the elements. So whether you are uh producing blocks in a based way sequenced use proofs I mean you have to use proofs but whether they are zk or something else like a multisc uh data availability VM all of this uh is up to the chain to choose.

Now some context about NOS's chain uh it's a network that's been live since 2018. Hopefully you all know about it now but maybe you don't. Um it's basically Ethereum just with a few tiny changes right so we have faster block times 5 seconds in instead of 12 sorry um we have faster epoch so finality is faster as well and the staking token is GNO which is an EC20 token rather than the native token but basically it's the same architecture same client same beacon chain whatnot um of course it is a live network so it has apps infrastructure and for example it runs nois circles.

Now hopefully the opportunity for no change should be clear, right? We want secret composibility with the L1 at least to begin with and potentially with other L2s as well. This would give uh access to liquidity from the L1 directly. So you don't have to have liquidity for example on L2 or less. So at least uh there's no longer any bridging so it's instant and there would be a huge first mover advantage for Nosis chain because no other chain currently does this. When I'm talking about the Ethereum liquidity it also allows you to do for example liquidations in one single transaction with funds that come from the L1 go to bridge in the same transaction to L2 so to Nosis chain liquidate there and then bridge back if

you want to. So it enables a lot of uh new options. So how does easy work under the hood? I'll start with the first component which is the composer. And essentially what it does is uh simulate transactions across multiple chains at the same time. Again here is a more basic example with just two chains. So Erium Nosis chain for example. It has a state of both chains. Then it gets transactions L1 and L2 from a me pool. Ideally, it's private and I'll explain why later. And then it basically simulates all those transactions on both chains at the same time and creates one block at the same time for the L2 and well the transactions needed in the L1.

So one question is how does the composer know that a transaction actually crosses the chain boundary? So how do you know that if you do a transaction on Ethereum at some point you're going to nosis chain? This is where we introduce crosschain proxies. So here for example we have a contract on NOS chain that is called B very original uh and it has a proxy representation uh called B star on Ethereum. So basically if you call B star on Ethereum the composer knows this is the contract B on nos's chain. This is all written in the proxy basically.

Um the the proxy here can be called by any caller. It can be an EOA. It can be a contract. can be whatever uh and those crushian proxies they can be deployed deterministically permissionlessly and the objective is that they can be basically be used in the current ecosystem you so you don't have to um update apps so technically it would be possible to use for example the 12 bytes that are empty in an EVM address uh to signify what chain it is on for example like the contract is targeting but we are not doing this because we don't want uh to have to update all the DAPs basically.

Now, this is a rough example. I think Jordi had one that was a bit more complex, but um let's just quickly show how it works. So, imagine you're in on Ethereum and then you do a transaction on a contract called A. It can do whatever it wants on this contract. So, that's calls whatever, but at some point it calls contract B star, which again is a proxy representation of contract B on noises chain. Now in this example here it just calls B.increment or B star.crement on Ethereum. Um and there on the chain again you can do whatever you want. So nested calls modify state of course the state will also get committed obviously because then it if not it doesn't work and then

at some point uh the contract B returns some value. I mean it can also just return nothing but in this case it returns 42. At that point, the composer goes back to Ethereum. Continuous execution on Ethereum and then the contract A can again do whatever it wants with that value. So there's no callbacks, no bridges, no nothing, just one transaction uh and that's it. Now obviously this does not really happen that way on Ethereum, right? You cannot just do a transaction and then stop execution on Ethereum. We are not uh running vital mosa unfortunately. Um so how this works is that we uh have execution tables. So execution tables essentially

are a log of everything that happens on both chains. So they can be just to be simple here they can be for example a call. So you call a different chain. They can be a return or a revert. Those are of course all part of the proofs. So you cannot modify an execution table uh and then sit expect a call to go through. then that block becomes invalid. So these are all u created the execution tables while the composer simulates uh the transactions and if we go back here to the previous example you can see we have here so one call one return so that's one execution table uh on nosis chain that is an incoming call and one on ethereum that is um well a return of course I mean

here ethereum nosis chain it works with the L1 and any other L2 it's the same same principle so in that previous example we end up with two execution u um sorry execution tables. So in Ethereum um just the fact that we called in this specific context or in this state by this user by with this call data just to keep it simple here um we call B star.inccrements increments and we get the answer of 42 and then on nosis chain a star which is a proxy representation of a but on nosis uh chain uh this is called so we have an inbound call so we have to execute it modify the state on

this chain and that's also an execution table now this was just the first part of the magic of course that by itself is still not enough so we have to post this on chain now somehow And the whole idea is that basically we are front running the user's transaction. So again let's go back to this example here. Um so A does a transaction calls B star. If we do it without anything um bar obviously does not know that the result will be 42 if you call B star.crements. So what you're doing is that before this transaction even happens we are inserting something in the easy contracts that says if in

this specific context so this specific state what not uh a calls bin increment then the answer would be 42. So we front run this in our post and verify batch which also includes um blobs for example I mean it includes the call data state roots whatever the L2 needs and anchors to the L1 it includes that but in addition to that it includes the execution tables. So basically again we front run um so B star can call the easy contracts to check what would the value be and then after this we include the L1 transactions. So in this case here the user transaction that calls a which ultimately calls B star increments. This

we do with just an eats and bundle. So basically MV bundle that will get executed by uh L1 builder. Of course this is only valid for one specific state or one specific block. uh and if the batch doesn't get included for example if we didn't pay enough gas or whatn not to be accepted on that one then uh we have to I mean it all reverts and we cannot actually do the synchronous transaction so again quick summary what makes an easy chain you need to reorg with ethereum you also need to prove it so that can be with zk or multisc whatever um then you need to use the easy contracts have a composer use question

proxies and the rest again is free uh to use or free for the chain to decide. Now, we already have this. I think Martin Jolie touched on this uh already, but basically Jordi wrote an E research post in February. By April, we had a prototype of the composer that could do nested calls via multiple chains, multiple nested calls. Uh so we can prove that we have instant deposits, calls with returns, uh even crosschain flash loans or whatever. Uh we tried this with five nested five well nested cores that are five levels deep but this is just a limit we set for ourselves.

Technically if you can pay for the gas you can do as many as you want. Now I mentioned that you can basically like a chain can decide many of the aspects um to integrate with easy. Now I'm going to go over what we think we should do for Nosis chain. So this is not quite final yet but we are working on those assumptions at least and what we want to do for nosis chain is to have a sequenced chain with two second block times we will prove the blocks with a multisk so not fully z proven yet and post all the roots call data and whatnot in ethereum blocks now you might question those uh choices and I would totally understand that but I'll try to

convince you that this is the best option at least for now so why ZK um well ZK teams like for example jurors with disk are doing a lot of great work but we believe that it's still a bit too early for noises chain first reason being that we want to have three different at least three different client implementations but also zk provers uh and they need to be of course able to prove everything in real time um the second reason is that we believe that it's still a tiny bit too slow right now for our needs and I'll actually get back to that a bit later.

Why do you want a sequenced chain? So basically now we have this beacon chain with a lot of validators. Um but Gasper so the um algorithm behind the bacon chain was not really made for fast block times for example. So we want two second block times and that's just very complicated to do in a fully decentralized manner where you have to attest all blocks and whatnot. The second reason is that composing is a heavy operation. Right? Right now you build blocks on nosis chain. You just run nosis chain. If you want to do this with synchronous blocks you need to run nosis chain but also ethereum and potentially many other L2s with which you want to uh compose. So it's a very

heavy process. We could use builders for that but anyways later down the road it will just make things more complicated when we want to add new chains for example also again we need to reorg with Ethereum reorgs and we cannot reorg if Ethereum didn't at least if we rely on that state and Gasper again was not made for this it was made to finalize on its own not to finalize based on a different chain uh and it also cannot guarantee that a current block that was mined or created will not reorg when this underlying L1 block it did not reorg. So basically just Gasper wasn't made for it. It doesn't really make sense to reinvent the wheel and to modify all the consular clients. So we believe that

sequenced is the way to go. Now you might ask what happens to the nosis validators. That's a very good question answer is it's not quite clear yet. Uh but ultimately most likely the set will have to get deprecated. How that happens again not clear but anyways all of this will go through the DAO with a GIP. Um, so technically speaking, well a bit more technically without going into too many details, what does that look like?

We have a chain that produces six blocks per Ethereum block. Of course, one of these every time will be able to be synchronous. So have synchronous transactions basically. Um, all the other ones will be PL2. So we continue building the chain without synchronous transactions. And all of these blocks will be signed by the sequencer. it's going to be permission to begin with. It's just again a design choice to move fast. Let's say of course the sync blocks don't necessarily have to be synced. So if there is no secret transactions, we can just continue building normal pure L2 blocks. And if that happens for some period of time, we would still let's say every couple of

minutes anchor our L2 state to the L1 to post the state roots, post the call data and everything you might need to follow the chain. For a composer, we actually want to start with a simpler version. So we call this for now, let's say composer v1. Uh well, not the official name, but whatever. Uh and what this will allow is just one incoming call from the L1. So from Ethereum um there it can do whatever it wants. Then one call to no chain where again it can do inside of no chain one of it once. And then one return call where it can resume um execution again.

We believe that this actually gives you let's say 70 to 80% of the capabilities right as mentioned before you can um swap tokens on L1 bridge them to no chain liquidate someone there bridge all of this back all in one single atomic transaction of course the objective longer term or even midterm is to have full composibility full nested composability uh so we can go from L1 to L2 how many times you want however many times you in one single transaction. So uh follower nodes, so basically for those running nodes currently, a follower node is what I'm calling um nodes that can sync the network but not create blocks. They will work a bit

differently now as well. So they will get blocks from the sequencer every two seconds and then also validate every time that the batch is posed on the L1. uh be it a sequence block or an anchor uh they will validate that the state they received from the sequencer is identical from what they see on the L1. Uh but of course you can still run a node, you can still have your own private RPC uh run everything locally, do simulations, all of this stays the same for the user. Ideally, this is simply um a client update basically. So you have your rest node, let's say, you just update it to a new version and then there you go. You participate in the no chain hard fork everything works as before.

Uh the way we are validating the blocks is that the current bridge validators that are um well basically validating transactions and bridging them over right this is a validator set currently a multisc for chain they could potentially become chain validators. So they will run three different kind implementations. They will validate locally that a block created by the sequencer and the composer are valid. then they will attest to it and we post the aggregation of uh this these attitations with the post and verify batch on the other one.

Um so what this gives us is a chain well that is very much like nois chain so the state is the same but we rip out the consensus layer and replace it with something else. Of course, we would lose some functionality that the beacon chain provides to us. For example, blobs. Um, but yeah, so the transaction times will go lower. So, block times from 5 seconds to 2 seconds. We have to reorgate Ethereum as mentioned plenty of times. Now, the finality will go up slightly, but that also means that we'll um inherit from Ethereum when they decide to go with faster finality like 3SF or whatever DF is working on currently. Of course, all of this also gives us secular and automic composibility, which

is the whole point of easy. So, I'll be honest, there are still a few issues that are not necessarily fully resolved yet. And two of them are linked to timing. So, for example, um inclusion time in DL1 is not necessarily known very quickly. So, if you do a sync block here, um so we have blocks every two seconds, right? If you only know after more than two seconds, let's say three seconds that a block actually like that your bundle was accepted in the layer one, then it's not quite clear what block you have to build your next one on. So let's say this block, do we have to build it on the sync block if it gets into the chain or do we have to build it on the

previous block? We don't know. Martin alluded to something where we could basically do different variations of those blocks and then take the one that is appropriate but it's just a bit more complex. The other issue is linked to proving as I was talking about earlier. So for proving you need um a bit of time after the proof hopefully that hasn't happened changed since last time. Wasn't able to fully listen to Jord this talk but presumably he talked about this. Um, and so basically, uh, if you have transactions here, you still need to build two blocks to post it on the L1, if you need three, four seconds at the end of a block to prove it. Of course, you cannot prove the last two blocks,

right? Because you just don't have time. Um, that means that those two last blocks would always be empty. So the the T+ and the next sync block, they will always be empty because you don't have time to create them and prove them. A solution for this would be potentially to build those blocks earlier. So at t plus 8, so 4 seconds before the next block, you could actually build the normal pur to block and then two more that you then have time to prove entirely. But they would then rely on slightly stale data, right? Because you don't get the transactions that happen here. You are not able to build a block that includes them. And of course, synchronous brows, they will always include transactions that are at least 4

seconds old and up to 16 seconds old, if that makes sense. This, to be clear, is not an issue with a multiscrover, which is our preferred solution at the moment. But if we were to go fully easy proven, this would be an issue. Now, I want to close with a bit of a timeline. I'll be honest, it's also um a bit optimistic at least very aggressive. Um so as mentioned there was this jolly uh post post on it research and we have a function prototype now for the composer full and whatnot but also for the sequenced chain and our plan is through uh hot fork shadow so our test

net by end of September and then hopefully Ethereum uh sorry my netsis chain uh by end of December of course once all of this is done hopefully by end of December uh We work on fullness at composibility as well as zk proving which are still obviously our objective right we want to do this the right way we just want to do it a bit earlier um so a less perfect version but earlier basically and yeah that's it for me so here are a few links if you want to follow uh development on on GitHub and follow news on on Twitter I hope this helped you kind of get a clear picture of what easy is and how we could implement mented

with nosis chain. >> Thank you very much. We have time for some questions. Who has who has over here? >> Can we get a mic over here? >> Thank you. >> Thank you. Um so I was wondering in this process as a user how much transparency do I have on each transaction and sort of where in the process is my transaction and I guess in a reverse

manner um to what extent is that information public i.e. how do I avoid front runners if I were to do a transaction that invites front running? >> Um okay I'm not sure I fully get the question to be honest. um as a user this is basically transparent. So you just send your transaction ideally to a private meool because if you don't um like if you just do L1 transaction that has a crosschain call and you send it to the public meool then a normal Ethereum validator can just pick it up mine it and then like in the well it's a few slice back but in the b.increment increment example

uh if we get to there right here bid increments if we if we don't front it with the composer but it's not really front running like we're not doing anything bad we just have to seed the state um on the other one but if this is done through the public me and a validator picks up the transaction um it gets bind and then B star increment will just revert because you don't know what the value actually is Um yeah so but except for that it's it's transparent. You just post your transaction to a private meool. The composer will do all the simulations and then it will submit a block to the L1.

So there's no really that there's no steps. This all happens like behind the scenes as if it were a normal um a normal transaction. I don't know if that kind of answers your question. Um, yes. I mean, yeah. Any more questions for Phillip? Okay, no more questions.