Implementing BPOs As Individual Forks For Enhanced Ethereum Testing

Jul 17, 2025 by Jeany 68 views

feat(forks): Adding BPOs as Individual Forks Including Transition Forks Discussion

This article delves into the proposed implementation of Blob Parameter Optimization (BPO) forks within the Ethereum execution-spec-tests. The primary focus is on treating BPOs as individual forks, similar to how Cancun, Prague, and Osaka are handled, allowing for precise control over maximum and target blob counts. This approach facilitates comprehensive testing of BPO-related functionalities and transitions between different BPO configurations. This article explores the benefits, implementation details, and testing strategies associated with this approach.

Base BPO Forks: A Detailed Examination

The cornerstone of this proposal lies in representing each BPO iteration as a distinct fork. By doing so, the testing framework gains the ability to configure key parameters, notably the maximum and target number of blobs, on a per-fork basis. This mirrors the existing methodology for forks like Cancun, Prague, and Osaka, ensuring consistency and ease of integration. This method provides a granular approach to testing, allowing for specific scenarios and edge cases to be targeted effectively.

Consider the example provided, where OsakaBPO2 is defined as a fork succeeding OsakaBPO1. The crucial aspect here is the ability to override the target_blobs_per_block and max_blobs_per_block methods. In the case of OsakaBPO2, the target is increased to 16 blobs, and the maximum is set to 24. This demonstrates the flexibility afforded by this approach, enabling testers to simulate different network conditions and BPO configurations.

class OsakaBPO2(OsakaBPO1):
    """Osaka BPO2 fork - Second blob parameter only fork after Osaka."""

    @classmethod
    def is_deployed(cls) -> bool:
        """BPO forks are not deployed to mainnet yet."""
        return False # mark this when deployed.
    
    @classmethod
    def target_blobs_per_block(cls, block_number: int = 0, timestamp: int = 0) -> int:
        """BPO2 increases target to 16 blobs."""
        return 16
    
    @classmethod
    def max_blobs_per_block(cls, block_number: int = 0, timestamp: int = 0) -> int:
        """BPO2 increases max to 24 blobs."""
        return 24

By defining these parameters directly within the fork definition, the testing process becomes streamlined. The uv run fill command can then be used to populate the test database with transactions and blocks relevant to the specific BPO fork. For instance, uv run fill --until OsakaBPO2 -n 10 --clean will generate test data up to the OsakaBPO2 fork, ensuring that the dataset reflects the defined blob limits. The -n 10 argument specifies the number of blocks to generate, and the --clean flag ensures a fresh test environment.

Crucially, the existing EIP-4844 tests are designed to be fork-agnostic. This means they dynamically adapt to the blob limits defined within the active fork's functions. This design choice significantly simplifies the testing process, as the same test suite can be reused across different BPO forks without modification. The execute command can then be leveraged to run these tests against a specific BPO fork, validating its behavior under various conditions. This reusability is a key advantage of the proposed approach, reducing the overhead associated with testing each BPO iteration.

Transition BPO Forks: Simulating Real-World Upgrades

Beyond testing individual BPO forks, it is crucial to evaluate the network's behavior during transitions between them. To address this, the proposal introduces the concept of "transition forks." These forks simulate the process of upgrading from one BPO configuration to the next, allowing for the identification and mitigation of potential issues that may arise during the upgrade process. Transition forks play a critical role in ensuring the seamless evolution of the Ethereum network.

Transition forks are defined using the @transition_fork decorator. This decorator specifies the target fork to transition to and the timestamp at which the transition should occur. For instance, the following code snippet defines a transition from the Osaka fork to OsakaBPO1 at timestamp 15,000:

@transition_fork(to_fork=OsakaBPO1, at_timestamp=15_000)
class OsakaBPO2TransitionAtTime15k(Osaka):
    """Osaka to BPO1 transition at specific timestamp."""
    pass

@transition_fork(to_fork=OsakaBPO2, at_timestamp=30_000)
class OsakaBPO1TransitionAtTime30k(OsakaBPO1):
    """Osaka BPO1 to BPO2 transition at specific timestamp."""
    pass

Similarly, a transition from OsakaBPO1 to OsakaBPO2 is defined to occur at timestamp 30,000. By creating these transition forks, developers can simulate the network's behavior as it upgrades between different BPO configurations. This allows for testing of various scenarios, such as the handling of blob transactions across fork boundaries. These simulations are invaluable in identifying and resolving potential compatibility issues.

