Building Synchronous Composability for the Ethereum Economic Zone

Pragma Lisbon 2026 · 25 Jul 2026 · 16:05

Philippe Schommers explains how the Ethereum Economic Zone aims to let a single atomic transaction span Ethereum and other chains, so that a user could take a flash loan on L1 (Ethereum itself), swap elsewhere and repay without waiting on a bridge. A composer acts like a block builder for several chains at once, simulating calls routed through proxy contracts and posting their proven results before the L1 transaction runs. He then sets out Gnosis Chain's plan to join first by becoming sequenced, with two-second blocks, Ethereum data availability, and reorgs and finality tied to Ethereum, starting with multisig attesters before moving to trusted execution environments (TEEs) and zero-knowledge (ZK) proofs.

Speakers

Topics

From Pragma Lisbon 2026, hosted by ETHGlobal.

Transcript

[music] Hello. Hello. Um, yeah. So, today I'm going to be talking about NOS's chain and it's becoming the first live easy chain. Now, I guess we need to start with a bit of context. What is easy? Uh, and for this, let's get back to how blockchain works currently. So if you have a layer 2 chain roll up uh usually um you have to bridge to go to that network right imagine you want to interact with two um and you want to send funds there because you don't have

any right you need them to interact with it uh and you don't want to use a centralized exchange and you just want to say on crypto what you would do then is to take funds on Ethereum for example and bridge them over to your L2 this takes a lot of time you have to go to a bridge UI for that specific chain. You have to do a transaction, wait for the transaction to happen and then go to a DL2 and then do one more transaction to interact with it. So it takes time. It's cumbersome. It's just not great. What easy wants to do is basically make this instantaneous atomic and work in one single transaction. So instead of uh well I guess we don't see the point that well here but instead of waiting between

uh for bridge events all well is done in one second transaction atomically. So you can start a transaction on Ethereum for example do a swap on the L2 and then bridge back the funds in one single atomic transaction. Now for this to happen uh there is one very important thing that is impossible I mean that you need to have is that you need to reorg when ETM reorgs. The reason for this is that imagine you do a swap on two chains at the same time. If Ethereum reorgs and then kind of cancels your swap, of course your I mean the L2 also needs to cancel the other leg of that swap, right? And then to interact with EZ, so I mean that condition is necessary for any synchronicity between

chains. But for EZ specifically, you also need to interact with the contracts, run a composer, and use crosschain proxies. I'll go over all of these one by one right after. Um, but the important thing is that easy is kind of a communication framework. So it's done to make synchronous composibility easy but it doesn't I mean it's not a full chain stack. You don't have to run the same chain as we do. It's just the communication layer between chains. So after that you can be based sequence CK proven have a multisc for proving whatever um be EVM chain wasn't chain this is all up to the chain. So the composer is basically a component that

um you can kind of think of it as a block builder but for multiple chains at the same time. So for example you have titan builder it builds L1 blocks right? So it just takes transactions orders them does I mean whatever else. And the composer does the same thing but on multiple chains at the same time. So it basically gets transactions from the here just to be simple the L1 and L2 me pools but it could actually work with way more chains at the same time. So in a simple case here you get transactions from the L1 and the L2. Uh you execute a transaction and you simulate it on both chains at the same time. So again if we take the example of um starting uh on one chain for example you do a

flash loan on Ethereum you bridge over to Nosis chain for example you do a swap there you bridge back you repay your loan. All of this happens automically and the composer simulates all those steps. So at the end you have one block uh for Ethereum and those chain at the same time stamp that executes again transaction at the same time. So for this to work um the composer needs to know when a chain boundary is crossed. So you are in Ethereum you don't call how do you know that you are now targeting nosis chain and this we do with proxy contracts. So here we have a contract B on noises chain and its proxy representation B star on Ethereum. That simply means if someone calls B star on

