You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: EIPS/eip-5806.md
+15-9
Original file line number
Diff line number
Diff line change
@@ -17,19 +17,21 @@ This EIP adds a new transaction type that allows EOAs to execute arbitrary code
17
17
18
18
## Motivation
19
19
20
-
EOA are the most widely used of account, yet their ability to perform operation is limited to deploying contracts and sending call transaction. It is currently not possible for an EOA to execute arbitrary code, which greatly limits the interractions users can have with he blockchain. Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [ERC-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.
20
+
EOA are the most widely used type of account, yet their ability to perform operations is limited to deploying contracts and sending "call" transactions. It is currently not possible for an EOA to execute arbitrary code, which greatly limits the interactions users can have with the blockchain. Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [ERC-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 option to extend the ability of EOA to execute batched or conditional calls, but remains limited to calls operation (with no access to opcodes such as create2).
21
21
22
-
While smart contract wallets have a lot to offer in terms of UX, it is unlikelly that all users will migrate any time soon because of the associated cost and the fact that some EOA have custody of non-transferable assets.
22
+
While smart contract wallets have a lot to offer in terms of UX, it is unlikely that all users will migrate any time soon because of the associated cost and the fact that some EOAs have custody of non-transferable assets.
23
23
24
-
This EIP proposes an approach to allow EOA executing arbitrary code, with minimal change over the EVM, and using the same security model users are used to. 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. This proposal goal is NOT to provide an account abstraction primitive, though it would enable some usescases that fall in the scope of account abstraction.
24
+
This EIP proposes an approach to allow the execution of arbitrary code by EOAs, with minimal change over the EVM, and using the same security model users are used to. 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. This proposal's goal is NOT to provide an account abstraction primitive.
25
25
26
-
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 deploying contracts using `create2`, emitting events or using storage under the EOA's account.
26
+
By 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 (being the `msg.sender` of all the sub calls). This would provide a better UX for users that want to interact with protocols (no need for multiple transactions, with variable gas prices and 21k gas overhead) and increase the security of such interactions (by avoiding unsafe token approvals being exploited between an `approval` and the following `transferFrom`).
27
+
28
+
Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes deploying contracts using `create2`, emitting events, or using storage under the EOA's account.
27
29
28
30
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.
29
31
30
32
## Specification
31
33
32
-
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.
34
+
The keywords “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.
33
35
34
36
### Parameters
35
37
@@ -48,11 +50,11 @@ rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, dest
48
50
49
51
The definitions of all fields share the same meaning with [EIP-1559](./eip-1559.md). Note the absence of `amount` field in this transaction!
50
52
51
-
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]))`.
53
+
The `signature_y_parity, signature_r, signature_s` elements of this transaction represent a secp256k1 signature over `keccak256(TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list]))`.
52
54
53
55
The [EIP-2718](./eip-2718.md)`ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`.
54
56
55
-
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.
57
+
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 or use `Create2` with the address of the EOA as the creator.
56
58
57
59
## Rationale
58
60
@@ -68,9 +70,13 @@ Due to the inclusion logic and the gas cost being similar to type 2 transactions
68
70
69
71
## Security Considerations
70
72
71
-
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).
73
+
The nonce mechanism, already used in other transaction types, prevents replay attacks. Similar to existing transaction types, a delegate transaction can be cancelled by replacing it with a dummy transaction that pays more fees.
74
+
75
+
Since the object signed by the wallet is a transaction and not a signature that could potentially be processed in many ways (as is the case for [EIP-3074](./eip-3074.md)), the risks associated with the miss-use of the signature are reduced. A wallet could simulate the execution of this delegate transaction and provide good guarantees that the operation that the user signs won't be manipulated.
76
+
77
+
Contracts being called through this mechanism can execute any operation on behalf of the signer. As with other transaction types, signers should be extremely careful when signing a delegate transaction.
72
78
73
-
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).
79
+
Because an EOA may perform delegate transactions to multiple contracts in its lifetime, there are risks associated with the storage under the EOA. Multiple contracts could have conflicting views of storage and tamper with one another. This would be potentially dangerous if wallets perform delegate transactions to arbitrary contracts that rely on existing storage. Wallets, on the other hand could hide this transaction type behind abstract interfaces for batch transactions (or others) that use standard contracts as targets (such as the one at `0xcA11bde05977b3631167028862bE2a173976CA11`). In any case, storage conflict should be detectable through simulation of the delegate transaction and could be resolved using a delegate transaction.
Copy file name to clipboardexpand all lines: EIPS/eip-6916.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -91,7 +91,7 @@ Note that depending on the client architecture, it may not be feasible to fully
91
91
92
92
Ephemeral testnets with deterministic parameters provide a sustainable alternative to traditional testnets, with the same infrastructure. At each reset, the validator set is cleared, faucets are filled again and the database is kept small.
93
93
94
-
Upon reset the whole state is purged, which, on the one hand keeps the network small and easy to bootstrap but introduces problems for testing longer term / advanced applications. However, basic contract infrastracture can be automatically deployed after each reset by any user. Generally, using the network is recommended for short term testing, deploying `Hello World` kinds of contracts that don't need to stay forever on a long term testnet. However, there can be an offchain mechanism that automatically deploys standard contract primitives after each reset so application developers can also utilize the network more.
94
+
Upon reset the whole state is purged, which, on the one hand keeps the network small and easy to bootstrap but introduces problems for testing longer term / advanced applications. However, basic contract infrastructure can be automatically deployed after each reset by any user. Generally, using the network is recommended for short term testing, deploying `Hello World` kinds of contracts that don't need to stay forever on a long term testnet. However, there can be an offchain mechanism that automatically deploys standard contract primitives after each reset so application developers can also utilize the network more.
95
95
96
96
By defining two mechanisms for Genesis and Reset, this EIP enables two levels of how a client implementation can support the testnet;
0 commit comments