PeerDAS & BPO Hardforks for Scaling Enterprise Ethereum

Transcript

So we just came up with this mechanism that says like okay we can do these mini hard forks where the only thing that changes is the block count and there's still hard forks in the sense that it has to happen on the same block right any kind of consensus rule we change all the nodes on the network have to agree but and this is the main thing Fusaka is bringing through pier cryptography performance is maybe one of the biggest bottlenecks on this industry and it is improving quickly especially for everything around ZK but we already save a lot and are able to scale Ethereum that way. [music] But one downside is that the [music]

welcome to the Fusaka files, a Fusaka upgrade special series by ECH Institute in collaboration with the enterprise [music] alliance. I am Puja Ranjan from ECH >> and I am Paul Brody the chairman of the Enterprise Ethereum Alliance and so I'm your co-host for these little podcasts. We believe the truth about these upgrades is out there. >> Of course it is and we are going to unpack the enterprise [music] impact of Ethereum's upcoming Fusaka upgrades. So today we are looking at two pivotal proposals. EIP7594 PI DAS and EIP7892 block parameter only hard. Together they change how data availability and block

parameters work which could dramatically improve scalability for enterprise application to explain the technical and enterprise perspective. We are joined by Tim Beo from Ethereum Foundation. Welcome Tim. >> Thank you for having me. Tim, I would love for you to maybe start by briefly explaining what PIA is and why it is important for the Fusaka upgrade. But before that, if you could just introduce yourself to the audience. >> Of course. I'm Tim. I [clears throat] work at the Ethereum Foundation. The main thing that I do there is coordinate the work on Ethereum core protocol development. So the way Ethereum works is we have a specification for the protocol and there's many different production implementations of it a bit

like web browsers where you know you have Chrome, you have Safari, you have Firefox they all allowed to serve web page and to browse the webs but they each have their different features. So Ethereum is structured the same way. Contributors to these protocol client implementations get together to discuss and debate you know potential changes to Ethereum. So what I do is I kind of sit at the middle of this. I help facilitate the uh kind of road mapping and and discussion process to get to what do we actually want to ship on Ethereum and then work with all of these teams to go from these like specification and early ideas to final EIPs that are deployed and live in production. And I've been doing that since 2021 at the EF.

>> And this is something I really wanted to sort of chime in on. I think most business users don't really understand that Ethereum goes through regular network upgrades. It's not something that's kind of, you know, somebody poured concrete over it and it's done. Every 3 to 6 months, I think what's the current number now? Like 17 network upgrades all without downtime. >> Something like that. Yeah. So, they tend to happen maybe more in the six to 12 month cadence. We don't follow like a fixed release schedule as much as figuring out what's the right scope and then doing the sufficient amount of testing to get there. But yeah, it is kind of this very thorough and and like heavily test-driven development that we do. And we will make sure that not only the specs are correct and sound, but that every single client implementation

uh is safe and, you know, ready for production. And before these network upgrades go in live, we'll typically even have these large bug bounties. So for this one that we're going to talk about, there's a $2 million bounty once the code is frozen. So if anyone finds issues that are like critical to the network then we'll happily pay out these bounties to make sure that they don't hit the network once it's live. So yeah through that process of just having like a very redundant system big focus on testing we've never had downtime on Ethereum. >> That is awesome. I know people are already know you because you have been the one who have been facilitating the all core dev where we are making decisions on accepting all these proposals and in today's episode we are also going to cover a special kind of proposal which is going to bring a

different kind of upgrade. So we will learn more about it but maybe we can go ahead and get started with the first proposal which is EIP7594 PI DAS. So Tim could you briefly explain what PIA is and why is it important for the Fusaka upgrade? >> Sure. So I'll take a step back from the gas to kind of explain in the broader context of Ethereum what it's helping with. So Ethereum does two things. It is a virtual machine that processes computation and it's also an environment where you can store data. Both the computation and the data for Ethereum ends up being stored or executed by every node on the network. So this is why it's extremely expensive to deploy something to Ethereum is because every line of code that'll execute or every

