Hi all — I’ve opened an update PR for EIP-7851 to reflect a design change toward delayed, irreversible ECDSA key deactivation (PR: Update EIP-7851: Move to Draft by colinlyguo · Pull Request #11316 · ethereum/EIPs · GitHub ). This is based on previous discussions in this Magicians thread, as well as recent conversations with @nicocsgy, incorporating some new context and ideas from PQ team.
This update changes EIP-7851 from a deactivate/reactivate precompile (encoding status via a trailing byte on the 7702 delegation designator) to an irreversible ECDSA key deactivation with a 7-day delay. Concretely: reactivation is removed to preserve post-quantum security guarantees (allowing an ECDSA key to come back would weaken the goal), and deactivation is no longer instant, it is scheduled with a 7-day cancellation window during which the current ECDSA key can call cancel() to prevent accidental or malicious lockout before finalization.
Because the delay requires storing a per-account finalizationTimestamp, the design moves from a precompile to a system contract. Compared to other minimalist designs, for example, (i) adding an account-state field (managed by a precompile), which would require complicated and error-prone RLP/p2p changes, and (ii) relying on a precompile, which has no natural storage mechanism. A system contract (following the EIP-4788 / EIP-2935 / EIP-7002 pattern) with interfaces deactivate/cancel/status as a single on-chain source of truth is more implementation-friendly and self-explanatory, and likely more backward-compatible.
About ecrecover for legacy immutable, non-upgradable contracts: to keep concerns separated, EIP-7851 itself does not depend on changing ecrecover. I opened a companion draft EIP to explore making ecrecover respect private-key deactivation status (for contracts relying on ECDSA signatures), here: EIP-8151: Private Key Deactivation Aware ecRecover - #4 by bbjubjub .