Update EIP-7377: EIP-7377 updates

Merged by EIP-Bot.

EIPS/eip-7377.md

@@ -8,7 +8,7 @@ status: Draft
 type: Standards Track
 category: Core
 created: 2023-07-21
-requires: 170, 1559, 2718
+requires: 170, 1559, 2200, 2718
 ---
 
 ## Abstract
@@ -37,15 +37,15 @@ At the fork block `X`, introduce the migration transaction type.
 
 | field                  | type      |
 |------------------------|-----------|
-| `chainId`              | `int256`  |
+| `chainId`              | `uint256` |
 | `nonce`                | `uint64`  |
-| `maxFeePerGas`         | `int256`  |
-| `maxPriorityFeePerGas` | `int256`  |
+| `maxFeePerGas`         | `uint256` |
+| `maxPriorityFeePerGas` | `uint256` |
 | `gasLimit`             | `uint64`  |
 | `codeAddr`             | `address` |
 | `storage`              | `List[Tuple[uint256, uint256]]` |
 | `data`                 | `bytes`   |
-| `value`                | `int256`  |
+| `value`                | `uint256` |
 | `accessList`           | `List[Tuple[address, List[uint256]]]` |
 | `yParity`              | `uint8`   |
 | `r`                    | `uint256` |
@@ -63,7 +63,7 @@ A migration transaction is considered valid if the follow properties hold:
 * the code at `codeAddr` is less than the [EIP-170](./eip-170.md) limit of `24576`
 * the code at `codeAddr` must not have size `0`
 
-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`.
+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`.
 
 #### Processing
 
@@ -91,7 +91,7 @@ Naively, one could design the migration transaction to have a field `code` of ty
 
 ### Cheaper storage
 
-Allowing cheaper storage in this instance acts as a reward to users who migrate their EOAs to smart contract wallets.
+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.
 
 ### Intrinsic does not account for contract deployment
 
@@ -113,8 +113,19 @@ No backward compatibility issues found.
 
 ## Security Considerations
 
+### Blind Signing
+
 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.
 
+### On `ecrecover`
+
+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:
+
+* 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.
+* 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.
+
+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).
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).