EIP-7697：AUTHCREATE opcode

EIPs EIPs core
, ,
1

EIP: Add EIP: AUTHCREATE opcode by txgyy · Pull Request #8493 · ethereum/EIPs · GitHub

Go-Ethereum: Comparing ethereum:master...txgyy:EIP-7697 · ethereum/go-ethereum · GitHub

AA Factory: Comparing eth-infinitism:develop...txgyy:AA-EIP-7697 · eth-infinitism/account-abstraction · GitHub

Abstract

The EIP introduces an EVM instruction AUTHCREATE. It allows a deterministic addresses to migrate to a smart contract.

Inspiration comes from EIP-3074 and EIP-5003:

Motivation

For a long time, the EVM ecosystem has been plagued by two issues:

  1. Difficulty ensuring consistency across addresses on multiple chains, even when using the same bytecode.
  2. EOAs lack contract capabilities, preventing the realization of account abstraction.
    1. Authentication - any form of proving one’s identity.
    2. Authorization - any access policy.
    3. Replay protection - transaction ordering decoupled from replay protection.
    4. Gas payment - gas payment decoupled from the account itself.
    5. Execution - any execution logic.
Feature EIP-7697 EIP-3074 EIP-5003 EIP-7377
Deploy the same address ERC-2470 :white_check_mark: :negative_squared_cross_mark: :white_check_mark: need 3 opcodes :white_check_mark: only EOA
Help EOA to upgrade to CA :white_check_mark: :negative_squared_cross_mark: :white_check_mark: need 3 opcodes :white_check_mark:
Support secp256r1 or more :white_check_mark: :white_check_mark: :negative_squared_cross_mark: :negative_squared_cross_mark:
Reuse existing wallet infrastructure :white_check_mark: adapt the contract :negative_squared_cross_mark: :white_check_mark: adapt the contract :negative_squared_cross_mark: adapt the node rpc
Integrate easily with ERC-4337 and RIP-7560 :white_check_mark: support factory contract :negative_squared_cross_mark: :negative_squared_cross_mark: :negative_squared_cross_mark:
Grant temporary CA capabilities to EOA :negative_squared_cross_mark: :white_check_mark: :negative_squared_cross_mark: :negative_squared_cross_mark:
2 Likes
2

This seems nearly identical to EIP-5003 AUTHUSURP. Can you please define the difference of your proposal?

3

Yes, AUTH_CREATE = AUTH + AUTHUSURP. If Ethereum’s goal is “Full AA,” it should not introduce new OpCodes that merely enhance EOAs.

4

Moreover, AUTH_CREATE integrates very easily with ERC-4337 and RIP-7560.

5

Yes, AUTH_CREATE = AUTH + AUTHUSURP. If Ethereum’s goal is “Full AA,” it should not introduce new OpCodes that merely enhance EOAs.

7

Building on a bit of what @txgyy was saying…

(3074) + 5003 == (AUTH + AUTHCALL) + AUTHUSURP
AUTHCREATE == AUTH + AUTHUSURP

AUTHCALL is undesirable for AA endgame as it is only used for fully featured invokers where the account remains an EOA. These invokers will not be reused when the eoa migrates via 5003/AUTHUSURP, leading to wasted effort and distraction. I think this is the strongest reasoning for combining 3074/5003 into something like AUTHCREATE.

1 Like
9

Based on the name I was expecting AUTHCREATE to be like AUTHCALL but performing sudo CREATE instead of sudo CALL.

1 Like
10

Yes, AUTHCREATE is ‘auth + create’. But after you CREATE, it becomes like a contract.

1 Like
11

It seems to differ from create in an important way, by usurping.

1 Like