# Scaling Ethereum with DAS: an iterative approach

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 25:22
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-XGDkz10tUmk
- YouTube: https://www.youtube.com/watch?v=XGDkz10tUmk

## Description

In this time between the launch of 4844 and the possible launch of a first version of PeerDAS, we explore and explain the iterative approach that has been employed in the rollout of blobs and DAS to Ethereum, and discuss the past and future steps.

## Transcript

[Music] [Music] hi everyone um I guess I was already introduced but still I'm I'm Franchesco I am a researcher ATF mostly focus on the consensus layer and I'm here uh today to talk to you about the approach that we taken to scaling ethereum which is a iterative incremental one the so but first let's start with a recap of the rollup Centric road map so far and all of the steps we've already taken which are many at the beginning was just ethereum this uh Standalone blockchain executing all transactions um no rollups then uh we've moved maybe around 2020 to having uh first rollups coming live uh basically other blockchains post posting their transactions on ethereum um as call data in particular and uh ethereum not executing any of this but only verifying uh the correctness through optimistic proofs uh or or I mean through fraud proofs or validity proofs and uh finally this year like a big milestone we've moved on to uh what we could call like the first scaling era of rollups through EIP 4844 blobs have been uh live and um you can already see from this picture things look a bit different now transactions go in this um these side cars these blobs that exist outside of blocks that the evm cannot access and yeah just for you know making sure that no one is upset here's just substituting with other logos so that everyone can find their favorite rollup uh but what have we actually achieve with blobs like why why was this a big milestone why have fees gone down and so on uh why are we scaled in some way and there's a few reasons the the main reason is that uh blobs essentially have an independent fee Market uh that it's completely separate from uh the execution fee market so this is probably one of the the biggest components of the way that blobs already scale something and then the other compon is that they're only stored and served for 18 days as opposed to for all of eternity and so this allows us to be much more comfortable with higher blob throughput and U another thing that is not in immediate um output to to to scaling but that is very important in this iterative road map that that I'm trying to tell you about is that we've kind of laid the cryptographic cryptographic groundwork uh and foundations for future upgrades so in particular the kzg ceremony and um all of this cryptography being introduced to the to ethereum and uh yeah now the question is what's missing why was this upgrade not enough and and we need to keep moving forward um so still the the issue is um there's no sharding all blobs are being downloaded by everyone a block proposal process looks the way you see here there's a block proposer with a block and some Associated blobs and it broadcasts everything to the network through in in these what we call blob subnets so these like kind of sub networks that are specifically for blobs well we call them subnets but they're not actually subnets everyone is is actually um participated in them they're what we call Global gossip topics just like the topic that we use for Beacon blocks so the whole network is downloading both the block and blobs so we haven't uh still really moved from the fundamental bottleneck of bandwidth which uh you might have seen that is really coming up more and more as uh the scarcest resource that we have and how do we solve it uh how do we solve this we mve to uh data availability sampling or we introduce data availability sampling to the protocol which is essentially the the next uh big goal for for scaling ethereum and or the da layer of ethereum and the rollups that they use it so first a small introduction to what is data availability sampling it's something that in abstract has been talked about for many years so probably many of you are familiar with it but uh still the at a basic level essentially we take what's on the left um which we could think about it as just any kind of data but let's think about it as a blob uh this um blue part uh and uh divide it in in a bunch of chunks then we eraser code it so we essentially introduce some redundancy to it in such a way that it becomes reconstructible as soon as any 50% of this data is available and so this redundancy is the orange part uh rather than you know needing the the whole 100% of it to be available and what this allows us to do is essentially to be able to check availability just by checking that any 50% is available which is a much easier problem and um yeah so ultimately what do we want to do with this um is that we would like uh users I mean full nodes and uh possibly validators as well to only be downloading a few chunks of data instead of the whole data which is what's happening uh right now um to verify that the data is available now what does it so that's you know abstractly uh we could talk about this but what would it look like in practice uh in in ethereum and what is it going to look like in practice you know maybe in the next fork or or whenever uh this comes to the network and uh yeah so you know we have many blobs you don't just have one blob so the the way we do sampling and you know the the easiest way we can we can think about doing sampling is to just essentially stack these blobs together create this sort of uh rectangle this this Matrix and then extend all blobs horizontally the the same way I showed you before um independently of each other but then doing sampling on this whole Matrix as opposed to on each blob individually now this actually in some sense is the same thing like you can look at this smaller image that would that's what it looks like to do sampling on each blob separately so we choose for each blob some indices whereas what's on the left is uh doing sampling on each blob in a coupled way where all of the indices are the same um but why do we call this one-dimensional Das is because anyway we're doing sampling kind of horizontally only um maybe one way to see it is forget about the distinction between each blob and just think about the Matrix um we can think about the Matrix as this kind of fat blob as like a you know big line that actually looks very much much like the original blob so it's essentially it really is the same picture where we're just doing sampling on this bigger object but the underline uh you know what we're trying to do with sampling there does not change in in any way and uh yeah so the qu once we've established okay maybe we want to do this onedimensional sampling uh it's a simple like intuitive way to extend sampling from uh single blobs to um the the whole set of blobs that we have in accompanying a block um how do we actually do this how do we actually put this into the protoc what do we do with it and it's kind of a helpful mental model to generally think of uh incorporating DS into the protocol um in three phases or thinking about uh how to do each phase individually so the first phase is distribution which is essentially there's a block producer it wants to send a block and ACC companying data so this some kind of extended Matrix of of blobs to the network and it first of all has to get this data spread out essentially um so somehow has to push this data to the network in some way and so we have to figure out what is this way then the the next phase is sampling so once the data exist somewhere in the network how do people actually do sampling how do they get the specific chunks that they want and then uh also another question in sampling is what do they do with it so how does it actually impact their behavior and this kind of has two component one is uh you could um it impacts your behavior in the for choice if you're an tester um and also it impacts your behavior in transaction confirmation like how do you decide that a certain transaction that I I want confirmation for is actually confirmed if I'm not downloading the whole data and you know we can use sampling in different ways in in these kind of decisions uh and then the last phase is reconstruction which is quite important and it is uh sure you know the data might be 50% available but you know eventually we actually want to be 100% available we want the whole network to agree that it is available and we want to be able to like everyone to retrieve all parts of the of of the data that we care about so for example look at the um image above it's uh this kind of red like corrupted Network where some columns are missing these black columns but actually most of the data is there more than 50% so in principle it is reconstructible and somehow we want to eventually uh this to happen in practice so we want to go from the red to this kind of blue like healthy Network where everything is is back in the right place and uh yeah now let's kind of think about what do these phases look like in the uh data availability sampling the concrete data availability samp sampling protocol that will most likely ship in fusaka which is the fork after the next one which is spectra and uh there's a simplification already in in fusak and in this particular way of doing data availability sampling in that distributor and sampling are essentially the same uh they're done in at the same time in in in the same phase essentially so if you remember the picture that we had before we had a block proposer sending a block and blobs through uh certain uh subnets now we essentially substituted the uh blob subnets with these uh which are you can think of as horizontal subnets with these uh vertical subnets where columns are sent so we've kind of moved from sending blobs to sending columns around which are the you know the units that we now care about the the samples that people are supposed to eventually be trying to get but we're still using the same kind of networking infrastructure uh underline to do this so the same way that now literally today in production we're sending blobs we will be sending columns um but the difference from before is that you don't participate in all of the column subnets like you as a random node um as a you know someone that's running one validator or as a full node you will only participate in a subset of these so essentially your participation in in these networks already decides uh which kind of sampling like which essentially samples you're getting so you choose uh which network to participate in or which gossip topics to participate in uh based on the sampling that you want to do and and so here really we've moved beyond the fre for four limitation that everyone is downloading everything um and then yeah reconstruction like at this point uh the assumption that will exist in order for reconstruction to uh to to happen is a kind of one of n honesty assumption that there should be at least one node in the network that is willing to download all of the data and then do reconstruction if necessary um so essentially We Go Again from this like red corrupted Network there's this one node at least one but of course we would hope there's more than one that uh downloads everything downloads all of the things that are not black that are actually available does locally reconstruction recomputes everything and then pushes all of the kind of heal data all the missing data to the network and just to call it out this is not actually necessary we don't need this assumption is just something that seems like a reasonable thing to start from and it can simplify certain things but it's even very possible that the the spec might change in this respect and we might move to something that actually supports distributed reconstruction which is very much possible and uh yeah just to kind of go more in depth on uh the the distribution SL sampling part um um what does it um look like in practice is that the um the whole Matrix is divided in 128 columns specifically and you only need to download eight of them and uh so you can think of this as essentially being 11/16th of the extended data so once you look at the The Matrix that includes both the blue and the orange part is 11/16th of the data that's kind of this minimum that you need to download um or 1/ E of the original data so in some sense the scaling factor that we would get with these parameters would be 8X compared to 484 for um now what does this mean in practice essentially yeah I mean there's this kind of adx scaling Factor the in the in the next uh four pectra the idea is that we would most likely have a target of four and a Max of six or maybe even more uh blobs currently it's three and six and so you know if you applied just naively this 8X Factor you would get to 3248 um so a four basically megabytes per slot Target which corresponds to roughly um um 1,800 uh ERC transfers per second and that's uncompressed and yeah it's also I guess another way to think about it in terms of a milestone would be that this is 4X away from the original goal of in some sense the midterm scaling ro road map of ethereum which was 128 blobs so we're actually hopefully getting close or we will uh once this upgrade uh is is actually on minute and uh yeah but still it's it's some uh you know Forex away or however much away how do we where do we go from there like how do we fill still this this remaining kind of Gap uh between where we are and and where we want to get and there's some immediate possible things we could do I mean there's there's really many things the design space is is quite open but in terms of very concrete kind of again in the spirit of this like just iteration on what we have um some concrete n steps are that we could for example just make samples thinner so we could have more of these uh subnets or gossip topics instead of 128 columns you could have you know 256 or however many and thinner samples means uh bandwidth um another thing we could do that's a bit more um Advanced let's say and more um like an interesting step I would say in the design space is we could try to reduce the gossip overhead that comes with all of these things being propagated in the network uh because right now it's it all happens very much in the critical path of a proposer tries to push a block and blobs to the network and it's really time critical there's only a few seconds everyone's supposed to get it in these few seconds so the timelines are very much compressed and uh because of this there's a lot of redundancy there's a lot of you know people downloading and uploading things multiple times instead of just once and so yeah maybe there's ways to relax the sampling timelines and do a bit more of like for example pulling instead of pushing and essentially try to reduce this this redundancy and one I'm going to call out like one research Direction that's come up from multiple people uh lately which I think is quite interesting which we might call mle sampling so going back to the picture that we had before with uh distribution sampling and reconstruction um actually we've kind of ignored pretty important part of the whole kind of pipeline of getting a blob to to um you know um from the transaction Center all the way to to being confirmed by the network in a in a safe way and uh yeah it is really the the sending part the part where you actually uh make a transaction attach a blob to it and you send it to the mle as as most uh you know most of the time would be the case and uh yeah this part is actually quite important and we we can exploit it um so this happens much before or at least a few seconds before um normally uh then uh a blob actually ending up in the in um attached to a block and kind of been been sent in this kind of critical path that I mentioned before so what we could think of is to essentially exploit this time in which blobs are kind of just floating around in the yell mle to already start doing sampling um so this another way that this has been called is vertical mle sharding because you can think of it as uh you know eventually we probably do want to Shard the Y mle we don't want everyone to be downloading all the blobs neither NE on the CL nor on the El mol but specifically we could do this sharding in this vertical way where the things that you download are across blobs as opposed to you know saying you only download some of the blobs you download all of the blob transactions but only some chunks from each blob and you know now again I didn't repeat the meme but again it's the same picture it's the same picture you've seen before uh with uh doing sampling on on columns except in this case you're doing it on each blob and then these blobs might be put into a block by someone and you could kind of go back to the second picture essentially but to to kind of clarify it uh more let's look at the whole kind of pipeline of what this could look like in practice so there's a meole on the um there is people that are making blob transactions and and sending it to it sending them to it um The Blob transaction now would already come encoded they would come with this like erasor coding already done uh by the transaction sender so the dmle would already have this like orange part essentially and people would be normally just sampling uh from there somehow the block proposer would get these for example it could try to really hard to just download everything at the time when uh it needs to to make a block this is actually very much not prohibitive in terms of bandwidth so it's it's quite it's it's much easier to just download uh blobs uh the one time that you need as opposed to be like part constantly participating in this like full mle um and yeah the block proposer will basically just send out actually the block not even the blobs you will not try to push the blobs to network at all uh which is you know costly it requires a lot of upload bandwidth it requires you to upload uh these blobs to or columns to many of your peers so it's it's it's much more prohibitive to do so you would just be sending out the block and some other node would be receiving the block know which blobs it needs to care about and you would already have done sampling on the blobs in the mol so the sampling would have kind of already happen uh in advance essentially and at that at that point the the you know the other uh node which only has you know these few columns that it kind of reconstructs from uh putting together the sampling that it has done it could already conclude like sure this this block is fine these blobs are available and for example in the case of an a tester it could vote for the for this block and uh yeah let's go back then to the original question how much could could we scale uh the ethereum data layer if we for example were to do something like this so we have like a few factors that make it easier to to do so like one is that now sampling would happen on like a slot timeline instead of on this uh block proposal timeline which is much more compressed so would be 12 seconds instead of 4 seconds so there's kind of a you know 3x Factor there on roughly speaking on average and uh yeah so that's that's one thing like sampling timelines are are generally uh relaxed you can you can do um you can do sampling in a much less aggressive way as well uh we we don't need to be uh accepting so much of of redundancy and and of waste we can try to be a bit more like um conservative for example uh really trying to only get one copy instead of many copies and uh there's no duplicate work between lncl we only have blobs existing essentially in one place as opposed to existing first in the Y M Pool and then being again like broadcast uh a second time on the and another thing is that it might not might not have been obvious from the previous picture is that it kind of supports local block building by default um as I said you you would not really need um a high upload bandwidth or or to be doing any uh expensive computation in order to propose a block with a lot of blobs because the the hard part uh which is like pushing out this bobster n network actually would have already happened in the yell manool and it's not something that you would need to take responsibility for it would be more of like a network-wide responsibility so it's in some sense this kind of distributive block building idea that that uh it's been in some sense the Holy Grail of of this whole uh section of research and uh yeah the idea there is that okay we were a Forex away we have now like a few things that seem like to be uh pushing Us in the opposite direction hopefully we can actually then scale to 128 Blobs of course we have to see this in practice but it in principle seems at least very plausible that that we could be able to do this and just to call it out that would be like around uh 7,000 uncompressed like rc20 transactions then you can choose your favorite transaction type and favorite compression algorithm um and see how much that actually corresponds and uh there's a lot that I didn't talk about because it's only 20 minutes so I just put some random pictures from my my draw.io with some other things that might have been interesting in in a different talk that went into a different direction um you know that that's kind of 2D sampling you might have seen this somewhere that's some kind of version of Pier sampling that's some something that's trying to tell you that um if you're talking about full nodes you actually don't need them to be doing sampling very fast you could do sampling on like a finality timeline which is very slow so you can kind of play with this a lot and you can use like a black box that's much different you could use very uh obscure sampling constructions for this um but yeah all of these things didn't have time to talk about them but the message there is that there are a lot of research ideas that are very interesting in this space and we should keep exploring them to eventually get to the best ones but thankfully this is not come in the trade-off for not being able to scale today because we can already scale with what we have and with like a simple iterative approach and in the meantime keep researching uh what's to come next essentially and yeah that that's all thank you very much uh these are some resources like a bunch of a list of blog posts that might be interesting if you want to learn more and uh yeah uh small plug like we are you know very much want uh this is a very important project for ethereum there's great interesting things to to uh work on so if you are interested in working on a P2P Network we are hiring and yeah this is a really great opportunity to work on something impact like extremely impactful for ethereum thank you thank you thank you we have a little bit of time for a few questions um so we are going to kick it off with how urgent do you think is the demand for more blob space I think it's pretty urgent uh I mean they they're saturated essentially as we speak and I think uh demand from from rollups will only increase so yeah I think it's very much like a top priority for for us and I think it should be for the ethereum ecosystem in general thank you is it CPU in is it a CPU intensive task to reconstruct blobs each node will do reconstruction at the receiving block for checking kzg commitment or is it add significant time for importing block um so you you don't need to be doing reconstruction in the normal case you only need to be doing reconstruction when things go wrong it's not extremely CPU intensive I mean if you had to do reconstruction of the whole Matrix that um you know something that you might need like a few cores to do efficiently and also this is one of the reasons why uh doing it in a more distributive way where you only can reconstruct one you only need to reconstruct one blob at a time to actually help the network would be nice and this is something that yeah we could even consider doing in like a first roll out but yeah generally speaking it's not something that's incredibly CPU intensive how far can we take this before it breaks down um it's a hard question to answer because I think you have to specify what exactly breaks down I think there's um yeah I would say right now the one of the main uh bolog like the thing that you could say breaks down first could be local block building depending on how how things are implemented like you could do this in a way where it becomes really difficult to do to do local block building at high blob count which does not mean that you could not do it but it might be difficult to do it high blob count and but I think a lot of what's hard about um doing these things is doing it in a way that does not compromise on a lot of these like nice properties that we have and so yeah I think we can actually push this if we do this carefully and like mindfully and you know we try to take the the right approaches instead of shortcuts I think we can do this in a way that does not break down in any of the things that we care about can dis decrease bandwidth requirements on some actors in the network yes decrease okay mhm yes decrease if yes then on which right uh yeah I mean for example um I mean it really depends on a combination of DS and how much scaling like for example if we were to do um you know what's now per do like the peer do in the peer do pack today and we did not in increase the blob count by a certain amount by you know more than a certain amount then it would decrease bandwidth requirement for essentially full nodes and validators with a few nodes with a few validators and kind of the idea is that if you have a lot of validators you would still be downloading uh most of like and when I say a lot it means like you know hundreds like you're really putting like tens of millions of dollars on on your node then you'd be downloading a lot of the data if you're someone that is just a full node or downloading a few um or running a few validators uh you would be downloading like a only these like few samples and that overall would yeah it should decrease your bandage requirement unless we scale to the maximum possible essentially and next question does this mean that there's a minimum peer threshold in order to reconstruct blobs and what is this threshold minimum peer thresold um yeah I guess I'm not entirely sure in what's yeah what exactly the question means um a minimum perer threshold in order to be able to be connected to all of the subnets in order to get of the data or yeah it really depends because for example you could be connected to like a single other node that has a lot of the data or like a few other nodes that have a lot of the data then you you could need just a few peers uh but if everyone around you is only doing the minimum amount of work you need more peers still yeah I think the network would be very heterogeneous in this sense you would have some peers that only do like a few like the minimum amount some peers that do anywhere in between the minimum and the maximum so it's kind of hard to say it really depends on like what this het heterogenea in the network ends up in practice actually looking like and I think we're going to do one more quickly uh who checks the Eraser and coding from the TX Center uh you just check proofs like it there's there's this kg kzg proofs that just tell you that it's it was done correctly essentially and it's actually very fast to check awesome that is all the time we have let's give up a huge round of applause for Franchesco thank you