Skip to content

feat: enable Osaka EIPs via berachain genesis config (BRIP-10)#243

Open
calbera wants to merge 5 commits intomainfrom
claude/enable-eip-precompiles-NcATK
Open

feat: enable Osaka EIPs via berachain genesis config (BRIP-10)#243
calbera wants to merge 5 commits intomainfrom
claude/enable-eip-precompiles-NcATK

Conversation

@calbera
Copy link
Copy Markdown
Contributor

@calbera calbera commented Apr 16, 2026

https://github.com/berachain/BRIPs/blob/main/meta/BRIP-0010.md

Enable EIP-7951 (P-256 precompile), EIP-7939 (CLZ opcode), EIP-7823/7883 (MODEXP repricing), EIP-7934/7825 (size caps), and contract code size limit increase (32 KB / 64 KB initcode) by activating EthereumHardfork::Osaka through a new osaka field in the berachain genesis configuration section. These EIPs are already implemented in revm's Osaka spec and only require config-level changes to enable.

Summary by CodeRabbit

  • New Features

    • Added Osaka hardfork configuration support with activation-time validation and display of Osaka activation.
    • Enforced Osaka activation ordering against prior hardforks; conflicting settings now produce a startup error.
    • Implemented Osaka-specific contract code and initcode size limits during execution.
  • Tests

    • Added a precompile availability test for P256VERIFY across hardfork versions.

Enable EIP-7951 (P-256 precompile), EIP-7939 (CLZ opcode),
EIP-7823/7883 (MODEXP repricing), EIP-7934/7825 (size caps), and
contract code size limit increase (32 KB / 64 KB initcode) by
activating EthereumHardfork::Osaka through a new `osaka` field in
the berachain genesis configuration section. These EIPs are already
implemented in revm's Osaka spec and only require config-level
changes to enable.

https://claude.ai/code/session_01G5Ax8QjmSv1NC49v26zr9c
@calbera calbera requested a review from a team April 16, 2026 11:22
@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 16, 2026

📝 Walkthrough

Walkthrough

Adds Osaka hardfork support: new OsakaConfig in genesis, optional osaka_config in BerachainChainSpec with validation/activation scheduling, Osaka-aware EVM code-size limits, and tests for P256VERIFY precompile activation.

Changes

Cohort / File(s) Summary
Genesis Configs
src/genesis/config.rs, src/genesis/mod.rs
Introduce OsakaConfig { time: u64 }; add osaka: Option<OsakaConfig> to BerachainGenesisConfig, default to None, re-export OsakaConfig.
Chainspec Integration
src/chainspec/mod.rs
Add pub osaka_config: Option<OsakaConfig> to BerachainChainSpec; parse berachain.osaka and compute effective_osaka_time (favoring berachain field), error on conflicting times; validate Osaka occurs after latest Prague fork; schedule EthereumHardfork::Osaka using effective time; update hardfork display.
EVM Runtime Config
src/node/evm/config.rs
Add Osaka-specific limits: limit_contract_code_size = 32_768 and limit_contract_initcode_size = 65_536; apply these in evm_env, next_evm_env, and evm_env_for_payload when Osaka is active.
Precompile Tests
src/evm/mod.rs
Add table-driven test case for P256VERIFY precompile: absent under SpecId::PRAGUE, present under SpecId::OSAKA.

Sequence Diagram(s)

sequenceDiagram
    participant Loader as Genesis Loader
    participant Spec as BerachainChainSpec
    participant EVM as EVM Env Builder
    participant Exec as Executor

    Loader->>Spec: parse genesis (including berachain.osaka & genesis.config.osaka_time)
    Spec->>Spec: compute effective_osaka_time, validate ordering against Prague forks
    Spec->>EVM: provide hardfork schedule & osaka_config
    EVM->>EVM: enable Osaka-specific code-size limits if active at timestamp
    EVM->>Exec: produce CfgEnv for execution
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Poem

