The coming months promise to bring significant advances in terms of Blockchain user experience and contribute to the resolution of a major pain point in the ecosystem.
Who hasn't had a moving - or amused - thought for the Welshman James Howells who has been multiplying since 2013 the steps to obtain the authorization to search from top to bottom the public dump where he unfortunatly threw the hard disk containing the key of his Bitcoin account, including nearly 150 million dollars at today's price.
There are many stories of lost access keys to one's Wallet - and therefore the associated funds -.
They illustrate the inevitable counterpart to the notion of Self-Custody: if the user is the only one to control his account via his cryptographic key, there is no right to make mistakes and no hotline to call in case of loss of key: "Not your keys, not your coins" as the saying goes.
If this notion of Self-Custody is at the heart of what Blockchains are all about, this responsibility that falls to the user is rightly a major obstacle to the adoption of the technology by a wider public.
To ensure the storage of one's cryptographic keys, it is certainly possible to use trusted third parties, such as, for example, centralized Exchanges. However, this clearly limits the scope of the user experience by restricting it mainly to the holding and transfer of crypto-assets, without the possibility of advanced interactions with Web applications3.
However, solutions exist, especially on Ethereum, via the use of Social Recovery Wallets, where :
- As in a traditional Wallet, the user holds a signing key that allows him to act on his funds and interact with the Blockchain.
- He can also associate one or more "Guardians" accounts to his Wallet (which can be, for example, accounts controlled by the user - back-up accounts, email accounts, etc. -, accounts controlled by members of his family or friends or accounts controlled by institutions).
- In case of loss of his signing key, the user can ask the Guardians to change the address of the lost signing key by the one of a new key, controlled by him, this operation can be done only if a predefined quorum of Guardians carries out jointly the operation.
With this type of mechanism, the user can act in case of loss of his key, with fine tuning modalities, covering a whole spectrum of possibilities: from full Self-Custody (the Guardians accounts are controlled by him) to a classic Custody system (only one institutional Guardian).
Such systems are already operational, but their implementation must comply with the technical modalities of implementing Accounts on Ethereum, where there are two types of Accounts:
- Externally-Owned Accounts (EOA), accounts held by physical users, including an address and a balance in Ether, the possibility to act on this account being ensured by a signing key. The address of the account being determined from the signing key, these two elements are strictly linked, hence the irrevocable impossibility to act on the account in case of loss of this signing key.
- Contracts Accounts: including code, in the form of a Smart Contract, and therefore the possibility of instantiating application logic.
If an EOA does not understand programming possibilities, it can call a function of a Smart Contract via a transaction. In this case, in order for his instruction to be processed by the Blockchain, he must pay fees in Ethers (called gas), the amount of these fees being, among other things, a function of the complexity of the operation to be carried out, and which can be considerable if elaborate Smart Contracts are used.
The implementation of all the application logic associated with a Social Recovery Wallet can therefore only be done in this technical paradigm via a dedicated Smart Contract, which implies:
- Potentially high gas costs in terms of deployment and usage.
- The need to pay for gas to call up the functions of the contract, which paradoxically requires holding another account credited in Ethers...; this point can be circumvented by setting up specific infrastructures (Relayers), which can nevertheless be complex and sub-optimal because it is often centralized.
Also, these technical constraints weigh heavily on the possibilities of widespread adoption of Social Recovery Wallets, especially since many Web3 applications have only been designed to interact with traditional user accounts and are therefore not compatible with Social Recovery Wallets.
These different constraints could be addressed at the protocol level by:
- Removing the dependency between account address and signing key, currently hard-coded.
- Introducing application logic allowing to instantiate management rules that can authorize, under condition, other keys to act on this account.
This could also be implemented by abolishing the distinction between Externally-Owned Accounts and Contracts Accounts, and by defining only one type of account, carrying application logic.
This is the notion of Account Abstraction, the implementation of which has been discussed since 2016 in the Ethereum community via protocol layout proposals (EIPs).
But the deployment in production of these various EIPs could not be done because of the need to intervene in depth on the technical layer of the Ethereum protocol, which moreover in an extremely busy period for the developers in particular because of the work on the passage in Proof Of Stake.
But the situation has recently changed.
A new PIE (4337) defines a more feasible implementation of Account Abstraction because it does not require intervention on the protocol layer managing consensus.
In addition, some of the Ethereum Layer 2 solutions, learning from the use of Ethereum without being constrained by its technical heritage, natively implement the notion of Account Abstraction, in line with the EIP 4337 specifications. This is for example the case of ZK Rollups ZKSync and Starknet. And some Wallets already implement Account Abstraction based Social Recovery features (Argent on ZKSync) or have it in their short term roadmap(ArgentX and Braavos on Starknet).
We are likely to see significant advances in the user experience of key retention in the coming months, helping to resolve a major and recurring pain point in the ecosystem.
And, beyond the implementation of Social Recovery Wallets, merging application logic and user accounts will also allow significant progress in terms of :
- security, including the ability to integrate new cryptographic signature schemes, including quantum-resistant signatures, into a wallet;
- performance, with the possibility of aggregating transactions or signatures;
- user onboarding, with the possibility of creating and crediting a user Wallet fed via his credit card by taking care of his gas expenses, or more generally to allow to pay these expenses with any type of Token;
- user experience, with the possibility for applications or services to pay for all or part of the gas costs related to their use, or to define spending thresholds pre-approved by the user (useful in particular in the gaming world, to avoid multiplying the confirmation by the user of all the micro-payments for each action in the game).
----
To go further
EIP-4337: Account Abstraction using alt mempool
----
Photo by Silas Köhler on Unsplash
