👉 This proposal adopts a distinct strategy that steers clear of making any modifications to the consensus layer.
The Ethereum Foundation has now published a verified version of the ERC-4337 standard on the Ethereum mainnet. The standard was implemented via the Smart Contract EntryPoint, which has already been active for a few weeks. It is intended to change the way users interact with wallet services, keyword: account abstraction.
Most Ethereum wallets are externally owned accounts (EOAs), including providers like MetaMask and Trust Wallet, as well as hardware wallets like Ledger Nano or Trezor. With EOAs, a private key controls an account, which means that if the key is compromised or lost, all tokens in the wallet would be affected.
How does the Ethereum ERC-4337 standard work anyway?
Through account abstraction, accounts can be flexibly adapted to the needs of users. The Ethereum Foundation aims to further develop the Ethereum ecosystem and its Native Token Ether (ETH). For some users, this could mean getting a user experience similar to that of a bank. For more sophisticated users, more controls or features could be added to their account.
An example of account abstraction is the addition of two-factor authentication when spending more than €5,000, for example. The measure also allows users to use the cryptographic signature of their choice and securely authorise transactions via SmartPhones.
Unlike EOAs, account abstraction allows users to use smart contract wallets with any verification logic. So rather than having to write twelve words on a piece of paper or on a digital note, devices can be added and removed and recovery options can be included with a friend or a lawyer.
How is the implementation of ERC-4337 done?
The implementation of the ERC-4337 standard has proven difficult, as it has been difficult to find consensus for a protocol change to support account abstraction. However, it is important to better understand security and usability. Instead of changing the consensus rules, the ERC-4337 standard provides an opt-in solution where everyone has to agree to a standard before they can actually use it on the chain. The ERC-20 token standard is an example of a widely used standard that does not require changes at the protocol level. The ERC-4337 standard creates a standard for account abstraction and provides a new mempool for user operations served by bundles. Stackup is one of the first protocols to comply with the ERC-4337 standard for bundles. Developers can create customised Web3 transaction flows and wallets using the latest ERC-4337 smart contract without worrying about how each blockchain works, as long as the wallet only supports ERC-4337.
Built-in mechanisms include a social recovery system that allows multiple users to restore access to an account if a user loses their personal private key. With account abstraction, it is also possible to create “multisig wallets” that grant a group of users access to an account and require transactions to be authorised by multiple users as an additional security mechanism.
In summary, the advantages and disadvantages of ERC-4337
Strengths:
Flexibility of verification logic: the validateUserOp function can add arbitrary signature and nonce verification logic (new signature methods, multisig…).
Sufficient to make the execution layer more quantum secure: no further work needs to be done on the execution layer to ensure quantum security. Users can individually upgrade their wallets to quantum-safe wallets. Even the wrapper transaction is secure, as the miner can use a new, freshly created and thus hash-protected EOA for each bundle transaction and does not publish the transaction before it is inserted into a block.
Updateability of wallets: The verification logic of wallets can be stateful, so that wallets can change their public keys or (when published with DELEGATECALL) update their code completely.
Execution logic flexibility: wallets can add custom logic to the execution step, e.g. atomic multiple operations (a key objective of EIP 3074).
Vulnerabilities:
Slightly increased DoS vulnerability despite the best efforts of the protocol, simply because the verification logic is allowed to be slightly more complex than the status quo of a single ECDSA verification.
Gas overhead: slightly more gas overhead (transaction fees for the decentralised network) than regular transactions (though this is offset in some use cases by support for multiple operations).
One transaction at a time: accounts cannot feed multiple transactions into the mempool. However, the ability to perform atomic multi-operations makes this feature far less necessary.
See more at the Specification on github.
Source:
