feat(benchmarks): add runtime delegated EIP-7702 benchmarks#2598
feat(benchmarks): add runtime delegated EIP-7702 benchmarks#2598jochem-brouwer wants to merge 2 commits intoethereum:forks/amsterdamfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## forks/amsterdam #2598 +/- ##
================================================
Coverage 86.24% 86.24%
================================================
Files 599 599
Lines 36984 36984
Branches 3795 3795
================================================
Hits 31895 31895
Misses 4525 4525
Partials 564 564
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
a84d4a0 to
751ea05
Compare
|
I am wondering if we could merge this with only the NO_CACHE variant for SLOAD and SSTORE to see results faster. What do you think, @jochem-brouwer ? Will this save us significant time? |
|
No cache variants added, open for review! I checked locally against a client and it looks fine. |
misilva73
left a comment
There was a problem hiding this comment.
After a first-level look at the code, I cannot find any issues. However, I do have two comments:
- A big part of the code in
test_sload_bloatedandtest_sstore_bloatedis duplicated (Same setup, same gas-loop to build transactions and same benchmark_test() call). I wonder is logic should be moved to a helper function to help with code maintainability. This is a nitpick and should definitely not block merging this. - The EIP-7702 delegation trick is quire clever 👏 However, I worry it could lead to different measurements. From a specification perspective, it shouldn't - every SLOAD/SSTORE should execute against the EOA's storage trie exactly the same way it would for a normal contract. The trie structure and lookup path should be identical regardless of how the code got there. However, individual client implementations could have different code paths or caching behavior for delegated accounts vs. native contracts. Can we double-check with clients that this is not the case?
|
@misilva73, (2) this is a good point and also a good exercise, I will do this today. I would be surprised if the code paths diverge here, I assume that most clients have simply swapped out the runtime code for a EIP-7702 delegated account and keep the account code (the 0xef0100..) (where EXTCODECOPY refers to). This is a good sanity check. I will check with the 5 clients to see if there is a mechanism which might cause problems for this approach. Regarding the duplication (1): you are right, I should refactor this. |
ea1d476 to
fab7ba6
Compare
|
Converted to draft, figuring out what goes wrong here. I have a local instance of Nethermind running to test, this is the error:
|
🗒️ Description
This adds benchmarks plus a template for future use. On perf-devnet-3, there are (so far) three EOAs being targeted with their bytecode being delegated to:
0x5f541515600b5760015f555b5f54805b818155600101906001019061ffff5a11600f575f55This (22866e0):
We now use the fact that we have pkey of these accounts to overwrite runtime bytecode via EIP-7702 to target these for our needs. The bloatnet/perf-devnet-3 accounts are thus bloated with a range from 1-N (1/10/20Gb currently) which we can now target for storage related benchmarks.
So far this PR accounts for the NO-CACHE variant with existing/non-existing keys in the case we run the setup bytecode as provided and then start the attack block.
To add:
Draft, but want to finish this ASAP as we are super interested in the benchmark results.
🔗 Related Issues or PRs
N/A.
✅ Checklist
toxchecks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:uvx tox -e statictype(scope):.mkdocs servelocally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.@ported_frommarker.Cute Animal Picture