DAOrayaki: What kind of social recovery system does the Ethereum community need?

特邀专栏作者

2022-08-20 14:00 (UTC+8)

This article is about 6087 words, reading the full article takes about 9 minutes

This post will discuss what social recovery wallets are, alternative use cases for social recovery systems, and user feedback.

AI Summary

Expand

This post will discuss what social recovery wallets are, alternative use cases for social recovery systems, and user feedback.

Original Author: Vitalik, isthisanart

Original title: What the Ethereum community would like to see in a social recovery system

One of the biggest challenges in making cryptocurrencies and blockchain applications usable to the average user is security: how do we prevent users from losing or having their funds stolen? Lost and stolen coins are a serious problem, often costing innocent blockchain users thousands of dollars, and in some cases, most of their net worth.

Over the years, many solutions have been proposed: paper wallets, hardware wallets, and my ever-favorite multi-signature wallets. In fact, they have led to dramatic improvements in security. However, these solutions all have various flaws - sometimes providing far less additional protection against coin theft and loss than is actually needed, sometimes being cumbersome to use resulting in little adoption, and sometimes both There are. At the beginning of 2021, v God proposed an alternative plan and emphasized again in the article "Decentralized Society: Finding the Soul of Web3" in May this year: an updated smart contract wallet, called "social recovery wallet" (social recovery wallet) . Compared with previous options, these wallets have the potential to provide a high level of security and better usability. When the Ethereum ecosystem migrates to the rollup layer-2 solution on a large scale, it can effectively solve the two major problems currently facing social recovery wallets: (1) Rely on centralized relayers, (2) High transaction fees. The DAOrayaki community sorted out and compiled a series of proposals for the social recovery system into this article. This post will discuss what social recovery wallets are, alternative use cases for social recovery systems, and user feedback.

1. Social Recovery Wallet

The social recovery system works as follows:

Only one "signing key" can be used to approve transactions
There are at least 3 (or more) "guardians", most of whom can cooperate to change the account's signing key.

The signing key has the ability to add or remove guardians, but only after a period of time (usually 1-3 days).

In all normal cases, users can simply use their social recovery wallet like a normal wallet, sign messages with their signing key, and each transaction signed can be quickly completed with a single confirmation, just like in As in "traditional" wallets (like Metamask).

If a user loses their signing key, that's when social recovery kicks in. Users simply need to contact their guardians and have them sign a special transaction that changes the signing public key registered in the wallet contract to a new signature. It's easy: they can simply visit a web page, say security.loopring. Review and sign the recovery request. It's as easy as trading Uniswap for each guardian.

There are many possible options for who you choose to be your guardian. The three most common options are:

Other devices (or paper seed phrases) owned by the wallet holder themselves
friends and family
The agency will sign the resume upon receipt of confirmation from your phone number or email, or in critical cases, verify your identity in person via video call

Guardians are easy to add: you can simply enter their ENS name or ETH address to add a guardian, although most social recovery wallets will require guardians to sign a transaction on the recovery web page to agree to be added. In any properly designed social recovery wallet, there is no need to download and use the same wallet; they can simply use their existing Ethereum wallet, no matter what type of wallet it is. Given the high level of convenience of adding guardians, if you're lucky enough that your social circle already consists of Ethereum users, I'd personally lean towards a higher number of guardians (ideally 7+) for added security. If you already have a wallet, there's no need for guardians to keep trying: any recovery operations you do will be done through your existing wallet. If you don't know many other active Ethereum users, you trust a small number of technically competent guardians to be the best.

To reduce the risk of guardian attacks and collusion, your guardians don't have to be public: in fact, they don't need to know each other's identities. This can be achieved in two ways. First, rather than storing the guardian's address directly on-chain, a hash of the list of addresses is stored on-chain, and the wallet owner simply publishes the full list when restored. Second, each guardian can be required to deterministically generate a new single-purpose address that they will only use for that particular recovery; they don't need to use that address to actually send any transactions unless the recovery is actually needed. To complement these technical protections, it is recommended to select a diverse set of guardians from different social circles (ideally including an institutional guardian); these recommendations taken together will make it difficult for guardians to be simultaneously attacked or complicit.

In the event of your death or permanent incapacity, guardians can publicly identify themselves so they can find each other and recover your funds.

The social recovery wallet is not a betrayal, but an expression of "cryptographic value".

