# Considerations for the `BLOB_BASE_COST` in EIP-7918 [EIP-7918](https://eips.ethereum.org/EIPS/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: 1. To ensure a functioning fee market, by keeping the blob base fee in a range where its adjustment affects the demand for blobspace. 2. To charge at least a fraction of the cost for the compute imposed on nodes, at the prevailing market rate. The preliminary setting is: ````python 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. ## Functioning fee market When it comes to ensuring a functioning fee market, the blob base fee should be kept in a range where its adjustment affects the demand for blobspace. When the blob base fee is reduced to 1 wei, a change in the blob base fee of 10% may shift the total cost of utilizing blobspace by just 0.0000001%, after accounting for the existing costs of, e.g., the blob-carrying tx and ZK proof verification. During an increase in demand, the fee update mechanism can then take hours to restore a market-clearing equilibrium fee, with users intermittently resorting to a first-price auction, complicating the UX. A blob consumer purchasing 6 blobs with a single blob-carrying tx amortizes the tx cost to pay only `21000/6=3500` gas per blob. Blob consumers purchasing a single blob and relying on ZK proof verification may on the other hand spend several hundred thousand gas per blob, resulting in a low sensitivity to shifts in the blob price around a cost of `3500` gas. Still, the fee would rather quickly rise to also affect these consumers, and it is in either case sufficient to moderate demand among bulk blob buyers to meaningfully affect aggregate demand. A reserve price of: ````python BLOB_BASE_COST = 2**12 # 4096 ```` or even ````python BLOB_BASE_COST = 2**11 # 2048 ```` could thus be perfectly sufficient for ensuring a functioning fee market. Currently, the blob base fee can at most increase by 8.2% per slot. A meaningful reference is the slot-by-slot increase in the real price of blobspace under full blocks (max blobs) for someone purchasing one blob with a simple tx, at the reserve price level. At, `16384`, this works out to around `0.082*16384/(16384+21000) = 0.036`, i.e., 3.6%. At `4096`, the increase in the real price of blob space from a full block would be around 1.34% and at `2048` it would be around 0.73%. As the constant falls, the maximum increase in the blob base fee around the reserve price becomes increasingly irrelevant to the blob consumer. Table 1 summarizes the maximum increase in the real price for blob space per slot from the reserve price, at various fixed costs $F$, for blobs purchased with a single tx. The ideal setting depends on how quickly we wish to be able to establish a market-clearing blob base fee during an increase in demand. | `BLOB_BASE_COST` | 1 blob, $F=21000$ | 6 blobs, $F=21000$ | 1 blob, $F=100000$ | |:---------------|------------------------------:|---------------------------------:|--------------------------------:| | $\;\;\;\;2^{11}$ (2048) | 0.73% | 3.03% | 0.16% | | $\;\;\;\;2^{12}$ (4096) | 1.34% | 4.42% | 0.32% | | $\;\;\;\;2^{13}$ (8192) | 2.30% | 5.75% | 0.62% | | $\;\;\;\;2^{14}$ (16384) | 3.59% | 6.76% | 1.15% | **Table 1.** The maximum possible increase in the real price for blob space per slot from the reserve price, accounting for fixed costs $F$ (such as the cost of the blob-carrying tx) that the purchased blobs are amortized across. ## Blob KZG proof verification cost Validators must under [EIP-4844](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md) verify that the KZG `commitments` in the payload correspond to the provided `blobs` by cryptographically verifying the accompanying KZG `proofs`. Execution layer (EL) nodes must also validate the `tx_payload_body` and verify the wrapped data for every blob entering a node's tx pool. [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594) introduces PeerDAS with blob cells and their individual proofs. The exact specification is not yet fully settled, but this is a rough guideline: * EL nodes batch-verify 128 cell proofs for each blob before including a tx carrying that blob in their tx pool. * Full nodes must verify 4 custodied columns (each containing a cell from all blobs) and supernodes must verify 128. Validators between full nodes and supernodes will custody between 4-128 columns. * Nodes peer-sample 8 columns each slot (in addition to any custodied columns). Figure 1 shows verification time per blob divided by the measured execution time of a single point evaluation operation (performed by the `VerifyKZGProof` precompile; blue line) for various configurations. A full node would for example do the EL mempool verification for all blobs propagated p2p (red line). It would also verify 8 sampled columns (brown lines) and finally verify 4 designated columns that it custodies (not shown). All column processing is batched, but the dashed line indicates *batching of the column batches*, and the dotted lines indicate parallel processing of the batches. The point evaluation used as a baseline reference is also amenable to parallelization. Refer to the EIP for a more detailed discussion on the compute workload. The green lines outline different potential settings for the `BLOB_BASE_COST`. Verification time is here displayed in terms of (and relative to) the charged `POINT_EVALUATION_PRECOMPILE_GAS=50000`, to allow for a direct comparison. When accounting for the various verification costs imposed on nodes, a setting of: ````python BLOB_BASE_COST = 2**15 # 32768 ```` might seem reasonable. Refer to a recent [Discord discussion](https://discord.com/channels/595666850260713488/598292067260825641/1376363559797391433) for perspectives on these matters.  **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 and the column verification time depends on the number of custodied/sampled columns (all examples already involve batching across the cells of a column). Three options for `BLOB_BASE_COST` are outlined with green lines. ## Discussion As presented, a functioning fee market can be satisfied with a setting below $2^{14}$. Going with $2^{12}$ would likely be sufficient and even $2^{11}$ could be considered. On the other hand, blobs subject nodes to rather substantial compute, above $2^{14}$ even when not accounting for the EL mempool verification. Blob consumers currently do not need to pay this cost, but it would be more fair if they did. A setting of $2^{15}$ would likely be more reflective of the compute costs that blobs impose. The setting of $2^{14}$ is approximately the mean of these two figures. I do not think we should depart too far in either direction from this level, but I am not attached to a specific figure. There is further an interaction with other upgrades. For example, when Ethereum adopts delayed execution or ePBS, compute will be spread out across a larger portion of the block, making any additional imposed compute more relevant in terms of straining our resources. Another thing to note is that the fee market would indeed "function" even at higher settings than what is required for the fee update to affect blob demand. The difference is that the reserve price at a higher setting can influence the quantity of blobs purchased each slot, as long as the equilibrium price at target blobs is not higher than this level. Further note that while the EL mempool verification requires substantial compute in the worst case, these operations may be performed in parallel to any compute dedicated to processing the block. In this EIP, blob compute is still not accounted for in the ELs gas limit, meaning that blob compute does not feed into and affect the execution gas price directly. Due to the somewhat separate conditions under which this compute is performed and its still limited scope, this has felt acceptable, but is something that can be considered for the future. The idea with the proposed constant is to balance the need for a functioning fee market and fairness in light of compute imposed by blobs, while still limiting the protocol change to this single line of code for Fusaka. From a macro perspective, we can also identify two separate potential goals. On one hand, there is the idea that L2s should pay their fair share for the value that they receive via blobs. A higher setting for `BLOB_BASE_COST` would uphold this. On the other hand, Ethereum may strategically wish to be a loss-leader on DA, to spur network effects and reach price-sensitive consumers on an accelerated timeline. I think that we can be attentive to the macro perspective, but must also acknowledge that it points in conflicting directions.