Scaling Without Sacrificing Decentralization – Jeroen Ost (Sony) | Onchain Soirée [1] @ KU Leuven

All right, thank you. So my talk is about um PRAS which is um a technology coming in the next Ethereum upgrades at the end of the year. Um and it's about scaling blockchains without sacrificing on the decentralization. Um just a very short slide about me. Um I'm a software engineer been all my career in software.

I uh also studied here in Ka. It's already a very long time ago since I left here. I just realized 25 years. Um I've been mostly doing distributed systems. Um I like complex algorithms, cryptography.

That's why I also studied mathematics first before doing computer science. Um I've been in crypto since 2015. Um ever since the Ethereum white paper came out. I've been following the space very closely. Um I have a strong Ethereum focus but I also look at many other uh parts of the web tree uh industry.

Um my focus in the last couple of years has been on infrastructure defi and institutional adoption mostly. Currently I'm working at Sony. Um and I do sometimes some technical due diligence for uh venture capital fund. All right. I think everyone knows the scalability trillemma right just quickly repeat it here.

Um but this is is that blockchain systems you cannot have all three scalability, security and decentralization at the same time, right? Um at least this was a trilmma until recently. Um and some argue that uh it kind of is broken now, but when Ethereum was launched, they chose strongly for the security and decentralization focus um and solve scalability later. um other chains choose a different approach and try to solve decentralization later which arguably is a also a noble goal but maybe a lot harder right so because Ethereum is very decentralized we currently have about 15,000 nodes and about 1 million validators that are um yeah attesting um the blocks um this means that um anyone can still run a nodes um because there are very low requirements in terms of hardware and uh internet connection right so you can use a standard consumer grade internet connection about 20 megabits is more than enough um inexpensive commodity hardware 3400 euros devices are fine and it doesn't consume a lot of power um so running a node you can do for yeah just maybe 20 to30 a year in terms of power and then Ethereum is trying to scale build through a rollup ccentric road map. Um, and what does that mean?

Um, the rollup ccentric road map um is basically um a set of chains on top of the Ethereum main chain. They're separate chains. They're secured and validated by Ethereum mainet where the transactions are batched together um from this rollup chain to the main chain in smaller chunks and this makes um that they consume less space and there's more capacity um in the initial um first iteration of roll-ups that was already a 10x improvement. Um and the whole idea about making these uh roll-ups is to support the endstate vision, right? So the endstate vision for scaling Ethereum is that yeah, we want to support eventually a world where every user on the planet is transacting um multiple times per day.

So that's really billions of transactions. And that's definitely something that's not yet possible today, but that's the end goal. And if you take this as an end goal, it's impossible to do that on a layer one chain. Uh no matter how powerful the hardware you choose because every node needs to get the consensus of every uh piece of state, that's really not possible. So you need this layered approach and admittedly as was said before here today as well uh the user experience because of these roll-ups is currently suffering because there's a lot of added complexity.

People need to switch chains. They need to have tokens on many chains. And so there's a lot of things that are not going so well. But that's not what this talk is about, right? There are efforts under way to solve this.

There's chain interrop, there are crosschain wallets, and there's user experience work being done to solve that. But this is about how we scale much further than the initial scaling benefits that the rollup centric road map has given us. So in March last year, Ethereum did an upgrade. It's called the Denon release where they introduced blobs. What are blobs?

Blobs are um a type of data that you can store on Ethereum mainet that is not to be stored forever for every node, right? If you want to know the balance um of a token, say USDC on your wallet on Ethereum, yeah, it's important that every node knows this because you cannot validate a transaction if you have no access to the balance. But some other data you don't need to to know forever. So these batches of data that the layer 2s or the rollups are submitting to Ethereum, they contain data that is only valid for a very short amount of time. um because it's only needed to validate that the state is correct and that there is consensus.

Um and so even in the case of opt you have optimistic and zero knowledge rollups but in most cases um there is consensus on the state in a couple of minutes or days. So um for this reason the blob type of uh transaction of data storage was introduced and um in Ethereum um this data is deleted after 18 dates. So there is a new type of transaction that was introduced and it's a transaction that contains a blob. Um and these are the transactions. They are created by rollups.

Um and they had um a blob of data which is 128 kilobyte to the transaction. Um and in the Denon release we had three possible bops um initially per slot of uh time. A slot is 12 seconds in Ethereum. Right? So this is a kind of an overview.

You have the blocks coming in. The blocks are full of transactions. Um and they can contain up to maximum six blobs in the Denon release. Um the blobs are created by L2 batch posters like arbitrum or base or whatever other rollup you have. Um the targets by the protocol is currently three, but you can have um short-term uh spikes of up to six, but that's not very it there is a pricing algorithm that makes sure that it's never more than average three because the prices go up exponentially.

