# Fusaka & Glamsterdam: Scaling Mission Accomplished? | Muriel Mรฉdard - Optimum - Channel: [Ethereum Denver](https://streameth.org/ethereum-denver) - Date: 2026-03-09 - Duration: 11:20 - Watch: https://streameth.org/watch/yt-SCSUxkwgD2k - YouTube: https://www.youtube.com/watch?v=SCSUxkwgD2k ## Description ๐Ÿš€ Get Ready for ETHDenver 2026! ๐Ÿš€ We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2026โ€”itโ€™s going to be epic! ๐ŸŒŸ ## Transcript Great. Thank you very much. Uh, hi everyone. Uh, I'm Yuriel. I'm going to be brief because I was told I need to make up a little bit of time. Uh, today I'm going to talk to you about scaling. What happens when Ethereum actually scales? There's been a lot of discussion about this uh, particularly with Fusaka, now Glamsterdam. Uh so we're going to talk about this from the point of view of the approach that we take at Optimum. I'm co-founder CEO of Optimum. Uh I have been building the tech behind Optimum for a long time as a faculty at MIT. Uh as a professor in electrical engineering, computer science um and here I am actually with my co-founders uh and partners that I see in the audience making this a reality. Okay. So I'm I'm just going to give you a little bit of a hint about some of the aspects which make scaling challenging and what things work, what things work partially and what are some of the missing pieces. Um so when we talk about scaling there's sort of a couple of different aspects. One is scaling in actually getting the data around. Uh and the other one is scaling in trying to avoid having to transport the data and being able to check that the data is there so that you don't have to transport it. So I'm going to talk about these two different aspects. first the transportation uh and then talk a little bit about the access to the data and just give you a little bit of a feel of some of um again the theory behind it but how the theory really affects uh what's going on in these systems. Um so I'm going to start with talking about throughput uh particular the propagation think in Ethereum something like the consensus layer the block uh block propagation um and then going to talk about data availability sampling where you avoid propagating because it's so expensive and instead try to go and check okay [snorts] this will be on the test um so the math here is the following there There are two ways in which there are two big elements in any analysis of a system. One is how many things you have coming at the system. How many blocks do you have? That's called lambda. And the second one is how big your blocks are. uh and how big your blocks are represent how quickly you can basically get those blocks out of the way. Mu represents how quickly you can get blocks out of the way. So imagine that you have a big tube and the blocks are bunches of fruits and vegetables and you're trying to shove them through the tube. How many fruits and vegetables you're trying to shove and then how big and clunky and unwieldy these fruits and vegetables are. Uh D as the delay is basically how long it takes you to get all your fruits and vegetables across this tube. Um this formula is actually has a name. It's called the Polishek hinchin formula. Yes. Also known affectionately as PK. Okay. So what happens when I shard? Well, I took the fruits and vegetables and I chopped them up so it's easier to get them through the tube. What I did is I now have a mew which is remember basically how long it takes me. Um I now have a mu where I I'm able to get these fruits and vegetables faster. So the mu has gone up by a factor of two. Great. I'm getting the stuff out faster because it's smaller. The problem is now I also have twice as many things. Right? If I take an apple and I cut it into two, I now have two pieces to get through. So my lambda, which was how fast stuff is arriving, has all also gone up by two. And there's something very important that's called the row. Row is called the utilization. The utilization is the fraction of how fast I'm throwing things out over how fast I can get them out of the way. And it better be less than one. Otherwise, your system clogs up and you're never done. And basically, if I b take the apples, cut them into two, I have twice as many things. I have to deal with them twice as fast. I actually haven't done anything with a row. It's different than when I actually speed things up. And when I speed things up beyond just chopping them up, I'm also taking the tube and basically making it twice as big. That's actually very very different because now I'm not if I make the tube twice as big, I'm not actually just, you know, artificially pretending that I get things in um uh faster. I'm actually able to get things faster. And basically the idea is the following. If I just charge, I get a benefit in speeding up. But if instead of just sharding, I just speed up by a factor of two, I get if I was at 80%ization, I get a six-fold increase. Okay, so sharding is not the same as speeding up. It's just not. Now, of course, you can do both. Uh, and this is what we do. This is our hoodie test net. Um this is particularly uh for the CL side we call it bump P2P. Uh and you can see the average latency for us in milliseconds on the top average latency for uh native hoodie uh which is not using coding on the bottom. And basically you can see this is in milliseconds we gave a huge uh huge benefit. Um, and you know, just putting it out there, we're going to be on Ethereum mainet in about a month. So, look out for us. Um, and, uh, to see this speeding up. Okay. So, remember that there were two parts. One part which was to try to make things faster and the other part was to try to avoid putting things into the network in the first place. And that's actually what something like data availability sampling does. Again, that's something that you see in Glamsterdam as emerging as being different and, you know, presumably more scalable. So, the oldfashioned uh data availability sampling, you have a full node sampling. If you look at what's happening in Amsterdam, you have what's called pure dash, which means it's not actually decentralized, um, but it's somewhat distributed. So, you have multiple nodes pretending to be a full node coordinating. And then you can imagine going to full decentralized uh DAS, fully decentralized custody. Uh what do you do in these systems? Well, you do something called coding. And what the coding is is basically taking data and creating equations. And what these equations are are effectively hashes. And you check these hashes. You check these equations to see if everything went okay. Uh what do we do currently? We use something called a read Solomon code. Reed Solomon codes are lovely codes. Uh they were particularly forwardthinking and revolutionary when they appeared in the 50s. Uh so you know they're they're all tried and true. They were done for completely different reasons. So there's no particular reason for using them other than uh you know and I'm guilty of it. You were people got taught this in grad school. I don't even teach them anymore because you know it's just uh it's time to move on. Uh but basically you know this is what people people do right now a two-dimensional they're also called tensor codes. Okay. What is actually the optimum way to do the coding? It's actually the same coding which I didn't tell you before about which was behind that huge hoodie speed up not just sharding but actual physical speed up is actually this kind of coding called randomly network coding of which I'm a co-inventor came out of my lab at MIT. uh and it allows you to create equations in a very malleable composable way and it's not just composable it's decentralized and this composability is what gives you the optimality. So now rather than having to you know code like it's whatever 1958 you can actually go and code in a completely fluid fashion and particularly you can do it in what's called a rateless fashion. You don't need to figure out ahead of time, you know, who does what to whom, who has custody of this piece or that piece, and then how do you pull the whole thing together. Um, just to give you an idea of what this does, um, one of the core elements in DAS is actually what's called a false negative probability, which basically means that somebody is able to get away with something wrong, right? that somebody was able to trick the hash into believing it was correct. Um here you have on the log a log log scale number of samples. So you want to sample as little as possible to check if data is there. Remember you're trying to avoid sending data around but you want to also avoid sending even checking too much. This is on a log scale and then it's also on a log scale in the uh ordinate. That's the probability of being able to get away with being tricky. So you want to be as far to the left as possible and as far down as possible. And uh orange is what people do right now with read Solomon tensor two dimensional codes. Green is something that was in the literature that people also wanted to look at a different kind of code called low density parity check codes which are actually invented by my adviser at MIT uh my doctoral adviser and that's us that is much much better remember this is a log scale okay so you know rather than a hundred you only need a couple of samples and you know for the same probability of 10^ theus man of uh of somebody being able to get away with stuff. Okay, with that uh I have I believe saved the two minutes that uh that we went over. I really would love for you to reach out. Uh as I mentioned, have I mentioned we're going uh we're doing a soft launch on uh on mainetum mainet later this uh um you know uh in about a month in a few weeks. So, thank you very much for your attention.