This is coming up in Metropolis, but I'm having a real hard time finding an understandable explanation.
2
-
Account abstraction has not yet been implemented due to complexity: github.com/ethereum/EIPs/issues/859– eth ♦May 25, 2019 at 8:50
-
People stumbling upon this thread may also be interested in the Account Abstraction Link Tree.– Paul Razvan BergJun 10, 2020 at 10:42
Add a comment
|
2 Answers
At the time of writing this, there are two types of accounts in Ethereum. First, there are external accounts which are controlled by private keys, like the accounts in a wallet. Then there are contract accounts, which are controlled by the code deployed to the blockchain.
Account Abstraction is an improvement to make these two types of accounts more similar, and make the logic controlling external accounts as flexible as contract accounts.
Once the system for accounts is abstracted, accounts controlled by keys will have code backing them. The difference is that the code will specify how to verify the transactions controlled by the keys. It may start off being that all standard private-key backed accounts just verify ECDSA signatures, but the signature verification algorithm can then be rewritten on a per account basis to support other types of signatures.
Account Abstraction opens up all kinds of other transaction permission management as well. For instance, right now the sender of a transaction needs to pay for it. This is not ideal for all use cases. It is proposed that with abstraction there will be systems where contracts can pay the miners instead of the transaction sender.
A simple explanation of Ethereums Account abstraction is the implementation to replace EOA's (Externally Owned Accounts) with smart contracts.
