EIP-7623

[daniellehrner]

PR description

Implements EIP-7623 (calldata cost increase)

https://eips.ethereum.org/EIPS/eip-7623

EELS:
https://github.com/ethereum/execution-specs/blob/devnets/prague/5/src/ethereum/prague/fork.py

EEST:
Nearly all execution-spec-tests are passing except for some that involve 7702, which might be fixed by #8118

Fixed Issue(s)

fixes #7994

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[siladu]

I think there's a bug in when the floor gets applied for tx processing, see comments.

I like the way you structured the refactor 👍

Perhaps not a functional issue, but I'm a little confused by the Long boundary checks:

• Their use appears inconsistent which makes me wonder if one or more of them were left in by accident?
• I understand checking MAX_VALUE before an add (although doesn't clampedAdd already handle this?) but I don't understand why we return early if the intermediate cost == MIN_VALUE. In the intermediate calculations, won't the subsequent addition usually mean cost > MIN_VALUE?

[siladu]

nit: baselineGas isn't the most descriptive name but this is a hard one to name. IMO we should try to match the spec with our names (which is still in flux so good luck 😆)

cc. @jflo as just noticed you had the opposite opinion 😅 #7997 (comment)

[siladu]

Why do we do check MIN_VALUE and return here, potentially bypassing adding more to the cost below?

To me, this doesn't appear to be equivalent behaviour to https://github.com/hyperledger/besu/blob/2aadbfcb0a6c22734ef3ae8cc2ae3823512c5419/evm/src/main/java/org/hyperledger/besu/evm/gascalculator/FrontierGasCalculator.java

[siladu]

@daniellehrner this question is still outstanding but I don't think it should block the PR

[siladu]

Do we need to do anything different to support EthEstimateGas, etc?

[macfarla]

think it looks good. prob needs a changelog entry