bit of data that's stored is stored across the entire blockchain and every node has to replicate this computational work. One way we've come up with to scale Ethereum in you know the past 5 years or so is this idea of layer 2 and layer 2 are very ingenious because on Ethereum it's more expensive to do computation than to store data which makes sense. You know computers work this way is more expensive than storage. So what layer 2s do is they execute all the computation outside of Ethereum in a different computing environment. So when you hear of like a layer 2 sequencer, this is what it does. It's like the computer that processes all the computation for all these layer 2 transactions. And then it posts the compressed data to execute all those computations back to Ethereum on layer

1. So they kind of exploit this asymmetry where computation is very expensive on Ethereum layer 1. Data is cheaper. So we're going to do the computation elsewhere, post the data back on Ethereum and they tend to have these like dispute resolution mechanisms such that if you ever disagree with the outcome of the computation you're able to go back to Ethereum layer 1 and say hey this is the data we all agreed to this is how you know it should be computed and then you can use Ethereum layer 1 as kind of this arbitrer of what is the right state and so when layer 2 talk about things like fraud proofs or fault proofs this is what they mean and this why we call them optimistic roll-ups. is we optimistically assume everything that's been posted is correct, but then anyone is able to look

at the blockchain on layer one and say, "Hey, something's off. I'm going to dispute this." And then this means we only pay the high cost of computation for these like dispute resolution computations rather than every single transactions by users. So this is great. We already save a lot and are able to scale Ethereum that way. But one downside is that the data is then stored on Ethereum forever. And in practice, people consider the data to be final and settled like in relatively short order. Right? The way layer 2s generally work today is they have a 7-day withdrawal period. So this means when you move your assets from L2 back to L1, they wait 7 days. If no one has claimed an issue, they'll give you your money back on L1.

And effectively, the L2s were paying to store this data on Ethereum L1 forever, even though they really only need it for 7 days. So a couple years ago, we came up with this idea of blob data, which is data that's stored on Ethereum layer 1, but only for about 3 4 weeks. And because it's stored less long, we're able to just charge less for it than data that's stored forever. So this is how Ethereum works today. So you kind of went from the stage where all the nodes store the data forever. All the nodes store the data for, you know, some fixed period of time. And with Fusaka, one thing that we're bringing is effectively data being sharded around the entire network. So if you assume Ethereum has like a fixed capacity in terms of, you know, storage and bandwidth, there's

only so many nodes, they only have, you know, so much bandwidth, the end process. The question becomes, do we want to make sure every node has a copy of every data or are we okay with some just redundancy factor on the network? If we can know that the data is stored, you know, in this amount of replicas and we can get cryptographic proofs from the holders of this data that say like, hey, you know, I'm not going to send you all the data, but I'm going to send you a proof that I've actually got like the samples you've requested. Then we can scale the total throughput. And this is the main thing Fusaka is bringing through Pieras is laying this infrastructure on Ethereum to go from every node having to store all of the data to nodes being assigned part of

this blob data and then doing cryptographic verification throughout the network to ensure that the people who are assigned other parts of the data actually have this and then obviously responding to checks from others and providing proofs that they hold the data. We can get into the numbers later, but like at a high level, just this new architecture effectively gives us the ability to raise the the amount of data on Ethereum by about an order of magnitude before starting to raise the actual bandwidth requirements just because of now not everyone is storing everything. >> I have so many questions. That was a fantastic explanation. Thank you. One of the things I first wanted to ask was there are two kinds of layer 2 networks.

Basically, there are ZK roll-ups and there are optimistic roll-ups. And does this change only affect optimistic roll-ups because it's just dealing with these fraud proofs that are specific to optimistic roll-ups or does it affect every type of rollup, every type of layer 2 network? >> Any type of layer 2 network. So the way ZK rollups work is instead of effectively having this dispute gate on chain, they post cryptographic proofs of what happened offchain and anyone is able to run a verifier and verify those proofs. So it actually happens on a much quicker time window than optimistic roll-ups. And there's also a lot of designs now that are exploring how you can merge both like effectively use like a ZK verifier for these optimistic rollup bridges. So, not to get too into

