From 01811a222322645434015877fe3228e53b930295 Mon Sep 17 00:00:00 2001
From: "yukino.xin" <yukino.xin@foxmail.com>
Date: Tue, 23 Apr 2024 11:52:23 +0800
Subject: [PATCH] EIP-7687: AuthCreate

---
 EIPS/eip-7687.md | 144 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 144 insertions(+)
 create mode 100644 EIPS/eip-7687.md

diff --git a/EIPS/eip-7687.md b/EIPS/eip-7687.md
new file mode 100644
index 00000000000000..7fe0acdeeadb4e
--- /dev/null
+++ b/EIPS/eip-7687.md
@@ -0,0 +1,144 @@
+---
+eip: 7687
+title: AUTH_CREATE opcode
+description: Authenticate and set code for EOA
+author: Xin Tian (@txgyy), Elim Poon (@yaonam)
+discussions-to: https://ethereum-magicians.org/t/integrates-with-erc4337-and-rip7560-auth-create-opcode/19780
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-04-23
+requires: 155
+---
+
+## Abstract
+
+This EIP introduces an EVM instruction `AUTH_CREATE`. It allows an externally owned account (EOA) to migrate to a smart contract.
+
+Perfectly integrates with [ERC-4337](./eip-4337.md) and RIP-7560.
+
+AuthCreate = Ecrecover(secp256k1,secp256r1) + Create2
+
+## Motivation
+
+thank [EIP-3074](./eip-3074.md), although I do not agree with it:
+
+if Ethereum's goal is 'FULL-AA', it should not permit proposals that merely enhance EOA for short-term benefits.
+
+This proposal mainly aims to address three issues:
+
+1. The cost for EOA users to migrate to AA is too high; this proposal helps EOA accounts directly upgrade to AA.
+2. In a multi-chain environment, it is difficult for CA to ensure consistent addresses across different chains; this
+   proposal directly uses EOA addresses as CA addresses.
+3. Once Ethereum supports [EIP-7212](./eip-7212.md), it will enable users to upgrade to AA using methods such as
+   passkeys.
+
+
+## Specification
+
+### Constants
+
+| Constant          | Value  |
+|-------------------|--------|
+| `AuthCreateMagic` | `0x04` |
+| `AUTH_CREATE`     | `0xf6` |
+
+`AuthCreateMagic` is used for [EIP-7687](./eip-7687.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
+
+**Authenticate**:
+
+- secp256k1: 3000
+- secp256r1: 3450
+
+**create** = create2: 32000 + dynamicGas
+
+todo detail
+
+## 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 `MagicCode`, `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 are 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](./eip-7212.md) algorithm when `yParity` is equal to 4 or 5.
+
+### 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).