A common response to the proposal to use any form of multisig, social recovery or otherwise, is that such a solution can be traced back to the idea of "trusting people", aka a betrayal of the values of the blockchain and cryptocurrency industry . While I understand why people think so at first glance, I would say that this criticism stems from a fundamental misunderstanding of encryption.

To me, the goal of cryptocurrencies has never been to remove the need for all trust. Instead, the purpose of encryption is to give people access to encryption and the bedrock of the economy, to give people more choice in who to trust, and to allow people to build a more constrained form of trust: giving someone the power to do something on your behalf without giving They have power to do whatever they want. Viewed in this light, multisig and social recovery are a perfect expression of this principle: each participant has some influence over the ability to accept or reject transactions, but no one can unilaterally move funds. This more complex logic allows for a mechanism that is far more secure than unilateral control of funds by a single person or key.

The basic idea that human input should be used sparingly, rather than discarded entirely, is powerful because it aligns so well with the strengths and weaknesses of the human brain. The human brain is poorly adapted to memorizing passwords and tracking paper wallets, but it is a specialized chip for tracking relationships with other people. This effect was stronger for non-technical users: they might struggle with wallets and passwords, but they were just as good at social tasks like "choose 7 people who won't team up against me." If we can extract at least some information from human input into a mechanism without turning those inputs into vectors for attack and exploitation, then we should figure out how to do that. Social recovery is very strong: for a wallet with 7 guardians to be compromised, 4 of those 7 guardians would need to somehow discover each other and agree to steal funds, none of which would give all Bring a tip. Of course, this is a tougher challenge than attacking a wallet purely protected by one person.

2. Alternative use cases for social recovery wallets

In the article in January 2021, v God briefly introduced the principle and characteristics of the social recovery wallet (that is, the smart contract wallet) through two examples of Argent and Loopring. and presenting "Alternative Mechanisms for Social Recovery Use Cases" on ethresear.ch [1] in July 2021. Our paper focuses on: this alternative mechanism.

The term Dark Crystal Web3 is derived from a proposal by Vitalik Buterin after the original post[2] in 2021, which suggested a system where recovery partners would not need to install software or hold any other data, provided they had a personal Ethereum wallet .

Magma Collective is currently working on developing it into an MVP (Minimum Viable Product). This is a social recovery protocol for which we identified three main important functions.

The app does not require restorers to remember anything, except the access password of their Ethereum master wallet;
The app is supposed to be confidential, meaning it can back up any kind of secret, including but not limited to Ethereum private keys;
The application should ideally allow anonymity for both the secret owner and the recovery partner.

Since the application deals with secrets, perhaps with high value, it is critical to verify the security assumptions and trust requirements in our project.

The system consists of two parts:

A web-based dAPP for use by recovery partners that calls web3 APIs to generate cryptographic key pair derived signatures and retrieve and decrypt shares from contracts during recovery.
An offline-first software component for backup personnel. Given a list of secret and public keys, a set of encrypted shares is generated and published to the blockchain. As an offline punch, the program does not actually post, but generates dapp links that contain encrypted payloads. This can then be transmitted to any browser with a web3 extension (e.g. via a QR code).

The basic process of its operation can refer to: https://gitlab.com/dark-crystal-web3/dark-crystal-web3-design-document

3. What kind of social recovery system does the Ethereum society need?

A social recovery system built on top of Ethereum with an emphasis on usability.

As part of the initial phase of MVP development, Dark Crystal Web3 conducted user research on core tools and protocols in the Web3 and Ethereum communities, interviewed representatives from WalletConnect, 3Box, Metamask, Gnosis Safe, Rainbow and Tally, and on Twitter and Discord An anonymous questionnaire was distributed. This goal is to take into account not only the usability of the Dark Crystal Web3 project, but also social recovery, an important protocol currently envisaged, and the potential need for instrumentation.

The role of cold storage
What is the technical level of the user?
What kind of "identity" is already in use on-chain, and the preference for anonymity
The role of on-chain storage and centralized storage
Most Important Roadmap Considerations

The role of cold storage

Availability is prioritized, which is an important consensus, and our most important finding is that cold storage use cases are rare. Cold storage refers to keeping keys in a way that is never connected to the internet — this could be a paper wallet, or a hard drive connected only to an offline computer. It is widely regarded as the most secure way of storing keys. However, conducting transactions with cold-storage keys presents a significant usability hurdle: a wallet program must typically be downloaded and set up on an offline computer, which packages and signs the transaction, which is then transferred to another device and exported to the public. broadcast. Since our application deals with privacy, we wonder how likely users are to accept this process?

