A long term goal in Ethereum is account abstraction (AA): making it so that users can use smart contract wallets to store their funds with the same convenience as EOAs, so that we no longer need externally owned accounts (EOAs). Smart contract wallets have the following benefits:
- They can encode more complex access policies (eg. multisig, social recovery) that provide users increased security
- They provide a natural upgrade path to other signature schemes that may have better properties (eg. Schnorr or BLS for much better threshold-sig-friendliness)
- They provide a natural upgrade path to quantum resistance: once AA is implemented, full quantum resistance would not require any execution-layer EVM changes, instead, users could just upgrade their wallets to quantum-safe alternatives on their own
- They allow user accounts to perform many operations in one transaction atomically, increasing safety and convenience and reducing gas costs
EIP 3074 accomplishes , but it does NOT accomplish [1, 2, 3]. Hence, EIP 3074 does not accomplish account abstraction (though as a short-term fix to , it or something like it can still be quite valuable). Currently, my favorite proposal for AA involves doing it outside the consensus layer via alternate mempools, to reduce load on consensus client developers who already need to work hard on testing, the merge, statelessness, optimization, etc, though we could decide on other approaches in the future as well. Nevertheless, if something like EIP 3074 is rolled out, it would be nice if it was forward-compatible with future AA goals.
If AA is rolled out, eventually we would want to remove EOAs as a category, to reduce client complexity. This can be done by making a hard fork that edits all existing and new EOAs in-place, replacing them with smart contract wallets that have the same functionality (but also an upgrade feature, so users can upgrade their accounts to a different scheme while keeping the same address).
Currently, there are no obstacles to doing this; the only issue is that there would need to be an irregular precompile that can create EOA-based wallets at addresses derived by hashing their public key. But EIP 3074’s
AUTHCALL mechanism increases this complexity.
AUTHCALL is an opcode that initiates a call from another address. Hence, in a post-EOA world, it could conceivably be replaced with a call to the wallet contract that asks the wallet contract to make the desired operation. However, there is a problem: the authorization is disconnected from the call itself. Hence, the smart contract wallet would have to have additional functionality, a “authorize deputy” function that would allow a specific address to call it without a signature and have those calls immediately forwarded.
AUTH would then become a call that calls this authorize-deputy mechanic, though even this doesn’t replicate the exact functionality because
AUTH as specified is call-scoped, and any in-EVM storage that could store the deputy is persistent.
All in all, a post-EIP-3074 post-AA world seems like it would carry a large amount of technical debt.
AUTHCALLprecompiles instead of opcodes. This way, they could later be replaced with pieces of code, avoiding EVM opcode technical debt.
- Implement Yoav’s alternative EIP 3074, which avoids the
AUTHmechanism and makes a series of calls from the EOA directly. This simplifies the logic, as such an
AUTHORIZED_MULTI_CALLEIP could in a post-AA world just be replaced with a series of calls to the wallet contract.
- Give the
AUTHCALLopcodes/precompiles a pre-determined fixed lifetime (eg. 2 years), clearly signaling to wallet developers that these are temporary measures and at some point applications will need to switch over to a different system.