So where we are today, there's a lot of rollups um that have since March last year migrated to using this blob type of transaction. You see here on the right bottom right side um what the rollups are how much they are submitting in terms of of blobs and you see that since October November last year um we are at this a average blob count of three. So the blobs are full we are at a capacity and to scale further um yeah we need to increase the amount of blobs. Um but what is the problem with increasing the amount of blobs even further? Well, as you can see here, um a target of three blobs, um but where we are today is for every node operator about 256 kilobits of bandwidth.

If we um increase that linearly, then also the bandwidth requirements for node operators will increase and they are already having this 12 to 13 megabits on average just to keep up with the state. And a node operator still also needs to be able to sync a new nodes. So whenever you uh come online for the first time or you had a small downtime, you need to catch up as well. So you need to leave some room. If you were to go um so we will be going to double this amount in the pectra release next week.

Um so the target blocks go from three to six and we'll go to half a megabit. But the goal is to go like um to 48. So even a lot further. So we want to do another AEX and that's something we cannot do just linearly because that's another 4 megabit that will be adding to node operators and a lot of nodes would uh would drop. They will no longer be able to validate a chain and that's something Ethereum does not want.

Right? So the Fusaka release which is targeted for end of year tries to solve this problem with um a technology called peer does and I'll explain how this works. Yeah. On top of the megabit requirements, there's obviously also the storage capacity requirements. So this is calculated as target of blobs times the amount of slots and then u the 18 days.

Right? So with pas we're trying to scale the blob count by by an 8x extra. Um the goal is to preserve this bandwidth and storage requirements that we will have um from the pectal release next week. Um and then one easy approach that you could think of is like let's just chart the blobs right so we make eight charts of blobs. Um so we'll have 48 blobs in pas we'll make eight charts say a group of nodes will uh custody 0 to 7 the next one 8 to 15 etc.

That would not be a good solution. It would be actually be um um decreasing the security of Ethereum because any attacker that would see um the the groups of nodes could target these nodes specifically with a denial of service attack and as soon as one set of blobs is missing the entire block um is is kind of worthless. no one can recompose the um the rollup states because yeah there are there are blobs that are missing um and so sharding with an a uh in a charts would decrease the security by a text and that's not an acceptable uh compromise. So the com the the solution here consists of combining all these blobs all 48 of them and instead of horizontally grouping them we split them vertically in 128 columns. So there's a visual slide here explaining this but um um one important uh first step is that um we we do eraser coding which is like for every blob we add another 128 kilob kilobyte of of data with um eraser coding which means that um first we double the size but if any um set of half of the bytes from this um new data structure is missing.

We can um recreate the missing pieces. So this is eraser coding a standard technique. It's also used for instance in CDROMs and optical parts and there's many other error correcting codes application. So this is an existing um known mathematical principle. And then we'll define um columns that are to be custodied the complete vertical row for every node.

Um and depending on the node type, there are different requirements, right? So simple node will need to custody four of the 128 columns. Um if you're running a validator, you will need to custody eight. You can decide and one extra for every additional validator. Um and you can still run a super nodes which is probably what the RPC providers will do where where you're custoing everything.

Um but which columns to custody is a deterministic algorithm purely from your node ID. So the node ID is publicly known just like your IP address and everything and anyone can determine which columns you custody based from the based on this node ID. But it's also in such a way that no um two nodes um will custody the very few nodes will custom. So the nodes that will custom tree will probably custody the different column numbers for the other columns they have to do. And then on top of the custody requirements there are also the sampling requirements.

So um every node will need to uh request columns from other nodes and score the peers that are serving this data on the peer-to-peer protocol and see that whatever they claim to be custodying is indeed correct and then also validate the proofs for that. And so what do we get now? Um if there are some columns unavailable um they can be healed. Um so the black um markers here are missing uh columns. So if a peer is not able to retrieve the third and the fifth column um that's okay as long as all the other data is there.

So as long as um the maximum the half of the half of the data is missing um the cells can be healed. And so this means that an attack on the data availability layer of Ethereum in this case would need to make 64 columns unavailable. Um if it's less than 64 columns then um still all of the data is recoverable. So the end situation here is that um 64 columns that's 128 um kilobytes is completely equal to the preper desk case. So we have the same protection um in terms of node counts uh while at the same time yeah greatly reducing the amount of data um to store and the amount of bandwidth the note needs to have.

So the current status is that um these changes are being implemented um on the execution and consensus layer clients. Um there's quite some changes on the consensus layer of course. Um the devets are running u bugs are being fixed and the target is to release this by end of year. So then Ethereum will scale by 8x but there's a gradual road map of increasing this blob count target um with parameter only changes and slowly increasing it um from end of year onwards. So as a summary I'd say yes Pas will upgrade the uh Ethereum scaling by 8x.

Um it uh the rollup centric road map is working. Uh you can see here a picture from grow the pie. The the blue um bottom uh values are the total Ethereum active addresses per day and the yellow and red ones are the layer 2 transactions per day. They're currently still uh going up um but quite limited because the the fees would increase um if the scaling of the data availability layer is not taken care of. Uh but this is something that yeah shall be addressed uh by end of the by the end of the year.

Thank you. [Applause]