Upgrade Summit 🚀 EIP-4844 from a Layer 2 Perspective

Wow, thank you. Uh, thanks for inviting me. Thank you to everyone who joined the broadcast. So, today I will talk about EIP-4844. This is one of the most, you know, talked about and anticipated EIPs.

It will improve Ethereum's usefulness as a data availability layer. And if any of these terms are new to you, I'll explain them shortly. My name is Muhammad. I am a researcher at Scroll. Scroll I am a researcher at Scroll.

Scroll is a ZK rollup. And rollups are one of the main users of this EIP users of this EIP . So I'll also talk a little bit about the rollups' perspective on this EIP. So, first of all, EIP-4844 is about data availability, and data availability data availability is an important element in Ethereum's overall scaling scheme. Quick reminder: Ethereum is a decentralized blockchain, it is very secure, but we can't do more than about 12 transactions per second, which is clearly not enough for global scale computing.

So people are thinking about how to solve this so-called “trilemma this so-called “trilemma ” and make Ethereum scalable while maintaining decentralization and security. And we are finally close to it. If you think about the evolution of Ethereum scaling ideas, initially people thought about increasing block sizes, and indeed, EIP- block sizes, and indeed, EIP- 2028 did this by reducing the cost of gas for call data, there were other attempts to move further. But for many reasons, such as the for many reasons, such as the risk of centralization, destabilization of the consensus mechanism, or simply enormous complexity, these EIPs were too difficult to implement, and then people thought about state sharding. State sharding—this was the idea of ​​dividing the blockchain, the entire Ethereum blockchain, into smaller blockchains, rotating validators across these smaller blockchains, and all that .

These ideas have now been discarded. Again , due to their excessive complexity, as well as the emergence of other solutions, such as rollups, which proved to be simpler to implement, easier to analyze, and did not require major changes to the protocol itself. But the important thing is that while people were studying state sharding and working on it, we ran into a data availability problem, which I will explain in more detail shortly. And then rollups appeared. The idea behind rollups is to perform calculations off- chain and confirm the correctness of transactions using proof within the blockchain itself.

But this evidence is not enough. We also need a solution for data accessibility. We also need to make completed transactions available to users who want to verify them. So, there are two parts to a roll . The first is proof of state change, and the second is a solution for data availability.

As I said, the Ethereum community came together and decided that Ethereum scaling would happen through rollups, and they adopted the rollup approach to scaling. This means that now rollups are full participants in Ethereum, and people are trying to make working with them better. This improves the experience of every Ethereum user, and data sharding is an idea that emerged after the introduction of rollups. So we have abandoned state sharding, but we still want to benefit from the idea of ​​distributing work between different validators so that not everyone has to do everything. EIP-4844 is the first step towards data sharding, which we will discuss in the following slides.

OK. The problem of data accessibility is ensuring that data that should be publicly available is publicly available is actually available and can be downloaded by anyone who wants it . Perhaps the name " data availability" is a bit confusing. Perhaps it would be better to call this a " call this a " data release," as can be seen in the tweets of Donrad, one of the developers of EIP-4844. And the interesting thing is that it is impossible to prove the absence of data.

So if you want to ensure that data is available, as opposed to executing transactions, you can't rely on evidence of fraud because it's impossible to prove that data is unavailable. Therefore, everyone should download all the data to make sure it is available. At least that's how it is now. I want you to remember this because we will come back to this concept later. The data availability layer data availability layer is the infrastructure that allows people or other protocols to publish data and ensures its availability, meaning anyone who wants to can download it.

Of course. Good. Now let's focus on the rollups. You may have heard of optimistic rollups and ZK rollups. This " and ZK rollups.

This " optimistic" or "ZK" refers to the way in which a rollup proves changes to its state, and how rollups guarantee execution integrity execution integrity . Optimistic rollups rely on evidence of fraud, and to create them you need to know the entire state of the rollup. Therefore, in optimistic rollups, data availability is necessary even to prove execution integrity execution integrity . OK. So, if you are an optimistic rollup optimistic rollup , you must make your state available, otherwise your proof system will be broken.

