Skip to content

BEP-657.md

Latest commit

 

History

History
75 lines (47 loc) · 4.08 KB

BEP-657.md

File metadata and controls

75 lines (47 loc) · 4.08 KB
  BEP: 657
  Title: Limit Blob Transaction Inclusion by Block Number
  Status: Draft
  Type: Standards
  Created: 2026-01-21
  Description: Restrict blob transactions to blocks where block number modulo N equals zero. Initial N=5.

BEP-657: Limit Blob Transaction Inclusion by Block Number

1. Summary

This BEP restricts blob transaction inclusion to blocks where the block number modulo N equals zero. The initial value of N is set to 5, allowing blob transactions in blocks 0, 5, 10, 15, etc. Non-eligible blocks preserve blob fee state from their parent to maintain market continuity.

2. Motivation

BSC's block time has been reduced from 3 seconds to 0.45 seconds, yet blob transaction volume has remained relatively constant at approximately one per 7-8 blocks. This mismatch has resulted in severe blob space oversupply.

Blob Fee Market Dysfunction: The ~6.7x increase in blob capacity with unchanged demand has caused the blob base fee to consistently remain at its minimum floor price. This prevents the EIP-4844 fee market mechanism from functioning properly, as it relies on supply-demand dynamics for price discovery.

By restricting blob transactions to every Nth block (blocks where blockNumber % N == 0), this BEP concentrates demand to restore proper fee market dynamics while maintaining adequate capacity for current usage patterns. The initial value of N is set to 5, meaning blob transactions can only be included in blocks 0, 5, 10, 15, etc. With 0.45s block times, the maximum inclusion delay of 2.25 seconds has minimal impact on L2 operations.

3. Specification

3.1 Blob Transaction Inclusion Rules

Define a parameter N that determines the frequency of eligible blocks. The initial value of N is 5.

For any block with block number blockNumber:

  • If blockNumber % N == 0: The block MAY contain blob transactions
  • If blockNumber % N != 0: The block MUST NOT contain any blob transactions

Blocks violating this rule MUST be rejected as invalid.

With N=5, eligible blocks are: 0, 5, 10, 15, 20, 25, 30, etc.

3.2 Blob Fee Calculation Modification

For blocks where blockNumber % N == 1:

  • Normal EIP-4844 blob fee calculation applies

For blocks where blockNumber % N != 1:

  • header.ExcessBlobGas MUST equal parent.ExcessBlobGas

This ensures the blob fee is calculated once after each eligible block, then preserved across subsequent blocks until the next calculation.

4. Rationale

The modulo N restriction (1 in every N blocks) aligns with current demand patterns. This BEP sets N=5 as the initial value.

  • Fee Market Alignment: Current usage (~1 blob tx per 7-8 blocks) naturally fits within the 1-in-5 schedule, enabling proper EIP-4844 fee mechanism operation while providing room for demand growth.
  • Minimal User Impact: With 0.45s block time, maximum inclusion delay is 2.25 seconds, negligible for L2 sequencers posting data every 30-60 seconds.
  • Fee Continuity: Non-eligible blocks inherit blob fee state from their parent, preserving market state across the 4-block gap and enabling proper price discovery at the next eligible block.
  • Adjustable Parameter: N can be adjusted in future upgrades to adapt to changing demand patterns without requiring fundamental changes to the mechanism.

5. Backward Compatibility

This is a consensus-breaking change requiring a hard fork. All validators and full nodes must upgrade before activation.

Transaction submitters must ensure blob transactions target eligible blocks (blocks where blockNumber % N == 0). With N=5, eligible blocks are 0, 5, 10, 15, 20, etc. Blob-related MEV opportunities will concentrate in these eligible blocks.

6. License

This document is licensed under CC0.