From 60e90db2c04684a1268ca94c93c05ae7fc8d8f4d Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 20 Oct 2022 16:17:02 +0200 Subject: [PATCH 1/6] first draft --- EIPS/eip-XXXX.md | 70 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 EIPS/eip-XXXX.md diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md new file mode 100644 index 00000000000000..6fedda44daa303 --- /dev/null +++ b/EIPS/eip-XXXX.md @@ -0,0 +1,70 @@ +--- +eip: todo +title: Account abstraction through delegate transaction +description: This EIP adds a new transaction type that allows a EOAs to execute arbitrary code through delegation +author: Hadrien Croubois (@Amxx) +discussions-to: todo +status: Draft +type: Standards Track +category: Core +created: 2022-10-20 +requires: 7, 155, 1559, 2718, 2929, 2930 +--- + +## Abstract + +This EIP adds a new transaction type that allows EOAs to execute arbitrary code using a delegate-call-like mechanism. + +## Motivation + +Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) proposes another approach that favors existing EOAs but comes with replay risks. + +This EIP proposes a simpler approach that addresses some of the objectives of account abstraction for EOAs with minimal change over the EVM. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using [EIP-7](https://eips.ethereum.org/EIPS/eip-7)), EOAs will be able to have more control over what operations they want to execute. + +Performing a delegate call to a multicall contract (such as the one deployed to `0xcA11bde05977b3631167028862bE2a173976CA11`), EOAs would be able to batch multiple transactions into a single one, while being the `msg.sender` of all the sub calls. Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes emitting events, using storage under the EOA's account, or even deploying contracts using `create2`. + +This EIP doesn't aim to replace other account abstraction proposals. It hopes to be an easy-to-implement alternative that would significantly improve the user experience of EOA owners in the near future. + +## Specification +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +### Parameters +- `FORK_BLKNUM` = `TBD` +- `TX_TYPE` = TBD, > 0x02 (EIP-1559) + +As of `FORK_BLOCK_NUMBER`, a new [EIP-2718](./eip-2718.md) transaction is introduced with `TransactionType` = `TX_TYPE(TBD)`. + +The intrinsic cost of the new transaction is inherited from [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. + +The [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) `TransactionPayload` for this transaction is + +``` +rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]) +``` + +The definitions of all fields share the same meaning with [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). Note the absence of `amount` field in this transaction! + +The `signature_y_parity, signature_r, signature_s` elements of this transaction represent a secp256k1 signature over `keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list]))`. + +The [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`. + +The execution of this new transaction type is equivalent to the delegate call mechanism introduced in [EIP-7](https://eips.ethereum.org/EIPS/eip-7), but performed by an EOA (the transaction sender). This implies that the code present at `destination`, if any, should be executed in the context of the sender. As a consequence, such a transaction can set and read storage under the EOA. It can also emit an event from the EOA. + +## Rationale + +EOAs are the most widely used type of wallet. + +This EIP would drastically expand the ability of EOAs to interact with smart contracts by using the pre-existing and well-understood delegation mechanism introduced in [EIP-7](https://eips.ethereum.org/EIPS/eip-7) and without adding new complexity to the EVM. + +## Backwards Compatibility + +No known backward compatibility issues thanks to the transaction envelope ([EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)) + +## Security Considerations + +The nonce mechanism, already used in other transaction types, prevents replay attacks. This makes this approach safer, but also less powerful than [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074). + +Contracts being called through this mechanism can execute any operation on behalf of the signer. Signers should be extremely careful signing this transaction (just like any other transaction). + +## Copyright +Copyright and related rights waived via [CC0](../LICENSE.md). From d813332dcbd78f46480ade4da35f6f6d3559f6db Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 20 Oct 2022 16:18:35 +0200 Subject: [PATCH 2/6] rename document --- EIPS/{eip-XXXX.md => eip-5806.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-XXXX.md => eip-5806.md} (99%) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-5806.md similarity index 99% rename from EIPS/eip-XXXX.md rename to EIPS/eip-5806.md index 6fedda44daa303..61c528e17b1a47 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-5806.md @@ -1,5 +1,5 @@ --- -eip: todo +eip: 5806 title: Account abstraction through delegate transaction description: This EIP adds a new transaction type that allows a EOAs to execute arbitrary code through delegation author: Hadrien Croubois (@Amxx) From 1a0c1b500d693be603f643745449e15e966a99d1 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 20 Oct 2022 16:21:40 +0200 Subject: [PATCH 3/6] relative links --- EIPS/eip-5806.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-5806.md b/EIPS/eip-5806.md index 61c528e17b1a47..62683fe2871d3f 100644 --- a/EIPS/eip-5806.md +++ b/EIPS/eip-5806.md @@ -17,9 +17,9 @@ This EIP adds a new transaction type that allows EOAs to execute arbitrary code ## Motivation -Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) proposes another approach that favors existing EOAs but comes with replay risks. +Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [EIP-4337](./eip-4337.md) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. [EIP-3074](./eip-3074.md) proposes another approach that favors existing EOAs but comes with replay risks. -This EIP proposes a simpler approach that addresses some of the objectives of account abstraction for EOAs with minimal change over the EVM. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using [EIP-7](https://eips.ethereum.org/EIPS/eip-7)), EOAs will be able to have more control over what operations they want to execute. +This EIP proposes a simpler approach that addresses some of the objectives of account abstraction for EOAs with minimal change over the EVM. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using [EIP-7](./eip-7.md)), EOAs will be able to have more control over what operations they want to execute. Performing a delegate call to a multicall contract (such as the one deployed to `0xcA11bde05977b3631167028862bE2a173976CA11`), EOAs would be able to batch multiple transactions into a single one, while being the `msg.sender` of all the sub calls. Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes emitting events, using storage under the EOA's account, or even deploying contracts using `create2`. @@ -34,35 +34,35 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL As of `FORK_BLOCK_NUMBER`, a new [EIP-2718](./eip-2718.md) transaction is introduced with `TransactionType` = `TX_TYPE(TBD)`. -The intrinsic cost of the new transaction is inherited from [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. +The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. -The [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) `TransactionPayload` for this transaction is +The [EIP-2718](./eip-2718.md) `TransactionPayload` for this transaction is ``` rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]) ``` -The definitions of all fields share the same meaning with [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). Note the absence of `amount` field in this transaction! +The definitions of all fields share the same meaning with [EIP-1559](./eip-1559.md). Note the absence of `amount` field in this transaction! The `signature_y_parity, signature_r, signature_s` elements of this transaction represent a secp256k1 signature over `keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list]))`. -The [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`. +The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`. -The execution of this new transaction type is equivalent to the delegate call mechanism introduced in [EIP-7](https://eips.ethereum.org/EIPS/eip-7), but performed by an EOA (the transaction sender). This implies that the code present at `destination`, if any, should be executed in the context of the sender. As a consequence, such a transaction can set and read storage under the EOA. It can also emit an event from the EOA. +The execution of this new transaction type is equivalent to the delegate call mechanism introduced in [EIP-7](./eip-7.md), but performed by an EOA (the transaction sender). This implies that the code present at `destination`, if any, should be executed in the context of the sender. As a consequence, such a transaction can set and read storage under the EOA. It can also emit an event from the EOA. ## Rationale EOAs are the most widely used type of wallet. -This EIP would drastically expand the ability of EOAs to interact with smart contracts by using the pre-existing and well-understood delegation mechanism introduced in [EIP-7](https://eips.ethereum.org/EIPS/eip-7) and without adding new complexity to the EVM. +This EIP would drastically expand the ability of EOAs to interact with smart contracts by using the pre-existing and well-understood delegation mechanism introduced in [EIP-7](./eip-7.md) and without adding new complexity to the EVM. ## Backwards Compatibility -No known backward compatibility issues thanks to the transaction envelope ([EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)) +No known backward compatibility issues thanks to the transaction envelope ([EIP-2718](./eip-2718.md)) ## Security Considerations -The nonce mechanism, already used in other transaction types, prevents replay attacks. This makes this approach safer, but also less powerful than [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074). +The nonce mechanism, already used in other transaction types, prevents replay attacks. This makes this approach safer, but also less powerful than [EIP-3074](./eip-3074.md). Contracts being called through this mechanism can execute any operation on behalf of the signer. Signers should be extremely careful signing this transaction (just like any other transaction). From 778f2c2dd6de2b74f170f38da24ee153211fc3a5 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 20 Oct 2022 16:26:35 +0200 Subject: [PATCH 4/6] fix EIP Walidator checks --- EIPS/eip-5806.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-5806.md b/EIPS/eip-5806.md index 62683fe2871d3f..3b5aa58907322e 100644 --- a/EIPS/eip-5806.md +++ b/EIPS/eip-5806.md @@ -1,9 +1,9 @@ --- eip: 5806 -title: Account abstraction through delegate transaction +title: Delegate transaction description: This EIP adds a new transaction type that allows a EOAs to execute arbitrary code through delegation author: Hadrien Croubois (@Amxx) -discussions-to: todo +discussions-to: https://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409 status: Draft type: Standards Track category: Core @@ -30,7 +30,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL ### Parameters - `FORK_BLKNUM` = `TBD` -- `TX_TYPE` = TBD, > 0x02 (EIP-1559) +- `TX_TYPE` = TBD, > 0x02 ([EIP-1559](./eip-1559.md)) As of `FORK_BLOCK_NUMBER`, a new [EIP-2718](./eip-2718.md) transaction is introduced with `TransactionType` = `TX_TYPE(TBD)`. From bf7cb8c44a431cf9d5083128617cd3f32af12b5e Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Fri, 21 Oct 2022 10:50:17 +0200 Subject: [PATCH 5/6] Apply suggestions from code review Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-5806.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5806.md b/EIPS/eip-5806.md index 3b5aa58907322e..6f474ecaf699b4 100644 --- a/EIPS/eip-5806.md +++ b/EIPS/eip-5806.md @@ -1,7 +1,7 @@ --- eip: 5806 title: Delegate transaction -description: This EIP adds a new transaction type that allows a EOAs to execute arbitrary code through delegation +description: Adds a new transaction type that allows a EOAs to execute arbitrary code through delegation author: Hadrien Croubois (@Amxx) discussions-to: https://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409 status: Draft From 17862ee410fcb0333729a4ee97b9c9156a72dd59 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Fri, 21 Oct 2022 10:55:00 +0200 Subject: [PATCH 6/6] Remove unecessary requires --- EIPS/eip-5806.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5806.md b/EIPS/eip-5806.md index 6f474ecaf699b4..4f2fd5133bbd4e 100644 --- a/EIPS/eip-5806.md +++ b/EIPS/eip-5806.md @@ -8,7 +8,7 @@ status: Draft type: Standards Track category: Core created: 2022-10-20 -requires: 7, 155, 1559, 2718, 2929, 2930 +requires: 2718, 2930 --- ## Abstract