The Role of the Public Mempool in CROPS Ethereum

Transcript

[music] [music] Thank you. Thank you. [snorts] So today I will be speaking about the meool. Uh the role of the meool in Ethereum, the role of the map pool in clubs Ethereum. I'm Chaba. I'm Chabakai from the guest team at DM Foundation. Let's see if my clicker is working. Yes. So the pool is quite important for crops.

Uh Ethereum must above remain censorship resistant, open source, private and secure. [snorts] And the chain itself might has its properties, but it's quite important that uh get getting onto the chain should have these properties. How you get on the chain? You are getting on the chain by sending your transactions. How you send your chains on the transaction? You are sending it to the public man pool if you want these properties. So how this is cops?

Uh if [snorts] you want censorship resistance, you need a place where you can send your transactions in a permissionless way so that anyone can send their transactions and they can get to the builder. So for that you need a public meool. The public me is also running on open source software. Uh it's it's the part that you can verify and uh audit if you want private flight access to the network. Are you sending your transactions through some RPC somewhere or do you want to send it to the public man? You want to send it to the public man poolool and [snorts] at that point they don't see that you send the transaction.

And also on the security side it's secure but there are challenges. Uh it should the public man pool should does it spam which is quite lucky. But let's roll back a little bit and and just speak a little bit about what's the public man pool because I realize some people actually don't know uh what's the public man poolool. So when you are looking at a blockchain consensus theory uh there these transactions they get included into the chain and then they get finalized like this is the the very simple view of a blockchain and you can do this at home on your home database you can include things and you can build a blockchain structure and it's a blockchain uh it's just not a distributed system and uh you don't have all the properties. So that is a bit of a more complex view of a of how things

get on the chain. Right? This is still not too complex. You [snorts] create a transaction. You send it to the meool [snorts] and the meool is this thing where you can send your transaction. How you send it? You send it to an LPC to infer. uh you send it somehow the node and that it gets to the me pool and then it gets included in the chain because a builder is including it and then it gets finalized after the finalization delay and then you are good and your thing is on the chain. So what is this demand pool? Now this demand poolool is a bit of a tricky beast. Uh because this is kind of a gray area. This is before the builder decides to to even consider your

thing. So when the builder is building the block, it should have a view of what are the transactions which are waiting in the queue. And this queue is in the me pool. I'm saying queue but it's not a queue. It's a pool. It's a pool of transactions which were already generated somehow submitted to this demand pool and then uh the builder is taking them putting them in a block they get included. They get finalized. Now when I'm saying this submit [snorts] to the memp pool uh there are two things to to notice. One is that the meool which is a public meool is a distributed thing. uh it's a distributed system of many nodes and we have 10,000 nodes actually 12 [snorts] epilog 10,000 nodes

and they handle this demand pool and then there are kind of other ways of getting on chain and this is the the private transaction feeds which are just getting directly to the builder and then you are not participating in this demand pool. So let's say you are sending it to the public pampool and then there is this system which is distributing these transactions. They are not under consensus. The rules of the game are not the consensus rules. The rules of the game are peer-to-peer rules which are seeing the prices, seeing the fees, seeing the transaction properties, seeing the nonses, seeing the source of the transaction and based on that trying

to keep this view of transactions [snorts] uh that are queuing to get on chain. Okay, if life would be this easy now [snorts] we are getting closer to the to the picture. So you create your transaction and you have these two different paths. Uh I was writing the public LPC but note that all or your own E node actually. So traditionally this is more like you have your own E node and you use the RPC of that thing. you're not using a public RPC. So either use a public RPC or you use your own own node and then your

transaction is in the public man pool or you are sending your transaction to a private flow which is going to searchers. Searchers are also obviously looking into the public man pool since it's public. Then this is going to builders and the builders are also getting private flows and those goes to delays and those goes to block and those goes included and those are finalized etc. So there is some complexity to it and between these two there is a bit of a race. Uh there are different advantages and disadvantages on one side or the other. Now we are at about like 50% here 50% there of transactions. If you're looking at value and gas, uh the public man poolool is capturing less than the private flows in the current situation.

But there is still that blocks box the public me and we still have a very simple view of that right it's the meool the queue of transactions so [snorts] that thing is a distributed system those are the e nodes sharing who have seen which transaction there's a node which saw some transactions there's another node that saw other transactions and they're kind of synchronizing on this and we from distance are looking at this as just one pool of transactions But the builder sitting in this thing has a different view from another builder.

So it is important to understand that these views differ. How much they differ you might ask. And uh this is something we studied. This is a study from two years ago now. But it's kind of the same. Didn't change this one. We change are changing other things. So what you see there is is is a time axis and how many nodes in the uh in the me pool in the from the 10,000 are seeing one given transaction. Each curve is one given transaction. A curve shooting up means that in less than a second 50% 60% so that transaction. So the meool is actually very synchronized in the system. If you are thinking of 12

second slots and we can discuss whether we should think of 12 seconds. If you think of 12 second slots then they kind of see the same. So we can have this view of the me pool as as one single pool and everyone is seeing the same thing today. What if we are increasing the volume? What if we are reducing the slot? You might ask these things start to matter. they will have different views [snorts] and we should kill about this. What if the sizes of transactions are increasing? Uh again these things will change and we should kill about this.