Ethereum that's that means that they are actually trying to reach B on NOS's chain or on any easy network. uh and yet so a more complete example let's say a very simple still but whatever uh if anyone here runs uh call sorry contract A on Ethereum that contract can do whatever it wants like a normal Ethereum contract at some point it will call B star and here the execution Ethereum kind of stops or the simulation rather and goes to N chain so on Ethereum you know okay we are trying to call for example here B starin increment so let's say B is simply a basic counter on ethereum we stop and then on noises chain there's an incoming call from a

star so the proxy representation of a but on nosis chain that calls binc increments now again nois chain does or the l2 whatever it does uh what it wants so here for example just increments a value and the end result is then 42 now here the execution on nosis chain ends right so you have the contract on nosis chain it all happened there you have a straight state transition Um and the yeah you send back the result to Ethereum. So there you again continue executing um well contract A on Ethereum knowing that B star increment is going to result in 42. I guess this is all a bit complicated to say.

Yeah, for example, this flash example, right? So, you would do a flash run on A. Uh, you do a swap for example on A and then you move that to Nosis chain. So, execution stops on Ethereum. You continue execution on the chain. Once that is done, you can bridge back or do whatever you want again on Ethereum. Um, yeah. Yeah. So I don't want to go into too many details about batches but the way this works is that basically because obviously we cannot I mean we cannot say okay Ethereum health execution here and we go to a different chain right so the way it works is that here once the composer calculates uh or simulates what happens on NOS's chain we actually kind of frontun this result uh

inside of B star. So we basically say if a were to call bar star.inccrements increments then the result or the return would be 42. So basically the composer will well do a transaction before the user transaction that calls a here. So we will kind of front run it to write inside of bar star that if a calls bar then the result is 42. So we kind of simulate this beforehand. We post this on chain and then the L1 transaction can actually go through. Now of course all of this has to be atomic right again if um all of a sudden now the return value would be 43 because someone else called

the function on L2 instead of 42 then everything has to revert so it is atomic and it is proven of course you cannot just say the result would be 50 because it's not I mean we can prove that it's not with zk proofs or any other um system for that. So yeah again here we kind of front run this with postbatch and ver post and verify batch whatever it's an easy specific thing and then the layer one transaction comes in and then it already has the context that if you call b increment the re value is 42.

Um so the good news is that we already kind of built this. So Jordy by Lina um you might know from Zisk posted his first E research post about easy in February and since then we've already kind of built everything I just mentioned. So we have instant deposit and withdrawals between multiple chains. Um we have course with return values crosschain flash loans nested calls that means you can go from the L1 to the L2 back to D1 back to the L2 whatever how many times you want however many times you want in one single transaction atomically. So all of this we have since a couple months actually on a devet of course it's not quite production ready but we are getting there uh quite quickly. Now this was kind of easy like

the communication framework I mentioned earlier. What does this mean for Nosis chain? So hopefully a few people here know what Nosis chain is but essentially it's a live mainet network that has been live since 2018. It is very ethereum aligned meaning that um we basically have the same architecture. So we have the consensus chain, execution chain and basically exactly the same as Ethereum just with a few tiny differences. And we have a real ecosystem of course we have the whole I mean you know infrastructure defy all of that but also noises pay circles and a few internal apps.

Now why do we want to become the first easy chain? Well, as I mentioned before, this allows us to tap into the L1 liquidity immediately, right? So, instead of having to provide liquidity to Nosis chain for D5 or whatn not, instead of having our own oracles, we can just use the L1 ones, so the Ethereum ones because we can call directly like into them with a proof that what they return is actually correct all in one single transaction and atomically. So instead of having liquidity on NOS's chain, you can just say I mean I have some assets I want to swap them but to swap them you could just go to the other one swap them there swap back and that's still just one single transaction.