the weeds about roll-ups, but broadly here, like you can assume this applies to every type of rollup. And also like any just user of Ethereum, even if they were using L1 directly and they just want to post data, have a proof that it was on Ethereum and potentially be able to cryptographically attest to this in the future. You know, they don't have to be a rollout to do this. like an application on L1 can just post data to the blobs and if this data doesn't need to be stored on chain forever they can always store it elsewhere and eventually just do a cryptographic proof that like oh last year on this block we posted this data and here's a proof that kind of ties it back to the current history >> okay now let's say I'm an enterprise right so I am and there are a lot of

different enterprise use cases but one of the major ones that people are spending time and energy on is this question of like payments and transfers especially things like stablecoin payments. It seems like on layer 2 networks, the price for transactions is already ridiculously low. But I I read in the some of the descriptions of the pure dash fork or the proposal that this will drive transaction cost down even lower. And I'm just wondering if you give me some sense of like for a layer 2 transaction, what kind of pricing impact do you foresee? >> Yeah, that's a great question. And the transaction costs for L2s are already subsent in a lot of cases, right? I think of this less as like lowering the cost at this point as meeting demand, right? A lot of the L2s or potential L2s

or enterprises we speak with, some of them aren't even using Ethereum yet because they know that like if they were if they were to come, they would just saturate the entire demand, right? Like today, Ethereum blocks can have, you know, up to six blobs per block, which is not a lot, right? Even if that's like thousands of transactions compressed, most enterprises alone can do more than that. So I think yeah this price is already very very low and it's more a question of can we offer more supply so that we can reach like much much like more use cases and and yeah different like markets that we're just not addressing today because we don't have the capacity.

>> So this is actually something that that we spend some time at EY thinking about. So I have one client in the medical space and they anticipate that to bring a single product line on chain, they would need capacity for about 4 million transactions a day just from that one product line because each one they make about a half a million serialized packages of medicine. And if it's a serial number, it's an NFT, not a fungeible token. >> And on average, each packet of medicine moves four times before it reaches the end patient. So half a million times four, that's an average of two million transactions a day for NFTTS. So for that's for one product line. So I I think your point is a fair one. Tell me, is there a tradeoff? Like so I'm getting a cheaper transaction, but is it going

to take longer? I mean, now you're splitting up all the data. So if I need to search the data, is it going to take me longer to find it and and verify the the truthfulness of a transaction? >> No, no, no. So the idea is still that like and the way Ethereum works already is we have blocks every 12 seconds for every one of those blocks we sample in the validator set who are the validators that are going to attest and and obviously who's the validator that's going to propose this block and whatnot. So sampling works the same for for data as well. So we expect that the sum of the data is stored across the sum of the validator set but that when we sample we're able to get at least one kind of party who can improve the data. So there's no extra delays or anything like

that. And then I think in terms of like the the enterprise use cases you described, the way to think about the trade-off is more who needs to be able to prove what where you can think of when you post something on Ethereum layer 1, you're saying the entire world now can attest to this and and you kind of get the highest level of like openness and and kind of trust in these statements. But this is probably not true of everything. Like for example, if you're if you're aggregating, you know, millions of serial numbers, you could imagine maybe something like there is some set of entities that verify the integrity and you know they can kind of bundle this and say like okay I looked at this batch and like I can ensure that like this entire batch is correct and then that entity can post like an

aggregated commitment to say Ethereum layer 1 or an Ethereum layer 2 and you know if if someone then has like a challenge or an issue they can say like okay there's like five entities verifying this or five people verifying this four out of the five agree, this one disagrees. And then you kind of have to trust that there's something offchain, some way to resolve this. And I think a lot of these enterprise use cases have this, right? Like they're not things that fully exist on chain. If you have talking about a physical product or anything in the real world, hopefully there are some mechanisms you have around quality control and whatnot, but the you can still get a a massive increase in terms of transparency, in terms of efficiency if you're not putting all of the raw data on chain because you can at least pinpoint like

okay, which parts of the process are critical, who is accountable for them, and if something fails, then you know have a way to diagnose this. >> That's really amazing. Thank you. Now I've got one other sort of question which is a lot of our conversation has been focused on like the cost of storing data versus computation. Some transactions are data intensive but other transactions are compute intensive right? So if I have a very complex like DeFi ecosystem with collateral lending or some other kind of tool it's going to use a lot of gas. I know from an EY perspective we care a lot about privacy and when we run our zero knowledge circuits the gas fees are are much much higher. So is this going to lower gas fees even for computationally expensive things or only for storage expensive

