The recent article by Vitalik on social recovery summarised his views on the different options for key management where he pushed for stronger adoption of social recovery wallets.
We resonate with much of what was mentioned. Especially the magnitude of key management issues, and the strong need for solutions better than mnemonics. Given that we’ve been working on the same problem for a while now, we want to present our thoughts on Smart Contract Wallets (SCW) that the social recovery Vitalik describes depends on, why we’ve gone a different direction with our suite of solutions (tKey, the Torus Network) and the tradeoffs that come with both.
Social Recovery is awesome, but SCW/multi-sigs on L2s are a tough problem
Social recovery as prefered by Vitalik manages a user’s account via a smart contract’s signing key. In the case of loss, Guardians which are added prior, allow changing of the signing key via social flows. While definitely a great ideal to work towards, Vitalik outlined SCWs that two main shortcomings to overcome in the near future:
- Gas costs. At ETH Gas Station’s standard gwei (250) and ETH’s price today this amounts to ~$35 per user to set up their SCW.
- Account abstraction and the reliance on relayers.
To address these issues, a migration to L2 and perhaps the inclusion of multi-sigs/SCWs on the protocol level was proposed. By no means is this a small task, there are definitely challenges to solve. With the different L2’s being dished out and the different SCWs/Multi-sigs in the space, each with their own technical architectures and business/project interests to align, one might expect implementations to vary quite a bit.
Because state is separate between all of the different L1s and L2s we face state issues. When we migrate, do we leave L1 state behind? Will we be able to have the same SCW on L1 as well as L2? Would we have to deploy our SCW on different L2s, deploying and syncing permissions on each? Combine this with ETH2 sharding complexity with managing state only increases.
On a technical level, these challenges are already complex, when we introduce building it for an onboardable UX for a mainstream user the restrictions are even tighter.
Using Threshold Cryptography (Off-chain Multi-sigs)
Because private keys are a relatively rigid crypto primitive, initiatives like SCWs/multi-sigs choose to wrap abstractions around accounts to provide more flexibility via an additional smart contract state that is managed on-chain. However, we can also secure accounts in the other direction, by using threshold cryptography to make private keys more flexible.
Initiatives, like Dark Crystal, Vault by Hashicorp, Shamir39 by Trezor as well as our tKey opt to go down this direction. The solutions often use a variation of Shamir Secret Sharing to split a user’s key into a number of shares. With a threshold number of these shares, a user is able to access/reconstruct their key (i.e. 2 out of 3). In specific, tKey has a focus on personal key management and user-centric flows and interested readers can try it out for themselves here.
It is very similar to a multi-sig but with one small (but impactful) difference — it results in a public-private key pair.
Tradeoffs between Threshold Key Management and SCWs/multi-sigs
As threshold key management results in a key pair, it’s directly and natively compatible with a multitude of other cryptographic constructs out there. When compared to SCW/multi-sigs, you have:
One account to manage — Instead of having to manage state across different L2s and L1 you only have one set of permissions/access control to worry about per account.
A key’s widespread compatibility — Cryptographic keys are the foundation of blockchains, and beyond being compatible with different chain states you can use your key to interact with whichever protocol out there be it zero-knowledge proofs on Aztec or staking on ETH2. Private keys are plug-and-play.
Supports use cases beyond blockchains — An application may want to simply sign a token to represent a login, encrypt data for a particular user. These constructions are by no means impossible for SCWs/multi-sigs but it introduces additional requirements and complexity to a stack.
Universally accepted — Key management is a universal problem across cryptography. Using key management structures that are more universally integrated allows blockchains to be more compatible, and potentially integrable with traditional software stacks.
Lack of generic computation — A strong benefit of SCWs is being able to read Ethereum state. You can set daily spending limits, add recoverability via timeouts, or even add DAOs as guardians. While wallets that support computation are definitely very powerful, arguably some of these features can be done client-side (e.g. daily thresholds) even if there aren’t consensus guarantees. Additionally, many useful security checks that applications use today (e.g. IP whitelisting) may be impossible to replicate on-chain.
Social Recovery flows via tKey
To an extent, social recovery flows can be replicated with tKey. To achieve:
There is a single “signing key” that can be used to approve transactions
There is a set of at least 3 (or a much higher number) of “guardians”, of which a majority can cooperate to change the signing key of the account.
We can create two separate sharings, one for the user to manage across their user devices (like a multi-sig) for personal use and another shared across people they know (like guardians). Hierarchies can be created for different groups through sub-sharings. Unfortunately, it is harder to replicate the timeouts or the “vault” architecture Vitalik through native crypto primitives since threshold key management doesn’t rely on Ethereum state.
Threshold Key Management or SCWs? Both?
As an ecosystem, on-chain wallets, with the power of generic computation have a lot to offer, but its compatibility and interoperability restrictions are definitely hurdles to overcome. As ETH2 progresses and more L2s evolve out with varying requirements, as well as other interesting low-level cryptographic tools that are being built, you can be sure that they will still always use native key pairs and we are always going to need good ways to secure them.
For us at Torus, we found the compatibility benefits from threshold key management very compelling. As an SDK it’s easier to integrate into different clients across platforms and blockchains, has no gas costs, and covers 80% of the access management flows required today. Because tKey is native it’s also naturally compatible with SCWs and we’re keeping an eye out for what could the right mix of solutions here. We’d love to work with any of the current SCW operators to see how that might look like.
For readers who want to try out what a Threshold Key Management flow could look like, you can check out tKey here. For developers, you can get the same experience in your application, no matter the platform. Check out docs.tor.us
