You’re right, but what I mean is that it’s exacerbating the risk of wallet attacks. A multisig m/n wallet with m > n/2 is vulnerable to DoS attacks in addition to the risk of wallet drained. This limits users security choices because choosing a lower threshold makes them more susceptible to draining, while a higher threshold makes them more likely to lose access to their wallet.
I understand the goal of this proposal is to patch the 7851 vulnerability, however, the reality is that the ECDSA usage flow on the contract is out of sync with the native flow (based on the envelope tx). In my opinion, before addressing PQ, the immediate problem is the trouble caused by the global deactivating of EOA. Perhaps we need more transition time or backward compatibility features throughout this long-term transition roadmap.
A user wants to migrate their EOA A to a wallet that hedges against either ECDSA or the PQ signature scheme breaking. Working assumption: as time passes, confidence in ECDSA decreases, while confidence in a chosen PQ scheme increases
The user doesn’t want to pick the exact moment of doing a SETCODEFROM migration from ECDSA to PQ. Instead, they want their account to be secured by both for some time. The user also doesn’t trust any alternative ECDSA recovery mechanism (e.g. an EVM one); they only want to use ecrecover at 0x01.
A solution for the user is to SETCODEFROM to a wallet that requires both ecrecover and the PQ scheme to pass to authenticate their account’s address. Such a wallet will not work under EIP-8151 in its current form.
There are two solutions for this:
A carve-out inside EIP-8151, so that if CALLER == recovered_address, then ecrecover continues to work normally
A separate code-less address A' kept just for ECDSA authorization via ecrecover. (This approach is still vulnerable to an adversary using SETCODEFROM after ECDSA breaks, but this can be mitigated: if EXTCODESIZE(A') > 0, then degrade to just the PQ scheme.)
Is (1) sound, and can be incorporated into EIP-8151, or should there be a separate effort standardizing a workaround like (2) to cover the use case?
Hi, I lean toward keeping this at the wallet layer. I’m not sure this combination is common enough to justify a protocol exception. If it is, a wallet-layer pattern may be sufficient. e.g., a wallet could implement ECDSA verification itself and combine it with PQ verification, keeping the protocol change simpler.
As a rough, implementation-dependent estimate, direct secp256k1 verification against a supplied or registered public key could cost around 300k–500k gas. For comparison, an optimized ML-DSA-44 EVM verifier reports approximately 1.23M gas per verification, excluding key registration. The additional ECDSA cost seems potentially bearable for this transitional use case, although the comparison depends on the chosen PQ scheme and implementation.
SETCODEFROM currently cannot adopt empty code. My concern is that adding a caller-dependent carve-out would introduce another ad hoc protocol exception, with additional call-context edge cases and test vectors.
If users are not comfortable trusting a separate ECDSA implementation, approach (2), with the code-state fallback you described, seems like a reasonable wallet-level workaround.
I’m preparing to contribute the EELS implementation and consensus tests for EIP-8151.
While reviewing the specification, I identified three questions concerning gas accounting under EIP-8038, block access lists under EIP-7928, and ecRecover’s return data.
I’ve documented the details in the EELS tracking issue:
I’m particularly concerned about the return-data behavior and backwards compatibility.
The current specification requires returning 32 zero bytes for failed ECDSA recovery and account-code rejection. However, the existing ecRecover precompile returns empty output on recovery failure.
For example, Solady’s ERC20.permit and ECDSA.recover rely on RETURNDATASIZE to detect invalid signatures. Changing the output to 32 zero bytes could alter their failure behavior.
I currently favor preserving empty output for both failure cases to maintain compatibility with existing contracts.
Was the change to 32-byte zero output intentional?
I’d appreciate your thoughts on this, as well as the gas and BAL questions linked above.
Thanks @nezu511! For EIP-8038, I chose option (b): checking the EIP-7702 delegation prefix requires reading raw code, so the extra WARM_ACCESS aligns with EXTCODESIZE/EXTCODECOPY pricing. I agree with your other points and have updated the draft accordingly. Your review would be very welcome!
Thanks @colinlyguo! EIPs#12540 resolves all three questions. I’ve updated the EELS implementation and tests to the new text and left a few suggestions on the PR.
Its migration guard builds on ethereum/EIPs#12540: the same ecrecover call must return the account before adoption and empty output after it. In the EIP-7702 route, the first call runs while the account still holds a delegation indicator, so the guard also relies on the indicator exemption. With @colinlyguo’s permission, the post uses his framing: a delegation keeps the key’s authority, adopting regular code retires it, and 8151 follows that choice.