So as I said each node has a view of the meool and uh in gas now we have this extension uh it's not like an official extension but you can download it and you can use the branch which has it at the moment uh which is showing you your live view of the meool and that's what I I wanted to show you. So what you see here is a live view uh that's not live this is a screenshot uh and you would see transactions going each with its hash and then the stage the stages I still have the screen you don't

now you do okay so you see the stages uh as I heard about the transaction me as a node in this 10,000 network uh 10,000 node network The A is I heard about the transaction. The next one is I requested it. The next one I received that specific transaction. I was putting it into my view of the pool and then it gets included and then it gets finalized or it gets rejected and [snorts] you can just watch it live. Let's see if we can watch it live. I'm not doing a live demo in the sense of connectivity, but this is how you would see it. So this is your live view of transactions going. Now I was scrolling. It didn't stop. I was just scrolling down and then you can see

transactions which are getting included and then if I would wait a little bit you would see them finalized. So you can see this dynamic behavior uh why we did this. So this is a tool for for us for researchers to see in the man poolool to understand how the manool is working and you have other views. You can look at the the peels of the node or you can look at the peels of the node on a map and you can just understand what's your node is doing in the network which are the peels from that those 10,000 which are the 50 from which you are with which you are exchanging uh the uh the transactions currently. You can

look at uh a diagram of how many transactions are there, how many this was not up up to date. This was already not too much data. But how many transactions are there? How many are uh are included in the chain. Okay. So this is how is the mempool today and this tool is to to observe how the mele works today. [snorts] Now how the mool will work tomorrow. Uh we are changing the mool. So actually we are changing a bunch of things in in how the mool is working. And the first one is I guess you were hearing about this. This is fossil. This is about

making sure that the censorship resistance property that we were speaking about at the at the beginning is actually happening. So that you don't you you can submit your transaction to the man poolool and then the builder sees it but it doesn't mean it it's also including it. It can just avoid it. Right? So we we we we have the means to to bring it to the builder but the builder can still say no with fossil it cannot because there are nodes in the network which are looking at their own public mele selecting transactions for first inclusion basically. Now this only works if your transaction is in the public man poolool. If we would go back to the to our old figure, if your transaction is not in the public man pool, but it would be on a private order feed, fossil

cannot protect you. So the transship resistance protection that we are adding with fossil is built on this infrastructure. We are also adding other things uh some ideas, some are going on. So uh are ongoing. So they speak of encrypted me pools uh which basically allows transactions to go in in an encrypted way so that you don't have to keep them private so that they cannot be sandwiched cannot be attacked. You can send them to the public man poolool yet you are not revealing what you are doing before it's actually included.

And then there is frame transactions. stream transactions is changing how you are composing your transaction and it's needed for many things but why it is needed here uh one reason is because the transactions are signed and the transactions are signed with your key and that key happens to be not uh PQ so not quantum resistant so if you want to yeah let's sign it PQ the problem is that PQ signatures are much bigger than our signatures 48 bytes for our current signatures 2.5 kilobytes or what depending on the choice uh for the PQ signatures. So transactions becomes much bigger.

Uh it still works but it it's becomes a large traffic volume. And that's where the next innovation comes which is uh frames gives us already a structure of the transaction where the signature part which is authenticating which is telling me [snorts] the transaction was sent by the one who claims that the transaction belongs to is separated from the actual what the transaction does what is being executed or was the actual exchange there.

So this is decoupled [snorts] and there's a new EIP EIP8288 in which uh we are dealing with this decoupling. [snorts] So what we are doing here we are doing saying the bulk of the data amount is the signatures and the signatures we just have to know that that was the signature. We just need that one bit of information basically that this thing was signed with the right signature. So we can actually in the me poolool verify the signature create a zcape proof. Unfortunately we have to create a zcape proof and say this thing was signed. Sounds good. So now we exchanging a 2.5 kilobyte

signature with a 250 kilobyte uh zcape proof. Now that's not the right business. But what we can do is we can look at 1,00 transactions and we can say these 10,00 transactions were signed. verify that and then we can create uh a signature and then we are playing and once we have these proofs we can do a recursive aggregation on these proofs inside the memp pool. So what we can do is as transactions are coming we can integrate them into this view of proven signatures. We can exchange these views between the nodes they can integrate these with recursive z aggregation and they just know that the transaction bodies which are small

that they see are signed by the right guy all the time. Okay. So we are going in this direction. It's changing the structure of the mampool. It's changing the work in the mool. It means that mampoo nodes will spend CPU doing these zcap loops. But these are relatively cheap zap zcap proofs. Uh but it's it's really changing how things operate. So what we can do we can resurge right. Uh we can check what this means and uh I was creating a a simulator to study this in the distributed system. So this is the simulation. Uh this is not the simulation. This is one result. Uh anyway, we can check with I was checking with 1,000 nodes. We can check with

