You’ve laid out 3 options here:
- Max security, put replay protection info in trie.
- Medium security, implement replay protection in separate smart contract and allowlist via EIP.
- Low security, implement replay protection in separate smart contract and use without allowlist.
Like I mentioned, option 1) is basically a non-starter. EIP-2935 received similar push back.
Option 2) is at odds philosophically with Ethereum. The only time we’ve done something similar to protocol-level allowlisting is with precompiles. This has been a major pain point in core development. Everyone wants their precompile in the next hard fork. Admittedly, precompiles are usually difficult to audit since they are usually implementing specific cryptographic primitives. But regardless, there is significant desire to allow people to write efficient cryptographic primitives without being blocked by hard forks and ACD.
No, this should be able to support all use-cases. Please note, this will inherently be more expensive due the additional contract call and be more complex to handle the edge cases.
Option 3) is really no different functionally than the current proposal of EIP-3074. Yes, the parameters of AUTH change slightly, but invoker implementers can just deploy their replay logic into a separate contract.
–
I argue that option 2) is equivalent to how we want EIP-3074 to be used in practice. If wallet developers do allowlist certain “safe” EIP-3074 invokers (like they’ve indicated), then the only invokers people will be able to use are the ones that have been “decided” as safe. I don’t see why forcing core devs to debate and decide on this is better than wallet developers doing the same.
If we don’t trust the developers of the wallet we use to upgrade their software securely, I think we have bigger problems.