Add EIP: AUTHCREATE opcode

EIPS/eip-7697.md

@@ -0,0 +1,146 @@
+---
+eip: 7697
+title: AUTHCREATE opcode
+description: Authenticate and set code for EOA
+author: Xin Tian (@txgyy), Elim Poon (@yaonam)
+discussions-to: https://ethereum-magicians.org/t/eip-7697-authcreate-opcode/19780
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-04-23
+requires: 155
+---
+
+## Abstract
+
+The EIP introduces an EVM instruction `AUTHCREATE`. It allows an externally owned account (EOA) to migrate to a smart
+contract.
+
+Inspiration comes from [EIP-3074](./eip-3074.md) and [EIP-5003](./eip-5003.md):
+
+- ([EIP-3074](./eip-3074.md)) + [EIP-5003](./eip-5003.md) = (`AUTH` + `AUTHCALL`) + `AUTHUSURP`
+- [EIP-7697](./eip-7697.md) = `AUTHCREATE` = `AUTH` + `AUTHUSURP`
+
+## Motivation
+
+If Ethereum's goal is `FULL AA`, it should not permit proposals that merely enhance EOA for short-term benefits.
+
+| Feature                                                        | [EIP-7697](./eip-7697.md)    | [EIP-3074](./eip-3074.md) | [EIP-5003](./eip-5003.md)    | [EIP-7377](./eip-7377.md)    |
+|----------------------------------------------------------------|------------------------------|---------------------------|------------------------------|------------------------------|
+| Help EOA to upgrade to CA                                      | ✅ new Opcode                 | ❎                         | ✅ new Opcode and need `AUTH` | ✅ new tx type                |
+| Deploy the same address(not only AA) [ERC-2470](./eip-2470.md) | ✅ new Opcode                 | ❎                         | ✅ new Opcode and need `AUTH` | ✅ new tx type                |
+| Support `secp256r1` or more                                    | ✅ through yParity            | ✅                         | ❎                            | ❎ only support `secp256k1`   |
+| Reuse existing wallet infrastructure                           | ✅ need to adapt the contract | ❎                         | ✅ need to adapt the contract | ❎ need to adapt the node rpc |
+| Integrate easily with [ERC-4337](./eip-4337.md) and RIP-7560   | ✅ support factory contract   | ❎                         | ❎                            | ❎                            |
+| Grant temporary CA capabilities to EOA                         | ❎                            | ✅ The greatest advantage  | ❎                            | ❎                            |
+
+## Specification
+
+### Constants
+
+| Constant          | Value  |
+|-------------------|--------|
+| `AuthCreateMagic` | `0x04` |
+| `AUTHCREATE`      | `0xf6` |
+
+`AuthCreateMagic` is used for [EIP-7697](./eip-7697.md) signatures to prevent signature collisions with other signing
+formats.
+
+#### Input
+
+##### Stack
+
+| Stack     | Value       |
+|-----------|-------------|
+| `top - 0` | `endowment` |
+| `top - 1` | `offset`    |
+| `top - 2` | `size`      |
+
+##### Memory
+
+The two stack arguments (`offset` and `size`) describe a range of memory. The format of the contents of that range is:
+
+- `memory[offset    : offset+1 ]` - `yParity`
+    - 0-1: secp256k1
+    - 4-5: secp256r1
+- `memory[offset+1  : offset+33]` - `r`
+- `memory[offset+33 : offset+65]` - `s`
+- `memory[offset+65 :          ]` - `creationCode`
+
+#### Output
+
+##### Stack
+
+| Stack     | Value          |
+|-----------|----------------|
+| `top - 0` | `contractAddr` |
+
+##### Memory
+
+Memory is not modified by this instruction.
+
+#### Behavior
+
+The arguments (`yParity`, `r`, `s`) are interpreted as an ECDSA signature on the secp256k1(or secp256r1) curve over the
+message `keccak256(AuthCreateMagic || chainId || creationCodeHash)`, where:
+
+- `chainId` is the current chain's [EIP-155](./eip-155.md) unique identifier padded to 32 bytes.
+- `creationCode` is the creation code set for the EOA.
+
+#### Gas Cost
+
+_todo: detail_
+
+`Authenticate`:
+
+- secp256k1: 3000
+- secp256r1: 3450
+
+`Set Code`:
+
+- create2: 32000 + dynamicGas
+
+## Rationale
+
+Authenticate and set code for EOA
+
+### Authenticate
+
+Users need to prove their ownership of an address using a specified signature algorithm to set the Code under that
+address.
+The signature content includes `AuthCreateMagic`, `chainId`, and `creationCodeHash`.
+
+The inclusion of `nonce` in the signature message was considered, but addresses generated by `secp256r1` do not have
+a `nonce`.
+
+Two signature algorithms can be supported (with the capability to easily expand to more):
+
+#### secp256k1
+
+Use the `secp256k1` algorithm when `yParity` is equal to 0 or 1.
+
+#### secp256r1
+
+Use the `secp256r1` algorithm when `yParity` is equal to 4 or 5. It depends on [EIP-7212](./eip-7212.md).
+
+### Set Code
+
+1. After the signature verification passes, first set the `nonce` to 0.
+2. The subsequent operations are the same as [Create2](./eip-1014.md).
+3. Restore to the original `nonce` and increment it by 1.
+
+## Backwards Compatibility
+
+Determine the signature type through the first byte, allowing for support of additional signature algorithms.
+
+## Security Considerations
+
+1. When an `EOA` upgrades to a `CA`, the `EOA` can no longer initiate transactions,
+   and if the contract checks `tx.origin`, it will cause the transaction to fail.
+2. Upgrading to a non-functional or malicious contract can result in the loss of user assets.
+3. It is possible to upgrade to a contract in a single transaction and perform `SELFDESTRUCT`,
+   but resetting the `nonce` to 0 poses a risk of transaction replay.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).