The ability to specify the transition timestamp is particularly useful, as it allows for the simulation of different upgrade timelines. This flexibility enables testers to assess the impact of varying network conditions and adoption rates on the upgrade process. By controlling the transition timestamp, a wide range of upgrade scenarios can be effectively tested. This level of control is essential for ensuring a smooth and predictable transition between BPO forks.

Addressing Testing Oversights: The `@bpo_fork` and `@bpo_test` Decorators

While the ability to fill tests for every BPO fork is powerful, it's essential to exercise caution and avoid unnecessary redundancy. Given that BPO forks primarily modify the maximum and target blob counts, filling every single test for each fork may be overkill. To address this potential inefficiency, the proposal introduces the concept of a @bpo_fork decorator and a @bpo_test marker. This mechanism provides a fine-grained control over which tests are executed for each BPO fork, optimizing the testing process.

The @bpo_fork decorator would be applied to specific BPO forks and transition forks. This decorator would restrict the test filling process, ensuring that only tests marked with the @bpo_test marker can be executed for these forks. The @bpo_test marker, on the other hand, would be applied to tests that are specifically relevant to BPO functionality, such as EIP-4844 tests. This approach ensures that the testing effort is focused on the areas most impacted by BPO changes.

By implementing this mechanism, the testing process becomes more targeted and efficient. For example, most of the EIP-4844 tests would be marked with the @bpo_test marker. This ensures that these tests are executed for all BPO forks, as they are directly related to blob transactions. However, other tests that are not directly impacted by BPO changes would not be executed for every BPO fork, reducing the overall testing time and resource consumption. This targeted approach is crucial for managing the complexity of testing multiple BPO forks.

This approach strikes a balance between thoroughness and efficiency, ensuring that all critical aspects of BPO functionality are tested without unnecessary repetition. The @bpo_fork and @bpo_test decorators provide a clear and concise way to control the scope of testing, making the process more manageable and effective. This targeted testing strategy is essential for ensuring the quality and stability of the Ethereum network as it evolves through different BPO configurations.

Tests To Update or Add: A Comprehensive Overview

To fully realize the benefits of the proposed BPO fork implementation, several updates and additions to the existing test suite are necessary. These modifications will ensure comprehensive coverage of BPO-related functionalities, including edge cases and transition scenarios. A well-defined test suite is crucial for ensuring the robustness and reliability of the BPO implementation.

The following areas require specific attention:

EIP-4844 tests: These tests should be marked with the @bpo_test marker. This ensures that they are executed for all BPO forks, as they are directly related to blob transactions. These tests validate the core functionality of EIP-4844, including the creation, transmission, and processing of blob transactions. Thorough testing of EIP-4844 is essential for the successful adoption of this technology.
BPO-specific tests within tests/osaka/eip7892.../: This directory should house tests that specifically target BPO-related edge cases and transition scenarios. This includes tests that validate the behavior of the network during transitions between different BPO configurations, as well as tests that explore the boundaries of the blob limits defined for each BPO fork. The conftest.py file within this directory should apply the @bpo_test marker to all tests within the directory, ensuring that they are executed only for relevant BPO forks. This dedicated test suite will provide a granular assessment of BPO-specific behaviors.
PeerDAS execute blobs tests: These tests may need to be updated to be fork-agnostic, ensuring compatibility with BPO forks. This may involve modifying the tests to dynamically adapt to the blob limits defined for each BPO fork. Ensuring the fork-agnostic nature of these tests will streamline the testing process and ensure consistency across different BPO configurations. Adaptability is key for maintaining a robust and versatile test suite.

By addressing these areas, the Ethereum execution-spec-tests can be effectively adapted to accommodate BPO forks. This will enable thorough testing of BPO-related functionalities, ensuring the stability and reliability of the network as it evolves. A comprehensive test suite is an invaluable asset for any blockchain project, and the proposed updates will significantly enhance the quality of the Ethereum ecosystem.

The proposed approach of adding BPOs as individual forks, including transition forks, offers a robust and flexible framework for testing BPO-related functionalities within the Ethereum execution-spec-tests. By treating each BPO iteration as a distinct fork, developers gain granular control over key parameters, such as maximum and target blob counts. This allows for the simulation of various network conditions and BPO configurations, facilitating comprehensive testing of BPO-related behaviors. The introduction of transition forks further enhances the testing capabilities, enabling the simulation of network upgrades between different BPO configurations. The @bpo_fork decorator and @bpo_test marker provide a mechanism for optimizing the testing process, ensuring that testing efforts are focused on the areas most impacted by BPO changes. By implementing these strategies, the Ethereum execution-spec-tests can effectively adapt to the evolving landscape of BPOs, ensuring the stability and reliability of the network as it evolves.