# Blob KZG proof verification cost as reserve price in EIP-7918 In the discussion of [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918), [Ben Adams](https://x.com/ben_a_adams) has [suggested](https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271/19) that we compute the minimum blob base fee based on the cost of `POINT_EVALUATION_PRECOMPILE_GAS`, as opposed to using the `TX_BASE_COST` with amortization across blobs. This would shift the rationale. Instead of using the lowest reserve price deemed influential on demand, the reserve price would be set closer to the computational cost imposed by the blobs (which is at a higher level). The design idea seems worthwhile, and I will here analyze it, based on discussion with—and feedback from—Ben, [Francesco D'Amato](https://x.com/fradamt), [Justin Traglia](https://x.com/JustinTraglia) and [Marius Van Der Wijden](https://x.com/vdwijden). ## Background ### EIP-4844 (Dencun) [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduced the first phase of Ethereum's data availability sampling (DAS) roadmap. Validators on the consensus layer (CL) verify that the the KZG `commitments` in the payload correspond to the provided `blobs` cryptographically verifying the accompanying KZG `proofs`. Furthermore, execution layer (EL) nodes must [also](https://eips.ethereum.org/EIPS/eip-4844#networking) validate the `tx_payload_body` and verify the wrapped data (blobs, commitments, and proofs) for every blob entering a node's tx pool. MEV-boost also performs similar checks on blobs via the `flashbots_validateBuilderSubmission` endpoint when they are included in the payload (at least in Nethermind). The computational requirements for verifying a KZG proof for an entire blob are slightly higher than those for verifying a KZG proof for a single point on that blob; the latter is the specific operation covered by the POINT_EVALUATION_PRECOMPILE_GAS (50000) charged to smart contracts. While blobs arriving directly via MEV-boost do not subject EL nodes to the burden of this p2p verification, MEV-boost is an out-of-protocol solution. The protocol should ideally charge users according to the regular (worst-case) scenario of blob txs propagating p2p. This is also the most common behavior today given limited MEV in blobs. ### EIP-7594 (Fusaka) [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594) introduces PeerDAS and is scheduled for Fusaka. It changes compute requirements due to the reliance on blob cells and their individual proofs. The exact specification is not yet fully settled, but this is a rough guideline: * EL nodes batch-verify `CELLS_PER_EXT_BLOB` (128) cell proofs for each blob before including a tx carrying that blob in their tx pool. This verification (e.g., using `verify_cell_kzg_proof_batch`) is roughly 15 times more expensive than the compute associated with a single `POINT_EVALUATION_PRECOMPILE_GAS` (which is for one `verify_kzg_proof`). * Full nodes must verify 4 custodied columns, each column containing one cell from all blobs referenced in the payload. Each column's cell proofs can be batch-verified (across all blobs). * Supernodes must verify 128 custodied columns, each column containing one cell from all blobs referenced in the payload. Each column's cell proofs can be batch-verified (across all blobs). * Validators between full nodes and supernodes will custody between 4-128 columns to verify. * Nodes peer-sample `SAMPLES_PER_SLOT` (8) columns each slot (in addition to custodied columns). Each column's cell proofs can, as previously, be batch-verified. For the verification performed on the CL for PeerDAS, the ability to jointly process cell proofs of a column (from all blobs) through batching reduces the compute time spent per blob as the number of blobs increases. If done sequentially for all custodied columns, the compute requirements are still high. However, it is also possible to batch columns jointly or to parallelize the processing across columns. When accounting for the prospect of parallelization for the CL, it is also worth remembering that the point evaluation proof verification performed by rollups using the precompile should generally not have many dependencies on other transactions in the execution block and thus also lends itself to parallelization. Such parallelization is an important current research focus. Figure 1 shows verification time per blob divided by the measured execution time of a single point evaluation operation (the operation performed by the VerifyKZGProof precompile) for various configurations. The test extends [previous analysis](https://gist.github.com/jtraglia/698a4f7bd43764db19753f9fa046998e) by varying the number of blobs in the columns, batching columns jointly, or parallelizing the computations. Thus, the cells of a column are always batched by the CL, but the configuration for how to process multiple columns is varied. The computed "point evaluation multiple" falls with a higher blob count on the CL (brown and pink lines) due to benefits from batching. The dashed cyan line shows that this relationship seems to be approximately reciprocal to the logarithm of the targeted number of blobs. The EL mempool verification step for PeerDAS (red), involving cell proof verification, does not benefit from a higher blob count in the worst-case scenario. The EL and CL verification steps are additive: nodes must perform both.  **Figure 1.** Verification time per blob relative to one point evaluation on an Apple M2 Max with 12 cores. The EL mempool verification (red) takes 15 times longer in the worst case, regardless of the blob target. Verification of custodied columns is faster for full nodes (custodying fewer columns than supernodes) and falls with the blob target due to speed-ups from processing all cells of a column jointly. Processing speeds up when batched or parallelized (albeit with more cores occupied in the latter case). The figure indicates that blobs under the current Fusaka PeerDAS specification will subject nodes to rather heavy compute requirements—when compared to the single point evaluation proof verification that a smart contract is charged `POINT_EVALUATION_PRECOMPILE_GAS` for. The issue of how to price the KZG proof verification is of course rather nuanced given the varying contexts in which it is performed. Charging a minimum price of `POINT_EVALUATION_PRECOMPILE_GAS` could act as a reasonable compromise/lower bound under current circumstances, representing the cost of a basic unit of blob data verification. ## Design To ensure blob transactions contribute to the computational overhead they impose on validators for verifying their KZG proofs, the protocol can introduce a reserve price per blob benchmarked against `POINT_EVALUATION_PRECOMPILE_GAS`, rebased and charged in blob gas. While the precompile's gas cost is for a distinct contract-level operation, it offers an understandable proxy for a basic unit of blob-related computational work.If accounting for worst-case scenarios imposed by EL verification, there would be no amortization across blobs in the calculation. This variant of the design [proposed](https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271/19) by Ben has been [referred to](https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271/30) as EIP-7918E, and would incorporate the following `if` clause: ```Python if POINT_EVALUATION_PRECOMPILE_GAS * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent): ``` This means that the protocol imposes a reserve price on the blob base fee of $$ b_\text{blob} = \frac{50000 \times b_\text{exec.}}{2^{17}}. $$ ## Implications With this change, the protocol would take the position that blob txs have no more right to utilize compute than other txs do, unless they pay their fair share at the prevailing market price (the execution base fee). They must thus pay a blob base fee that at least corresponds to the execution cost of one `POINT_EVALUATION_PRECOMPILE_GAS`, representing a new reserve price. They thus make the payment via blob gas. The cost for the blob data is still charged on top of this minimum fee, but set fully independently according to the market-clearing price with a reserve price. From a mechanism design perspective, the EIP would then resolve two separate issues: 1. Ensuring that blob consumers pay at least for the compute they impose, with any further fees for data determined in the independent blob fee market. 2. Ensuring a functioning blob fee update mechanism by establishing a price floor representative of the minimum costs facing the *blob consumer* (this is the previous rationale). By charging the proof verification cost via the blob base fee in this manner, (1) and (2) are fulfilled jointly. Any costs imposed in the independent fee market on top of the compute cost are for the actual data. As this base fee is set in blob gas, of which 100% is burned, it is not subject to additional costs via priority fees (the blob consumer can still calibrate priority fees for their blob-carrying transaction). Given that `POINT_EVALUATION_PRECOMPILE_GAS > TX_BASE_COST`, there would be no need to account for transaction costs for the purpose of establishing a functioning fee market. The solution can be understood as a composite fee market where the cost for a "base" resource (execution) represents the reserve price when charging for the secondary resource (blob data). It should be noted that this change would substantially raise the minimum fee for blobs, relative to the previous proposal. There is no amortization since the cost is imposed for every blob, and `POINT_EVALUATION_PRECOMPILE_GAS=50000`—thus more than twice as high as `TX_BASE_COST=21000`. The minimum blob base fee then becomes around 38% of the execution base fee: ```python POINT_EVALUATION_PRECOMPILE_GAS / GAS_PER_BLOB = 50000 / 131072 = 0.38 ``` If the execution base fee is 1 gwei, the imposed minimum blob base fee would be 0.38 gwei. If the execution base fee is 2.62 gwei, the imposed minimum blob base fee would be 1 gwei. At a 1 gwei blob base fee and \$2500 ETH price, the protocol would charge at least `131072 * 1 * 2500 / 10**9 = 0.33` dollars for a blob. If the execution base fee is 26.2 gwei, the minimum blob base fee becomes 10 gwei, and the imposed minimum price would be as high as \$3.3 dollars per blob. It is however important to remember that blob consumers would pay for compute that they actually impose on EL nodes, and that this fee also is imposed on smart contracts via `POINT_EVALUATION_PRECOMPILE_GAS`. It is not an arbitrary fee, but a neutral way to resolve two separate problems with the current fee market design. ## Alternative designs As indicated by the cyan line in Figure 1, the CL's verification cost per blob appears to decrease approximately logarithmically as the number of processed blobs increases. If, in the future, the EL's handling of blobs is made more efficient, the minimum blob base fee could be designed to decrease with an increase in blobs according to this more subtle amortization schedule. Unfortunately, there is no log-function defined at the EL. A straightforward way to obtain the integer part of a base-2 logarithm (i.e., $\lfloor \log_2 N \rfloor$) is to calculate the bit length of the targeted number of blobs and subtract one. This computation is equivalent to Python's `(target).bit_length() - 1`. Linking with the execution base fee ensures that blob consumers pay according to how in-demand compute services of the nodes are at the time that they are requested. But using the constant `POINT_EVALUATION_PRECOMPILE_GAS` directly may be [suboptimal](https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271/5), even if it currently is deemed appropriate. After all, the `POINT_EVALUATION_PRECOMPILE_GAS` itself might be changed, for example on account of [high proving costs](https://ethresear.ch/t/the-hunt-tracking-organic-prover-killer-blocks-on-ethereum/22332#p-54284-results-3). Furthermore, even if compute cost are deemed to correspond to `POINT_EVALUATION_PRECOMPILE_GAS`, Ethereum might initially wish to be a "loss-leader" on DAS for strategic purposes, and thus charge according to a lower constant. ## Empirical analysis Figures 2-3 show price evolution over three weeks in November 2024, when the average execution base fee was around 16 gwei, as well as in March 2025, when the average was around 1.3 gwei. The observed fee is shown in black and the cost of `POINT_EVALUATION_PRECOMPILE_GAS` in blue, rebased to become the minimum blob base fee as prescribed by the mechanism. EIP-7918 imposes the maximum of the two curves, indicated in darker colors. As evident, the minimum fee becomes rather substantial when execution gas is more expensive, and lower when execution gas is cheaper.  **Figure 2.** Blob base fee evolution with the current fee market (black) and the blob-base-fee denominated cost of `POINT_EVALUATION_PRECOMPILE_GAS` (blue), during three weeks of November 2024 when the average execution base fee was around 16 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors.  **Figure 3.** Blob base fee evolution with the current fee market (black) and the blob-base-fee denominated cost of `POINT_EVALUATION_PRECOMPILE_GAS` (blue), during three weeks of March 2025 when the average execution base fee was around 1.3 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. Figure 4 shows histograms for observed fees and the maximum of the two curves (EIP-7918E) for the four-month period from November 2024 (start of Figure 2's data period) through March 2025 (end of Figure 3's data period), corresponding to approximately 900k blocks beginning at block number 22075724. The histograms employ 100 log-spaced bins per decade (factor-of-ten increase), which are smoothed using a Hanning window of width 21 with mirror-reflected edges.  **Figure 4.** Histogram of the blob base fee when there is no threshold or when applying EIP-7918 (green; combination of the darker black and blue curves from previous figures), with light smoothing applied. A four-month period from November 2024 through March 2025 was analyzed. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.