Skip to content
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

Pectra devnet 5: 7702 changes #8118

Merged
merged 10 commits into from
Jan 16, 2025

Conversation

daniellehrner
Copy link
Contributor

PR description

EIP-7702 changes required for Pectra devnet-5

Fixed Issue(s)

fixes #7948

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 siladu mentioned this pull request Jan 16, 2025
8 tasks
Copy link
Contributor

@siladu siladu left a comment

Choose a reason for hiding this comment

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

Approved with some minor comments which can be picked up in the next PR.

General point: throughout the code and specs we appear to use "delegated" vs "authorized" interchangeable (and "delegation" vs "authorization").

One point where this is obvious is in EVMWorldUpdater:
public DelegatedCodeService authorizedCodeService() { return delegatedCodeService; }

Think we should pick one or is there a semantic difference depending on usage?
Related, could there be confusion with the existing "DELEGATECALL"?

}

return getDelegatedAccount().map(Account::getUnprocessedCode).orElse(Bytes.EMPTY);
return Optional.of(maybeDelegatedAccount.get().getCode());
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
return Optional.of(maybeDelegatedAccount.get().getCode());
return maybeDelegatedAccount.map(AccountState::getCode);

Comment on lines +45 to +48
public static boolean hasDelegatedCode(final Bytes code) {
return code != null
&& code.size() == DELEGATED_CODE_SIZE
&& code.slice(0, DELEGATED_CODE_PREFIX.size()).equals(DELEGATED_CODE_PREFIX);
Copy link
Contributor

Choose a reason for hiding this comment

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

Might be good to have a unit test for this.

@@ -114,4 +103,14 @@ public OperationResult execute(final MessageFrame frame, final EVM evm) {
return new OperationResult(cost(true), ExceptionalHaltReason.TOO_MANY_STACK_ITEMS);
}
}

private static Bytes getCode(final Account account) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
private static Bytes getCode(final Account account) {
private Bytes getCode(final Account account) {

@@ -115,4 +104,12 @@ public OperationResult execute(final MessageFrame frame, final EVM evm) {
return new OperationResult(cost(true), ExceptionalHaltReason.TOO_MANY_STACK_ITEMS);
}
}

private static Bytes getCode(final Account account) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
private static Bytes getCode(final Account account) {
private Bytes getCode(final Account account) {

@@ -118,4 +108,14 @@ public OperationResult execute(final MessageFrame frame, final EVM evm) {

return new OperationResult(cost, null);
}

private static Bytes getCode(final Account account) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
private static Bytes getCode(final Account account) {
private Bytes getCode(final Account account) {

* @param account the account which needs to be retrieved
* @return the code
*/
protected static Code getCode(final EVM evm, final Account account) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
protected static Code getCode(final EVM evm, final Account account) {
protected Code getCode(final EVM evm, final Account account) {

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm surprised to see ExtCall in here since the EIP doesn't mention it is impacted?

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like it's a future EIP https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7069.md
Has there been any discussion about how this EIP should interact with 7702?

@siladu siladu enabled auto-merge (squash) January 16, 2025 06:05
@siladu siladu merged commit b5fdcc0 into hyperledger:main Jan 16, 2025
43 checks passed
@daniellehrner daniellehrner deleted the feat/issue-7948/7702-devnet-5 branch January 21, 2025 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pectra-Devnet-5: 7702: Remove delegation behavior of EXTCODE*
3 participants