Transaction pooling in 4844 How to not go boom, in theory - Péter Szilágyi

foreign [Music] good morning afternoon not sure what your status is in the hackathon so um today I want to talk about something new that's coming in ethereum specifically if you think back about uh past ethereum hard Forks or passive theorem e eyepiece most of them were all about features features features which is super nice but we kind of reached a point where ethereum kind of works except it's super expensive so nowadays people are much more focusing on how can we make things cheaper or faster or do we have this word scaling as a basically a bag of features that we want to work on and one specific Solution that's coming up is will be eip4844 and I would like to talk about some very small aspect of it but before we dive into that maybe we should let me just do that yes no peeking on the next slide so uh first of all uh what is eip4844 well uh talk about that maybe we should just mention very very briefly what layer twos are in layer ones essentially ethereum is a layer one network Bitcoin is a layer one network Avalanche etc etc layer wall networks are kind of defined as self-contained networks you have transaction handling networking security all kinds of everything that the blockchain needs to do is just self-contained wrapped into this single Global Network that's kind of a layer one layer two networks are almost like it it's kind of almost like a completely self-sustaining blockchain but it is somewhat dependent on somebody else for example if you look at optimism or polygon or the other layer twos all of them run transactions concurrently to ethereum have their own networking State Management etc etc but at some point usually at the security side they kind of delegate that out to some other blockchain for example polygon optimism they don't have 10 000 nodes globally running some complex proof of worker proof of stake a chain rather they just piggyback and the way they piggyback is that they just run all the transactions that they have aggregate the results and from time to time submit those results to ethereum as proofs and why is this good well this has the potential to scale ethereum why does why could the scale ethereum well if optimism for example runs transactions and submits the proofs only every 15 minutes then it means that even though one of those proofs might be super expensive since they only submitted every 15 minutes A lot of that expensive key fee gets broken down across all those transactions so that's the scaling part now the potential part is that the drawback everything is a trade-off in ethereum world the drawback is that these proofs since they are submitted only let's say every 15 minutes yeah so I submit my transaction it gets included but yeah will it be included I am will I be sure that it ends up on chain I don't know I have to wait for 15 minutes so the security is a bit wonky furthermore it gets an even more wonky Arab thing that these commitments can be challenged so anything that's run on ethereum is immediately proven but anything that's run on optimism it can be challenged for a week so it means that if you sell your house on optimism maybe you want to wait for a week before you just hand over the keys but after a week passes the commitments let's say nobody challenged it everything is fine life goes on but what happens to these commitments well currently these commitments stay on chain but they are kind of the weak past so they are completely useless now and that's a problem and why is that a problem well specifically because data and ethereum generally lives forever which means that it is very expensive for example just to take a round number of 128 kilobytes uh submitting just 128 kilobytes to ethereum costs about give or take a hundred dollars at current prices and but that's just sending the data to ethereum if you want to actually store it in a smart contract good luck that's four thousand dollars and if you want to emit the log that's maybe eighty dollars now obviously layer 2 Solutions will have their own weird ways of what data they submit how they store it so I can't really say that okay optimism will cost this much or arbitrine will cost that much just the idea is that the costs are insane and if this data would be something we want to actually rely on long term then we could maybe rationalize the cost but the moment this data needs to be thrown away after a week no that's Insanity we need something better and this is where 4844 comes in specifically foreign introduces a new type of transaction called blob transactions where you kind of have a normal ethereum transaction but you can have this ephemeral data blob attached and this blog will stay in the network for a month or a week it's kind of not decided yet the the spec is not final and then this data blob will get dropped out of the network and the very very interesting property is that this means that the long-term usage or long-term price for storing this data is essentially zero we have to store it for a month but then we can delete it and of course 1559 was very very popular because it solved a lot of issues and for it for for introducers something similar for data blobs where the fees for these data can go dynamically up and down cool now there's an interesting aspect a political aspect here that I want to mention specifically that um 4844 introduces somewhat a parallel universe for these block transactions so whereas currently you have this gas that you just pay for evm execution and you have the base fee which is the cost for this gas as I mentioned previously 4844 introduces a data fee which is completely parallel to the base fee and that kind of means that if a layer 2 submits a block transaction it doesn't need to pay the base fee it needs to pay the data fee and these move dynamically independently from one another so what we could end up with users having to pay a lot of money for large transactions and layer 2 is having to pay very little money for those transactions so that might be a bit uh wonky is that fair is that uh good and well first up is definitely somewhat of a preferential treatment for layer twos but it turns out that it's not that bad because blobs consume this data gas it means that uh it doesn't matter how many data blobs we submit to the blocks they won't consume the normal gas so users they won't simply so we the assumption is that layer tools will always have a lot of money they can always afford the transactions so by moving their gas usage outside of the block space they don't compete with users so all of a sudden users can run their own transactions they don't get pushed out because of the layer twos and the fee wise for sure data fees move independently and that means that they can actually be cheaper than the base fee but it also means that if layer 2 start having a little war between themselves on who gets to publish the next data blob that doesn't impact normal users so the base fee remains completely independent from the data fee so all in all yes 4844 is professional treatment of layer twos but from the global perspective system it is probably better for everybody like this cool but so this was just a little background on 4844 why it's useful and why we think that it will be useful but let's go into a little bit of technicalities and maybe I should look at that screen and that is uh blob transaction pooling now the 4844 is a big EIP it has a lot of different uh aspects it touches consensus it touches cryptography it touches execution layer there's a lot of stuff to talk about what interests me personally or what keeps me up at night is if the network crashes denial of service stuff if a smart contract gets hacked I sleep well I I can't do anything about it that's not my problem if the network goes down that's my problem so that's what I'm focused on and that's why this talk is about what it takes to handle these transactions and I will try to contrast them with the normal ethereum transactions and the normal ethereum transaction pool to maybe highlight why they are different and what we need to do to handle them differently first up transactional sizes while ethereum transactions are really small probably a value transfer is 100 bytes or 200 bytes I can't really say most contract interactions are less than one kilobyte in size for sure if you want to deploy a new contract or if you want to do something very very fancy certainly some transactions might be higher in size but generally one kilobyte below a kilobyte is a good estimate so that means that networking wise we don't care about how you do how you propagate these transactions through the network you can just send it to everybody you can just send it to a subset of your peers the impact is so small that it's not that relevant so what we currently do is we just broadcast it to a square root number of our peers it's just a random number we could broadcast it to five peers it would be the same thing it doesn't matter in the great grand scheme of things and usually as long as we have a while connected Network like the first little graph there so sending it to a couple of our peers is enough there are certain parts of the Ethereal Network which are kind of degenerate where you have this box probably corporate networks there it actually might make sense to have a backup mechanism and what we do there is we not only broadcast it to a few of our peers we just announced it to everybody else just say that hey I have this transaction with hash whatever if you want it come and take it so that's kind of the entire transaction propagation for legacy classical ethereum transactions blob transactions are different however they are big the smallest block transaction will be 128 kilobytes in size depending on what the final spec will be it can be half a megabyte two megabyte it can really grow and that's an issue so even if I take one 128 kilobytes propagating that across the network where every single node just gets it once and sends it once to somebody else that's already I think either 1.3 gigabytes or something of data traffic for the network so it's it's large so if you all of a sudden start passing around these blob transactions all over the place and sending it to many peers is going to be a huge hit on the networking so we don't want that to happen so first up first rule of block transactions no broadcast broadcasts are forbidden and a networking layer the only thing we must allow is we can announce it to other peers and they can retrieve it if they want to this has some implications that latency or block transactions will be a bit larger but we're willing to live with that and the other thing we need to take care of is that fetching transaction the concurrency the vulnerable transactions transactions rules are done hey here's a new transaction awesome give it to me here's another transaction awesome give it to me for blob transactions we need to kind of be a bit smarter and make sure that if we start requesting random transactions we don't overload ourselves so that kind of requires a bit of extensions on the networking layer so when something is announced we also know how large it is what that is so we can be a bit smarter and that actually is the 868 protocol that was deployed a couple months ago okay transaction size blobs are big rule number one the other interesting aspect is block space now an ethereum block contains I mean there are there's it's targeted to contain 15 million gas and it's capped at 30 million gas that quite a lot of transactions how if I were to fill it up with plain value transfers that would be a bit over fourteen thousand fourteen hundred the transactions that could fit in a single block now the implication of this is that there's a very very high rate of churn on the transaction pool by turn I mean just new transactions arrive all transactions get popped out people cancel transactions replace so it's just this big pile of random transactions shooting in the network and there's a big problem with these these things we cannot really persist the transaction Bluetooth disk there are so many transactions coming and going all the time in the network that pushing them to disk is problematic okay if you have a very fast SSD you can probably do it but it's it's not obvious what the implications are so what currently at least get I would assume other clients also do is they just keep everything in memory and don't care about disk but if you keep everything in memory the implications are that you can only keep a limited amount of transactions in memory so all of a sudden you open up to these it's called resend and eviction attacks where somebody just swarms you with transactions then your pool gets emptied out then they cancel those transactions and it's just a horrible constant patching of the pool and tweaking it so that different weird attacks cannot happen now opposed to this blobs are much better the blob space in a block is capped to four in the current spec it was 16 in your previous spec my assumption is that it will go back to 16 in a future spec uh just uh kind of a roll out just start slow and ramp it up afterwards now the interesting thing about having four of these transactions in a block is that it the churn is very very slow so I can actually so if I need one of these blocks arrived every 16 seconds or sorry 12 seconds and like it just and contains only four of these transactions I can just save it to disk load this from disk all of a sudden disk storage becomes possible and this allows us a very interesting thing to increase the capacity very significantly the exact number is kind of anybody's guess if we were to increase it to 10 gigabyte of disk storage we can probably store about 80 000 transactions block transactions there probably doesn't really make sense to increase it that much we can push it even more even less doesn't really matter it was just a random number but the idea is that the moment we have a disk backend for the transactions evicting legit transactions becomes kind of unreasonable meaning that somebody if I if somebody wanted to attack a Minor's transaction pool they would actually need to fill up 10 gigabyte worth of block transactions and you cannot really cancel that so fast so you will probably end up paying a lot to do that however the moment we want to introduce at this back end we need to take care of artificial churn meaning pool wars currently transaction pools constantly allow Replacements and miners constantly try to or tried to somehow beat each other and sandwich each other we need to prevent that and before we get to that point one more thing I want to discuss what is the purpose of transaction ethereum transactions are super generic it's kind of we deliberately didn't want to choose what you can do with a transaction it's just there just go out do whatever you want with it and that's nice because for users uh they can just sub iTunes transactions then replace the fifth one then cancel them because they're dap I don't know requires that and uh that's super nice and we are really happy that we can support that use case but it is a nightmare on on our side because it's just uh so many bad things can happen and any constraint any limitation that we want to introduce all of a sudden we break somebody's dap or somebody's use case and then we have a big pile of issues and it's just head scratching on how to make it work now with blob transactions the purpose is layer twos so all of a sudden we access a very very well know what we want to do or what we want to use these block transactions for and specifically that the blob transactions are made for commitments and these commitments are independent of ethereum it doesn't matter what happens on ethereum optimism still needs to prove that there are 10 000 transactions did this so these blob transactions cannot become stale there's no absolutely no reason for optimism to say that I want to cancel that transaction it just doesn't happen or it shouldn't happen so um furthermore these layer twos need to commit regularly so every 15 minutes so not only cancellations don't really happen but um they those the past transactional problem needs to go through in that 15 minute window before the next one comes along and the other reason the other interesting thing is that since layer twos are meant to um since essentially since this block commitments cannot really change there's no reason to replace one transaction versus the other except if the fee really goes up for whatever reason the network feed debates feed the data fee so we would like to allow Replacements but not that often and the reason for that is the cost of replacements now a normally ethereum transaction can be replaced very very cheaply currently there's no minimum price required for an internal transaction it's one way and the only reason there's one way is that you cannot it should not spend the network if you want to replace it would require 10 fee bump again just a tiny random number so to disinter by spam uh quote uh sorry parenthesis it doesn't work so no spam sensitivization there anyway but the idea is that these transactions are small so it doesn't matter if if somebody replaces it we just re-propagate it through the network it's fine and validating one of these normal ethereum transactions is cheap well there's some signature recovery some State lookups but otherwise it's okay however blob transactions are a completely different story rebroadcasting them is very very very expensive so as I said just sending one single block transaction through the network incurs gigabytes of transfer cost for the entire network so if people would start fighting with each other replacing one another's transactions then the network would probably grind the hold so we really don't want it processing time I've kind of found a benchmark that it takes about two milliseconds to verify one of these blobs via kcg that's the cryptography behind the block transactions I don't know about that number I haven't tried it myself so let's take that with a grain of salt that two millisecond doesn't seem like that big of a number I kind of it boils down to how many of we get how many of these transactions arrive but the idea is that the bandwidth is horrible so we need to prevent people from replacing transactions and essentially my solution is just penalize it heavily meaning that the starting price is fairly high and if you want to replace something the feed that you have to bump up is again very high now note uh before 1559 if you bump something by twice the price essentially had to pay twice as much but with the dynamic fees it's not necessarily paying twice as much it's just that you allow the base fee to go up a bit further so requiring a 100 feedback doesn't mean that we're going to be evil and you have to pay or layer twos have to pay twice as much money just that they have to accommodate to the fee potentially going twice as high just to make it fair and just to prevent them from having to resubmit 373 resubmit with these 10 races so with a cost blob transactions should be replaceable but they should be relatively expensive to replace on the other hand cancellations are completely different story ethereum transactions can be canceled people use it for example they submit the uni swap swap and then something changes and oh I want to cancel it because all of a sudden some liquidity provider changed and all of a sudden I need to pay more and then they can just submit a self-transfer which just does nothing at a bit higher fee just cancels the other transaction or I think we've also seen where some people submit multiple transactions and then they try to cancel all of them by just sweeping their funds with the with a new transaction I maybe that second option is a bit more of an attack vector I don't know if there's a legitimate use case for it but either way it can be done and as I said the problem is you want to remain flexible and it's very hard after 10 years of running ethereum to just say okay from today onwards you cannot do that anymore yeah that's kind of far to say however with blob transactions we can be the evil ones and we can say that okay no you're not allowed to cancel them and that has a few aspects specifically you can replace it as I said previously because it's normal that you uh I don't know the base theorizes some theorizes I want to replace it but the replacement would only be accepted if that doesn't invalid in any future ones so you cannot just sweep your account that's not allowed anymore for Block transactions and again the reason is that if you propagate five megabytes worth of block transactions through the network that's I don't know 100 gigs give or take offload for the network then you're not allowed to cancel them you're not you you're not allowed to just go no no no no undo everything so rule number one is that you can replace a transaction but it cannot invalidate any future ones the other one is same vein that nonce gaps are not allowed so the normal transactions I can submit transaction with non-zero then five then ten and eventually maybe fill it up the gaps or not this is kind of useful because people submit transactions randomly they propagate randomly it's a useful feature but it's also an attack vector for adopt transactions we don't want that to allow that simply because the bandwidth cannot take it so rule number two no no dance gaps and rule number three which is a bit interesting is that if you have a blob transaction skewed up you're not allowed to submit a normal transaction until that block transaction goes through again the reason is to prevent you from wasting bandwidth with the block transaction again as long as it's used by layer twos they submit one transaction every 15 minutes these rules are perfectly acceptable so again the rules were designed for the use case in mind and the rules allow us to create a much more robust pool now locality I'm going to speed up a tiny bit normal transaction pools has this notion of locality where you we allowed pre 1559 was meaningful for um local transactions to exist where it can be made with zero gas price or um if the more important thing for local transactions was that any transaction that you submitted yourself was kept in your pool always even if it was too cheap because of all kind of hacks to somehow try to prevent try to work around the fact that the pool was too small to fit everything inside but with blob transactions we saw everything on disk so in theory we can make the disk in theory again we need to measure this in live in production so until then everything is in theory but in theory if the the pool is large enough then there's no reason for anybody to be evicted so there's no reason to say that okay this is my transaction I need to retain this and that simplifies quite a lot plus since the basic was introduced in 1559 and now a new data theme 4844 this whole zero price thing is just uh eliminated so there's again no need for this no shut off locality now another interesting aspect with block transactions is that in every single transaction ethereum was always a superset of the previous one the access list was extend wholesale transactions were extended with access lists then the accesses transactions was extended will be 1559 base fees and there's a very very serious push from the research side to have block fees extend this is something we debate the idea is that ideally in my world lab transactions should be Standalone because um the problem with generic stuff is that every time something you make something more generic implementing it and handling it is getting more and more complicated because you just need to do everything that you did until now plus a whole lot of other stuff and as we've seen previously there are a lot of problems with the existing transaction pool so if we make something even more generic then instead of making something more robust we're making it even wonkier so that's why personally we we push towards making block transactions uh Standalone meaning that we want to forbid a blob transaction that does not have a blob so that's that's the big debate on the research side do we allow zero blobs or don't we allow zero blobs and ideally we wouldn't allow it and uh I guess uh life cycle of transaction I renamed the slide an hour ago thank you uh yes so there are a few Works in for Block transactions um normal transaction in theorem transactions are Standalone this is the beginning of the transaction the end of transaction if it's sent over the network it's completely sent over the network if it's included in a block it's completely included in a block if there is a reorg I can just say that okay block X was reordered I can pull out the transactions and stuff them into the next block it's easy to handle blob transactions are a bit more notorious because these blobs are kind of dangling um outside of the transactions and that makes a lot of problems because one of the problems is that if there's a reorg then I can pull the transaction itself back from the chain but the blobs nope and that's a big problem which means that anybody working on implementing block transaction or transaction pool needs to take care of this fact that it's uh they have a very very different life cycle and the other thing that's a very very interesting with blood transactions is exactly the same reason is that there's the point of entry or block transaction is not clear normal transactions arrive into the pool and you have it or as I said previously maybe they arrive in a block but you have it whereas the problem with blob transactions is that if we have an Mev bot that mines the block transaction and we just receive a block which contains three block transactions but we don't have the blobs okay what do we do then and it turns out that this is a complication that needs to be handled on the consensus layer too haha because all of a sudden it's um it's just an interesting aspect I wanted to highlight that uh there are implications for everybody for Block transactions now to close up the whole thing why why did I talk about all this what's the whole point of all these constraints and details and whatnot well we only have a prototype implementation but our current Legacy pool is kept at a very very low number at 4 000 transactions in theory it contain it consumes 200 megabyte Ram in practice it consumes a lot more the problem is there are a lot of problems because of this small number and we wanted to introduce as many constraints as possible to blow up this number as much as possible and with this design it kind of allows us to arbitrarily blow up the disk usage while the memory usage is fairly insignificant so I just random Benchmark that we did for 80 000 transactions it consumes I know 20 megabytes of memory so that's not relevant and the disk churn is not relevant either however the problem everything is a trade-off so whereas the Legacy block pool whenever a new block arrives we can reshuffle it very fast in one millisecond for the blocks for the data blobs we have a two-dimensional data view we have the base fee and the block fee that makes everything insanely complicated so for this this number it takes a lot more a lot bigger hit but still 75 milliseconds after a block is processed before the next block arrives it's acceptable all in all uh what I would really want so what the takeaway could be is that everything will be a trade-off so introducing a new blog type of transaction is a trade-off you have to very very carefully pick what you want to support and what you want to forbid and the more things you forbid the better it is for everybody except the user except Liberties but uh yeah they'll have to live with it and uh finally that kind of metrics is king So measure everything because it's very very easy to say that some things should be should work but as you can see there um 75 milliseconds is completely acceptable but it's not a small number so you need to always be aware of what the implications will be and kind of that would be a very very short intro into the challenges of blob transactions at least on the execution list thank you very much I got it