things? >> It'll create more bandwidth for L2s generally. So if you're doing expensive computation on L2, it will help. it will help less than if you're doing data intensive things and cryptography like I mean you know this but like yes cryptography performance is maybe one of the biggest bottlenecks on this industry and it is improving quickly especially for everything around ZK but yeah fundamentally this is like the one thing more bottleneck the speed at which we can do ZK proof verification for that said for nonzk computation I think a big area of research now where it does feel like a lot of Ethereum call it like vanilla computation is probably slightly overpriced and we are looking at how to effectively either increase the cost of storage to to offset it but to better

subsidize just like vanilla computation on Ethereum. It's not coming in this upgrade but it's something you should expect to see in in the coming upgrade after Fusaka. >> In our own estimates in our work on ZK computation we think we're about a thousand times more functional or faster and efficient than we were when we started seven or eight years ago. So that's a really good like result. But we were starting from an insanely high expensive transaction fee. Now we've achieved a reasonable one. But I think if we we feel like we need to get another order of magnitude lower to to really onboard large numbers of business users in like big supply chain use cases for transactions under privacy which are so compute intensive. Yeah, I was just going to say on the ZK point like this

is something that shows up in different parts of the protocol. Like again, as you know, we're we're looking at the ZK for proof of Ethereum execution for consensus. And it is true like yeah four or five years ago all the numbers you saw were like oh we're like a thousandx or 10,000x away from this being viable and it was easy to almost dismiss this but now like yes we are in a lot of use cases within an order of magnitude and and it's really been like this exponential curve kind of coming down and it's it feels like we're we're just at the frontier of things being like economically and computationally possible. So I expect in like you know two or three years this will be pretty much the default right like we'll get to a spot where the performance is good then after that obviously people want to

test it and ensure it's reliable and bug free but it really does feel like we're kind of on the cusp of things going from like zk being practical to zk becoming the default. >> That's pretty awesome. So blob data were introduced by EIP4844 in earlier upgrade and now we are adding infrastructure to verify and make these data available for layer 2. expecting that it's going to help get the price lower and we could have more transactions on chain. Today we are also discussing another proposal which is related to blob. So I would love to hear your take on blob parameters only hard folks that is being proposed with this fusaka upgrade. How does this mechanism help adjust Ethereum

capacity without the full upgrade and why do you think it is important to have BPOS independent of Ethereum upgrade? >> Yeah. So the idea for this like I mentioned earlier we're moving to an entire new mechanism of how we we kind of handle blood data on Ethereum and this mechanism allows us to scale but before we scale we want to be pretty confident that it works. So what we're doing with the original activation of this upgrade is just saying, okay, we're going to keep the amount of data constant, but we're just going to change like the back end and make sure this works. And we're obviously quite confident by this point that it works just to kind of isolate variables and ensure we have a high security threshold. We've decided to stagger the

actual capacity of upgrades for blobs over time. And so this is what these blob parameter only forks are is they're effectively saying, okay, the new system is in place. Now let's just like tune this number up. And on Ethereum's execution layer for gas limit, you know, the validators control this. We don't need hard forks. The validators can just vote on the gas limit and it moves up and down alone. Whereas for blobs, because it's it's also like a smaller discrete number, right? Like we have six per blobs now and you know eventually we're going to go to nine and then to 10 and 14 and whatnot. It's less of a like continuous value to tweak. So we just came up with this mechanism that says like okay we can do these mini hard forks where the only thing that changes is the block count and there's still

hard forks in the sense that it has to happen on the same block right any kind of consensus rule we change all the nodes on the network have to agree but because we already kind of know what is going to happen we wanted to make sure to decouple these from like the features that go into hard forks and like we were just talking at the start of this episode you know it usually takes us six to 12 months to to ship a hard fork. There's a lot of debate and conversation and testing that goes into it. And so we want to make sure that we have a way to just continuously increase the amount of blobs we have on Ethereum without having to go through this entire like governance process. So this is the the rationale for these blob parameter forks. So with the original release for

