Forgotten Treasure: Should EIP4488 be deployed in the next upgrade of Ethereum?
W3.Hitchhiker
2022-09-13 08:50
本文约3040字,阅读全文需要约12分钟
Why EIP-4488 and not EIP-4844?

Original title:4488 and Done

Original author:Polynay

Original title:W3.Hitchhker

Original author:4844 and Done

Previously, I've discussed why ethereum should do away with Danksharding (or do it years later when it's strong and battle-tested):EIP-4488

IHere, I'll go a step further and show that even the original danksharding (EIP-4844) was too complicated, and now we should focus on a forgotten gem:I

Not very tech-savvy and misinformed(Well, I'm not being misled, I'm just not technical), but based on my discussions with actual technical developers, EIP-4488 is a relatively simple EIP that requires only a few lines of code modification. It can be deployed in a few weeks if you want.However, I suggest some modifications to EIP-4488. After merging, assuming Ethereum is 100% calldata, we prepare 77 kB/s or 940 kB/block. I recommend making the target calldata for EIP-4488 lower than the existing target. This will a) alleviate any concerns about burst throughput, as it will actually be lower than what currently exists. Also, b) there isn't much need for rollups right now. We've seen transaction fees on rollups drop to $0.01-$0.05, or even sub-cent in "quieter" times. At these times, we've seen L2 fees actually start to dominate in zk rollups, even

Be an important part of optimistic rollups

. Even if we adopt half of the recommended maximum calldata per block, this will be enough for the next few months/years, even if there is some unforeseen sudden exponential number of applications at some point.

The real benefits of EIP-4488 are: a) repricing to make calldata more reflective; b) preparing for heavy usage of Ethereum rollups when demand returns; and c) showing that Ethereum is very rollup-centric commitment to the roadmap.Now, EIP-4488's BASE_MAX_CALLDATA_PER_BLOCK (lower than originally proposed) should be the easiest path forward, and IMO should do something in their own hard fork before Shanghai. I know it's not possible, but I just added my 2 wei.What about the average block size? This will undoubtedly increase, but given the level of demand for rollups, it will be negligible for a while. Even in the worst-case scenario, it's worth noting that since the last gas limit debate event in 2021, hard drive prices have dropped significantly (you can nowGet a 16TB enterprise hard drive for about $150). Now, evenThe cheapest $400 budget laptop also comes with a 1TB NVMe SSD. At the same time, 5G and Gigabit fiber are being

rapid diffusion


  • , is expected to have 1 billion 5G users this year. For example, I live in a 3rd world country and my 1Gbps fiber recently dropped to $50/month while the bandwidth cap tripled. I know some first world countries like the US and UK are notoriously bad at this (but that's certainly not the case in most of the world). So anyway, we are long overdue to increase the average data throughput.

  • Let's look at EIP-4844 again, compared to EIP-4488, the average throughput is not an issue, because there will be a similar increase anyway. So, why EIP-4488 and not EIP-4844?

  • EIP-4844 is too complex and requires a KZG polynomial commitment, which will take months to prepare (I can't find the link, but someone once showed me a roadmap targeting Q1 2023, and We all know that the goals of crypto roadmaps will always be biased)


The consensus layer client requires new components (forgive me if that's the wrong word) to handle blobs, and new cryptography on the execution layer side.

Requires significant changes for the rollup team to adapt"danksharding "At the same time, EIP-4488 is really simple, with only a few lines of code changes, rollups can take advantage of it directly, and probably only need to make a one-line change to their fee estimation algorithm.

One option is to simplify EIP-4844. The rationale for the current specification of EIP-4844 is to be forward compatible with full Danksharding. But some people think that


  • is very complex, requires a major upgrade of PBS, a new P2P mechanism for DAS, and may be several years away. I'm okay with this question because I don't understand this technical stuff. I also admit that there are differences of opinion on this issue. However, at least some have expressed skepticism about the complexity of full-blown sharding, and apparently there is no prototype implementation yet. If this is the case, it would make sense to first implement a simpler version of EIP-4844 without KZG, and then upgrade to a darksharding-compatible variant when full darksharding is ready.

  • However, I think the best way is to simply upgrade EIP-4488 with some features:


A simple pruning mechanism (or a global mechanism like EIP-4444)

A fee market for calldata only (hence, EIP-1559 in 2D).These two changes combined with EIP-4844 will satisfy the needs of rollups for a long time to come. I may have missed some of the goodness of EIP-4844, but regardless, the above should lead to a lot of development. I know there is a potential political tradeoff here (since the above changes need to be made at the execution layer, not the consensus layer). But I do think that the client developers at the execution layer are also very keen on reducing calldata, and these are relatively minor(?) changes. Plus, they can postpone the cumbersome procedures of BLS and KZG!I would also point out that with Arbitrum Nova we provide a nice EVM equivalent solution for low-value applications that don't require high security, with a simple 2-of-N honest minority assumption. StarkEx validiums continue to gain popularity with a 1-of-N assumption. They certainly need to improve to make it trustless and permissionless, but we also haveEigenDAInteresting concepts like adamantium are being developed

. We also have new DA layers such as


  • , which uses restaked ETH for security and has a 5% honest minority assumption. Therefore, the world of off-chain DA is not sitting still, and there are still a lot of innovations breaking ground. Of course, the holy grail is a permissionless 1-of-N honest minority DA layer with rotation mechanism and slash penalty to account for potential liveness issues. If such a solution were invented, it would give validiums similar properties to full rollups. Of course, high-value transactions can continue in full rollups, but for low-value transactions that don't require high security, there will always be enough capacity.

  • So, to wrap it up, here's a list of ideas to think about in the shower:

  • Ethereum should strive to be as simple and powerful as possible

  • Ethereum should implement a rollup-centric upgrade as soon as possible

  • EIP-4488 is simple and fast to implement

  • It can be upgraded with two simple functions, which will mimic the feature set of EIP-4844, but be simpler for both Ethereum and rollups.


With this upgraded 4488, there will be plenty of room for high-value transactions on rollups; ever-improving validiums and optimistic chains can handle low-value transactions that don't require high security.

Find full darksharding first, ensure its robustness, and then upgrade to a darksharding-compatible EIP-4844 solution in the future as a step towards full darksharding.GeorgiosIn the end, as usual, the crypto world is a little hobby for me and I don't have strong opinions. My only hope is that some real technical researchers or developers see this and get pushed to think of better solutions.

A brief conversation with me inspired me to write this article.

Original link

W3.Hitchhiker
作者文库