10,000 nodes. It doesn't really matter. Actually, what I'm showing here is it does matter and it does matter in the sense that this new pool technique has a nice property and that nice property is that the nodes are adding compute capacity into the network and they are not doing the same thing. They are not reexecuting the same check. they are compressing the signatures and the more nodes I'm adding to the system the more compression CPU power I have in the system so the capacity of the system is increasing with the number of nodes right today it's constant or decreasing so we are going from a regime where we have constant capacity or decreasing capacity

we're going to reg increasing capacity in the me pool and that's a very nice property another nice property is that we can handle today's load fortunately and we can handle more as well. Oh, and typically it's asked how much is the latency. The latency is still below one slot because we are doing this ZK proving and we are doing it recursively many times. There's latency added but it's still below the slot time and we can work on that. Okay. Two takeaways the public man pool is changing and the public man poolool is changing in a way that it's becoming more and more part of the protocol uh with fossil we are integrating it it's the public man poolool is the one which is giving

this enforcement on what should be included in the blocks but this means that we should also build out this guarantees that and logic how f should be done um Then the uh another part that of the of the A28 that I didn't mention actually is that by having ZK proofs you can also do private transactions in the meool itself because you already have the machinery to handle ZK proofs which you can use for private transactions.

Okay. So overall uh we are changing going into a into a scenario where the the meool itself and the rules of the mool become critical for the system. So we should work on the on the security of these uh but we are also work uh improving the tools and improving research on this slide to finish if I say it wrong uh I'm using today this lens uh this is more a tool for research or if you are interested uh how [snorts] your node is working

I was also working on this simulator for A288. This is a research simulator. So if you're a researcher, uh this is a tool to study the the algorithm. This is a tool in which you have all the design options embedded and you can play around with with different designs. And then there are two things that I was releasing I will be releasing soon. one is purge uh which will be your personal RPC and chain scope which is an Ethereum ecosystem observatory. So if you are interested in these I couldn't put quotes for this unfortunately I would have preferred >> [snorts] >> uh what's remains is is follow me. Thank you.

>> Hey Shaba this is amazing and we have questions for you. >> Oh >> yes a lot of questions. What about that one? Um since there are no extra reward uh for building an inclusion list, what motivates a validator to include a transaction that others are trying to censor? [snorts] >> So that's a good question. I let me answer it from uh from another perspective not that much fuel specific uh more focusing on the on the for example the on the aggregation role uh in the in the man poolool. So for example for the

aggregation role in meool there is no motivation why you would do that. Uh but there we are building machinery uh and I have a a write up on that which is working such that when you are doing the aggregation of the signatures you can put your name next to the the job that that you done. Uh you can say I was doing this aggregation this I've seen this signatures I've put it uh into the zk proofs and that's me. And since the builder doesn't see the signatures only this when it's using this your tooth it's forced to include also your claim and you can be paid for this. So that's that's a little bit different from this one but we do we are building mechanisms to actually pay work in the meool. Now

whether we will use this or not depends on many factors whether it can be used in fossil or not depends on many factors. uh but I'm working on these mechanisms which allow you to actually make claims based on mele work because the work is changing who is doing the work in the system is changing a lot and uh more and more work is being put on the mele nodes uh and it's not fair that they are not paid in some sense so depending on how we are planning this and and playing this uh we might change also who is getting paid uh but we have some means for this >> interesting yes and they I have another question and if you'd like to do your question, you know that you can use the care code over there. Um,

so and the question like change a bit the order now. Uh, but I was reading the second one since there are no extra uh well we talk about that. So let's go to the first one now. If the meo is mostly a node policy, why do enforce admission rules at the protocol level could we relax this and allow each node to handle the DOS in their own implementation? >> Yeah, so this is what we have today. So today it's not un it depends on the implementation and different implementations are different and everyone is handling it every client is handling it on its best way. Uh it's still an open question how much of this

we want to make rules that we enforce and how much of that uh we want to make uh leave to the implementation things to what what is important to understand is that the meool is a more like a traditional peer-to-peer system and the enforcement in in it is more like a traditional enforcement system because it comes before the chain but we do have means to tie it to the chain. So for example in gas now we are ranking peers based on their performance but not the peer-to-peer performance based on the how much what they are giving us goes on chain and is being finalized. So there's a feedback loop from chain into the operation of the meur which we can do to use to protect and protect from DOS and

protect from from other attacks. >> Okay. And now it's not my understand but from uh anyone that is here um that proof of can be computally expensive. Uh what incentives do node operators have to take on that extra work? >> Yeah, I was speaking a little bit about this uh but this is something that I I care a lot about. So uh depending on how much work it is we can actually uh make it in a way that if if you do that work you are getting paid. Uh there are obviously details to to speak about like if there is repeated work then who is getting paid who is not. So there are

details to work out but from the aggregation perspective we have the primitives to to to pay the aggregation work. Uh whether we need it or not depends on on on the amount of work is needed. uh we are making huge slides on that. So uh aggregation of two proofs into one is now around 250 millconds or something but it's burning CPU power. So uh we have to see where we arrive with the efficiency and based on that we have to decide um what we do here. >> So Shaba I learned a lot about the main pool and thank you so [music] much