That means no bridging anymore all instantaneous much faster much better. Um of course you want to be also the first implementation because I mean there's a first mover advantage but also because we want to show the way. We want to show that it's possible to take an existing network that is you know complex has its state for a lot of years and take all of this and become an easy chain. So no chain is going to change significantly to allow for this. Um one of the things is that we are going to become sequenced instead of having our own consensus layer. We are going to become a bit more permissions. Um, and we're going to use Ethium for data availability.

Now, the end objective is to have this be fully ZK proven because we want um I mean to prove that everything is correct. We are not going to do that to begin with though because we still feel like ZK is a bit too slow. Uh, and we want to have more client diversity on the execution layer but also on the ZK front. So, we're going to start with basically with a multisc of at testers or evaluators for the chain and you're also going to use most likely tees to prove execution of the chain but again um for easy this is all kind of uh customizable so you can use whatever you want and we can upgrade them bit by bit so for the chain we are going to start

with a multisc and then move to ts and then zk for example this is all allowed by easy now why do we want to become sequenced this is kind of a controversial choice I would say for no chain specifically because we've historically tried to be very decentralized, very censorship resistant, very distributed, all of this becoming sequenced kind of goes against that but essent essentially it's a technical requirement. So Casper the consensus engine of Ethereum is just not made for for example fast block times.

We want two second block times like OBS stack rather than the five and it's just not possible with the consensus layer we have currently just even because of latency if you want to have consensus between nodes distributed across the network uh across the globe sorry that's a bit complicated uh and then composing is heavy so you have to run multiple chains run simulations between multiple chains so it takes a lot of time it's not easy normal validators usually or typically are not able to do that and then Again this whole thing about having to reorg when Ethereum reorgs and actually in addition to that we also cannot reorg if Ethereum does not reorg because then again we would have one leg of a swap for example but not the other one and

that would be very bad and again I mean Ethereum is built to finalize on its own not to finalize based on a different chain so for it it's just too complicated and um yeah it just makes sense to become sequenced. So what would that give us? Basically Nosis chain would lose its consensus um well chain speaking chain um and with that also rubs for example that we know and love from Ethereum. the block time would go down. uh reorgs would be tied to Ethereum as I mentioned plenty of time at this point and finality would also be tied to Ethereum meaning it will finalize slower but um I mean Ethereum

is working on finality making it faster and whatn not and we would then also of course inherit those um improvements that Ethereum creates for us and then of course there's this whole composability thing that's the main objective of easy so you can do synchronous atomic transactions between the L1 nosis chain and also any other chains that join the easy. Now this we all building in public it's all open source uh I actually share the repo a bit later so we've already built this multi-chain composer uh the common interface so basically the easy contracts that allow well chains that use easy contracts to interact with

other chains DL1 but also other L2 L2s that are easy compatible. Uh there is proof diversity. So as I mentioned you can use multisigs, you can use zk provers, you can use cs, whatever you want. Uh we already accounted for all the failure modes. So what happens if you well if the L1 reorgs what happens if you miss a bundle all those things and um is basically a repeatable path. So if we are able to do this with the live chain there's no reason that other chains might not be able to do it. Uh so this is the road map. Uh as mentioned in February we started this whole thing. Now we have a fully working DevNet and uh for Nosis specifically a GIP that is planning uh for how chain

might become an easy chain. So this is because Nosis is a DAO. Uh of course you can feel free to interact with it if you are interested. We have the technical uh specification ready very soon and our target for no sustain specifically is end of this year to beginning of next year. It is quite ambitious but I believe we can get there and then in the next year we'll work uh towards well improving composibility between chains do nested calls do realtime CK proving all of this is our objective and will come at some point.

Now here I would invite anyone who is interested with this to join our efforts. It is an open protocol. It is um well built for auto chains to join the efforts as well. Uh so if you are operating a chain, if you're building uh clients, provers, build infrastructure or apps, please feel free to reach out to us uh be it well to me directly after this talk or uh on GitHub or on Nosis Chain Twitter or Economic Zone on Twitter. Yeah. So um that's it for me. Thanks for listening.

>> Thank you so much. >> [music]