Skip to content

WIP: feat(Osaka): eip7907 Meter Contract Code Size And Increase Limit #2550

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 11 commits into from

Conversation

jgresham
Copy link
Contributor

@jgresham jgresham commented May 28, 2025

EIP: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7907.md

  • Add new max contract size and max initcode size variables
  • Add additional account code warm status
  • (cold access) Implement additional gas fees for size > previous max sizes
  • set code warm after create/create2
  • Test new limit of max initcode & contract size
  • Test code cold/warm statuses. Test with txn containing multiple calls to same account code.
  • TBD on eip7702 and EXTCODESIZE related changes

execution specs reference implementation https://github.com/ethereum/execution-specs/pull/1231/files

I'll try to get more of this ready and tested in advance of fusaka devnet-2 testing

Copy link

codspeed-hq bot commented May 28, 2025

CodSpeed Performance Report

Merging #2550 will degrade performances by 4.7%

Comparing jgresham:feat/eip-7907 (c359206) with main (a3d2006)

Summary

⚡ 48 improvements
❌ 2 regressions
✅ 113 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark BASE HEAD Change
DUP11_50 27.8 µs 27 µs +3.1%
DUP14_50 27.8 µs 26.9 µs +3.31%
DUP15_50 27.6 µs 26.8 µs +3.1%
DUP16_50 28.2 µs 27.3 µs +3.37%
DUP1_50 27.8 µs 26.8 µs +3.54%
DUP2_50 27.7 µs 26.7 µs +3.54%
DUP3_50 27.7 µs 26.7 µs +3.65%
DUP4_50 27.8 µs 26.8 µs +3.54%
DUP5_50 27.7 µs 26.8 µs +3.4%
DUP6_50 27.8 µs 26.7 µs +4.09%
DUP7_50 27.9 µs 26.9 µs +3.85%
DUP8_50 27.8 µs 26.9 µs +3.09%
DUP9_50 27.8 µs 26.8 µs +3.51%
PUSH12_50 22.6 µs 21.6 µs +4.66%
PUSH13_50 22.8 µs 21.7 µs +5.05%
PUSH14_50 22.8 µs 21.8 µs +4.62%
PUSH15_50 22.8 µs 21.7 µs +4.77%
PUSH16_50 22.7 µs 21.8 µs +4.12%
PUSH17_50 22.9 µs 21.8 µs +4.74%
PUSH18_50 22.7 µs 21.9 µs +3.49%
... ... ... ... ...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

@rakita
Copy link
Member

rakita commented May 28, 2025

Appreciate the effort! Lets do this more holistically.

Change this field

pub limit_contract_code_size: Option<usize>,
and add fn max_code_size(&self) -> usize to CfgEnv that would give us a runtime limit depending on SpecId, or if concrete value is set

@jgresham
Copy link
Contributor Author

Appreciate the effort! Lets do this more holistically.

Change this field

pub limit_contract_code_size: Option<usize>,

and add fn max_code_size(&self) -> usize to CfgEnv that would give us a runtime limit depending on SpecId, or if concrete value is set

will do! any and all feedback and suggestions is much appreciated

@jgresham
Copy link
Contributor Author

jgresham commented May 29, 2025

Appreciate the effort! Lets do this more holistically.

Change this field

pub limit_contract_code_size: Option<usize>,

and add fn max_code_size(&self) -> usize to CfgEnv that would give us a runtime limit depending on SpecId, or if concrete value is set

Added specId conditional to max_code_size, but wasn't sure what the change to pub limit_contract_code_size: Option<usize> should be.

Also, I'm planning to work on the gas metering and additional code warmed (account code loaded) state next. I can tag you when I think this PR (and the EIP is more finalized) if you'd like, otherwise any reviews in the meantime are appreciated.

One question: How should I think about backwards compatibility? For example, if L1 and op-stack adopts this EIP, would the plan be to remove any eip-170 code (eip7907 replaces it)?

Co-authored-by: rakita <rakita@users.noreply.github.com>
@@ -290,6 +290,53 @@ impl<T> StateLoad<T> {
}
}

/// Duplicates StateLoad, adding code cold status.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rakita I needed to return is_code_cold from account load calls to use it for gas calculations. Is there a better way to extend StateLoad without duplicating the rest of the code here? StateLoad is widely used and was hesitant to change it

Copy link
Member

Choose a reason for hiding this comment

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

Looks reasonable,

let block_and_txn_gas_limit_cap = gas_limit.unwrap_or(eip7825::TX_GAS_LIMIT_CAP);
cfg.tx_gas_limit_cap = Some(block_and_txn_gas_limit_cap);

let ctx = Context::mainnet().with_db(CacheDB::<EmptyDB>::default()).with_cfg(cfg);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rakita I was thinking to add more tests to check the journal/db if code is warmed properly and txns with multiple CALL and CREATE. Should this be done in this repo and if so are there any good examples of this? or should these scenarios be covered in the EEST tests?

warm_cold_cost(is_cold)
} else if spec_id.is_enabled_in(SpecId::TANGERINE) {
700
} else {
20
};
if spec_id.is_enabled_in(SpecId::OSAKA) && is_code_cold {
let large_contract_cost = large_contract_code_size_cost(len);
base_gas += large_contract_cost;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Saw code around this doing safe adds, but was getting an error

@rakita
Copy link
Member

rakita commented Jun 9, 2025

@jgresham we had ian nternal discussion and are probably changing it to just increase of contract limit increase. Will take this over to push it over the line.

@rakita rakita changed the base branch from main to fusaka/devnet2 June 10, 2025 07:22
@rakita rakita changed the base branch from fusaka/devnet2 to main June 10, 2025 07:22
@rakita
Copy link
Member

rakita commented Jun 11, 2025

Closing in favour of #2605 . Awesome work @jgresham!

@rakita rakita closed this Jun 11, 2025
@jgresham
Copy link
Contributor Author

Closing in favour of #2605 . Awesome work @jgresham!

awesome, thanks!

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.

2 participants