Scaling After the Merge: How We Can Massively Lower Transaction Fees on Rollups

Transcript

so now we're going to talk about what some of the things that are happening after the merge so lots of things are happening after the merge um obviously there's uh a lot of improvements around the blockchain security a lot of application layer stuff in trying to improve ease of use a lot of improvements around privacy but the thing that I want to focus on right now is uh what is our top priority once the merge is finished which is increasing the ethereum blockchains scalability so why is increasing the ethereum blockchain's scalability is important I think there's two ways of looking at it

one is to just like do the math and understand how many transactions the ethereum blockchain can process today right so the ethereum blockchain uh today um the number is like it get processed about 20 transactions a second if we're looking at like actual transactions that just regular people send Unchained today but it can go up to about 60 per second if we're talking about in like very small and minimally sized transactions right now how much can 20 per second or 60 per second actually do it's uh good enough for a lot of use cases right so one way to look at 20 per second is multiply it and look at the number per year right so 20 multiplied by 31.5

million 630 million in transactions per year so it's enough for ever everyone in the United States and Europe to say register a domain name and update it once a year but nothing else right if you look at payments applications a lot of the mainstream payment processors they have TPS numbers of uh sometimes like one thousand to ten thousand sometimes up to a hundred thousand or even up to a million right and if we start looking at other applications like um even you know gaming and like non-financial applications on the internet they're kind of TPS that they require is even higher right so

scaling is important another way to look at it is from the point of view of transaction fees right so today a transaction fees are still very high they're much lower than they were one or two years ago fortunately but it still takes like some somewhere between you know maybe 50 cents and a few dollars to send a transaction this is good enough for large-scale financial applications but it's not good enough for like say accepting payments for just random like you know at a coffee shop or for like some products on the internet that only costs 10 or 15 dollars so reducing

transaction fees is very important and the only way to reduce transaction fees is well there's two ways to reduce transaction fees one way is to make ethereum useless so nobody wants to use it then transaction fees will be very cheap um the other way is only to increase Supply right to increase the amount of space on the Chain so that users in transactions like don't have to compete against each other as much so how are we doing scalability um this is a document that I published about two years ago the ethereum roll-up Centric roadmap and it's um at the time I think things were really moving in

this direction already right so I think in a lot of ways this was kind of more acknowledging what was uh already happening and Well on its way um but the core idea basically is that instead of the ethereum base layer protocol being responsible for kind of doing all of the scaling by itself we have this kind of separation of layers right where you have the ethereum base layer which is which provides like data space for transactions for Roll-Ups and other applications to store data and the job of the base layer is to just be open decentralized censorship resistance and secure and in the long term as stable as

possible and then you have layer two projects that can use the base layer to Anchor themselves and provide more scalability and speed on top so this is the role of centric roadmap um right so base chain focuses on providing what we call availability guarantees so basically Base to Base chain is a place where data Trend people can sense transactions that just contain large amounts of data and roll ups use this space you know of data and put transaction data into that space and this allows rollups to be this kind of

chain inside of a chain that can process a much larger number of transactions um so that that's this is the format right so basically we have this kind of blob data space that's on chain and Roll-Ups need that data space and uh the more data space we have the more transactions we can include there's two ways to try to optimize this right so one way to optimize this is to add more data to add to the base chain the ability to store and process and verify the availability of more data the other way to optimize this is to make each transaction take up less data so we can kind of look at some of these in turn right so today in

vehicle status quo a block theoretically can be up to a megabyte in size but the big problem that we have today is that roll-up data has to compete with existing transactions and existing applications for space right and so in any actual ethereum block today only a small portion of the gas in the block is actually being spent on data for Roll-Ups right so because Roll-Ups have to compete with these existing applications basically so because using in the blockchain indirectly through these layer 2 protocols has to compete with using the blockchain directly as a

layer one it's very expensive and it only gets a small portion of the space on chain right so on average maybe somewhere around 10 to 50 kilobytes in a block um prototank sharding so the um also known as eip4844 right so this is the uh probably biggest EIP after the merge that people are working on right now and the goal basically is to introduce a new transaction type where this new transaction type can store what we call these large Blobs of data and in these Blobs of data you can have a much larger amount of space so 128 kilobytes in one blob and in into each of these blobs you can have rollups that can put the data

for a very large number of transactions now prototank sharing is called proto-dink shorting because it's the first step full tank sharding actually the picture is a little bit uh typoed the full tank shorting should not be one megabyte because that's proto-dink sharding it should be 16 megabytes right so and in the future I expect it will go even higher than 16 megabytes right so full tank sharding is this can kind of further extension to the same protocol that allows the chain to include a much larger amount of data and there is like extra cryptographic magic that's happening to make this possible to run while only allowing each individual node to Store and download and check a small

