feat: enable Osaka EIPs via berachain genesis config (BRIP-10)#243
feat: enable Osaka EIPs via berachain genesis config (BRIP-10)#243
Conversation
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
📝 WalkthroughWalkthroughAdds Osaka hardfork support: new Changes
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
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
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
There was a problem hiding this comment.
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.osakagenesis config (OsakaConfig { time }) and threads it intoBerachainChainSpec. - Activates
EthereumHardfork::Osakafrom Berachain genesis config (with fallback to standard genesisosaka_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.
There was a problem hiding this comment.
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
📒 Files selected for processing (5)
src/chainspec/mod.rssrc/evm/mod.rssrc/genesis/config.rssrc/genesis/mod.rssrc/node/evm/config.rs
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
bar-bera
left a comment
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 | 🟡 MinorNormalize
osaka_configfor standardosakaTime.
effective_osaka_timeactivatesEthereumHardfork::Osaka, butosaka_configis still assigned from onlyberachain.osaka. For a standard-onlyosakaTime,BerachainChainSpec::osaka_configstaysNone, sodisplay_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).
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
osakafield 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
Tests