Add a new transaction type that allows EIP-7702-style delegation of accounts to non-ECDSA keys. Specify ed25519 as the first non-ecdsa key type. Discuss extension to post-quantum key schemes, pending selection of a suitable scheme
4 Likes
Good read.
The “either or” interaction with 7702 delegations is a bit offputting as it feels like a regression. I understand that it simplifies the scope.. do you see the future combined designator EIP as necessary / inevitable, or is that just one potential approach?
I think it’s worth acknowledging that this will become a new best practice for sweeping compromised accounts and we can expect a spike in delegations similar to 7702 (additionally there isn’t the opportunity to recover any assets which weren’t swept, given the irreversibility of this type of delegation)
I’d advise against hard coding signature algorithms, particularly ed25519 as you will run into the same problem as EIP-7980 (ACDE do not want to add another non PQ safe algorithm).
You should also probably modularise your spec, I.e. support signing for any algorithm. You may wish to checkout EIP-7932, it could be useful.
1 Like
I think the followup work is
- native key tx type that supports 4844
- native key tx type that supports 7702
- combined key + contract delegation
7702 that does a combined delegation, as well as of 4844 txn.
2 Likes
The purpose of the EIP is to address that ACDE concern. It is impossible to have a secure migration path to a PQ scheme without first having a secure migration path to some scheme. It’s explicitly not modular to keep it as simple as possible. What we want is a single-signature migration path for existing accounts that allows batching. We added a specific scheme (ed25519) so that the path can be used in prod and have tooling built around it well before it’s needed
1 Like
If you had to pick a scheme use P256. It was the initial design of EIP-7932 and EIP-7980 to use ed25519, and it got almost instantly dropped because of ed25519.
I have no attachement to any signature scheme. Just to establishing a migration pattern early
3 Likes
Is this a contingency plan in case EIP-8141 is not approved, since we will specify the signature and validate during execution using code?
I think this is a much simpler alternative to one of the things that EIP-8141 does.
2 Likes
i think 8141 is trying to solve too many problems at once, and has too much complexity to be effectively reviewed. 4 new opcodes, which may operate in 15 different modes is not a reasonable approach to any problem, and will not result in normalizing user migration in a reasonable amount of time. 8141 is likely to go the way of 7702, where hardware and other wallets explicitly disable it due to their inability to assess the safety of any individual transaction
2 Likes