Current wallet status
So far, we have seen a lot of blockchain wallet solutions, and they try to do a lot of things at the same time. So far, the function of wallet is not complete, but as we enter a world where users want to interact with many networks, the current unscalable architecture cannot meet this need. At a high level, the various responsibilities of Wallet include:
- Private key management
- Application interface
- Transaction management
Ethereum blockchain wallet has experienced some of these growth pains, because Turing complete virtual machines like EVM allow almost any kind of applications to exist, and they all expect to work from a wallet. Although Ethereum blockchain wallet has proposed protocols and clever solutions to provide interfaces for a variety of applications, they still expect that these applications come from a common EVM infrastructure. As we see the pattern of specific application blockchain become a reality, the boundaries of how Ethereum handles various applications will be broken through IBC connection.
The practical way is to separate the concerns. Let these three tasks exist as independent solutions, each of which can focus on doing its own unique task. This will reveal the need for a new type of service, which I have always called account coordination function.
Private key management
Cryptography is very difficult. If you are not an expert, the chances of making mistakes are high, and the consequences can be disastrous. It is unfair to expect all wallet and dApp developers to have this expertise internally. Traditional applications have recognized this and often solve it by entrusting authentication to third parties using the oAuth standard.
You may think that the only real responsibility of the wallet is to keep your private key safe. But when I introduce other common features, you will find that this is far from the case. In fact, this is often the last ability that wallet builders have. Cryptography and security experts should be responsible for developing industry-standard solutions and implementing best practices for private key storage. This should be all their business, but instead, we see that wallets are doing a good job in terms of security now – but when it comes to cryptography, it is not good enough.
If the responsibility for private key storage is removed from the blockchain wallet, it may lead to a wider variety of security solutions that rely on different assumptions and provide different functions. At present, there are many private key solutions beyond traditional software storage:
hardware security modules in Ledger, or other encryption technologies, such as Shamir secret sharing used by Torus, threshold schemes used by ZenGo, multi-party computing, or novel zero-knowledge technologies. To solemnly declare, I think the shared responsibility space for keeping private key management has not been developed at all.
No matter how the private key is stored, the responsibility of the storage scheme should actually end there. It only does one thing, and it should do a good job — store the private key. Access to private keys should be handled by similar security authorization technologies.
Application interface
Nowadays, a wallet has a wide range of application interfaces. On the one hand, some wallets provide deep integrated access to application functions. Both Argent and Gnosis Safe support an increasing number of custom interfaces on the basis of each application. This is also the route of most Cosmos wallets, and the network expects the minimum take and governance interface. Providing a custom interface directly within your wallet means you can ensure a better user experience, but it limits the number of apps your wallet can access and also limits your blockchain wallet becoming new.
At the other end, it is an attempt to shift most of the interface responsibility to the wallet of the application developer. Generally, wallets use web3.js or cosmJS to connect an API or interface to the application. Alternatively, the wallet may contain its own browser and has integrated APIs (Mist, Metamask Mobile, Status and Coinbase blockchain wallet).
They can also use browser extensions to access the API (Metamask, Keplr). WalletConnect allows interfaces to be transferred between mobile and desktop browsers and between mobile and mobile. Either way, it is up to the application developer to access and utilize the Wallet API to provide users with signature functions. This path eliminates the bottleneck of wallet as an accessing application, but it also brings its own challenges — security and smooth user experience.
A secure authorization technology should be considered to ensure that the application can access the signature function without persuading users to quit because of the confirmation interface and do not put users in the situation of accidentally signing. MetaMask has been trying to solve this problem.
It creates a combinatorial security interface for private keys to communicate with applications, called “Snaps”. It draws heavily on the work of Mark Miller, Agori’s chief scientist, on object capabilities, which encodes precise object-level controls that can be transmitted across environments. Snaps provides the security and standardization needed to connect applications and private key managers, but I think Metamask is not far enough on this architecture, because all three blockchain wallet functions may be isolated and composed of this model.
Transaction management
Although we have seen many wallets have taken on the heavy responsibility of providing application interfaces, I still believe that the main responsibility of blockchain wallets so far is private key management. This makes the third responsibility of the wallet, transaction management, seriously insufficient resources.
I would like to see this become the main responsibility of the wallet, because application interface and private key management become the responsibility of the designated third party.
Transaction management can be regarded as the actual interface between the application and the signature solution. This is a step in which requests for some operations are resolved into formats that can be signed by private keys. It includes communication with applications and private key management. Between these, the data to be signed should be parsed and displayed to users in a way that allows the user to understand what and why they are signing. In addition, the history and status of these signature requests should be recorded and provided to users.
Transaction management is tricky when using Ethereum blockchain wallet, because there is basically only one transaction type (eth_send), but it includes a data field that can refer to any number of methods when targeting smart contracts. If you’re lucky, the wallet has access to the ABI file of a specific contract that interacts with it, allowing data fields to be converted to function names and parameters. ABI files can also allow the wallet to display events sent after the transaction is successfully processed. This enters the realm of block browser, which is a complete service, basically dedicated to account history — and the history of the whole network. However, so far, block browsers have mostly been single in terms of network.
In this space, there are many different messages that can be included in the transaction. Each of these messages has different functions, but it is traditionally self-run, so external ABI files are not required. As we migrate to protobuf, we see ongoing discussions on how to preserve these properties while ensuring all the performance improvements that protobuf brings. One option would be to use it like an ABI in protobuf files, but many other solutions are still being explored.
This is a thorny issue regardless of network architecture, but it is essential to ensure that users can verify what they are doing. This problem becomes more complicated when additional private keys are added to this combination. Some wallets already allow you to create many accounts, all from a common mnemonics and private key derivative paths.
This is a very useful function for users who do not want to mix their defi accounts with game accounts. You can switch between networks through private key derivatives, although I don’t know which Ethereum blockchain wallet allows you to merge accounts by supporting multiple mnemonics and private keys (Keplr does though). This places a burden on users to track which identity is associated with which private key.
Account coordination function
Transaction management has not been adequately served, and with the increase of network and the corresponding private keys, the problem will only become more and more serious. This problem will multiply as the ability of the sub-private key to allocate account capacity to a specific private key increases. The expanded scope of responsibility is worth giving the role a new name. I want to give a reason for a new type of wallet, which is mainly focused on becoming an account coordination service.
The main goal of account coordination function is to track which private keys have what functions on which networks — and how to use protocols such as WalletConnect to access the signature function of these private keys. While it should strive for external privacy and anonymity, from a user’s point of view, it should provide a complete overview of all dApps, private keystore and network activities.
It may require the primary public key of a private key mnemonics in order to derive all possible public keys. This will allow the Account Coordination feature to check all possible accounts on all possible networks to see if you have interacted there. It will detect whether the private key is part of a multi-signed, contract-based blockchain wallet, group module or sub-private key. As you confirm, it will start tracking all these accounts for you, remembering your preferences, and when to use which private key.
The account coordination feature should allow you to audit your interactions on each app while maintaining a consistent history—think Google’s oAuth tells you which services and devices you’re currently logged in. Ultimately, this should look like a user-centric multi-network block browser that tracks all your own private keys and coordinates them on your behalf.
This will require a lot of information about the many networks you have used or may interact with in the future. This information can be collected from different sources and will depend on which application you are facing. I imagine most of the information should come from the application itself, through an interface like WalletConnect.
The account coordination function will be firmly between your private key and the application, it will act as an intermediary between the two parties, and will join all your interactions on the blockchain-based network. It will be built for you only, so although it will have your information treasure house, it can only be accessed at your own discretion.