portion of all of the data right so this is one way to improve things the other way to improve things is to reduce the amount of data per transaction that has to go unchain so the uncompressed so this is uh the way that things started um if you if you look at erc20 token transfers so it transfers of any token that's not if um then a transaction like just a regular ethereum transaction sending um an erc20 token requires somewhere about 180 bytes of data Unchained and if you just make a roll up the easy way and you make a roll-up that just like copies

the logic of the ethereum base layer then you need to put 180 bytes on chain for every one of these transactions now if we want to like get try to understand how much efficiency you're gaining by doing this versus um just using ethereum directly we can try to measure things in gas right so in gas today um 180 bytes is going to cost about 180 times 60 and so about 2880 gas and on layer one in New York state 20 transfer costs maybe about 50 000 gas so you're gaining about 20x in this particular case

um but so it's a significant gain but in the long term it's not enough of a game so how can we make transactions take up less space now the answer is compression but this is kind of a cop-out answer because the definition of the word compression is making things take less space um so we need to understand kind of how are we making these uh transactions take less space so one simple uh thing that you can we can do is just use compression algorithms right so the simplest form of compression is uh what I call a zero byte compression basically anytime you have a string of a large number of zeros you just replace it with

two bytes and the first byte tells you how many zeros there are and the second byte is a zero or you know something approximately like this right so this by itself reduces it already to about 154 bytes now you could go a step further and you can use um you know a Snappy or like some other kind of like mainstream compression algorithm and you lose a little bit more um but probably not enough right now another path that thing that we can look at is the signature now signatures are cryptographic basically random data and so you might think that signatures are not compressible right so but there is one thing that we can do with signatures which is instead of

compressing them we aggregate them so what does it mean to aggregate signatures right basically what this means is uh instead of putting every single transaction signature on chain we replace all of the signatures with a single cryptographic proof that says all of these signatures exist right so we just replace this as an all a huge number of signatures with one proof and the proof cryptographically proves that a lot of signatures exist there's different ways of doing this um so BLS aggregation is uh one that technically inclines people um might be familiar with um ironically enough people who are less technically inclined but but deep into ethereum lands might understand the

aggregation strategy called like just make a snark um so which is mathematically much more complex but like people have been blabbing the word snark in people's faces for a few years so people might know what it is already um who here has heard of snarks okay good yeah so you could you know there's lots of ways to aggregate signatures right but the point is if you replace all like all of these signatures with just like one proof then you can go down a bit more go down to 128 bytes and then if you replace zero byte compression with like theoretically optimal ideal stainless compression so this is not a general purpose compression it's not like Snappy or gzip or whatever right this is like a special purpose compression algorithm

that's aware of the fact that the thing that you're trying to compress is an ethereum and ethereum er seats when you transfer um and so you know it the algorithm might even have like some a lot of like different special cases that are optimized for the specific use case so for example you know if he wants to encode like what fee someone pays you might like it might have a specific representation for like every whole number of gray right so if your fee is like seven way which is seven which as a number is seven billion but you know there might be like one byte for it right so you just try to like pack as many really complicated tricks as you can and you can get it down to 75 bytes now ideal State voltage impression basically means well we don't just do

like regular compression we also have a compression algorithm that lets you read the history of the chain right so we could be instead of just saying um you know compressing numbers into like smaller numbers we actually say like replace an entire address with a pointer to the last time the same address was used right so if you do that sort of like very fancy stuff on average I'm expecting you know you can get down to about 23 bytes so this is like about a factor of of eight um improvements right so instead of Roll-Ups being a 20x efficiency Improvement roll ups become a 160x efficiency improvements one of the ironic interesting things by the way is that um here um the special purpose ZK

Roll-Ups so things like Loop ring they actually had ideal stable compression for a very long time right so like things like loopering I believe they've already had like 16 byte transactions basically for over a year but the problem is that like people don't want special purpose Roll-Ups people want the evm right and I think one of the fascinating things that's hap that's uh like happening with scaling over the next couple of years and with some of these like more complicated Technologies and you know zero knowledge proofs and compression is that there aren't really fundamentally new technical problems that are being solved right the technical problems have already been solved the problem is that people want fancy scaling and people want the existing general purpose evm at the same

time and it just takes like a lot of kind of hard you know Dirty Work trying to make the two fit together but you know lots of teams are actually doing this and people are making a lot of progress hmm so protein sharding basically as I mentioned right you know you have this new concept of a data transaction and so it's a transaction where that transaction contains this extra objects that we call a data blob and data blobs they're just Blobs of data right so you can stick application data into it you can take a cat picture into blob data um you know you can stick a picture of a dinosaur into blob data or you know you can have these protocols called roll ups

which use data as a place to like put transaction data and they need this to keep their security and they basically create these kind of blockchains inside of a blockchain that give if you um this like ethereum-like environments that has much more scalability now the next step folding sharding right I mentioned it briefly but it does involve like a a lot a bit more cleverness in how blockchains work um so the idea basically is right that you have these data transactions and it introduces this concept of data availability sampling so the way data availability sampling works is basically instead of a node downloading all of the data in all of the blobs a node randomly

