How could we solve the pain point of private key management for crypto wallets?

1. The paint point of private key management

Private key (or seed phrase) management has been a major pain point for crypto users since day one. To the flip side of “Not Your Keys, Not Your Coins”, it is “If you lose your private key, you lose everything”.

Of course, you can write down your private key and seed phrase on paper, maybe multiple pieces if one is not safe enough and you want backup.

If you are a more advanced crypto user, you could buy a decent cold wallet and keep it offline most of the time.

There are other options like mobile wallets (e.g. Trust Wallet), browser wallets (e.g. MetaMask), desktop wallets (e.g. Electrum), smart contract wallets (e.g. Argent), MPC wallets (e.g. ZenGo and UniPass) and etc.

All of the above require the user to hold a private key or a share of the private key in order to sign transactions. The problem of single point of failure remains when you lose your private key.

There have been relentless efforts to solve this problem for mass adoption for crypto, such as Smart Contract, MPC and Account Abstraction.

2. A better solution needed

As per David Wheeler’s quote:

All problems in computer science can be solved by another level of indirection.

We have been asking ourselves what is the best place to store our private keys, the answer is “The blockchain itself” since we are already on it. Now the question is “How would it be possible and safe?”, the answer is that the concept has been proven to be feasible, and there are already some implementations emerging.

Lit Protocol is one of them.

3. How it works

1. Lit Protocol is based on TSS / MPC, and is a protocol running on a decentralised network governed by consensus.
2. The protocol slices your private key into pieces and store them across the network nodes with a certain degree of redundancy.
3. The private key shares will only be retrieved and aggregated in a designated HSM environment when the access conditions are all met, then things like transaction signing and secret decryption will take place in there, and the user would get the final results without exposing the private key to risks.
4. The access conditions are programmable, they could look like below.

If the user has valid access token and today is a Sunday, then grant user access to retrieve the key shares.

4. Pros and Cons

The advantages:

1. It is not a 2 of 2 or 2 of 3 scheme as most current MPC solutions.It is run by consensus across the entire network. There is no single point of failure as long as the network is up and running.The private key is never exposed to anyone, even to the owner.
2. Security is guaranteed as the key share retrieval and aggregation as well as signing take place in a designated HSM environment.
3. It is blockchain agnostic, it supports ECDSA and BLS at the moment, and more to be added, hence it supports most mainstream cryptocurrencies like BTC and ETH.
4. It is Web2 friendly, what it means is that the access conditions can be programmed to validate if the user has valid access to his Google account, if so then the access to key shares is granted. Being Web2 friendly is essential for mass adoption.
5. It is extensible in terms of security mechanisms and business logic, so that enhanced security mechanisms like MFA is feasible. It is critical for building a crypto wallet with bank level security.

Some challenges:

1. The security of the protocol is to be tested in reality, and ongoing efforts are required to maintain and upgrade the protocol to fix bugs and vulnerabilities.
2. The performance of the protocol is to be battle tested and proven in production, especially when it is at scale.