Discussion topic for EIP-7932 GitHub PR
This EIP introduces a new EIP-2718 typed transaction that wraps (contains) another transaction, this EIP nullifies the default signature parameters and appends signature data to the front of the transaction with a selector, this effectively wraps a transaction and swaps out signature data for alternative algorithms and data. It also creates a new precompile to be able to decode these additional signature algorithms.
Update Log
- 2025-04-12: initial draft PR
External Reviews
Outstanding Issues
None as of 2025-04-12.
EIP-7702 defines a transaction type with nested signatures. You should probably explain how 7702 and this proposal interact.
1 Like
I’d extend this proposal with support for patching ecrecover as well. Fixing the outer transaction signature without fixing ecrecover will only solve part of the PQ problem.
One approach that’s been tossed around is to embed a list of tuples in the transaction that contain a mapping from the ecrecover arguments to the real signature/algorithm data. I haven’t thought that through entirely, but hopefully it’s a starting point.
2 Likes
The EIP-7702 problem was solved by adding space for additional signatures after the transaction, I don’t know how practical this would be but it was one of my better solutions. (edit: I also added the NULL algorithm for edge cases where the initial signature is secp256k1 but the others are not)
I also patched ecrecover instead of using a mapping as that seemed a bit too complex, I made any v recovery value v > 0xFF && v <= 0xFFFF trigger the contract to be treated as an Algorithmic. Might still need to work on the name, but for now Algorithmic transaction rolls of the tounge. I am going to introduce a new precompile, with a name similar to sigrecover as the “overload the v value” seemed somewhat hacky and may break some implementations.