Perhaps a little surprised, we found this security practice uncommon. Or more precisely, the subset of overlap between the cold storage keys and the keys users will back up with our application is very small. In all of our sync conversations, we've learned that while supporting a cold storage path is important, users won't use it. From those respondents who did have cold storage keys, we learned that they would only use a system like ours for less valuable hot wallet keys.

Respondents were somewhat more inclined towards cold storage - 33% said they would keep their keys in cold storage at all times. As the research lengthened, we also received feedback that the most security-conscious users tended to have their own backup systems rather than trust ours. Consider that those most in need of social recovery are often not tech-savvy: "Anyone who can use the command line doesn't need social recovery".

What is the technical level of the user?

In fact, what kind of technical literacy we can ask users to have is another area of discussion-what tools, wallets, etc. are our potential users familiar with or need?

Architecturally, Dark Crystal Web3 involves a browser-based hosted application, and a Rust command-line component with a web frontend that can be served locally. Our survey respondents and respondents were technical, with 80% saying they would be happy to use a command-line application if necessary. The current architecture plan is motivated by a desire to support cold storage, but based on feedback we suspect that if we had a fully managed version of our application, only a small percentage of clearly motivated users would use it in other ways use it. These feedbacks are so strong that even though we have worked from cold storage to colocation, including design and execution, it is not impossible to go the other way.

Although we discussed browser-based dapps as the main entry point, we received strong feedback from 2 out of 6 respondents that downloadable apps are a more worthwhile option due to the frequency of phishing attacks. Trusted and preferred design patterns. Overwhelmingly, tools like Metamask, Walletconnect, mobile wallets, and block explorers presented no problems for respondents or respondents. While we try to make the protocol agnostic about whether secrets are backed up or not, we believe that all potential secret owners have joined Ethereum. We have heard clearly many times that non-Ethereum users will be less likely to choose our social recovery protocol. In other words, they hope that recovery partners can cover technical novices, those who don't even have wallets. We need to account for this unique requirement.

What kind of "identity" is already in use on-chain, and the preference for anonymity

One of our core questions is how to support participant anonymity: how much anonymity is required, and how can recovery data be reliably found later while maintaining anonymity? There are several potential solutions, all involving storing recovery data with some kind of lookup key that can be hashed or derived from the user's main wallet. However, we wondered whether user usage patterns would support this practice. Do people keep one persistent wallet, or are they constantly switching between different wallets forked from the same seed? Do they generate new seeds? All in-person interviews confirm that our typical user will have a "master Ethereum address" that they cannot possibly forget under any circumstances. Interestingly, however, half of the respondents said that it is possible or true that users have forgotten this, or never have. The frequency of the "master Ethereum address" as an identity concept is a potential area of future research.

Overall, the feedback is very supportive of anonymity, but we've heard repeatedly that once a significant number of users are part of the app, the "needle in a haystack" level of anonymity is enough in many cases. But it wasn't clear how this would get off the ground, or exactly what threshold would be reached to make this happen. We discussed with several interviewees whether there is a public protocol that could be used to map Ethereum addresses to public cryptographic keys, thus providing a starter package for this anonymity, but did not find an existing project that could fill this Role. We also found that the anonymity of the recovery partner was more agreed upon than the anonymity of the secret owner, as shown in the figure below.

Three respondents raised concerns that they might forget who their recovery partner is, and we've had feature requests to be able to switch recovery partners multiple times.

On-chain storage and centralized storage

We have received criticism for storing encrypted secrets on-chain in two contexts, one from a cost perspective and one from concerns about quantum threats to cryptography. That’s right, if any of the cryptography we use is ever broken, all the secrets our protocols store will be affected. In terms of cost, respondents and respondents agreed that around $200 is the upper limit for an application's transaction costs, with lower costs being more welcome.

We've heard that for our use case, there's no advantage to being on mainnet versus being on another ethereum-like network like polygon or gnosischain. Finally, it has been suggested to consider a centralized path for applications where users can choose not to store on-chain, which of course presents other potential problems (continuous maintenance, potential leaks), but may still meaningfully increase reliability. accessibility. 37% of respondents said they would be more comfortable with off-chain storage. Also, long-term maintenance of the protocol was cited as a concern on several occasions: how can potential users trust the recovery process to still work after our team has potentially disbanded or undergone major changes? And, is there any way for the secret owner to verify that the secret is recoverable without going through the whole process?