Previously, I’ve discussed why Ethereum should cancel danksharding (or at least, do it only when it’s robust and battle-tested years down the line): 4844 and Done.

Here, I’ll go even further and argue even proto-danksharding (EIP-4844) is too complex and right now we should focus on a forgotten gem: EIP-4488.

I’m wildly non-technical and misinformed (OK, I’m not misinformed, just non-technical), but as I understand it from discussions with actually technical people, EIP-4488 is a relatively simple EIP with only a few lines of change required. It can be shipped within weeks, if there’s a desire to.

I’ll recommend a couple of changes to EIP-4488, though. Post-Merge, assuming Ethereum is 100% calldata, we’re prepared for 77 kB/s or 940 kB/block. I’d recommend making EIP-4488’s target calldata lower than the existing target. This will a) alleviate all fears about burst throughput, because it’ll actually be lower than what currently exists. And b) there isn’t that much demand for rollups right now. We have seen transaction fees on rollups drop to $0.01-$0.05, and even sub-cent in quieter times. In these times, we’ve seen L2 fees actually start to dominate on zk rollups, and even become a significant portion on optimistic rollups. Even if we go with half the max calldata per block proposed, that’ll be enough for months/years to come, even if there’s some unforeseen sudden exponential adoption at some point.

The real benefit of EIP-4488 will be a) reprice calldata to be more reflective; b) prepare Ethereum rollups for when demand does return; and c) to signal Ethereum’s commitment to the rollup-centric roadmap.

Now, EIP-4488 with a lower BASE_MAX_CALLDATA_PER_BLOCK than initially proposed ought to be easiest path forward, and something IMO should be done in its own hardfork before Shanghai. I know that will never happen, but just adding my 2 wei.

What about average block size then? This will no doubt increase, but given the demand level of rollups, this is going to be negligible for a while yet. Even in the worst-case scenario, it’s worth noting that since the last gas limit bump in 2021, hard drive prices have decreased significantly - you can now get 16 TB enterprise hard drives for ~$150. Nowdays, even the cheapest $400 budget laptops ship with 1 TB NVMe SSDs. Meanwhile, 5G and gigabit fibre are proliferating fast with 1 billion 5G users forecasted this year. For example, I live in a third world country, 1 Gbps fibre for me recently dropped to $50/mo, while the bandwidth cap tripled. I know some first world countries like the US & UK are notoriously bad at this - but this is certainly not the case in most places around the world.) So, ceteris paribus, we’re well overdue for a bump in average data throughput anyway.

That gets us to EIP-4844. The average throughput is a non-issue versus EIP-4488 because it’ll be a similar increase anyway. So, why EIP-4488 and not EIP-4844?

• EIP-4844 is too complex, requires a KZG ceremony that’ll take months to prepare (I can’t find the link, but someone showed me a roadmap once that targeted Q1 2023, and as we all know, crypto roadmap targets always slip)

• Requires new components (forgive me if this is the wrong term) on consensus layer clients to handle blobs, and new cryptography on the execution layer side

• Requires significant changes by rollup teams to leverage

Meanwhile, EIP-4488 is dead simple, only a few lines of change, and rollups can take advantage of it straight away requiring potentially only a single line change to their fee estimation algorithms.

One option is to simplify EIP-4844. The rationale for EIP-4844’s current spec was to be forward-compatible with full danksharding. But some believe that danksharding is immensely complex, requires a major PBS upgrade, new P2P mechanisms for DAS, and is likely several years away. I have no opinion on the matter because I do not understand the technical stuff. I also acknowledge that opinion differs on the matter. But there’s at least some doubt about the complexities of full danksharding, and clearly there is no prototype implementation currently. Were that the case, it makes sense to implement a simpler version of EIP-4844 without KZG first, and upgrade to a danksharding-compatible variant when full danksharding is ready.

However, I showerthink the best route is to simply upgrade EIP-4488 with a couple of features:

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

• A fee market just for calldata (so, two-dimensional EIP-1559)

