EIP-7918 introduces the constant BLOB_BASE_COST, constituting the reserve price for a blob expressed in EL gas. The reserve-price design fulfills two separate functions: To ensure a functioning fee market, by keeping the blob base fee in a range where its adjustment affects the demand for blobspace. To charge at least a fraction of the cost for the compute imposed on nodes, at the prevailing market rate. The preliminary setting is: BLOB_BASE_COST = 2**14 # 16384 This means that the blob reserve price is slightly below the cost of a simple tx and that the reserve blob base fee is 1/8 (2**14/2**17) of the execution base fee. The setting balances the two stated goals of the EIP, where (1) is ensured already at a lower setting (e.g., $2^{11}$ or $2^{12}$) and (2) can be satisfied with an even higher setting (e.g., $2^{15}$). During the SFI decision, we left the door open to adjust BLOB_BASE_COST after testing the core functionality in devnets. I will here outline why the preliminary setting was selected and the range of settings that could be considered.
6/19/2025During the discussion phase for EIP-7918, Ben Adams has suggested 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, Justin Traglia, Toni Wahrstätter and Marius Van Der Wijden. 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 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 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.
5/26/2025When 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/2025Apples 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