Fusaka, we're going to have the activation of Pure Das and then the first two blob parameter forks going live in the in the weeks after. Um, and then we expect in Q1 of next year, we'll put together another set of upgrades for a couple more broad parameter forks. And then lastly, the thing that this allows us to do is in the world where we saw an issue, right? Like between say blob parameter fork one and two, there's something, we can always cancel the next one, right? We can just put out another client release that says, "Okay, actually don't fork in a couple weeks and and allow us to deal with this." So it's just effectively a nice way to get this capacity on chain in a a more like steady rollout rather than a step function change.

>> So one of the things that I've been wondering about is so I've been hearing a lot about how some people are saying blobs are mispriced or they're too cheap and that the L2s are kind of taking value from Ethereum. And so one of the things I was wondering is is does these upgrades affect blob pricing and what is kind of some of the current thinking about that because that's obviously enormously important to the business models of layer 2 networks and to the business models of companies that are thinking about implementing layer 2 networks. >> Yes. So there is another EIP in Fusaka focused on block pricing updates that mostly aims to make it more predictable.

And so this is EIP7918. it it might actually be worth diving into the details, but I can give you the highle overview. The way that the blob pricing was set is effectively based on rolling averages and we set it very low, expecting that it would be like a one-time ramp up, you know, past the floor and then it would kind of settle there. But one thing that we've seen is that there are actually periods where there's just right now like very little blobs on Ethereum and it's made the price kind of go back to this floor again. And what this creates is not necessarily that the pricing is too cheap, but I it's too volatile. Meaning that we'll have these cases where like I don't know for a couple hours there hasn't been blobs and all of a sudden, you know, there's an NFT drop on Arbitum

and then there's a ton of traffic and the price goes up like exponentially in a very short amount of time making it hard for people to get reliability and arbitrum even had a system for this because this happened on their network. I think when they launched their token, you know, the price just shot up so much that it became cheaper for them to store data on the permanent data stored than the blobs because of like this dis this mispricing. So EIP718 is just going to help with this to make sure that there's like a kind of more smooth I guess changes in pricing and and help make things generally more predictable. Yeah.

So I think that would be an interesting one to bring the authors on and and kind of get into the weeds of exactly how the entire mechanism works. >> Okay. Okay. So, but otherwise this this second EIP 7892 is really just about a smooth implementation of 7594 so that there's no big radical change and if there is any problems they get caught and this is just more about Ethereum being pretty cautious generally about not being reckless with upgrades. Uh it's not a move fast and break things kind of mentality.

>> Yeah, correct. So, we want to make sure we can actually commit the scaling, right? like we don't want to say like okay we have this new system and now we're not using it for a year because we're debating this other random feature. So the idea is to decouple like the actual scaling of the blobs from the rest of the governance process and then also to just roll it out in a more metric way. >> Well, I have a question with respect to like preparation. How do you think that enterprise people should prepare for these two EIPs getting included in Fusaka upgrade? Do you have any special guidelines that they should be mindful of or any hardware requirement? I understand there is aformational EIP that provides information on hardware that should be there in order to run nodes. But anything specific that people

should be mindful of? >> Yeah, if you're a staker and whatnot that yes, you should review those hardware requirements. I assume we can link the EIP in the details in the show notes. But if you're like an enterprise that just wants to use the chain, I think yes, reconsidering some use cases that you thought might have been previously impossible because of like data constraints on Ethereum is is something that would be wise to do. And I would look at obviously these two EIPs and the current numbers. But I think what's nice is they also allow you to kind of start forecasting like you know the blob capacity continuing to increase beyond this initial fork. And I think this is really where the interesting thing is where there's just like we were discussing there are some use cases where just the sheer scale was not possible before it was almost

independent of the price whereas now like okay there might be things that are like cost effective to do that leverages data. So um yeah Tim thank you so much this has been incredibly interesting. I look forward to seeing you in person at Dev Connect in Argentina. Thank you so much for having me. This has been great. >> Well thank you listeners. Check out our show notes for related resources and links. And please follow ECH Institute on YouTube [music] and Spotify for more on Fusaka files. Until next time, keep building on Ethereum.