Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-7377: EIP-7377 updates #7424

Merged
merged 6 commits into from
Jul 28, 2023
Merged

Update EIP-7377: EIP-7377 updates #7424

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
332d986
7377: all int values should be uint
lightclient Jul 27, 2023
0254b71
7377: remove storage discount
lightclient Jul 27, 2023
164f369
7377: add additional security considerations around ecrecover
lightclient Jul 27, 2023
3c5a31e
7377: add links
lightclient Jul 28, 2023
adbb91f
7377: correct section order
lightclient Jul 28, 2023
6d55fab
7377: fix list issue
lightclient Jul 28, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 17 additions & 7 deletions EIPS/eip-7377.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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` |
Expand All @@ -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

Expand Down Expand Up @@ -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 `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 `COLD_SLOAD_COST` of `2100`, because no load occurs.

### Intrinsic does not account for contract deployment

Expand All @@ -113,8 +113,18 @@ 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 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.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Expand Down