Written by Antoine Herzog from IOV and Peg from darkcrystal.pw
From a crypto address-centric blockchain to a user-centric blockchain to enable private key recovery.
Since 2009, Bitcoin has allowed the user to trade digital assets without needing a third party. This innovation was made possible thanks to cryptography. Because of cryptographic public/private keys, individual users can execute transfers of bitcoin from his/her public address directly to another address by ‘signing’ them.
Since Bitcoin, most blockchains also use public key cryptography to certify the authenticity and provenance of a transaction order and execute it only when the sender verifies they are the owner of the funds they want to transfer.
In 2014, Ethereum enabled developers to execute smart-contracts on the blockchain. These smart-contracts have enabled a lot of experimentation. Very quickly, Ethereum saw the emergence of standards allowing anyone to create fungible tokens (ERC20) or non-fungible tokens (ERC721).
Cryptography as a first class citizen
Using cryptography as a means to authenticate a transaction order has made it possible to secure the decentralized exchange of values in the blockchain.
Send a Bitcoin, Ether or an ERC20 Token
To send Bitcoin or Ether, you must sign a transaction. This signature must match the account to which Bitcoin or Ether are attached in order to be valid. In the same way as sending Ether or Bitcoin, the ERC20 standard offers a series of methods. The main method is the functional transfer (address to, uint tokens) which allows a cryptographic signature to send an ERC20 token.
By making the cryptographic signature the only necessary element required to validate the conditions for an asset transfer, this system loses focus on something important: the actual user.
User as a first class citizen and enabling private key recovery.
Indeed, users can lose their cryptographic private key or just forget it. By losing this key, users with standard wallets interacting with ERC20 tokens without any additional smart contract do not have the possibility to recover their key or their digital assets.
The loss of private keys is a major obstacle to the adoption of blockchain assets based by the general public.
Almost all services on the internet offers an option to recover a lost password. And for good reason: a study (https://phys.org/news/2017-06-customers-passwords-business.html) shows 21 percent of users forget passwords after 2 weeks and 25 percent forget one password at least once a day.
However, the password recovery mechanisms that we are used to on traditional web services, although convenient, come at a great cost to the user’s autonomy and independence. The user’s data and identity is essentially controlled by the provider of that service. Increasingly, people are becoming dissatisfied with this arrangement, and are seeing the benefits of decentralised technologies. However the private key custody problem presents a critical barrier to their adoption and use.
Even though an alert is often displayed when a Bitcoin Wallet is initialized before registration to ask users to back up their password securely, another study estimates that 2.8 million to 3.8 million bitcoins are lost because of missing/forgotten keys. That’s almost 23% of the total supply.
A limitation of current blockchains is to think of the user a posteriori, such as the problem of recovering a lost private key. Indeed, every time someone transfer an asset, it is a question of looking at whether the cryptographic signature corresponds to the public address which own this asset. There is no user in a traditional blockchain, only addresses.
We propose an actor-asset model to put the user at the center of all the interactions with blockchains.
Actor and Actor ID
An actor represents a user or any kind of entity like an organization and the actor ID is the unique identifier for an actor. Actor ID has the same format as a public cryptographic address.
When it comes to transfer an asset, instead of giving a traditional public address, the user must specify to which actor ID the asset should be sent. Actor ID does not bind anymore to a specific public key / private key forever. It brings back the idea of an immutable account like a webmail account. Actor ID should be the immutable information that a user gives to receive a payment. Anyone can lose their private key but still want to be able to receive assets and be able potentially to re-create a new public / private key attached to their actor ID account.
How can we adapt an Actor-based framework in Ethereum?
Define an Smart Actor Contract standard
We define an smart actor contract standard. It should contain at least four functions: isTransferAuthorized, isUpgradeAuthorized, performUpgrade, recoverOwnership:
isTransferAuthorized should be called by any smart contract asset to check if the actor authorized the transfer before executing it. isTransferAuthorized should take as parameters sender signature, all other signatures for optional multi-signature transaction (additionalData), the smart contract address from which the function is being called, and optionally the amount of token requested for transfer.
isUpgradeAuthorized should be called by the performUpgrade function to check if the actor has authorized the actor smart contract upgrade.
performUpgrade can be called by the actor to upgrade the actor smart contract.
recoverOwnership is an optional method to recover an actor account in case the actor lost its private keys. If the method exists, this method should take as parameters a list of cryptographic signatures and the new public address from which the actor will be able to transfer assets and upgrade its actor smart contract. If specific conditions are met, it should reset the conditions to transfer assets of isTransferAuthorized and reset the conditions to perform an upgrade of isUpgradeAuthorized.
A simple isTransferAuthorized implementation could simply check if the current signature for the transfer matches the actor ID authorized to transfer assets stored in the actor smart contract. A list of public address could be added into the isTransferAuthorized function so different dapps could transfer assets of an actor on his behalf (similar than the allowance methods in the ERC20 Token).
An actor can upgrade their actor smart contract via performUpgrade. It should be done very rarely, as upgrading its smart contract means being able to change the isTransferAuthorized function and transfer any kind of assets to anyone.
A more complex isTransferAuthorized could be a multisig enforcement like a Gnosis multisig smart contract or even specific approval conditions for recurring payments coming from another smart contract dApp itself.
A simple recoverOwnership could check if the signatures are valid and match the current authorized list of KYC providers signatures present in the function. In an other version, this function can opens the way also to social recovery procedure in case an actor lose its private key.
A possible way to implement the private key recovery mechanism is using Shamir’s Secret Sharing. In its simplest form, a user could delegate five friends to be responsible in case of a lost key. The private key is split into five shares which are each encrypted with a friend’s public key and sent to them. In the case of the key being lost, the friends are asked to return their shares to a new address. Since this is a threshold algorithm we can allow for the case that some friends are unavailable by having a quorum of three, meaning the key can be recovered with any three of the five shares.
The advantage of this approach is that Shamir’s scheme is information-theoretically secure. That is, individual shares contain absolutely no semantic information about the key itself.
The difficult part is that the friends need to be sure that the new address really does belong to the user and not an attacker. This can be done by contacting them out-of-band (for example on a phone call) and confirming the new address after verifying by means of a conversation.
This scheme can be improved by also sending shares to other devices which the user owns but stores separately, ideally at another location. Or by printing shares as QR codes and keeping them in a variety of different locations. The combination of social and physical backups gives security, while the threshold scheme, which allows for situations where some shares cannot be retrieved, gives resilience.
Traditional end-users will not be scared, since they are already familiar with the opportunity to increase the security of their Gmail account or to recover their password without the need to “re-create an account”.
Deployment of the Smart Actor Contract to a public address which I owned the private key.
The beauty of cryptography is: it is free.
Creating a public/private key doesn’t cost anything and you don’t need to create a transaction on the blockchain to start receiving any kind of asset. You just need to give your public address. That’s one of the reasons why all current blockchains use only cryptography to create offline new addresses for new users interacting with a blockchain. It is working beautifully.
The same way a user can generate a public/private key for free, a user should be able to get an immutable actor ID for free to be able to receive a first payment. Motivation follows the same reason than the EIP1056 (https://github.com/ethereum/EIPs/issues/1056):
Actor creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the Actor ID. The Actor system should be fit to use off-chain as well as on-chain.
Later, the user should be able to deploy its actor smart contract to its current Actor ID address generated previously offline. We can use the new opcode CREATE2 in the Ethereum Constantinople release to enable this feature.
Improve the standard ERC20 and ERC721 to be user-centric
In Ethereum, ERC20 are working well to create and exchange fungible tokens. However, the basic transfer function of a ERC20 is not user-center centric. The method checks directly the address signature (msg.sender) where ideally we would need to delegate to the actor authorization function.
As we consider only Actor ID as a kind of address which can own assets, we remove the traditional transfer method and as well methods related to allowance as this information is now stored into the Actor Smart Contract in the isTransferAuthorized method. Also, we propose a new version of the transferFrom method:
transferFrom(fromActorID, toActorID, uint tokens, bytes additionalData)
transferFrom calls at the beginning isTransferAuthorized from the Actor Smart Contract to check if the msg.sender is allow to transfer from fromActorID. We pass as well additionalData parameter into isTransferAuthorized in case the transfer needs a multisig. In case the smart contract with the address fromActorID doesn’t exist yet, we simply check if the single signature of the potential transaction msg.sender matches fromActorID.
Benefits of the actor-asset framework
By providing an actor-asset model, we now rely on the actorID to transfer assets and we are still being able to update the authorization conditions of future transfers later. We can recover actor account by calling recoverOwnership function. We got additional benefits such as complex multi-sig authorization, potential dApps monthly subscription by just upgrading the isTransferAuthorized function.
With this framework described, we propose the creation of 2 standards smart contracts (Actor and Updated ERC20, ERC721) to get a solid Actor-Asset model which puts the user as a first class citizen in blockchain account creation. At the same time, this framework is very open and simple as each actor is be able to customize their own isTransferAuthorized and recoverOwnership function. To get mass adoption from the end-user, we need to make sure anyone can create or recover their account easily the same way the people manage their webmail account today. We look forward to bring blockchain to the people.
Shamir, Adi (1979), “How to share a secret”, Communications of the ACM, 22 (11): 612–613, doi:10.1145/359168.359176.