Dynamic Blob Targets for Better Blob Pricing

Abstract

This proposal introduces a dynamic pricing mechanism for blobs in Ethereum, using a PID (Proportional-Integral-Derivative) controller to adjust the target number of blobs. The goal is to maintain baseline security and assumes Data Availability Sampling (DAS) while optimizing blob usage and burn rates, ensuring economic stability and predictability for network participants.

Key Concepts

1. PID-Controlled Blob Target: Adjust the target number of blobs based on network usage over time.
2. Bounded Pricing Mechanism: Implement different pricing behaviors within and outside target bounds.
3. Existing Pricing Mechanism at Limits: Use existing blob pricing mechanisms at the bounds.
4. Burn Rate Optimization: Balance per-blob pricing with overall burn amounts.

Detailed Mechanism

Blob Target Adjustment

• A PID controller algorithm adjusts the target number of blobs based on consistent deviations from the current target.
• The target blob count floats between predetermined lower and upper bounds, the upper bound is set based on security considerations and the lower bound is assumed to be 1.

Pricing Mechanism

1. Within Target Bounds:

   • Price adjusts linearly as actual blob count varies from the target.
   • Increases when above target, decreases when below.

2. Outside Target Bounds:

   • Existing blob pricing mechanisms take over, causing exponential price changes.
   • This continues until actual blob count returns within the target bounds.

3. Blob Target Adjustment Effects:

   • When target increases: Price per blob decreases, but overall burn amount increases.
   • When target decreases: Price per blob increases, but overall burn amount decreases.

Security and Economic Considerations

• Upper bound for blob target is determined by validator count and DAS security requirements assuming a given bandwidth per validator (i.e. we know in advance when validators are withdrawing and it is rate limited as well so we should be safe and able to account for those with enough time to start adjusting the upper blob target limit if needed). We can assume 33% or something similar of validators online in determine how many samples can be completed, etc. to determine a conservative upper limit.
• The system aims to maintain predictable pricing within the target range while ensuring security at the limits.
• Economic stability is prioritized by making gradual adjustments to the target, avoiding sudden price shocks.

Benefits

1. More predictable and stable pricing within the target range.
2. Adaptive to long-term changes in network conditions.
3. Maintains crucial security guarantees through existing mechanisms at the bounds.
4. Optimizes network usage and burn rates over time.

Challenges and Considerations

1. Tuning the PID controller parameters for optimal responsiveness without introducing instability.
2. Ensuring the mechanism remains economically sound under various network conditions.
3. Balancing short-term price stability with long-term adaptability to network changes.

Implementation Considerations

• Thorough economic modeling and simulation are necessary to validate the mechanism’s stability and effectiveness.
• At the lower and upper target blob bound you can define a target burn as a percentage of issuance rates as well. e.g. lower target burn of 1% of issuance and upper target burn of 33% of issuance before we are considered to have re-entered the target blob bounds and start making blob target adjustments. What these targets should be should have modeling and simulations and should be discussed thoroughly as well.

This proposal aims to create a more dynamic and responsive blob pricing system for Ethereum, enhancing network efficiency and economic stability while maintaining crucial security guarantees. The use of a PID controller for target adjustment provides a well-established control mechanism, potentially offering more predictable, sustainable, and stable long-term behavior compared to other algorithmic approaches. It is my belief that a pricing mechanism with similar behavior to what I’ve described would better match the inelastic demand common to L2s utilizing blobs for DA.