During 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/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/2025What 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/2024There 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