🐰 A rabbit hops where Osaka springs,
New times and limits, gentle things,
Genesis whispers times to bind,
ChainSpec sets the rule in kind,
Code-size fences keep hops in line.

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: enabling Osaka EIPs through berachain genesis configuration, which is the central objective reflected in all modified files.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/enable-eip-precompiles-NcATK

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@calbera calbera marked this pull request as ready for review April 16, 2026 11:35
Copilot AI review requested due to automatic review settings April 16, 2026 11:35
Include prague4_details in display_hardforks output (pre-existing
omission). Tighten Osaka ordering validation to check against the
latest preceding Berachain fork (Prague4 > Prague3 > Prague2) rather
than only against the base Prague hardfork.

https://claude.ai/code/session_01G5Ax8QjmSv1NC49v26zr9c
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds Berachain genesis-level configuration to activate the Ethereum Osaka hardfork (BRIP-10) and wires Osaka-specific EVM limits/tests into the node.

Changes:

  • Introduces berachain.osaka genesis config (OsakaConfig { time }) and threads it into BerachainChainSpec.
  • Activates EthereumHardfork::Osaka from Berachain genesis config (with fallback to standard genesis osaka_time).
  • Applies Osaka-specific EVM caps (code size/initcode size) and adds a precompile presence test for P256VERIFY (0x100).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
src/node/evm/config.rs Applies Osaka-specific tx gas cap and contract code/initcode size limits to EVM config envs.
src/genesis/mod.rs Extends Berachain genesis parsing model to include optional osaka section and re-exports OsakaConfig.
src/genesis/config.rs Adds OsakaConfig type for berachain.osaka genesis configuration.
src/evm/mod.rs Extends precompile availability tests to include Osaka’s P-256 verify precompile at 0x100.
src/chainspec/mod.rs Parses/stores Osaka config, validates ordering (partially), and activates EthereumHardfork::Osaka.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/chainspec/mod.rs Outdated
Comment thread src/chainspec/mod.rs Outdated
Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/evm/mod.rs`:
- Around line 326-332: Remove the three inline comments in the tuple containing
address!("0x0000000000000000000000000000000000000100"), SpecId::PRAGUE,
SpecId::OSAKA, "P256VERIFY" in src/evm/mod.rs so the test data is comment-free;
leave the tuple values as-is (address literal, SpecId::PRAGUE, SpecId::OSAKA,
and "P256VERIFY") and ensure no other comments remain on that line or adjacent
lines related to this entry.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 5bbf0e86-9c7c-47df-a813-937b9c79036c

📥 Commits

Reviewing files that changed from the base of the PR and between 1898a51 and 6b7789d.

📒 Files selected for processing (5)
  • src/chainspec/mod.rs
  • src/evm/mod.rs
  • src/genesis/config.rs
  • src/genesis/mod.rs
  • src/node/evm/config.rs

Comment thread src/evm/mod.rs
claude and others added 2 commits April 16, 2026 11:47
Resolve effective Osaka timestamp from either berachain.osaka or
standard osakaTime, rejecting mismatched dual configuration. Apply
ordering validation against the latest preceding fork regardless of
which source activated Osaka.

Add tests for Osaka activation via berachain config, standard genesis
config, ordering panics against Prague2/Prague4, conflicting dual
config rejection, and matching dual config acceptance. Also include
the previously missing prague4_details in display_hardforks.

https://claude.ai/code/session_01G5Ax8QjmSv1NC49v26zr9c
Copy link
Copy Markdown
Collaborator

@bar-bera bar-bera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just my curiosity, why do we support both ways of forking? seems like just allowing osakaTime outside of berachain specific forks would bring less overhead in terms of code in this PR.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
src/chainspec/mod.rs (1)

820-828: ⚠️ Potential issue | 🟡 Minor

Normalize osaka_config for standard osakaTime.

effective_osaka_time activates EthereumHardfork::Osaka, but osaka_config is still assigned from only berachain.osaka. For a standard-only osakaTime, BerachainChainSpec::osaka_config stays None, so display_hardforks() also omits the Osaka details for a supported activation path.

Proposed fix
-            osaka_config: osaka_config_opt,
+            osaka_config: osaka_config_opt
+                .or_else(|| effective_osaka_time.map(|time| OsakaConfig { time })),
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/chainspec/mod.rs` around lines 820 - 828, The osaka_config field is left
None when berachain.osaka is None even though effective_osaka_time indicates
EthereumHardfork::Osaka will activate; update the constructor that builds Self
so that when effective_osaka_time activates Osaka and
prague4_config/osaka_config_opt are None you populate osaka_config
(BerachainChainSpec::osaka_config) with the normalized/standard Osaka config
derived for that activation path (e.g., by creating the standard osaka config
from the same source used to compute effective_osaka_time/genesis_header or a
dedicated builder), ensuring display_hardforks() sees Osaka details; locate the
initialization of osaka_config_opt and effective_osaka_time in mod.rs and add
the conditional assignment so osaka_config is Some(normalized_osaka_config)
whenever effective_osaka_time == EthereumHardfork::Osaka.
🧹 Nitpick comments (1)
src/chainspec/mod.rs (1)