For ZK- broken. For ZK- rollup, this is not necessary, you can have a ZK-rollup with evidence, and users will be confident that everything was done correctly, and data availability is not required. But the integrity of execution is integrity of execution is not everything. We need other things in our rollup if we want to maintain the level of security and decentralization that is found in the first level (L1). For example, if the data is unavailable and we only confirm the correctness of the execution using a ZK proof, and the one who has the full state of the rollup never makes it available, then if he does not appear one day , the rollup will be blocked.

And if you want to commit a transaction commit a transaction , this is the only way to do it, as they are the only ones who can create a new proof and push the rollup state forward. There are other issues, for example, if you want to enable withdrawals without intermediaries, this is not possible because the proctor may simply refuse to enable these forced withdrawal transactions withdrawal transactions . This can lead to a blocked state or censorship, depending on the design. So this is not the best situation. So, a rollup must be fully recoverable, and rollups do this in two different ways.

One is ways. One is to make all committed transactions available elsewhere, most likely on L1, or to make rollup state updates after a batch of transactions is committed available. This is just a technical detail, but the ultimate goal is ultimate goal is to make the full state of the rollup available to anyone who wants it, so we can have multiple provers, decentralized provers, permissionless withdrawals, etc. Okay etc. Okay .

Now about how Scroll approaches data accessibility and what it looks like in Scroll. The rollup process in Scroll is quite complex. It has many steps It has many steps , but two of them are important to us: commit and finalize. So if you look here, rollup nodes send transaction packets to the rollup contract. This phase is called a commit, and its purpose is commit, and its purpose is to publish transactions to the network to ensure data availability, as well as to record the transactions executed in that batch and the new state obtained as a result.

The second thing we focus on here is finalization. At the finalization stage, the proof-taker sends a proof to the rollup contract, which is verified by this contract, after which the rollup state is finalized, i.e. the new state becomes final. As I've outlined here, you can think of it this way: commit is responsible for data availability, and finalize is responsible for execution integrity.

So, how do we commit in Scroll? We do this through call data, and I mean we want to execute a batch of transactions. We want to make this transaction package available. So we code it in the call data or place it in the call data of a function called commit batch of our rollup contract. We just feed it into the chain.

The rollup contract never stores all call data. It simply calculates a certain hash- calculates a certain hash- commit of the data, i.e. the transactions that will be executed, and stores it. But does the call data itself disappear ?

They are not actually stored in the Ethereum state, but they can be recovered from Ethereum blocks. So anyone who wants to download them can do so forever; they will be there as long as Ethereum exists. So, yes, they are available. Call data is cheaper than regular storage, but not so much that it is optimal: currently 80% of our operating costs for paying for gas on the network fall on commits, and only 20% on commits, and only 20% on proof verification. So, 80% of the cost goes to data availability.

This means we need cheaper solutions for data availability, but we don't want to compromise on security. We could use a different data availability solution other than Ethereum, which would be significantly cheaper, but it would be centralized and carry a lot of security assumptions. We don't want that. Therefore, EIP-4844 is here to solve this problem. Uh-huh.

EIP-4844 contains two objects, for example, there is an object called " called " blob". A blob is a piece of data about 125 kilobytes in size. You can think of it this way. If you look closely, it's 2 to the 12th power of the elements of the BLS 12-381 field. Uh-huh.

So what can you do with a blob can you do with a blob ? You can place your transaction or state change package inside a blob and publish it. And remember, data availability does not equal permanent storage. Although call data is stored permanently, we don't need, you know, the data we provide to be stored forever stored forever . We just want to make sure that everyone who wants to download them, everyone download them, everyone who is interested, has the opportunity to download them, maybe for a while.

