# Blob KZG proof verification cost as reserve price in EIP-7918 During the discussion phase for [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 from the cost of `POINT_EVALUATION_PRECOMPILE_GAS`, as opposed to using `TX_BASE_COST` with amortization across blobs. The design 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), [Toni Wahrstätter](https://x.com/nero_eth) and [Marius Van Der Wijden](https://x.com/vdwijden). ## Summary The threshold in the `if`-clause is changed by switching constants, but EIP-7918 remains two lines of spec code. The original constants establish a low minimum blob base fee that still ensures a functioning fee market. The suggested new constants would raise the minimum blob base fee by charging closer to the workload that blobs impose on nodes, still also ensuring a functioning fee market. The rest of this document simply discusses the underlying rationale and implications, illustrating the total workload imposed by blobs on nodes relative to the workload of one point evaluation. ## 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 KZG `commitments` in the payload correspond to the provided `blobs` by 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. * 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. * Validators between full nodes and supernodes will custody between 4-128 columns. * 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 in 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. When columns are batched sequentially, the compute time per blob is still quite high relative to the point evaluation. It is also possible to batch all columns jointly or to parallelize the processing across columns. When accounting for the prospect of parallelization for the CL, it is however 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 (both the point evaluation itself and operations taken conditional on the outcome) and thus also lends itself to parallelization. Such parallelization is an important current research focus. This means that a comparison between the point evaluation and the sequential processing of blobs (batched per column) is still relevant (because *both* could be parallelized). Figure 1 shows verification time per blob divided by the measured execution time of a single point evaluation operation (performed by the `VerifyKZGProof` precompile) for various configurations. The test extends [previous tests](https://gist.github.com/jtraglia/698a4f7bd43764db19753f9fa046998e) in the [C-KZG-4844](https://github.com/ethereum/c-kzg-4844/) library by varying the number of blobs in the columns, batching columns jointly, or parallelizing the computations. Associated vibe code and test results are available [here](https://gist.github.com/anderselowsson/b3e67245fa6a32747c157a53a631268f). 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.--> ![](https://notes.ethereum.org/_uploads/ry4Govwbxg.png) **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. The per-blob verification time of columns depends on the number of custodied/sampled columns and falls with an increase in 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. A full node would for example do the EL mempool verification for all blobs propagated p2p (already 15x). It would also sample 8 columns which at a target of 32 blobs requires 2x more time when done sequentially (batching each column separately), and they would finally custody 4 designated columns which are about equally as demanding as the point evaluation. As previously discussed, whether or not the parallelized verification is comparable is a nuanced issue. This is true also in general. How to price the KZG proof verification is a complex question 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 with an assigned gas cost. ## Design To ensure blob transactions compensate for the computational overhead they impose on nodes for verifying their KZG proofs, the protocol would with the suggestion introduce a reserve price per blob benchmarked against `POINT_EVALUATION_PRECOMPILE_GAS`, rebased and charged in blob gas, by applying 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): ``` 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. Accounting for worst-case scenarios imposed by EL verification, there is no amortization across blobs in the calculation. The protocol thus 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 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, factoring in the 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 which is significant relative to the minimum execution cost for the blob consumer (this is the previous rationale). By charging the proof verification cost via the blob base fee, (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 tx). Given that `POINT_EVALUATION_PRECOMPILE_GAS > TX_BASE_COST`, there is 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 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 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. Furthermore, when compute is in-demand and more expensive, the fee for transacting on the L1 also rises according to the same relative trajectory as the minimum blob base fee. ## Alternative specifications As indicated by the cyan line in Figure 1, the CL's verification cost per blob appears to decrease approximately logarithmically with an increase in the number of processed blobs. 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 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`. The link to 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 costs correspond to `POINT_EVALUATION_PRECOMPILE_GAS`, Ethereum might initially wish to be a "loss-leader" on DA 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](https://notes.ethereum.org/_uploads/SynGxclZlx.png) **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](https://notes.ethereum.org/_uploads/ryFAxclZge.png) **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 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. ![](https://notes.ethereum.org/_uploads/ByFjMSFZlx.png) **Figure 4.** Histogram of the blob base fee when there is no threshold or when applying EIP-7918 with adjusted constants (dashed 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.
Last changed by  
 
Anders Elowsson
254

Read more

On the EIP-7918 `return` statement

When the if-clause in EIP-7918 evaluates to true, the fee update is operating in the thresholded regime, and should not decrease the blob base fee further. The function then returns: return parent.excess_blob_gas + parent.blob_gas_used // 3 This produces a positive linear response in blob_gas_used that has the same maximum increase as when the if-clause evaluates to false. Two alternatives will be outlined here. Incorporating max blobs in the equation As previously mentioned, computing // 3 ensures that the maximum increase stays the same as in the regular update. Specifically, // 3 compensates for the fact that 1/3 of the max blob gas remains after subtracting TARGET_BLOB_GAS_PER_BLOCK. This is expressed as the equation: (max - target) / max = 1/3. It would be convenient to encode the relationship, which is easily achieved if the EL has access to blobSchedule.target and blobSchedule.max from EIP-7892. In this case, the return statement can be modified to: return parent.excess_blob_gas + parent.blob_gas_used * (blobSchedule.max - blobSchedule.target) // blobSchedule.max If EIP-7892 is confirmed for Fusaka with accessible constants, this return statement could be pursued.

5/20/2025
Untitled

