Criticism of EIP-3074 and a simple replacement
For developers, the AUTH/AUTHCALL mechanism is very attractive. It lets one create callers to implement different batching strategies (e.g. support multiple nonces for better parallelism), gas abstraction models, complex account abstraction methods, etc.
This flexibility stems from the great freedom this mechanism gives developers. The AUTH/AUTHCALL mechanism does not require developers to follow a specific pattern, but requires users to sign a commit hash value (the commit content will be parsed by the caller), allowing developers to set their own restrictions based on the commit.
However, this flexibility comes at the expense of security. In this article, I want to introduce a simpler alternative. This solution has most of the advantages of the AUTH/AUTHCALL mechanism, but the risk is much lower than the latter.
Why is signing an AUTH commit riskier than signing a transaction related to a vulnerable/malicious contract?
When a user signs a contract-related transaction, the risk that the user takes is known, that is, the assets within the control of the contract may be lost. Let's say a user signs an approval transaction to an ERC 20 contract authorizing a malicious DEX contract. This malicious DEX contract can withdraw the user's entire balance in the ERC 20 contract. However, it cannot withdraw tokens from the user's other ERC 20 contracts unless approved by the user. It also cannot perform other actions on behalf of the user, as this also requires exclusive user approval.
In contrast, EIP 3074 not only requires the user to sign a "blank check", but also assumes that the caller is honest and free of vulnerabilities. A malicious/vulnerable caller can perform any action on behalf of the user - access assets held by the user, vote on behalf of the user, control contracts owned by the user, etc.
Worse, the caller can do evil at any time, since the nonce implementation is under the control of the caller. Vulnerable/malicious implementation of nonce logic could replay user past transactions. If the logic of other parts of commit verification is also vulnerable, the caller can use this nonce logic implementation to perform any operation on behalf of the user. Even if the vulnerability is discovered, the user cannot withdraw the blank check. This external account (EOA) has been permanently compromised.
Writing a correct caller program is hard, and we're almost certain callers will bug out from time to time, as evidenced by the non-exhaustive list of checks/vulnerabilities/circumstances callers should be wary of at the end of EIP 3074. The list is bound to grow longer, likely with a painful discovery process.
Additionally, a malicious actor could write a seemingly innocuous caller program, but intentionally leave a subtle vulnerability that would not be exploited by the attacker until a large number of external accounts authorized the caller.
secondary title
Governance hijack example
The malicious decentralized exchange EveSwap wrote a caller program for its users. This caller program provides gas funding for users by airdropping EVE tokens, and batches user approval and transfer transactions.
EveSwap's caller program is seemingly harmless and will never steal the user's tokens, because it would be revealed immediately.
Users are happy. The transactions were all successful, and the transaction fees were cheap. It's been an uneventful few months.
However, whenever someone uses EveSwap to trade AliceSwap's governance token ALI, the user's AliceSwap voting rights will be automatically delegated to EveSwap.
Once the authorized number reaches a certain threshold, EveSwap will hijack AliceSwap through the governance proposal.
secondary title
Example of cross-chain replay
EIP 3074 reasonably suggests that commits should contain chainids. However, this is enforced by the caller, not the protocol. Callers with the same address on another chain may skip this check (or checks for that matter).
EveSwap runs on the EVM-compatible BobSpongeChain, which supports EIP 3074. EveSwap deploys an honest caller on BobSpongeChain.
Users use this caller to transact on BobSpongeChain, and then use the bridge to transfer assets to Ethereum.
EveSwap deploys another caller with the same address on Ethereum using the same deployment key. This caller on Ethereum does not check commits, only ownerOnly, and acts as a generic AUTH/AUTHCALL proxy for its owner.
In this way, EveSwap can hijack users' external accounts on Ethereum and take away their assets.
Users have never traded on Ethereum, and the caller program running on BobSpongeChain has undergone strict security reviews. Despite this, users lost their entire assets.
secondary title
What else can we do?
My proposal is to implement a more explicit mechanism that enforces the meaning of commit at the protocol level. The commit structure will be typed (as described in EIP 712), and the wallet will present the commit in a user-readable form. Users can know exactly what a transaction looks like, and be confident that this transaction will not be replayed on any chain, without relying on the character and ability of the developer of the calling program.
A possible implementation:
AUTH will replace the commit hash with a typed struct containing a list of authorized calls. Each call will specify {nonce,to,gas,calldata,value,chainid}. The signature will be verified and the entire list of authorized calls will be saved as authorized_transactions instead of the authorized address variable.
AUTHCALL will get a new parameter index which points to the address in the list created by the last AUTH .
The nonce of the user address will be incremented with AUTHCALL. The nonce is not stored by the caller, but the actual account nonce.
profit:
Users can clearly understand the situation.
Security is guaranteed by the protocol.
Batch and account abstractions are still supported.
The nonce implementation does not support parallelism.
Transactions for complex caller programs can be cumbersome because the user must review and accept the entire list of calls.
Disadvantages:
Different implementations may support different nonce schemes. However, whatever mechanism we use, that mechanism must be implemented by the protocol, not the caller.
secondary title
Alternative: Avoid hard forks altogether
There is also an option to avoid the AUTH mechanism entirely, and solve the account abstraction and batching problem with an alternative transaction pool as suggested by vbuterin.
profit:
No hard fork required, supported by smart contracts and nodes that are aware of those smart contracts.
Can be used with any implementation that supports EIP 3074 without introducing additional risk.
Not backward compatible with existing external accounts. Users need to deploy a contract wallet and transfer assets into the wallet.
Disadvantages:
Original link:
Original link:
https://blog.mycrypto.com/eip-3074/
Translation & Proofreading: Min Min & A Jian
Translation & Proofreading: Min Min & A Jian