A blob transaction, which you know blob transaction, which you know is a new transaction type introduced in EIP-4844, can carry multiple blobs. So, in a transaction you might have, for example, two or three blobs, and the transaction itself actually only contains commits to those blobs. Therefore, only the commitment to blobs falls into the EVM and smart contract execution environment. And the contents of the blobs themselves are only stored by consensus nodes for about three weeks. Good.

So what does a blob- carrying transaction look like ? It's actually the same old EIP-1559 transaction with two additional fields. One of them is the maximum blob gas fee, which specifies how much you want to pay for each unit of blob gas, which I'll explain in a bit , and a list of blob commitments that you're transferring. And these commits are versioned hashes; it's just a type of commitment. Okay, let's take a closer look: the maximum blob gas fee exists because EIP-4844 implements a two-dimensional gas market.

We have regular gas and blob gas, and we have to specify how much we want to pay for regular gas, as before, and how much we want to pay for blob gas. That's why we have this field, and, you know, blob gas also has a pricing mechanism similar to EIP-1559, which works as follows. Whenever there are more than three blobs in a block, the price increases, and we cannot have more than six blobs per block. So, the mechanism works so that in each block we have approximately three blobs. This is an important number.

We will come back to it later. Good. And the second new field is a field of blob version hashes. It will store a list of hashes of blob versions. Yes, each version hash looks like version 1.

It identifies the commit version we are using and then the hash of the commit itself against the blob. This is a KZG commitment. So, this is a polynomial commitment scheme. There's a good reason for this, but for now, just focus on how it works. A blob is simply an array of 2 to the 12th power of the field elements.

We can apply Lagrangian interpolation to it and get a polynomial where each element of the blob is encoded as p(x) computed for omega to the ith power. Okay. So why do we need this version byte? Because we can update this commitment format without breaking the format itself. For example, we can change the version and use something else instead of KZG, right?

Why KZG? This will be convenient when you want to use this commitment scheme in ZK- commitment scheme in ZK- rollups and optimistic rollups. I'll show you this, but with KZG we're committing to a polynomial, not an array, okay? And that's actually useful. Okay, before we continue, let's compare blobs and call data.

Call data is what we use now, and blob is what we will potentially use in the future. Blobs are only stored temporarily. Call data is stored permanently. Smart permanently. Smart contracts do not have direct access to blobs, while call data is available from smart is available from smart contracts, and the blob has its own gas, which separates it from the fluctuations of the regular gas market.

For all these reasons, it seems that blobs do not have any unnecessary features. They only have what is necessary for data accessibility. So we expect them to be cheaper, but because they have their own market, it's impossible to be sure for sure. We'll have to wait and see how things play out, but the expectation, and a reasonable one at that, is that blobs will be significantly cheaper. Okay, EIP also implements precompilation.

This precompilation is a point estimate precompilation. What it does: you have a blob, you create a polynomial from it, and you make a commitment to that polynomial. But the advantage of this polynomial is that you can evaluate it at any point; for example, you can use a point evaluation polynomial and prove or confirm that at point Z the polynomial has the value Y. This may seem illogical. So why not just query the value of the blob?

But it will come in handy soon. And remember, we have to pay for this precompilation calls, and it costs 50k gas. Okay. Let's return to the rollup process. We've seen how we perform the commit phase with call data, but now we want to do it with blobs.

It's very simple. Previously, rollup nodes served transaction packets as call data. Now they serve them as blobs, and the rollup contract was supposed to calculate the commitment to the batch of transactions, calculate the hash of that batch. We don't need to do this anymore. We simply store a hashed version of the corresponding blob, and again, the blob or transaction bundle itself is not stored in the Ethereum state, but it is available in consensus available in consensus clients for about 3 weeks.

So everyone interested has enough time to download them. But remember, we only store the commitment to these transaction batches, and the commitment is not enough to execute zkEVM. We need to open this commit and then the zkEVM schemes can start executing. There is a public input (PI) subschema that is responsible for opening a commitment opening a commitment . So, the prover must provide a prototype of transactions that are real transactions, and the PI transactions, and the PI scheme checks whether these prototypes match what was recorded in the chain.

