This is our second last fireside for the day and without further ado, I'd like to bring on Jordi to tell you all about the theorem economic zone. So please give Jordi a big round of applause. Welcome back. It's uh always fun to learn something new from you every day on stage or every time we we do this. So I'm excited to learn about not just easy, but also just the latest of what's happening with a lot of ZK.
Um my kind of first question to you is it's been a big week for you and and the noses team um especially with the launch of the Ethereum economic zone. So tell us about what it is and how did it come to be? So like how like what is easy and how did it sort of start? Yeah, easy easy is um mainly it's a very at the end it's a protocol and the idea is to connect rollups in a synchronous way. So at the end is and connecting the I would say the I like to say is that the Ethereum way.
And uh and that's just you have one smart contract in one chain, you have another smart contract in one chain and you just call it in the same way that if you were in the same chain. And this looks like ideal and this looks like a a dream, but yeah, this is definitely possible. This is possible because of the advances in the recent month uh of the ZK real the real time proving and well, we are building this easy thing uh just to connect the rollups. I mean that's would say this is the the main idea on on that. Amazing.
So um fair warning to the audience, we're going to go slightly technical on this one, which is just we're going to go more on the infrastructure side, and luckily the talk after this covers What does it actually mean for all of you? So, we'll we'll actually see a much higher level of view and a very easy to digest version of easy as well. So, the next 40 minutes are going to be pretty pretty awesome. Um So, the first kind of question I have is what what changed in the last month? What what new invention allowed you to do this on the ZK side in real-time proving?
And why was this not possible before? Well, um mainly is this advance of ZK. I mean, being able to prove anything in real-time or almost real-time. Uh So, you're saying this was always possible, but it's just now faster so that it's practical. This is the faster and practical.
So, just So, ZK they scale very well on the So, if you want to prove, let's say, more transactions, you just put more GPUs. And this has been reduced a lot. I mean, in the last in the last month we we we are able, for example, to prove a full Ethereum block with just 12 GPUs and even getting lower. So, that means that uh well, it can scale as much as much as you can. So, uh the prover is not a bottleneck.
Of course, I'm putting 12 GPUs work together.
are getting faster, so it it naturally commoditizes, too. So, it's not the matter But the thing is the question is, okay, you start you have a block of maybe a composable block, and you want to have a proof out of that. The whole long it takes uh to prove it. I mean, if you want to build that in the same I mean, the 12 seconds in the block, you need to do these things faster. And this is a high computation that's in there.
So, the the the trick here is uh putting a lot of GPUs to work together. And the trick is, okay, how we minimize the latency? And this is the real progress that happened in the in the last month. I mean, 6 months ago, uh last June, when we first proof on the Ethereum block, I think we needed like 128 GPUs. And and and and you see the the the the difference.
And before that was not even possible. I mean, before even 1 1 year ago, uh we could not even talk about that.
Wait, so so what exactly is changing in this time window? Is it the fact that we're getting better kind of algorithms to do this computation, or just the GPUs just became 10 times faster, so we reduced everything by 10x? I would say that's very much engineering and engineering effort. There are some tricks that uh that that come more in the protocol, but mainly is an engineering thing. Uh when we started building the first provers, first this was just building the proof, then it's, okay, we build the proof fast, but just using a normal CPU, then GPUs.
But uh uh like 2 years ago, we started in Polygon, and uh then we continue outside. Uh the goal was to reduce this latency. So, okay, we already are able to build this proof, but it takes a while to to build them. I mean, we're doing in a very quite synchronous way. What we need to change in the way that we are manufacturing this proof in order to minimize this latency.
And this has been the focus uh that uh I mean, since we started.
And you've been at this for years. Yeah, yeah, I mean, this is a result of 2 years. I mean, it looks like, but this is uh the result of 2 years of working really hard in improving each of the pieces, and actually doing a lot of redesign in this connection. I mean, basic pieces are the same, but the the this um decentralized architecture where you can have a cluster of servers uh building a single proof so that you can get this proof available really fast and that scales very well. This is the This is the the the achievement.
I mean, this is the the difference. And this is what we have now and we didn't had just few months ago. Amazing. So, let's get some better context on what this is easy. So, is it a roll-up?
And if not, how do you kind of classify it? And then also, I think it would be helpful if you can kind of give us the difference between a different type of roll-up and different interoperability solutions and what kind of the list looks like. I would say Well, there is a lot of different things and and and a lot of important things. Um First is that um um easy is synchronous. I mean, and this is an important thing.
So, until now, most of the ways to connect, they were synchronous and a lot of Second is that's decentralized. Again, it's a smart contract. There is no multi-sig. There is no servers. There is just a smart contract uh that's running in mainnet, okay?
Third thing is that these these are more organizational, but easy is a specific association built for that. It's a non-for It's a non- non-profit association that the only mission is to build that. There is no token. There is no monetization. There is no um side interest.
That's not based
Yes, it's So, the focus is we just set up a relatively small team, and team from uh Zcash and and and Gnosis, but we started this way and be very focused uh to to to build that. This is our goal. We want to achieve this and this is the mission and the only mission of this of this association on this project. All this together is what we believe that this that this can really succeed trying to keep this protocol lean as easy as possible. The end is just defining whole this in between chain calls happen.
I mean a call is destination address, data, and a return value. I mean this very simple how they handle that and and have a nice trick of of ZK and compressing all these ZK all these executions in other rollups in a single ZK. And also this idea that you can connect layer one and layer twos and layer twos and layer twos. This also very very very interesting and I believe that this will change a lot how the I mean how the centralized applications will be built. Awesome.
So I have a lot more questions. I'm going to keep some of them. Well, I'll ask only a few of them. That's just probably a better way of saying it. And can I just help us get a better sort of understanding of how to think about this.
So the first kind of question is are there any limitations of what can be exchanged between two chains? Is it just tokens or is it any arbitrary contract call? What can and can you not do? It's literally it's it's absolutely it's just a normal call. So you can of course you can do transfers if you are calling to the token contracts, but you can vote, you can work in the identity.
Any call data payload works.
it's it it should be seen from your standpoint of view, it should be seen as if you are calling another smart contract in inside the chain. Important to mention is for example to create a roll-up, it's permissionless. I mean, you just anybody can create a permissionless there. And the other important thing that's there is that the state transition function of the roll-ups um anybody can decide and anybody can decide what's the governance of this state transition function. Here it fits native roll-ups without governance.
They just feel specific, I mean, just extensions of just replicas of what would be a layer one. And here could be private chains, decentralized chains, things with I mean, chains with their own token, with different governance, uh um we we were talking with different even even chains that are not EVM, chains like I mean, WASM.
Anybody can basically
Anybody can Anybody can build. This is also interesting because this allows also to extend Ethereum. Just uh Give us an example of what that extension could be. Uh well, I mean, it could be for example a private chain. So, a private chain can be a roll-up.
You can be running internally, they do whatever they want, but they can synchronously call other chains call also this private chain. Chains with privacy. Identities.
Does that mean that all sides have to be EVM compatible chains or are you saying that's not the case? No, no, no. Not necessarily needs to be EVM. So, they need to support calls. So, it's like, okay, what happened So, how the state The question you need to make is how the state transition function will be modified what I'm doing when I'm doing a call.
If you are doing a call, you are going to have this return and and state transition function is going to be modified.
As long as I understand the instructions, doesn't matter what's on the other end cuz you're just passing instructions.
how they are processing these calls. This is specific to to each chain. So, this allows in a lot of flexibility on on on on on the things that you can build.
That sounds like an awesome feature. Um so maybe a high-level question is, well, can you give us a better understanding of what real-time proving is and why is that important? And um and specifically it feels like we need to know what real-time proving is useful for to understand why EEZ is useful cuz in a way you're describing a bridge and we've seen bridges before. We've seen a lot of things go wrong with bridges, but this is not exactly that. So, help us kind of understand the difference.
Yeah, explain a little bit. We'll try to do it in a easy way. But I mean, when you are doing uh cross I mean, a cross call execution, let's example from between L1 and L2, okay? So, uh yeah. So, a transaction that starts in L1 at some point is doing a call to L2.
L2 is executing something there and it's returning there, okay? So it's returning and continuing executing in L1. How this is done? Well, actually we are taking I mean, we are asking this question. It's like, "Okay, if you do a call what's going to be the result and how the the state is going to be exchanged, okay?"
And and this is you can put this as an entry in a table, okay? And actually we store this entry in layer one maybe with a previous transaction in a bundle. And uh it and all this is zero-knowledge proof, okay? So, this is true. I mean, this is how it's following the rules in there, okay?
So, we have this um table in the in the in the layer one in the storage somewhere. So, when the L1 transaction is executed, it's going to be a proxy contract, something that will represent the
same version of functions but on the other chain. Yeah, exactly. So, if you call away call contract in another chain, well, it's going to be a contract in L1 that will have a say an alias So, that's a similar looking intermediary. So, you will do the call there. And what will this contract do?
Actually, it will receive the call. This is all this happening in L1. It will receive the call. It will look into this table where all these executions this execution table where all these executions are located. It will take it.
It will modify the state of the L2. Modifying the state this is actually is like executing this estate and it will return the value that's actually prove it in there. So, from the L1's contract, they will see that's that that the real call. And actually, this will be update in the in the layer two. Of course, all these calls that happens to layer two and that we can put all of them in a table with a single proof, you prove all of them.
all of these things happen together as a single version.
you you you you you execute So, that's real-time proving. This is real-time proving because you want to build that because you want to build that in an Ethereum block. So, you have like 12 seconds.
have 12 seconds to do all of these functions. It doesn't matter how many there are. Yeah, and the cool thing of this is that uh this is scales as much as you as as however you have. I mean, is this
a million instructions, it's still one proof as long as you can generate that in time. Of course, you have some limitations. The limitations are the the layer So, the the Well, the limitations are the Well, the the machine that you have. I mean, how many GPUs you have? How many transactions can you process?
Uh you have of course the L1 gas if you are calling something to L1. I mean L1 gas rate is still
doesn't eliminate the cost of execution. It just lets you have a big Exactly.
set of changes. If you are calling to L1 you will have to pay the gas in L1 for sure, okay? And also the data availability which is I want to mention here. But just want to mention I like here that for example transactions in between L2s these are they are free. I mean what I'm saying free, of course you have to prove all these transactions but you can have as many transactions as you want.
You can have rollups that they cross call one each other many times and the limits is going to be only from the
It's your CPU, yeah. So it's like if there is provide we call this piece is it's not the builder it's a composer. We call this composer that's building these bundles. Um I mean hardware of the composer is going to be the the real limitation on the of the transactions that happens in between L2. I learned a lot of things.
How does the audience feel about this? You good? Good. Does that make sense? This is this is great.
This is a good lecture. We're we're we're both doing our degrees or all of us are doing our degrees. Okay, so I have a good understanding of easy now. I have a good understanding of real time proving. The question I have is does it actually help Ethereum and rollups or does that create more fragmentation cuz now you've given people even more reasons to just leave and do things elsewhere?
We build this I mean I'm an Ethereum I'm an Ethereum believer.
It's a trick question, Jordi. Come on.
And and and Gnosis has always been proven that it's an Ethereum believer. We won we believe in Ethereum. I mean we we were born in Ethereum. We have been in Ethereum for 10 years almost there. So and we want to make Ethereum we want to make Ethereum like this our home, this our host.
We are trying to we are doing what we believe that Ethereum should be. I've been pushing hard since I started in the space to make this happen, make this work. And of course every time it looks like it there is more work to do, but it's this is I mean this is our this is our mission just pushing so that Ethereum is what it should be with the values that Ethereum had from the first day. Okay, that makes sense. Um maybe I did ask this question before, but I don't think I phrased it well, but we've kind of heard a lot of the good things.
What are the downsides or what are the trade-offs right now of like limitations or things that are not fully there for for this setup and and kind of how do we think about those? I would I mean would probably the the thing that I have more more concern of these systems is that in currently block builders they have a lot of power and we are giving them more. So, they can choose to basically discriminate.
Here the hope here the hope is the validators and the people that's staking. These are the validators for EEZ specifically, is that right?
validators for Ethereum blocks. So, it's just for Ethereum validators. But but they won't know what's in there, right? Cuz they just see a proof. Is that not that correct?
but they can I mean validators right now they are choosing which builder they have most of the times is the economical more things, but but they can So, they can say that this is coming from an EEZ node and I can do something with it if I don't want to.
We will see the structure, but probably builders they will have this composer that will choose there, but at the end the at the last word is in the the last word is in the validators, okay? And the validators they have like two incentive. One is like say the short-term incentive to to to I mean to explain
Yeah, to make money to an extract as much value in the short run, but they also have the the the the mean that the long run the the long term. I mean all validators they can make a lot of money now, but maybe they can kill the network if they are not acting in the right way. So they have also these incentive there. So the hope is that the validators of the Ethereum it's still very decentralized and the validators are choosing what are going to be those builders and those composers and those people that doing this hard work uh to keep the values to keep the network the values on that. So this is the the end this is what gives Ethereum the decentralization, but we need to go back to the validators people that is staking in the network.
And basically ask them to not discriminate or what is the question for them? Like what's the choice that they're being given? Well, that the the question for them is well, imagine well, we we have seen that for example with OFAC builders. I mean that at some point there were some builders that were not including OFAC transactions and there was a reaction in there and they were okay, let's put some builders that actually accept let's say no no OFAC things. So this is and this was pushed because at the end the validator is the one that can choose the the things and the place.
political thing not like a technical reason for them to Yeah, and also for example responsibility. I mean it would not be good that there is a monopoly of block building. So validators have also this responsibility for choosing different builders in the network. So this is probably it's going to become more important if we are giving more power to them. But yeah, when you were talking the concerns, this is some things that the concerns to me.
No, makes a lot of sense. My final question to you is just getting an understanding of where the project is. Is this live? Can people use it? If not, when does the easy become available for others to try out?
What's the status? How can people find out more? Well, of course, I mean, you know, this we're building it. Right now, we have a devnet fully working. It's an internal devnet.
We hope to in the coming weeks, month uh Very soon. Yeah, very soon uh open this devnet uh some way so that the people can start using and experiment on that and then from there going to mainnet, but this is more about security securing audit and there is all this ZK um prover that needs to be secured here. Ethereum Foundation is doing a great work here in in in in auditing and formal verifying all this. So, here maybe we'll take a little bit more time. We'll see.
We'll try to go as fast as we can, but also as safe as we can and and this is a little bit the the commitment that we have. Seems like very soon Very soon.
hands of people and I can't wait to to see this in in production. So, Jordi, thank you so much for this amazing lecture. I learned a lot and uh please give me a big round of applause.
Automatic transcript — names and jargon may be misspelled.