Apples of the Infinite Garden: A Children's Book on EIP-7918 Audrey the Auctioneer, Pontus the Ponderer and Therese the Tree Tender have just started an apple orchard in a huge garden. The friends have a vision: feeding the world with apples. Their orchard currently produces an average of 6 fresh apples every 12 seconds. To set the price, Audrey counts how many apples are sold in each 12-second round and keeps the price fixed if exactly 6 apples are sold. She increases the price by around 10% if more than 6 apples are sold (Pontus sells up to 9 apples when working the fastest he can), and decreases it similarly if none or just a few apples are sold. This is generally a sound approach. The apples are tasty and the friends are sure there will always be demand if the price becomes low enough. The first day, everything runs smoothly and the price rises and falls as expected with changes in apple demand. You hear Audrey announcing "Apples for $16!", and 12 seconds later "Get your apples for $15!", etc. However, the next day a very strange thing happens: when Audrey lowers the price, there is no increase in demand. You hear her calling "Apples for $0.01!", a few hours later, "Apples for $0.0001!", and the next morning "Apples for $0.000000001!". The friends are stunned, they were sure thousands of people would want apples at these giveaway prices. They know they're selling prime apples, and at this price, millions upon millions of apples could be bought for just a dollar. Later that day, demand picks up. Customers swarm the stand, waving money to secure an apple. But Audrey follows the same rule as always, raising the price by 10% per round. It takes seven rounds for the price to increase from $0.000000001 to $0.000000002, and this does not seem to have any effect on demand. Customers try to tip extra to jump the queue, but it's difficult to run the stand that way; things were easier when Audrey had control over apple demand.

4/25/2025
Consolidation incentives in Orbit SSF (draft)

What follows is a rough draft of how we can design consolidation incentives in Orbit SSF, published to facilitate discussion during Devcon. 1. Introduction A key proposition of Orbit SSF is that validators rotate based on their size, such that those with larger balances are active more frequently. Active validators can be slashed, so large validators will therefore assume greater risk than small validators. Setting aside mass slashing events, a staking pool might prefer to run smaller validators so that a faulty setup can be caught early and affect only a small fracion of its total stake. For these reasons, Orbit SSF should provide individual consolidation incentives. These can be combined with collective consolidation incentives that reward everyone upon consolidation. As stipulated in the Vorbit SSF post, it can be desirable to see activity rates and incentives change across the full range of validators sizes, from 32 ETH to 2048 ETH. However, it can be difficult to assess beforehand how to distribute incentives such that it does not favor certain validator sizes, leading validators to congregate there. Validators' activity rates might also not be the same for the active chain and the finality gadget. This further complicates the analysis. As noted in Practical endgame on issuance policy, it is perilious to let a validator's stipulated activity rate also apply to its probability to propose blocks. However, if proposal rights are distributed according to stake as they are today, then individual incentives must be relatively stronger at a low issuance than at a high issuance, to compensate for the relatively high MEV that a a validator can accrue while staking with a relatively lower risk. This post presents how consolidation incentives can be designed to account for outlined requirements. A consolidation force $f_1$ is presented in Section 2, which determines the overall strength of the incentives, varying with consolidation level. Section 3 then explores the force distribution $f_2$ that defines how the yield differential is distributed across validator sizes.

11/13/2024
Reward curve with capped issuance

There is a paradigm for the design of the reward curve, with similar economic effects as the reward curve with tempered issuance, at least with the setting that will be highlighted here. The paradigm is to adopt a reward curve with capped issuance, that replicates the current reward up to some cap, defined by the deposit size at which issuance stops growing $D_c$. Since this policy is rather similar to the reward curve with tempered issuance, the reader is encouraged to review its associated ethresearch post that goes into great detail on various trade-offs for the design. My write-up on the foundations of minimum viable issuance from yesterday might also be useful. The figure below illustrates a reward curve in pink where the cap kicks in at $D_c=2^{24}$. One interesting detail is that Vitalik's active validator cap and rotation proposal from 2021 has the same effect on issuance as when using the setting of $D_c=2^{24}$. The green reward curves are alternatives with tempered issuance specified in Section 3.1 of the previously linked write-up. As evident, the reward curve with an issuance cap would also halve issuance relative to the current trajectory at $D=2^{26}$, just as the tempered issuance under a graduated approach. Of course, it might seem appealing to stakers to then cap issuance at the current deposit size instead, i.e., $D_c=2^{25}$. However, the gains from adopting such a policy would be much more limited, albeit not insignificant. In my view, a change to $D_c=2^{24}$ is then clearly preferable in the case that a change is instituted using this paradigm. The figure below instead shows the effect on staking yield under the current level of MEV (300 000 ETH/year). Hypothetical future supply curves are illustrated in blue (discussed in the longer previous write-up). I will return shortly with a longer write-up on this paradigm, detailing its benefits and drawbacks, and most interesting variants. One of those is extensions using methods described in Section 6.3. Just as with the reward curve with tempered issuance, the reward curve with capped issuance is trivial to implement. One interesting question is if the simplicity of this design makes it easier to accept to the community. The reward curve with tempered issuance is of course also very simple in its design: divide the equation for the current reward curve by $1+D/k$. But it might not "look" as simple. An aspect that can both be a benefit and drawback is the discontinuity and specific shape around the cap, which will be discussed further in the forthcoming longer write-up.

4/18/2024
Read more from Anders Elowsson
Published on HackMD