picks a few different chunks of every data blob and it just verifies a few random chunks and it knows that if enough of the chunks in the data blob can be found then with very high probability enough of The Blob has been published that if you want to you can reconstruct the whole blob right so these blobs have this kind of magic cryptographic kind of self-repair property where if you have more than half of the blob you can always kind of repair it back to um you know 100 right um no it's if anyone's watched Star Trek come you know if you know if you remember kind of the bork cubes and um you know how they can kind of repair themselves this isn't like that but with math so yay polynomials um okay next

um right so a lot of like interesting and fancy math a lot of cryptography a lot of polynomials um but you know how far can we go with this right so there's two ways that um I think we can look at how far we can go here one of those ways is to look at limits to a data availability sampling right so data availability sampling is what I call a collaborative verification protocol right it is a way in which a community verifies that some chain is uh or like has data which is available um so where the blow ups have actually been published that depends on their being enough people doing the procedure at the same time if only one person DNA

data availability samples then you can trick that one person if 10 000 people are data availability sampling you cannot trick all of them without revealing enough data that that everyone can just very quickly reconstruct the blob so limits the data availability sampling if each client downloads 50 kilobytes during every slot and the total data during every slot is n megabytes then you need to have on average like 20 times n times maybe a safety factor of four clients sampling in order to be safe right so if you have 50 kilobytes and then the total data is going to be let's say yeah 16 megabytes so just like regular day charting so plug that into the equation 88 times 16.

and so you need about a thousand to a 1080 client sampling now if we want decide to be brave and we go with um I don't know what's the block size on bsv right now is it like 512 do they push it up even higher these days but I don't know let's say you know we're going to go crazy and try to do 512 right so 512 megabytes in this lot you would need 80 times 512 clients 80 times 512 is uh 40 960. so over 40 000 clients like so many clients some they can't even fit in the same him sampling at the same time for the blockchain to be safe right so there's this limit to this data availability sampling procedure that basically says that look the the higher the number goes the more you need to

have this kind of guarantee that a huge a very large number of people are checking the chain at the same time and if you don't have this property it's not safe anymore this is one of the limits to scaling another limit to scaling is long-term storage limits right so people want to look a guarantee that they can look up um data from the blockchain's history and they want a guarantee that blockchain history is not just going to be forgotten now the good news is that in order to achieve this guarantee we do not need to require every single node to store the entire history the way that we do today right the way that we do it today is actually like quite Overkill right and eip444 is actually going to

kind of separate out the function of being a consensus node from the function of storing the history so you can store the history if you want but you know you don't have to and validators do not have to and we can use other decentralized protocols to simultaneously kind of store the history and make sure it's very easy to access but the problem is that there's still a large amount of data here and we don't want to make it too difficult for people who really really really wants to store the entire history to do so if they want to so any megabytes per slot it turns there's a two and a half million slots per year so that turns into 2.5 times n terabytes per year so 16 megabytes per slot turns

into 40 terabytes per year that it requires you to be a hobbyist and it requires you to pay quite a bit of money but within reach of a hobbyist right um if we increase n to 512 then you know we're talking about petabytes per year and now becomes like a more institutional thing um so the higher scalability goes eventually storing all of the history becomes too hard um so these are the two limits the numbers for dank sharding which by the way can like if you do the math they can offer somewhere between like maybe twenty thousand to a hundred thousand or even more transactions per second with rollups they are kind of well within the safety margins but this also can be increased over time

um so next yeah so there's still a lot that we can do right now an interesting thing we do I think need to start thinking about like what's going to happen after the scaling transition right after the scaling transition different kinds of things become expensive so today reading and writing from the state is expensive doing computation on chain is expensive or a bit less expensive and data is not very expensive in a roll-up data will be very expensive if it's a ZK roll up then snark unfriendly computation will be expensive and reading and writing from

the state will be kind of expensive but computation is going to be cheap right so we are going to be scaling and a lot of things will become cheaper but some things will become cheaper than others and in this post roll-up world like you will still have to care about the kind of economizing on your blockchain use and the way that applications are designed probably will have to change at least at least somewhere so how do we get here right so three big eips eip4844 proto-dink shorting first up to dank sharding adding more space on chain um erc4337 is um account abstraction I did not talk about this but that's the ERC that's like that will allow ethereum

accounts like on Roll-Ups and on layer one to benefit from saving data uh through things like BLS aggregation um so you can uh it's a like really decrease the amount of data that they need and eap4444 um is the EIP that a lot that kind of separates out being a consensus node from storing history and so it allows regular nodes to continue to be easy to run even while the blockchain has all of this extra data so all of this stuff is in progress so lots are very smart and very hard working people uh trying um you know every day to make uh to make this happen and you know this is all going to create a kind of much more exciting much more scalable and you

know accessible and a cheap blockchain space okay [Music]