For the leakage of wallet private key and mnemonic phases, SAFE VAULT uses isolation security to improve and solve. For the problem of private key loss, SAFE VAULT will introduce a new security module in the next step: "OwnedWithTimer", which allows the Contract Timer After the specified timespan, the contract is allowed to specify the second owner to enter activation, This is a safe and meaningful new way to avoid wallet assets deadlock caused by the loss of the private key
The user experience of wallets, as the entrance to Web 3.0, directly affects when the crypto industry can usher in mass adoption. Although the major wallets have made great efforts in this regard, in the eyes of ordinary users, the wallet experience is still unsatisfactory. Although custodial wallets are easy to use, security is a big hidden danger, and there are endless incidents of wallet theft. Self-custodial wallets, while relatively secure, hold long mnemonic phrases and private keys in a much more complex way than the username-cryptosystem of the traditional internet. According to Chainalysis research reports, about 20% of bitcoins in circulation as of 2021 were lost because the owner did not remember the private key.
At the Devcon 6 conference held in Bogotá, Tomasz Tunguz mentioned some statistics of Web 3.0: the cumulative DAU of each mainstream public chain is about 2.5 million, while the DAU of the traditional Internet is 5 billion, Therefore, Web 3.0 is still far from mass adoption.
Three questions about wallet
The large-scale popularization of Web3.0 needs to solve some key problems, including one user experience problem and two security problems caused by wallet.
1. One UX question:
A. Mnemonic phases and private key are difficult to remember and save, resulting in high barriers to use for users
2. Two security concerns:
B. Leakage of mnemonic phases and private key led to asset theft.
C. The loss of mnemonic phases and private key leads to the loss of assets.
Why can we only verify it by means of a private key? To answer this question, we need some background knowledge and concepts. The first is the account type on Ethereum. There are two types of Ethereum accounts: external accounts(EOA) and contract accounts(CA).
Contract accounts are smart contracts whose code is run by the Ethereum Virtual Machine. The external account is the wallet account we usually use to initiate transactions, and it is called “external” because the account itself has no code, so it is independent of the Ethereum Virtual Machine and controlled by the user through the private key.
Although the contract account has custom logic, it cannot initiate transactions on its own initiative. Therefore, any change in contract status is initiated by an external account, which pays for Eth.
So how do you verify the legitimacy of a transaction? The verification method on Ethereum is the same as the initiator of the check transaction and the owner of the asset (Ether), that is, the owner of this external account. Therefore, the user needs to sign the transaction through the wallet. The correctness of the signature can be verified by verifying that the signature is from a private key corresponding to a common key, so the user must have the private key. That’s why no matter how much you optimize the user experience of your wallet, you can’t bypass the private key.
As mentioned earlier, external accounts do not have code logic. If you want to introduce more complex logic to implement other functions, such as multisig, etc., it cannot be carried out directly on external accounts. So, what are the current ways to solve this problem? We will introduce two solutions that are considered the most feasible and effective: MPC wallets and smart contract wallets.
MPC, or Multi-Party Computation, is an important cryptographic security measure. It contains a variety of technical solutions, which in the context of this article mainly refers to MPC-TSS. MPC wallet, on the other hand, realizes more complex verification methods such as “multi-sig” and “cross-chain” off-chain through multi-party calculation of private keys.
Simply put, it is to break a private key into multiple pieces, and hand over the private key fragments to a decentralized network for calculation and encryption. When a private key signature is required, the pieces are spliced together to form a complete private key. The core idea of MPC is to decentralize control to achieve the purpose of risk diversification or improve disaster preparedness, effectively avoiding security problems such as single point of failure.
The concept of “multi-party participation” of MPC wallet is somewhat similar to “multi-signature wallet”, but in fact, although the function of “multi-si” can be realized, the implementation of the two is different.
Multi-signature wallets that we know before, such as Gnosis Safe, etc., are wallets built on smart contracts, and the verification logic is defined in the contract, such as if you need to verify a transaction, you need more than one private key, or at least three of the five private keys for verification. This type of wallet belongs to the smart wallet mentioned later.
MPC wallets, on the other hand, decompose a private key into multiple fragments, and the verification process involves only one private key. And the computing network is off-chain and has no connection to smart contracts.
Smart contract wallets, as the name suggests, are wallets based on smart contracts rather than external accounts. There are already many smart contract wallets on the market, but because these smart contracts are customized, lack a unified industry standard, and have contract vulnerabilities and compatibility with other contracts, they have not been widely used.
The upcoming Ethereum Shanghai upgrade, Recently smart contract wallets have once again been a hot topic due to the significant development of the “account abstraction” proposal EIP-4337. So what exactly does account abstraction mean? After realizing the account abstraction, what kind of new experience can it bring to users?
Before we can understand account abstraction on Ethereum, we first need to understand the abstraction concepts in CS.
“Abstraction” is one of the most important concepts in computer science, which refers to providing the necessary key information to the outside world while hiding the implementation details behind it, so that developers only need to focus on this abstraction layer when dealing with the task of an abstraction layer.
In the same way as account abstraction, we, as wallet users, still need to consider many factors, such as gas price, gas limit, transaction blocking and other complex fee logic. The fundamental reason is that wallets based on external accounts cannot be well “abstracted”, which directly leads to users having to deal with many problems that should not be handled by users. So how to solve it?
The logic is simple, we can abstract the external account and the contract account to make the external account closer to the contract account, so that we can give the wallet more complex logic through smart contracts. The functions that smart contract wallets can achieve are not only the scenario of “multi-sign”.
If EIP-4337 enables a systematic upgrade of Ethereum accounts, what new experience can we get as users? Theoretically, any function that can be defined by smart contract code can be realized. First, smart contract wallets can be verified by non-secp256k1 validation algorithms, and users do not need to face long key pairs and mnemonic phrases.
At the same time, smart contracts can also give more logic to the key. For example, in the multi-signature scenario, define different permissions for each private key: transactions below 50USDC need to be signed by private key A, transactions above 50USDC require private key B signature, transactions over 2000USDC require private key ABC to co-sign, and so on.
In addition, it will be easier to interact with the blockchain through mobile terminals, we can authorize a key unique to the mobile phone, and we can define this key plus restrictions, such as only able to interact with a few fixed smart contracts, or smart verification of small transactions. Other features that can be implemented include one-click authorization for batch transactions, transaction blacklisting, and so on. In short, the imagination of smart contract wallets is very large.
1. Safe Vault
Safe Vault - Trustless Ethereum self-custodial contract safe, is a series of open source and secure Ethereum smart contracts. The funds you deposit (ETH and ERC20 assets) can be safely "escrowed", and only the owner of the vault can withdraw according to the pre-defined contract ratio.
NO 3RD PARTY
Safe Vault is powered by merkle trees. Normally dealing with merkle trees is complex and requires offchain storage, and often results in some business running it as a centralized service. But not with Safe Vault. You DO NOT need to rely on a 3rd party. Here's how it works::
1. MERKLE TREE ON IPFS: The merkle tree is stored on IPFS (future will on ARWEAVE sametime)
2. IPFS HASH STORED ON ETHEREUM: The IPFS hash of the merkle tree is then stored on the smart contract.
Therefore Vault does not have any centralized cloud that stores your merkle trees, and has no 3rd party reliance. Everything is on IPFS and Ethereum. Anyone can host Vault on their own.
SECURITY RISK ASSESSMENT
1. Contract security : Safe Vault smart contract is open source and has been tested for a long time. It accepts 3rd-party open audits and has unquestionable security.
2. Funds security : Each Safe Vault is a smart contract with its own independent address. Since there is no private key, once the funds are deposited into the vault contract, they will be permanently stored and operated according to the contract code, and the security of funds is fully guaranteed.
3. Safe Operation : SV (Safe Vault) is a free, client-side Web3.0 interface helping you interact with the Ethereum blockchain. Our easy-to-use, open-source platform allows you to generate Vault on-chain (contract wallets), interact with smart contracts, and so much more.
4. Isolation security : Funds are generally stored in the vault, and the wallet address of the owner of the vault has the right to withdraw money (equivalent to the vault key). If the private key of the owner's wallet is leaked, since the vault and the owner's wallet are information isolated, the hacker does not know the Vault information (1. He didn't know that it was the vault key that was leaked; 2. He didn't know the Vault address), so he couldn't steal the Vault funds.
5. Targeted attack : (1). If a hacker learns the fact that a certain wallet is a Safe Vault owner's wallet through a social engineering attack, (2). Then launches a subsequent targeted attack on it and successfully obtains the private key of the owner's wallet, (3 ). At this time, the information isolation between the Vault and the owner's wallet has been broken. The hacker may trace the transaction history data of the owner’s wallet through analysis tools, obtain the address of the Vault contract, and initiate a withdrawal operation on the Vault contract.
99% Safety Improvement
For the leakage of wallet private key and mnemonic words, SAFE VAULT uses isolation security to improve and solve. For the problem of Private key loss, SAFE VAULT will introduce a new security module in the next step: "OwnedWithTimer", which allows the contract timer After the specified sleep time, the contract is allowed to specify the second owner to enter activation, This is a safe and meaningful new way to avoid wallet assets deadlock caused by the loss of the private key.
Comprehensive risk analysis shows that application Safe Vault can improve security by 99% compared to general hot wallets; but for 100% fund security, we still recommend that you: (1). Protect the owner's wallet private key or mnemonic phrase Security; (2). Keep the privacy of the vault address and maintain the information security isolation between the vault and the owner's wallet..
Next step, Safe Vault will be to provide universal, independent, scalable, and open Web3.0 SafeVault API standards and services, we are waiting for the ethereum Account Abstraction and ERC-4337 proposal to be mature, and will gradually introduce MPC technology., so users can experience it carefully.
Among the MPC wallets that have appeared recently, we noticed that OpenBlock, a wallet with a long history that existed in 2014, recently launched a new MPC encryption protocol wallet through cooperation with OPEN-TSS, applying a 2-3 threshold signature scheme (TSS), approver model and multi-layer multi-dimensional security protection system. It has a good user experience and ease of use, but the shortcoming is that there is currently no open source plan for the key code of the OPENBLOCK wallet, and users can experience it carefully
After introducing the two wallets, readers may ask, which of these two solutions is better? The author believes that it is difficult to compare because MPC wallets and smart contract wallets are not essentially solving problems at the same level. MPC wallets are off-chain solutions that can control both regular wallets based on external accounts and smart wallets. The two have their own use cases and are not in conflict. Therefore, the author will list the opportunities and challenges of the two solutions separately.
As an off-chain solution, MPC wallet does not involve changes to the Ethereum consensus layer or contract layer, and the user cost is lower and more feasible in the short term. In addition, in some special usage scenarios such as cross-chain keys, it is more advantageous. Smart contract wallets are a systematic upgrade of Ethereum that can bring users more new experiences and use cases. However, account abstraction is a big project that requires “moving the crowd”, requiring other smart contracts, developers, and Ethereum architecture to cooperate with upgrades. The difficulty of the practical operation has made the vision that has been put forward since 2015 not fully implemented today. The most direct problem for smart contract wallets for users is that the cost of using the wallet will increase, and you need to pay fees from the beginning of creating the wallet.
We believes that smart contract wallets are our ultimate vision, and MPC is a more feasible solution in the short term, and it is more advantageous in some special scenarios.
Due to the cost problem, the feasibility and possibility of future smart wallet implementation on the Ethereum mainnet are low. Readers can pay more attention to account abstraction and smart wallet progress on Layer 2. At present, EIP-4337 is the most feasible account abstraction solution, and many smart contract wallet projects are already exploring this path, and the full landing of smart wallets may be closer than we think.