.webp)
.webp)
Web3 aka crypto currency aka block chains is built on the base assumption that you minimise trust in people and systems. The aim is to be trust-less and with it comes the variety of choices across various levels of the system that build up this eco system. We have varying levels of trust assumptions in the design of the block chains, the wallets we use and the protocols we interact with. In this piece I would like to dive deeper on the wallets that we use for holding digital assets, the choices out there on the trust spectrum.
At its core a block chain uses cryptographic signatures to verify the ownership of an asset, so you hold the private key, sign a transaction message with this private key, the block chain verifies that the signature is valid for the public key holding the asset and then executes that transaction. A gross over simplification of the process but at its guts this is what happens on almost all block chains. This private key that you hold is the key information that you have to safe guard for ensuring that your assets are completely controlled by you. A crypto wallet is the one that manages your private key and generates this signed transaction message for the block chain to execute. We will come to smart contract wallets a little later.
What you notice in this base transaction flow is that you as a user, as long as you can sign the transaction message and is posted for processing on chain, there is no other party in the middle between your assets and you. Nothing stops you from writing your own piece of code which generates a public/private key pair, store this private key anyway you please (write it down on a piece of paper, keep it on a secure encrypted server or even memorise it), and then retrieve it to sign the message for the block chain. How this private key is managed is where the key is.
Key to managing the keys!
How do we keep this insanely large number secure and make sure it does not get into the wrong hands, while making sure its easily accessible for generating signatures? Your wallet choices are various attempts to manage this private key on how they are stored, and retrieved for generating a signature. At one extreme you can have it stored in a secure air gapped custom built hardware which stores the key and will generate a signature given a message or you could have an app on a phone which stores this private key with a biometric safeguard or have it secured by a third party on a secure server with varying levels of data encryption and authorise access via passwords, 2fa schemes and so on.
Without getting too much into the weeds, from the perspective of Ethereum, a private key is a very large number and your public key is an (x,y) co-ordinate on a specific curve that Ethereum uses for its cryptographic signature verification. You can read lots of it online, highly recommend Practical Cryptography for Developers is an excellent starting point. It all boils down to how do you store this large number that is the key for your digital asset ownership.
If you manage the key on your own the biggest worry is how do you ensure you don’t loose access to the key because of a lost hardware device or a phone or what not. Most of these wallets give you the option to backup the private key so that you can then restore this onto a different wallet in case of an eventuality. Seed phrases are a way of encoding the private key in a human friendly manner by using simple words from a predefined dictionary to form a bit string of indexes which can be decoded to a large number.
Again I’m simplifying the HD wallet derivation and entropy aspects for a wallet generation and seed backup but the idea is that a seed phrase captures your private key in a succinct human friendly way. This is also the biggest attack vector. Seed phrases are there as the last resort for any eventualities, for continuity so you don’t loose access to the assets. People get tricked into giving the seed phrase away and if that is done no matter how secure that chip which holds your private key is you have given away your assets to someone else.
Social Wallets
So then you have your social wallets which generate / restore your private key based on credentials to a centralised server and maybe additionally secured by second and third factor authentication mechanisms. This is where third parties now come into the private key management.
There are again a range of parameters on which a wallet of this nature could be evaluated, a core tenet that is being introduced here is a trust assumption on the third party. What is the continuity for these wallets if the entity is not able to perform the duty for any number of reasons? It could range from temporary software glitches, network glitches or blackouts or shutdowns and what not.
Where is the eject switch where you can directly interact with the block chain to interact with your assets? If this again boils down to taking down your private key or seed phrase we are back to square one. If there is none then understand the risk and decide how to evaluate the trust on the third party.
MPC Wallets
MPC wallets come with a different approach to this private key management. In layman terms it uses cryptographic techniques to generate a private key. Again a rabbit hole to dive into but one specific approach which uses threshold signature scheme uses cryptography to assemble the signature from multiple parties. So rather than have the private key in a single place and generate the signature from that via a function call, think of this as a distributed logic where you could generate the signature in pieces and this can be assembled to form a valid signature to a private key which is not in anybody’s control or knowledge.
In this scheme of private key management you could have a trusted third party as one of the parties who provide a piece of the signature. Now we go back again to trust assumptions and how do you still fully remain in control. This could also be designed where you have the various parties be devices in your control, for eg; between your mobile and desktop. This gives full control while sacrificing the usability aspects on how the various devices need to be co ordinated for a transaction. This approach too needs to have failsafes, what happens if a device is lost, you could have a centralised 3rd party for this or another device altogether.
Plenty of options to solve these problems each leading to even more subtle issues on the nuances of trust levels. All the while these become more and more daunting for a someone to understand how the various pieces work together, where the risks are and what are the cases where self custody promise fails.
Smart Contract Wallets
So Smart Contract Wallets and where do they fit in. Lets look at it from an Ethereum perspective, as we recently launched one in Obvious Wallet. This is essentially an address on the blockchain which does not have a private key to prove ownership so while this wallet address looks very much like a normal ethereum address because this does not fall on the elliptic curve that EVM uses there is no private key to control this address.
Instead you have code deployed on this address. To interact with this wallet you now send messages to this wallet which contains some form of authorisation. The relayer of this message can be anyone and thanks to ERC-4337 this has been standardised. The code which controls the wallet is now free to implement whatever logic you want to ensure that you have ownership. Your ownership is now not bound to private key only, the authorisation could be as simple as using a different signature scheme that is not supported by EVM or complicated enough to have checks based on transaction values and approval schemes and probably tied to oracles to talk to outside systems.
While you could get wildly crazy on your authentication approach its probably wise to look at cryptographic ways to prove ownership. Using different signature schemes, using multiple signers, using a level of indirection like ownership of an NFT for ownership of wallet are all schemes which can be cooked up. This again opens up a different attack vectors on each authorisation scheme, trust assumptions there and continuity for each.
An additional area of concern is the compatibility across various EVM networks. A private key based signature is valid on all EVM compatible chains, an SCW with contrived authentication mechanisms need to look at how they would behave on different EVM chains. The ability to transact seamlessly across L1/L2/side chains are a key for EVM networks. However if the same wallet code with same configs are not deployed across different chains this could break user assumptions. Assume a multi sig where you added an additional signer on one chain but not on another. Synchronising across supported chains now become an additional point in your design consideration.
To conclude, the wallet space is a vast open space with lots of options to build on. How we present solutions without violating the core principles of true self custody and trust-less ness while maintaining user friendliness and user comprehensibility of the solution is going to be key for true mass adoption.
Recommended reading
- Nomenclature of Web3 Custody from Silence Labs