These two changes combined with EIP-4844 will be adequate for rollups for a long time to come. I’m probably missing some advantage to EIP-4844 here (Addendum: what I was missing - “simple pruning” is much simper with EIP-4844, and allows for much more frequent pruning. So, this is definitely an advantage for EIP-4844 vs. an upgraded EIP-4488.), but either way, the above ought to go a long way. I understand that there’s potentially a political trade-off here - because the above changes would need to be made at the execution layer, instead of consensus layer. But I do think execution layer client devs are also very keen on reducing calldata, and these are both relatively minor (?) changes. Also, they can delay implementing BLS and KZG paraphernalia!

I’ll also note that with Arbitrum Nova we have a nice EVM-equivalent solution for low-value applications that do not 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 be improved and made trustless & permissionless, but we have intriguing concepts like adamantium being developed for that too. We also have novel DA layers like EigenDA which uses restaked ETH for security, and has 5% honest-minority assumptions. So, the world of off-chain DA is not sitting still, and there’s tons of innovation to come. The holy grail, of course, is a permissionless 1-of-N honest-minority DA layer with rotation mechanisms and slashing penalties to account for potential liveness issues. Were such a solution invented, it would give validiums similar properties to full rollups. Of course, the high-value transactions can continue on full rollups, but there’ll always be plenty of capacity for low-value transactions that don’t require high security.

So, summing it up, here’s the train of showerthought:

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

• Ethereum should deliver rollup-centric upgrades asap

• EIP-4488 is both simple and can be delivered very soon

• It can be upgraded with two simple features that’ll mimic EIP-4844’s feature set but with much greater simplicity for both Ethereum and rollups

• With this upgraded 4488, there’ll be plenty of room for high-value transactions on rollups; with ever-improving validiums & optimistic chains on hand to handle the low-value transactions that do not need high security

• Figure out full danksharding first, ensure its robust, then upgrade to a danksharding-compatible EIP-4844-like solution in the future as a step to full danksharding

Lastly, as always, crypto is a minor hobby for me, and I don’t have a strong opinion. My only hope is some actually technical researcher or developer will see this and be pushed to think about better solutions.

Thank you to Georgios for a brief conversation that inspired this post.

Holy shit, that turned out to be one helluva rambly post, apologies! As some of you may know, I write these blog posts stream-of-conscious showerthought style and don’t bother editing.

Previously, I’ve discussed why Ethereum should cancel danksharding (or at least, do it only when it’s robust and battle-tested years down the line): 4844 and Done.

Here, I’ll go even further and argue even proto-danksharding (EIP-4844) is too complex and right now we should focus on a forgotten gem: EIP-4488.

I’m wildly non-technical and misinformed (OK, I’m not misinformed, just non-technical), but as I understand it from discussions with actually technical people, EIP-4488 is a relatively simple EIP with only a few lines of change required. It can be shipped within weeks, if there’s a desire to.

I’ll recommend a couple of changes to EIP-4488, though. Post-Merge, assuming Ethereum is 100% calldata, we’re prepared for 77 kB/s or 940 kB/block. I’d recommend making EIP-4488’s target calldata lower than the existing target. This will a) alleviate all fears about burst throughput, because it’ll actually be lower than what currently exists. And b) there isn’t that much demand for rollups right now. We have seen transaction fees on rollups drop to $0.01-$0.05, and even sub-cent in quieter times. In these times, we’ve seen L2 fees actually start to dominate on zk rollups, and even become a significant portion on optimistic rollups. Even if we go with half the max calldata per block proposed, that’ll be enough for months/years to come, even if there’s some unforeseen sudden exponential adoption at some point.

The real benefit of EIP-4488 will be a) reprice calldata to be more reflective; b) prepare Ethereum rollups for when demand does return; and c) to signal Ethereum’s commitment to the rollup-centric roadmap.

Now, EIP-4488 with a lower BASE_MAX_CALLDATA_PER_BLOCK than initially proposed ought to be easiest path forward, and something IMO should be done in its own hardfork before Shanghai. I know that will never happen, but just adding my 2 wei.

