EIP-7851: Deactivate/Reactivate a Delegated EOA's Key

EIPs EIPs core
1

Discussion topic for EIP-7851

Update Log

External Reviews

None as of 2024-12-27.

Outstanding Issues

None as of 2024-12-27.

3 Likes
2

Strong thanks to @jochem-brouwer and @thegaram33 for the valuable reviews of the draft PR.

Here’s a summary of some open discussions for broader visibility:

  1. Extra Storage Read During Transaction Validation
    This EIP introduces an additional storage read during transaction validation as noted in this discussion. Alternatives include:

    • Adding a new Boolean field in the account state.
    • Encoding the “active/deactivated” status into the nonce.

  2. Concerns About Reactivation
    Concerns (e.g., comment link) that users might not keep their private keys secure after deactivation. Possible solutions:

    • Users need to keep and back up their private keys as they used to. Nothing changes after they are deactivated since the main purpose is safeguarding the delegated EOA in one chain instead of deactivating the private key globally in a multi-EVM-compatible chains ecosystem.
    • Not supporting private key reactivation.
    • Allowing redelegation through a precompiled contract instead of supporting private key reactivation.

  3. Permit Extension
    The permit extension concern is mentioned in the relevant section of this EIP and also in this X post. Possible solutions:

    • Modify ecRecover precompile to check the deactivated status and if the recovered address is deactivated: return a precompile contract error (or, if not adding an error return, return a zero address or a designated magic address).
    • Trace transactions and check if the Permit function is invoked, if so, check the signer’s deactivated status, this solution would like to introduce a heavy check for clients.
    • The contracts upgrade the implementation and deactivate the Permit function. However, some ERC-20 contracts cannot be upgraded.
2 Likes
3

I believe another issue that needs to be addressed is the behavior of ecrecover, specifically expected behavior should be that it doesn’t work anymore if the pk is deactivated, right?

1 Like
4

Interesting. also have considered this, This method also sounds promising to address the Permit Extension issue listed above. since Permit usually utilizes ecrecover to verify EOA’s signature. while when I first thought of changing the behavior of ecrecover, it may be a bit unintuitive since this precompile does not do a “single job” (signature recovery) anymore. not sure. it’s worth discussing. so you think it’s more natural to consider the “deactivated” status in ecrecover? any considerations?

btw, I added the possible solutions in the previous Permit Extension issue session.

1 Like
5

yes I definitely agree on this making ecrecover more complex (and stateful). however, to me relying on contracts to implement correct behaviour (ie checking codesize and doing 1271 before ecrecover) feels hacky and not like a fully complete solution

1 Like
6

Totally agree with @kopykat here! Definitely think it would be worthwhile to restrict EOA signatures as without it, an attacker could work around this EIP.

3 Likes
7

I am not sure this has to be addressed. Anyone can implement ECDSA signature verification natively in Solidity. Yes, this would be more expensive, but changing ecrecover behavior introduces a leaky abstraction that doesn’t fix the problem completely.

Nevertheless, the deactivation concept sounds really cool to me as it relaxes the “god mode” access of delegated multisigs.

1 Like
8

yes this is a good point. you’re completely right that there’s no way to modify ECDSA to conform to this behavior.

however, I understand this proposal to be about making it possible to activate/deactivate a private key from the perspective of the EVM. currently, this includes mainly transactions (with the exception of addressing permit-based systems), but to me it feels like this change should also address any out-of-the-box features the EVM provides for ECDSA operations, namely ecrecover.

9

You know, ecrecover still accepts signatures with S values from both halves of the curve, while transaction can only be sent with S <= N / 2 (EIP-2). So this distinction has already been done before :slight_smile:.