After ACDE #220, there were some questions that I’ll answer here:
The SSZ transaction type may block inclusion, could RLP be used?
It is entirely possible to also add an RLP transaction type. I initially moved away from RLP as it was significantly more complex to use RLP (at least my initial idea was). If anyone has a simple way to have RLP support, I’ll be more than happy to include it.
Ed25519 is not quantum secure; we should prioritise PQ algorithms
I agree that EIP-7932 should primarily use PQ algorithms.
The reason I went with Ed25519 is because it is another battle-tested algorithm that is similar to secp256k1. This allows us to fully test EIP-7932, without releasing a newer algorithm like ML-DSA with potentially unknown security holes.
Similarly with RLP support, this EIP can change to make life easier for everyone. If there is some way to test EIP-7932 without adding additional cryptography, that is also a possible path.
Does account abstraction already do this?
Yes, it does. However, sigrecover can help unify the result of addresses with native and account abstraction schemes. I won’t deny it, account abstraction can work as a viable replacement by itself. It just would be a nicer UX if all account abstraction systems with multiple signature schemes result in the same address from the same key.
Should we change transaction signature types?
As Felix said, “[changing transaction signature schemes] has never been done before”. That is why this EIP is modular, it allows us to change the signature format only once but swap in new algorithms much more efficiently. On the topic of whether we should even try to change tx sig types, it’ll have to happen at some point. It might be better to do this early with a lot more planning, instead of within a couple of days after ECDSA becomes vulnerable.
Do we need to redefine how an Ethereum address is calculated?
Currently there are three ways to make an Ethereum account (i.e. entry in the state trie, etc):
- Send ETH to that account
- Via the
CREATEorCREATE2opcodes - Via a precompile or network wide action
The account creation process and proving account ownership are rather decoupled. This means that as long as someone can prove access to an account e.g., by smart contract code or by recovering and hashing the transaction signer, they can spend the funds of the account. The same applies to EIP-7932, nothing changes in regards to addresses other than an additional way to prove account ownership.
Why I am against fixing the signature algorithms
If, in the distant future, we find a new, better PQ algorithm to replace Falcon or ML-DSA, all existing tooling, infrastructure and smart contracts would either break, or need to be upgraded. Decoupling signature schemes and accounts can still allow people to use legacy algorithms (if they are just inefficient) and ensure no compatibility issues exist with the new algorithms so adoption can happen much faster. I believe @jflo touched upon this in the ACDE call.
CC: @shemnon @fjl (sorry if I incorrectly pinged you, there were many people to choose from in the list)
Nothing stops an algorithm specification from calling precompile logic; sigrecover and the wrapper only turns some signature bytes into an ExecutionAddress. A precompile call can happen during this process, so p256verify can be used as well (if deemed a good idea). EIP-7592 can also be used during these processes.