What about average block size then? This will no doubt increase, but given the demand level of rollups, this is going to be negligible for a while yet. Even in the worst-case scenario, it’s worth noting that since the last gas limit bump in 2021, hard drive prices have decreased significantly - you can now get 16 TB enterprise hard drives for ~$150. Nowdays, even the cheapest $400 budget laptops ship with 1 TB NVMe SSDs. Meanwhile, 5G and gigabit fibre are proliferating fast with 1 billion 5G users forecasted this year. For example, I live in a third world country, 1 Gbps fibre for me recently dropped to $50/mo, while the bandwidth cap tripled. I know some first world countries like the US & UK are notoriously bad at this - but this is certainly not the case in most places around the world.) So, ceteris paribus, we’re well overdue for a bump in average data throughput anyway.

That gets us to EIP-4844. The average throughput is a non-issue versus EIP-4488 because it’ll be a similar increase anyway. So, why EIP-4488 and not EIP-4844?

• EIP-4844 is too complex, requires a KZG ceremony that’ll take months to prepare (I can’t find the link, but someone showed me a roadmap once that targeted Q1 2023, and as we all know, crypto roadmap targets always slip)

• Requires new components (forgive me if this is the wrong term) on consensus layer clients to handle blobs, and new cryptography on the execution layer side

• Requires significant changes by rollup teams to leverage

Meanwhile, EIP-4488 is dead simple, only a few lines of change, and rollups can take advantage of it straight away requiring potentially only a single line change to their fee estimation algorithms.

One option is to simplify EIP-4844. The rationale for EIP-4844’s current spec was to be forward-compatible with full danksharding. But some believe that danksharding is immensely complex, requires a major PBS upgrade, new P2P mechanisms for DAS, and is likely several years away. I have no opinion on the matter because I do not understand the technical stuff. I also acknowledge that opinion differs on the matter. But there’s at least some doubt about the complexities of full danksharding, and clearly there is no prototype implementation currently. Were that the case, it makes sense to implement a simpler version of EIP-4844 without KZG first, and upgrade to a danksharding-compatible variant when full danksharding is ready.

However, I showerthink the best route is to simply upgrade EIP-4488 with a couple of features:

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

• A fee market just for calldata (so, two-dimensional EIP-1559)

These two changes combined with EIP-4844 will be adequate for rollups for a long time to come. I’m probably missing some advantage to EIP-4844 here (Addendum: what I was missing - “simple pruning” is much simper with EIP-4844, and allows for much more frequent pruning. So, this is definitely an advantage for EIP-4844 vs. an upgraded EIP-4488.), but either way, the above ought to go a long way. I understand that there’s potentially a political trade-off here - because the above changes would need to be made at the execution layer, instead of consensus layer. But I do think execution layer client devs are also very keen on reducing calldata, and these are both relatively minor (?) changes. Also, they can delay implementing BLS and KZG paraphernalia!

I’ll also note that with Arbitrum Nova we have a nice EVM-equivalent solution for low-value applications that do not 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 be improved and made trustless & permissionless, but we have intriguing concepts like adamantium being developed for that too. We also have novel DA layers like EigenDA which uses restaked ETH for security, and has 5% honest-minority assumptions. So, the world of off-chain DA is not sitting still, and there’s tons of innovation to come. The holy grail, of course, is a permissionless 1-of-N honest-minority DA layer with rotation mechanisms and slashing penalties to account for potential liveness issues. Were such a solution invented, it would give validiums similar properties to full rollups. Of course, the high-value transactions can continue on full rollups, but there’ll always be plenty of capacity for low-value transactions that don’t require high security.

So, summing it up, here’s the train of showerthought:

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

• Ethereum should deliver rollup-centric upgrades asap

• EIP-4488 is both simple and can be delivered very soon

• It can be upgraded with two simple features that’ll mimic EIP-4844’s feature set but with much greater simplicity for both Ethereum and rollups

• With this upgraded 4488, there’ll be plenty of room for high-value transactions on rollups; with ever-improving validiums & optimistic chains on hand to handle the low-value transactions that do not need high security

• Figure out full danksharding first, ensure its robust, then upgrade to a danksharding-compatible EIP-4844-like solution in the future as a step to full danksharding

Lastly, as always, crypto is a minor hobby for me, and I don’t have a strong opinion. My only hope is some actually technical researcher or developer will see this and be pushed to think about better solutions.

Thank you to Georgios for a brief conversation that inspired this post.

Holy shit, that turned out to be one helluva rambly post, apologies! As some of you may know, I write these blog posts stream-of-conscious showerthought style and don’t bother editing.