Why do we only have commitment? Because it is very expensive for a verifier to have large public input data, and the PI scheme can be considered a means of decompressing public input data. And why is it necessary to have it? Otherwise, the prover could execute any batch of transactions, record it, but not perform a consistency check; the prover could execute another batch of transactions, which is undesirable. So, after introducing blobs, the PI scheme is very easy to implement .

I mean, relatively easy since we have estimates at random points. If you want to verify that two polynomials are equal that two polynomials are equal , you can simply look at a random point and see if the values ​​of these polynomials are the same at that point polynomials are the same at that point . This is called the Schwarz-Zippel lemma, and with precompilation of the point estimate, it is easy to do. I won't go into detail because we don't have time, but expect a post on the Scroll blog in about a week where all of this will be explained in detail . So, back to blobs and the capacity they add.

As I mentioned, blobs have a mechanism similar to EIP-1559, which targets 3 blobs per block and does not allow more than 6 blobs per block. What does this mean? This means that on average we have 380 kilobytes of additional space per block thanks to these three blobs. OK. And that means 100 transactions, 100 transactions in Ethereum, like transactions in Ethereum, like regular transactions, for example, an exchange on Uniswap.

Which doesn't sound very convincing, because for all rollups we only get 100 transactions per second. For comparison, you know comparison, you know that Ethereum has about 12. So we're just increasing the number of possible transactions tenfold. Okay, why are these parameters set the way they are, why don't we allow more blobs in a block more blobs in a block ? If you think about it, the amount of storage requirements added for consensus clients to store these blobs is only 50GB.

This is nothing. We can easily double or triple this number. Customers and people running nodes will not be dissatisfied. However, the problem is that the larger the blobs or the more of them in a block, the longer the delay will be for each block to propagate through the network. And this is bad, because each block must be confirmed in 4 seconds, meaning it must have time to spread through the network during this time.

If the block is too large, attesters or validators will not be able to confirm it in time , and this will make the consensus mechanism unstable. For this reason, we are very careful with these parameters; we don't overestimate them too much. But on the other hand, we don't get many benefits from it. OK. When EIP 4844 is released on the mainnet, it will be included in the Dencun update.

It's expected, as far as I know, to be next year, and we probably need a lot more testing before it's finalized. Okay, I mentioned that there is another proposal, data sharding, and this data sharding proposal is mostly known as danksharding. Sharding is the same idea of ​​using blobs, but instead of everyone having to download all the blobs, each consensus client had to store all the blobs and serve them, and before a block is considered fully downloaded, you have to download all the blobs, etc. The idea is that we don't force everyone to download all the blobs. People only need to run a few tests to make sure the blobs are available.

While we cannot create proof of unavailability for blobs, we can effectively verify their availability, and that is the idea behind data availability sampling. And EIP-4844 is a step in that direction, as it introduces some components that will be reused in dunk reused in dunk sharding. So, with this, we can have more blobs, like 10, 100 or even more per block, because, you know, the cost of efficiently checking the availability of a blob is much less than downloading the entire blob. OK. This allows us to not worry too much about the delay in distribution.

OK. Conclusions. We have come a long way. The implementation of EIP-4844 was quite complex. Well, you know, finalizing the dunk sharding design was not easy, and I think these are the things we've achieved so far.

And we can expect, well, you know, very good results in the near future. Maybe it's not enough now, but in a few months or a year or two, we expect to hear better news. So, EIP-4844 fees will decrease. I expect them to fall 2-5 times, but it is important to remember that they can still be high during another bull market and a large number of transactions number of transactions ; this is not low enough to conduct transactions, so the community should continue working on dunk sharding. However, I can assure you that the design of dunk sharding is almost ready.

EIP-4844 provides many components that will be reused in dunk in dunk sharding. So we can expect good results. So, thank you. That's all.