510-510: Remove the new what-only comments.

These comments restate the immediately following code paths; the variable names and panic messages already carry the intent. As per coding guidelines, src/**/*.rs: No comments in code unless explicitly requested.

Proposed cleanup
-        // Parse hardfork configurations if present
         let prague1_config_opt = berachain_genesis_config.prague1;
-        // Resolve effective Osaka activation timestamp from either source, rejecting conflicts
         let effective_osaka_time = match (osaka_config_opt.as_ref(), genesis.config.osaka_time) {
-        // Validate Osaka ordering if configured (must come at or after the latest preceding fork)
         if let Some(osaka_time) = effective_osaka_time {

Also applies to: 618-618, 633-633

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/chainspec/mod.rs` at line 510, Remove the redundant "what-only" comments
like "Parse hardfork configurations if present" and similar one-line
restatements elsewhere in src/chainspec/mod.rs (the comments around the hardfork
parsing/code paths noted in the review). Locate the comment text and simply
delete those lines so the code relies on clear variable names and panic messages
instead of restating behavior; do the same for the other occurrences referenced
in the review (the analogous single-line comments near the hardfork parsing
logic).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@src/chainspec/mod.rs`:
- Around line 820-828: The osaka_config field is left None when berachain.osaka
is None even though effective_osaka_time indicates EthereumHardfork::Osaka will
activate; update the constructor that builds Self so that when
effective_osaka_time activates Osaka and prague4_config/osaka_config_opt are
None you populate osaka_config (BerachainChainSpec::osaka_config) with the
normalized/standard Osaka config derived for that activation path (e.g., by
creating the standard osaka config from the same source used to compute
effective_osaka_time/genesis_header or a dedicated builder), ensuring
display_hardforks() sees Osaka details; locate the initialization of
osaka_config_opt and effective_osaka_time in mod.rs and add the conditional
assignment so osaka_config is Some(normalized_osaka_config) whenever
effective_osaka_time == EthereumHardfork::Osaka.

---

Nitpick comments:
In `@src/chainspec/mod.rs`:
- Line 510: Remove the redundant "what-only" comments like "Parse hardfork
configurations if present" and similar one-line restatements elsewhere in
src/chainspec/mod.rs (the comments around the hardfork parsing/code paths noted
in the review). Locate the comment text and simply delete those lines so the
code relies on clear variable names and panic messages instead of restating
behavior; do the same for the other occurrences referenced in the review (the
analogous single-line comments near the hardfork parsing logic).

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 085d35b4-ba8d-45d7-84e6-e5aaf3b4318e

📥 Commits

Reviewing files that changed from the base of the PR and between 6b7789d and fc5e3c0.

📒 Files selected for processing (1)
  • src/chainspec/mod.rs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants