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
@@ -32,7 +31,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
32
31
```solidity
33
32
pragma solidity >=0.7.0 <0.9.0;
34
33
35
-
/// The EIP-165 identifier of this interface is 0xdd691946
34
+
/// The ERC-165 identifier of this interface is 0xdd691946
36
35
interface IERC2135 {
37
36
/// @notice The consume function consumes a token every time it succeeds.
38
37
/// @param _consumer the address of consumer of this token. It doesn't have
@@ -74,9 +73,9 @@ interface IERC2135 {
74
73
}
75
74
```
76
75
77
-
2. If the compliant contract is an [EIP-721](./eip-721.md) or [EIP-1155](./eip-1155.md) token, in addition to `OnConsumption`, it **MUST** also emit the `Transfer` / `TransferSingle` event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to `consume` method succeeds.
76
+
2. If the compliant contract is an [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md) token, in addition to `OnConsumption`, it **MUST** also emit the `Transfer` / `TransferSingle` event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to `consume` method succeeds.
78
77
79
-
3.`supportsInterface(0xdd691946)`**MUST** return `true` for any compliant contract, as per [EIP-165](./eip-165.md).
78
+
3.`supportsInterface(0xdd691946)`**MUST** return `true` for any compliant contract, as per [ERC-165](./eip-165.md).
80
79
81
80
## Rationale
82
81
@@ -85,29 +84,29 @@ interface IERC2135 {
85
84
- who has the power to perform consumption
86
85
- under what condition consumption can occur
87
86
88
-
It does, however, assume the asset can be identified in a `uint256` asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the EIP-721 pattern.
87
+
It does, however, assume the asset can be identified in a `uint256` asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the ERC-721 pattern.
89
88
90
89
2. The event notifies subscribers whoever are interested to learn an asset is being consumed.
91
90
92
91
3. To keep it simple, this standard *intentionally* contains no functions or events related to the creation of a consumable asset. This is because the creation of a consumable asset will need to make assumptions about the nature of an actual use-case. If there are common use-cases for creation, another follow up standard can be created.
93
92
94
-
4. Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like `ERC721Metadata` from [EIP-721](./eip-721.md)
93
+
4. Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like `ERC721Metadata` from [ERC-721](./eip-721.md)
95
94
96
95
5. We choose to include an `address consumer` for `consume` function and `isConsumableBy` so that an NFT MAY be consumed for someone other than the transaction initiator.
97
96
98
97
6. We choose to include an extra `_data` field for future extension, such as
99
98
adding crypto endorsements.
100
99
101
-
7. We explicitly stay opinion-less about whether EIP-721 or EIP-1155 shall be required because
102
-
while we design this EIP with EIP-721 and EIP-1155 in mind mostly, we don't want to rule out
100
+
7. We explicitly stay opinion-less about whether ERC-721 or ERC-1155 shall be required because
101
+
while we design this EIP with ERC-721 and ERC-1155 in mind mostly, we don't want to rule out
103
102
the potential future case someone use a different token standard or use it in different use cases.
104
103
105
104
8. The boolean view function of `isConsumableBy` can be used to check whether an asset is
106
105
consumable by the `_consumer`.
107
106
108
107
## Backwards Compatibility
109
108
110
-
This interface is designed to be compatible with EIP-721 and NFT of EIP-1155. It can be tweaked to used for [EIP-20](./eip-20.md), [EIP-777](./eip-777.md) and Fungible Token of EIP-1155.
109
+
This interface is designed to be compatible with ERC-721 and NFT of ERC-1155. It can be tweaked to used for [ERC-20](./eip-20.md), [ERC-777](./eip-777.md) and Fungible Token of ERC-1155.
Copy file name to clipboardExpand all lines: EIPS/eip-5806.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ 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 witht 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 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.
21
21
22
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.
23
23
@@ -34,7 +34,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
@@ -63,7 +63,7 @@ A migration transaction is considered valid if the follow properties hold:
63
63
* the code at `codeAddr` is less than the [EIP-170](./eip-170.md) limit of `24576`
64
64
* the code at `codeAddr` must not have size `0`
65
65
66
-
The intrinsic gas calculation modified from [EIP-1559](./eip-1559.md) to be `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count + 15000 * length of storage`.
66
+
The intrinsic gas calculation modified from [EIP-1559](./eip-1559.md) to be `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count + 20000 * length of storage`.
67
67
68
68
#### Processing
69
69
@@ -91,7 +91,7 @@ Naively, one could design the migration transaction to have a field `code` of ty
91
91
92
92
### Cheaper storage
93
93
94
-
Allowing cheaper storage in this instance acts as a reward to users who migrate their EOAs to smart contract wallets.
94
+
Since the storage is guaranteed to be empty, there is no need to read before write. This means only 20,000 gas is needed to pay for the [EIP-2200](./eip-2200.md)`SSTORE_SET_GAS` value. This is a small discount to the normal cost of `22,100`, which is `SSTORE_SET_GAS` plus the [EIP-2929](./eip-2929.md)`COLD_SLOAD_COST` of `2100`, because no load occurs.
95
95
96
96
### Intrinsic does not account for contract deployment
97
97
@@ -113,8 +113,19 @@ No backward compatibility issues found.
113
113
114
114
## Security Considerations
115
115
116
+
### Blind Signing
117
+
116
118
As with all sufficiently sophisticated account designs, if a user can be convinced to sign an arbitrary message, that message could be a migration transaction which is owned by a malicious actor instead of the user. This can generally be avoided if wallets treat these transactions with *extreme* care and create as much friction and verification as possible before completing the signature.
117
119
120
+
### On `ecrecover`
121
+
122
+
Applications standards such as [ERC-2612: Permit Extension](./eip-2612.md) have exploited the cryptographic relationship between EOA addresses and their private keys. Many tokens today support this extension, allowing EOAs to approve the transfer of fund from their account using only a signature. Although collisions between EOAs and contract accounts are considered unlikely and [maybe impossible](./eip-3607.md) given today's computing power, this EIP would make it common place for private keys to exist for contract accounts. There are some considerations here regarding security:
123
+
124
+
* The obvious attack is a defi protocol deploys some their contract using this EIP and later sign an [ERC-2612](./eip-2612.md) message to steal the funds accrued in the contract. This can be avoided by wallets simply not allowing users to interact with protocols deployed in this manner.
125
+
* It's also worth mentioning that there are concerns around how this EIP will affect the cross chain experience. Ultimately a users private key may still have some control over the account's assets, depending on the exact protocols used on Ethereum and on other chains. It isn't really possible perfectly migrate the EOA at the same time, on all chains. The best thing that can be done is to educate the user that just because their account has been migrated doesn't mean that they are safe to now publicly reveal their private key. This seems like a reasonable request, especially since they'll want to retain the private key in case they want to use the address on any other EVM-like chain.
126
+
127
+
Something that may alleviate these issues to some degree would be to add an `EXTCODEHASH` check in `ecrecover`. If the recovered account has code, the precompile will revert. This would disallow migrated EOAs from using standards like [ERC-2612](./eip-2612.md).
128
+
118
129
## Copyright
119
130
120
131
Copyright and related rights waived via [CC0](../LICENSE.md).
0 commit comments