The Road to Danksharding
Everything You Need to Know About EIP-4844 in Bite-Sized Blobs
tl;dr
EIP-4844 (aka Proto-Danksharding) introduces blob transactions to improve rollup data availability on Ethereum. Blobs allow large amounts of data to be posted cheaply.
It separates execution and consensus layers. Blobs are propagated/verified by consensus nodes in sidecars, not execution clients. This enables modular enhancements.
With EIP-4844, an independent blob gas market is created, adjusting pricing based on supply/demand. This prevents blob transactions from making normal Ethereum gas more expensive.
Posting data as blobs reduces costs from calldata gas. 500kb blobs cost ~$0.80 vs ~$380 for calldata.
Blob lifetimes are customizable, unlike normal transaction data, so old blobs can be pruned. This manages state growth.
KZG commitments enable compact proofs of blob validity without revealing full contents. The point evaluation precompile can selectively verify proofs on-chain.
Usage targeting incentivizes optimal blob usage by increasing/decreasing gas price when demand exceeds/is below target per block.
In summary, EIP-4844 improves rollup data availability through technical innovations like blobs, modular architecture, customized economics, and usage targeting mechanisms.
Introduction
Last week, we spoke about the Ethereum fee markets, specifically EIP-1559, which was supposed to make transaction fees more predictable, and how its dynamics affect Shared Sequencing solutions for rollups. As we put some points forward, EIP1559 doesn’t exactly suit the fee markets Ethereum’s ecosystem participants hoped for. We also explored how the fee market dynamics would change in the coming months for Ethereum, and EIP-4844 is one of the major upgrades to look for.
EIP-1559 focused more on making transaction base fees predictable, and the upcoming EIP-4844 focuses on reducing Data Availability costs of rollups.
With either EIP-1559 or EIP-4844, the main goal of these proposals is to help Ethereum scale. EIP-4844 is the first step Ethereum takes toward Danksharding, which is a bit different from the concept of Sharding initially proposed to scale Ethereum.
What is Sharding?
Sharding is a database design principle that involves breaking down a larger database into smaller, more manageable pieces called "shards." Each shard operates independently of the others, allowing for parallel processing and increasing the overall efficiency and scalability of the system.
For Ethereum, sharding was seen as a solution to scalability challenges. By sharding the main chain, each node doesn't have to process every transaction. Instead, nodes can process transactions for specific shards, increasing the overall transaction throughput of the network.
However, the emergence and success of rollups have indeed influenced Ethereum's scaling roadmap.
Shift from Traditional Sharding to Danksharding
With multiple rollups already operating on Ethereum's L2, they provide immediate scalability benefits without waiting for more extensive protocol upgrades. Given the success of rollups, the Ethereum community has been re-evaluating the necessity of traditional sharding. Instead of having shards manage both state and transaction execution, the focus has shifted towards a concept known as "Danksharding."
Danksharding aims to maximize the benefits of rollups by having shards primarily manage data availability, turning them into data layers. This approach complements rollups, which can handle transaction execution off-chain and then post data to these shards.
Proto-Danksharding: The First Step
Proto-Danksharding (EIP-4844) is the initial phase in the transition to full Danksharding. It introduces the concept of "shards" but in a way that's optimized for data availability rather than execution. This makes it more compatible with the rollup-centric vision of Ethereum's future.
By focusing on data availability, Proto-Danksharding ensures that rollups can reliably and securely post their data to Ethereum without worrying about data withholding attacks. This synergy between Proto-Danksharding and rollups is expected to offer substantial scalability improvements.
All of which we will be discussing in detail in this article.
EIP-4844
With all these developments and iterations to scale Ethereum, EIP-4844, also called “proto-danksharding,” aims to scale the data availability of Ethereum in a straightforward and forward-compatible manner. It introduces blob-carrying transactions, a new transaction format that is more cost-effective than the traditional calldata (a data location on Ethereum’s block).
EIP-4844 is a prototype of "danksharding," a sharding architecture that leverages large data pieces to enhance throughput and scalability.
The core architecture of EIP-4844 is as follows:
Data availability is a central focus and motivation behind EIP-4844's design.
The key value that rollups need from Ethereum Layer 1 is data availability - ensuring transaction data is posted and stored long enough to be processed by other nodes. EIP-4844 directly tackles the data availability problem for rollups by allowing large amounts of data to be posted more cheaply as blobs.
Previously, rollups were constrained by high calldata gas costs when posting transaction batches. This limited how much data they could afford to post to L1. By introducing a separate blob gas market with lower prices, EIP-4844 enables rollups to post much more transaction data to L1 within a given gas budget.
Blobs up to ~125kB can be posted per transaction, over 10x more than typical batch sizes in calldata. This vastly increases the amount of rollup data that can be made available on L1 in a cost-effective manner.
In addition, the consensus layer stores and propagates the blobs separately from execution layer blocks. This ensures the blob data remains available independently for the duration rollups need even as execution layer blocks get pruned. Posting as blobs also allows rollups to avoid including signatures and compress data, further optimizing L1 space usage for pure data availability.
Why is understanding DA important for EIP-4844?
Sufficient data availability unlocks scalability, as it allows computation and long-term storage burdens to be offloaded from Layer 1. EIP-4844 recognizes data availability as the most crucial bottleneck and relieves it first.
However, as rollup usage grows, data demands may again test the limits of even EIP-4844's provisions. This is why longer-term research into highly scalable and decentralized data availability layers remains critical.
EIP-4844 can be seen as an excellent stopgap that buys time for developing more advanced DA layer designs. An ecosystem of abundant data availability, where L1 space limitations unconstrain rollups, remains the end goal.
On sustainability, the fixed blob sizes and expiry via EIP-4444 are prudent steps to avoid unchecked growth. But usage-based pricing models that better reflect externalities like storage costs can also help align incentives long-term.
One thing's for sure: as DA costs plummet, the Ethereum landscape will undergo a seismic shift. We can expect rapid growth in the number of rollups, each with its unique value proposition. Some will be a jack-of-all-trades, while others will carve out specialized niches. As the market grows, the benefits of economies of scale will come into sharp focus.
The below table shows Data Availability for different rollups:
After EIP-4844, we can expect the following for each rollup:
Optimistic Rollups:
Can now post compressed transaction data cheaply as blobs instead of expensive calldata. This drastically reduces gas costs.
Still ensures highest level of availability on mainnet. Censorship risks can also be reduced due to blob gas market separation.
Zero-Knowledge Rollups:
Can post minimal proof data required to verify blobs, instead of IPFS/Swarm data references.
Mainnet blobs provide availability. External sources only optionally needed for human-readable data.
Availability risks can be minimized as blobs provide sufficient data for validity.
Hybrid Rollups:
Similarly can leverage mainnet blobs for bulk data availability instead of calldata.
Still maintain high scalability without compromising availability.
EIP-4844 introduces a separation between the execution layer and consensus layer in Ethereum to enable modular processing and verification of blob data:
Previously, transaction data was posted directly into the execution layer blocks, which are processed and propagated by execution clients. This caused a few key problems:
State growth: Storing all transaction data permanently leads to unchecked state growth. This affects sync times for new nodes joining the network, increasing hardware requirements. In the long run this could reduce decentralization and security of Ethereum.
Calldata gas costs: Posting transaction data requires significant calldata, which costs 16 gas per byte (as proposed by EIP-2028) because calldata must be processed and validated by all nodes. At current gas prices, this makes large data availability prohibitively expensive.
Inflexibility: Transaction data lifespans cannot be customized, forcing rollups to persist data indefinitely even if they only need it temporarily to finalize proofs. This prevents optimizations for transient rollup data.
Tight coupling: Putting transaction data management into the execution layer creates a tight coupling. Any changes risk disruptive and risky hard forks of Ethereum clients. This limits modular enhancements.
How blobs help:
Separate storage: Blobs are stored by consensus nodes separately from execution layer state. This reduces overhead but means blobs are not EVM/contract accessible.
Lower costs: The blob gas market allows high throughput data availability at low cost based on a formula balancing supply and demand. 500 kb blobs would cost ~$0.80 vs ~$380 for calldata.
Custom lifetimes: Blob lifetimes can be customized to allow pruning old data no longer needed. This is enforced via a deposit/penalty system.
Modularity: Separating blob propagation and storage enables independent innovations. For example, using VDF or erasure coded blobs with different properties and tradeoffs.
Note: check appendix for calculations
Blobs can be up to around 125kB in size. The target is 3 blobs per Ethereum block (12 second slot), with a max of 6. If there are more than 3 blobs, the ‘blob_gas’ cost increases. If less than 3, the cost does not decrease and stays constant at a minimum value of 0.5 Gwei per byte. This is to prevent spamming the network with too many small blobs.
Blobs are stored in sidecars run by consensus layer nodes (e.g. Prysm, Lighthouse), not execution clients (Geth, Besu, etc). This separation allows refinements to blob handling without impacting execution layer upgrades.
Consensus clients have to batch verify blob signatures and store blobs separately from normal blocks. Block builders need to be able to accept blobs.
This division of responsibilities between execution and consensus allows specialization of the different layers:
Execution clients can focus on transaction execution without the burden of large blob data. This lets execution innovations proceed unencumbered.
Consensus clients specialize in efficient large data availability and verification. This is their strength.
The modular separation also makes future optimizations easier, allowing enhancements like data pruning and availability sampling to be integrated into the consensus layer without disrupting the execution layer.
By separating out data availability to the consensus layer, EIP-4844 sets the stage for major scalability gains through rollups while keeping the execution layer streamlined and focused. This innovative layered approach promises sustainability and evolvability.
What are Blobs (Binary Large Objects)?
Blobs are a new data type that is specifically designed for storing rollup data. Rollups are a type of layer 2 solution that can execute transactions off-chain and then post the results back to the Ethereum main chain. Blobs allow rollups to store their data on the Ethereum network in a more efficient and scalable way.
The data gas market works similarly to EIP-1559. There is a target capacity per block, and the base fee adjusts dynamically based on usage. Each blob transaction has fields like max_fee_per_data_gas for the bid price, just like max_priority_fee in EIP-1559.
The base data gas price starts at 1 wei per byte. The community is debating whether to raise the minimum to 1 gwei to avoid spam. At current rollup demand, fees will remain near zero for 1-2 years until usage reaches the target capacity.
Once demand exceeds targets, the base fee can exponentially increase 10x in hours, pricing out transactions. The community is discussing reducing the target blob capacity by half to make the fee market more responsive. After capacity is reached, rollup operators will need to carefully manage bids to avoid price spikes pricing out users.
Below, you can see how blob transactions are created:
The rollup sequencer assembles the data payload, which includes transactions or state transition data from the rollup chain.
The payload is divided into chunks according to the blob specification.
The sequencer applies the Kate-Zaverucha-Goldberg (KZG) commitment scheme to generate cryptographic commitments for each blob.
The KZG commitments are hashed to create versioned hashes, serving as unique references to each blob.
The transaction payload body is constructed, including metadata such as nonce, gas values, versioned hashes, and signature, following the EIP-2718 transaction format.
The blob data chunks are packaged separately for propagation to consensus layer sidecars.
The transaction is submitted, and the execution layer includes the payload body.
Consensus clients verify the blobs against the KZG commitments and make the full data available.
Smart contracts can use the point evaluation precompile to verify proofs that specific parts of a blob evaluate to expected values by cross-checking against the versioned hash.
How does it enforce Ethereum fee markets?
The introduction of a customized blob gas market specifically optimized for pricing rollup data availability unlocks substantial fee reductions that will propel rapid rollup adoption. By transitioning transaction data posting to substantially cheaper blobs, EIP-4844 dramatically improves rollup economics. This provides a compelling incentive for an ecosystem-wide migration to the low-cost, high-throughput world of Layer 2 rollups.
From a technical perspective, EIP-4844's novel constructs, such as the separation of execution and consensus layers, establish a robust foundation for ongoing refinements and optimizations. The elegant modular design enables future upgrades to be integrated smoothly and flexibly.
On balance, EIP-4844 solidifies rollups as the centerpiece of Ethereum's scaling roadmap moving forward. By catalyzing mass rollup adoption through substantially improved fee economics while retaining flexibility for ongoing enhancements, EIP-4844 puts Ethereum firmly on the path to becoming the world's most decentralized and secure blockchain-based financial settlement layer.
How does EIP-4844’s gas accounting work?
Currently, on Ethereum, all transactions compete for the same gas supply and are priced using the same gas price. EIP-4844 creates a separate "blob" transaction type for rollups to post data. These blob transactions will have their own gas market called "blob gas".
Blob gas works independently from the regular gas market. Normal and blob transactions don't compete for gas. The blob gas price automatically adjusts up or down based on the total blob gas used recently. If more blob gas is used, the price increases. If less is used, the price decreases. This helps balance supply and demand.
Each blob transaction burns a fixed amount of blob gas based on its data size. This blob gas cost is paid upfront by the user. Block creators now have to consider two gas limits - the regular block gas limit and the blob gas limit. They can't exceed either limit.
Note: Check appendix for simplified calculations around blob gas costs
Before we explore the technical components of EIP-4844, we need to understand the concept of data availability.
Now, let’s explore the technical components of EIP-4844:
Gas Pricing Model
The blob gas pricing model creates a separate gas market specifically for pricing "blob" transactions posted by rollups. Blobs allow rollups to post large amounts of data to Ethereum cheaply. This is important because high transaction fees have been a major limitation for rollup adoption and usage.
For easy understanding: The blob gas pricing model is like paying for luggage at the airport. The more luggage (blob data) you have, the more you pay. And if the airport is busy (high demand), the price might increase.
The key innovation is that blob gas operates independently from the main Ethereum gas market. Blob transactions don't compete with normal transactions for gas. This prevents blobs from congesting the network and driving up fees for normal users.
The blob gas price self-adjusts based on a measure called the excess_blob_gas. This tracks when blob gas usage exceeds or falls below a target amount per block. When excess blob gas is high, the blob gas price increases exponentially, using a formula similar to EIP-1559's fee adjustment mechanism. This responsive pricing aims to be a self-correcting mechanism.
Each blob transaction costs a fixed amount of blob gas based on its data size. This cost is paid upfront by the user. Because the blob gas market operates independently, these transactions can be priced very low, without impacting the main gas market.
This creates substantial fee savings for users of rollups enabled by EIP-4844. Lower fees improve accessibility and make rollups viable for more applications. It incentivizes an ecosystem-wide migration of users from L1 to L2 rollups.
However, very low L1 usage could impact Ethereum's overall security budget long-term. Validators may also face increased hardware costs to manage the extra block data. So, these dynamics will need to be monitored and managed carefully as the ecosystem evolves.
The dynamic blob gas price adjustment based on excess demand reflects basic supply and demand economics.
In basic economics, the price of a resource is determined by the interaction of supply and demand.
When demand is high relative to supply, buyers compete for the limited resource. Their willingness to pay higher prices drives the equilibrium price up.
Conversely, when supply is plentiful relative to demand, suppliers compete to sell the surplus. Their willingness to accept lower prices causes the equilibrium price to fall.
This dynamic adjustment of price based on market conditions is essential to achieving an efficient allocation of resources in economics.
The EIP-4844 blob gas pricing mechanism works similarly. The supply is the target amount of blob gas per block - currently set to a maximum of 6 blobs. The demand is how much blob gas transactions attempt to use in a block. The ‘excess_blob_gas’ value measures this - the difference between the target supply and actual usage.
When excess demand (usage > target) is high, the blob gas price increases exponentially. This disincentivizes demand, and
When excess supply (usage < target) is high, the blob gas price decreases. This incentivizes demand.
So, the mechanism dynamically adjusts the blob gas price based on market conditions of supply and demand, just like in basic economics. This economically efficient design ensures equilibrium blob usage over time.
The ultimate purpose of the dynamic blob gas pricing mechanism is to maintain an optimal level of blob usage on the Ethereum network over time.
Maximizes network throughput - The target matches supply with demand to fully utilize the allotted blob gas per block without oversaturating. This maximizes useful transaction throughput.
Balances costs - If usage far exceeds the target, nodes incur higher costs to propagate and store the excess blob data. Bringing usage down saves costs.
Stabilizes fees - Unpredictable swings in usage lead to volatile fee spikes as the network struggles to adjust. A stable target prevents wild fluctuations.
Sustains decentralization - If blobs become too large, smaller validators may be unable to keep up, centralizing the network. The target prevents unsustainable sizes.
Optimizes incentives - Usage-based pricing incentivizes rollups and users to fine-tune their activity to match the target. This aligns individual incentives with optimal overall utilization.
Dynamically adjusting the blob gas price to stabilize usage around the target level helps achieve key economic goals like maximizing throughput, balancing costs, providing fee predictability, sustaining decentralization, and optimizing incentives for all network participants.
KZG commitments
KZG commitments, also known as Kate-Zaverucha-Goldberg (KZG) commitments, are a type of cryptographic commitment scheme. They're based on bilinear pairings and are particularly useful for their succinctness and efficiency. In the context of EIP-4844, KZG commitments are used to commit to the data blobs. This allows for efficient proofs and validations without revealing the entire data blob.
For easy understanding: Imagine you have a secret recipe. Instead of showing the whole recipe, you just give a small hint (like the smell of the dish). If someone asks if there's a specific ingredient in it, you can say "yes" or "no" without revealing the entire recipe. KZG commitments are like that hint – they give a way to prove something about the data without showing all of it.
For EIP-4844, when data blobs are introduced into the Ethereum network, it's essential to ensure they're valid without clogging the system. KZG commitments allow Ethereum to have a short proof of each blob's validity without needing to see the entire blob. They're crucial in EIP-4844 for committing to data blobs, ensuring the Ethereum network remains efficient and secure.
Point evaluation precompile
The Point Evaluation Precompile is designed to validate the correctness of data in EIP-4844. It provides a way to efficiently verify certain cryptographic properties of the blob data without having to process the entire blob.
How It Works:
The precompile evaluates specific cryptographic functions at designated points. This evaluation ensures the integrity of the data and confirms that it hasn't been tampered with. By evaluating specific points, the system can achieve a balance between security (ensuring data integrity) and efficiency (not processing the entire blob).
For easy understanding: Imagine a teacher checking homework. Instead of reading every word, she checks a few sentences here and there. If they're correct, she trusts the whole homework is done well. The Point Evaluation Precompile is like the teacher's quick check method.
Both interactive optimistic rollups and zk rollups can utilize the Point Evaluation Precompile. This makes it a versatile tool for different scaling solutions on Ethereum.
For Optimistic Rollups, the precompile allows extracting small parts of a blob as needed when submitting fraud proofs. Rather than requiring the entire blob contents on-chain, only the specific elements related to the disputed transition need to be validated. This minimizes calldata gas costs for fraud proofs, while still allowing validity to be proven by cross-checking against the blob's compact cryptographic commitment. Fraud proofs can thereby be made economically viable even for large blob sizes.
For zk-Rollups, the precompile offers an efficient trustless bridge between the succinct cryptographic commitments used by the rollup and Ethereum's underlying hash commitments. The zk-Rollup can prove the equivalence between the blob hash commitment and its own Semaphore, PLONK, or other commitment. This shows the Ethereum contract that the data was correctly incorporated into the rollup's validity proof.
By allowing direct on-chain access to check cryptographic consistency between blobs and rollup validity proofs, the precompile provides a portable trust minimization mechanism. This flexibility makes it suitable across rollup designs.
Usage Targeting
EIP-4844 utilizes usage targeting for the blob gas market to dynamically adjust the blob gas price based on demand.
Note: it’s simplified.
the target supply of blob gas per block is an absolute value of 250000000 gas. This corresponds to approximately 250 kB or 2 blobs worth of data.
usage targeting encourages rollups to post data when the blob gas price is low and avoid posting data when the blob gas price is high. This way, rollups can save costs and optimize their data availability.
Usage targeting refers to setting a target supply of blob gas per block and then using a feedback mechanism to keep actual usage near that target level. This is accomplished by increasing the blob gas price when demand exceeds the target and decreasing it when supply exceeds the target. Specifically, the target supply is currently set to approximately 250kB or 2 blobs worth.
The actual blob gas consumed in a block is compared to this target to calculate the excess_blob_gas for that block. A positive value indicates excess demand, while a negative value indicates excess supply.
This excess amount feeds into the blob gas pricing formula to determine the blob gas price for the next block. The greater the excess demand, the higher the next price will exponentially increase.
This dynamic adjustment process responds similarly to EIP-1559's basefee algorithm, attempting to keep usage near the target over time through economic incentives.
When demand exceeds the target, higher prices disincentivize demand. When supply exceeds the target, lower prices incentivize demand. This balances usage around the target.
The target level ensures blocks do not get too large while also providing rollups sufficient data availability. Adjusting the price around this point aims to achieve economic equilibrium.
Data Pruning
Without pruning, all blob data from EIP-4844 would need to be permanently stored by all Ethereum clients. This would cause the state size to grow exponentially, likely leading to centralization of nodes and infrastructure over time as hardware requirements to store all data become prohibitive.
Data pruning refers to safely deleting old and unneeded data that is no longer actively in use. This prevents unchecked state growth. For EIP-4844, pruning blob data provides an efficient way to reap the scalability benefits of large rollup transaction posts while avoiding excessive long-term storage costs.
Specifically, blob data can be safely deleted after a relatively short durations like 18 days, since rollups only need the data for a limited window to process withdrawals and handle fraud proofs. Permanent availability of historical rollup transactions is not required for correctness and safety, unlike on L1. Only recent blob availability matters.
Data pruning will likely be implemented via schemes like EIP-4444, which introduce flexible state expiry mechanisms into the Ethereum protocol. These will allow specifying tailored expiry policies for different types of state data based on usage patterns. Blobs can be assigned short lifespans appropriate for their ephemeral nature. The exact expiry duration for blobs will be calibrated based on factors like typical fraud proof challenge windows. The expiry would be set safely longer than this window.
Last week, we discussed how shared sequencing was affected by EIP-1559 due to the unpredictability of base fees.
EIP-4844 could have significant implications for the shared sequencing of rollups.
Shared sequencing allows multiple rollups to submit their transaction data to a single sequencing provider in aggregated batches. This improves efficiency by sharing computing resources and avoiding duplicative work.
As we continue this discussion on Shared Sequencing from last week’s article, we believe EIP-4844 does help with Shared Sequencing. The increased data bandwidth per block enables more data availability for all rollups. This reduces the need to rely on specific sequencing providers for L1 inclusion. Rollups have more flexibility to switch providers if needed. The independent blob gas market better aligns incentives. Usage-based pricing prevents shared sequencers from exploiting informational advantages in gas pricing to extract excessive profits from rollups.
Lower L1 data fees also make rollup operations like sequencing more affordable overall. This allows a more diverse and decentralized set of entities to participate in shared sequencing. More participants improve censorship resistance, liveness, and ensure competitive pricing discipline. No single sequencer becomes a central point of control or failure.
Computation for sequencing and aggregating rollup data also becomes cheaper with EIP-4844. Gas savings can be passed back to reduce costs for users.
This has second-order benefits like better security, censorship resistance, competitive pricing, and reliability for users relying on rollups sequenced through shared infrastructure. So, in multiple ways, we can expect EIP-4844 to facilitate a healthier ecosystem of diverse shared sequencers serving the needs of Ethereum rollups.
Conclusion:
EIP-4844 is supposed to go live with the Deneb-Cancun upgrade, along with a few other EIPs. The exact dates are still yet to be rolled out. We think with just one more devnet in the works (devnet 10), we would see rolling it out on testnets in November/December, so we can expect the Deneb-Cancun upgrade live by early 2024.
EIP-4844 represents a milestone on Ethereum's incremental journey towards highly scalable and decentralized rollup-powered transactions. By recognizing data availability as the most urgent bottleneck and innovating a tailored solution optimized for rollups, EIP-4844 puts Ethereum firmly on the path towards becoming the preeminent settlement layer for global finance.
Of course, work remains even after EIP-4844 delivers its core value proposition. Research must continue into areas like decentralized sequencing, cross-rollup composability, sustainable infrastructure revenue models, and enhancements to the data availability paradigm. Prudent future upgrades will likely be needed to calibrate incentives and prevent unintended consequences as the ecosystem evolves.
Appendix
1. To illustrate this high cost of high calldata for directly posting into the execution layer blocks, see this simplified formula as mentioned in the Gas Accounting section under EIP-4844 documentation:
calldata_cost = calldata_gas_cost * gas_price * calldata_size
calldata_cost = 16 * 30 * 10^-9 * 500 * 10^3
calldata_cost = 0.24 ETH
At the current rate of ~$1600 per ETH, this translates to about $384 per block. As you can see, the calldata cost per block is still very high, even with a lower ETH price.
For calculating the cost using blobs, the formula is a bit complex which can be simplified into
blob_gas_price = (blob_gas_cost / (blob_size blob_lifetime)) (1 + log10(average_block_size / target_block_size))
With further calculations, the blob cost per block under EIP-4844 would be only ~$0.80 per block, regardless of the ETH price.
Assumptions:
The blob size is 500 kb, which is a typical value for rollups that use data availability on the main chain.
The blob lifetime is 2 weeks, which is a reasonable duration for rollups to finalize their proofs and delete their data.
The average block size is 0.375 MB, which is the target value for the blob gas market.
Using these values, we can calculate the blob gas cost per block as follows:
blob_gas_cost = blob_size * blob_lifetime * average_block_size
blob_gas_cost = 500 * 10^3 * 14 * 24 * 60 * 0.375 * 10^-6
blob_gas_cost = 378 ETH
The blob gas price is then determined by a formula that takes into account the blob gas cost and the supply and demand of blob space. The formula aims to balance the blob gas market and incentivize efficient use of resources. The formula is:
blob_gas_price = (378 / (500 * 10^3 * 14 * 24 * 60)) * (1 + log10(0.375 / 0.375))
blob_gas_price = 0.000001 ETH
The blob cost per block is then calculated by multiplying the blob gas price by the blob size:
blob_cost = blob_gas_price * blob_size
blob_cost = 0.000001 * 500 * 10^3
blob_cost = 0.0005 ETH
At the current exchange rate of about $1600 per ETH, this translates to about $0.80 per block. This is because the blob gas price is not affected by the market price of ETH but by the supply and demand of blob space.
Find L2IV at l2iterative.com and on Twitter l2iterative
Author: Arhat Bhagwatkar, Research Analyst, L2IV (@0xArhat)
References:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md
KZG in Practice: Polynomial Commitment Schemes and Their Usage in Scaling Ethereum
Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.