Author: Shew, Xianrang
In the Web3 space, private key management is a matter of life and death. Once a wallet's private key is stolen or lost, millions of dollars in assets can vanish in an instant. However, the vast majority of people are accustomed to using single-point private key management, which is akin to putting all eggs in one basket, making it easy to fall victim to phishing links and hand over all assets to hackers.
To address this issue, various solutions have emerged in the blockchain field. From multi-signature wallets to MPC, and then to the CRVA proposed by the DeepSafe project team, each technological advancement opens new pathways for asset management. This article will explore the principles, characteristics, and applicable scenarios of the three asset management solutions mentioned above, helping readers choose the path that best suits them.
Multi-Signature Wallets: Adequate, but Not Excellent
The concept of multi-signature wallets stems from a simple wisdom: do not concentrate all permissions in one place. This idea has long been widely applied in reality, such as in the separation of powers and board voting.
Similarly, in Web3, multi-signature wallets create multiple independent keys to disperse risk. The most common model is the "M-of-N" model. For example, in a "2-of-3" setup, the system generates three private keys, but only requires any two of them to generate a signature to allow the designated account to execute a transaction.
This design provides a certain level of fault tolerance—if one private key is lost, the assets remain secure and controllable. If you have multiple independent devices for storing keys, the multi-signature solution is relatively reliable.
Generally speaking, multi-signature wallets can be technically divided into two categories: one is conventional multi-signatures, which typically use on-chain smart contracts or supporting components of public chains to implement, often not relying on specific cryptographic tools. The other is multi-signature wallets that depend on special cryptographic algorithms, where security relies on the specific algorithm and sometimes can operate without the involvement of on-chain contracts. Below, we will discuss both solutions separately.
Representative of Conventional Multi-Signature Solutions: Safe Wallet and Bitcoin Taproot
Safe Wallet, one of the most popular multi-signature solutions today, implements multi-signature through conventional Solidity smart contracts. In the architecture of Safe Wallet, each multi-signature participant controls an independent key, while the on-chain smart contract acts as an "arbitrator." The contract only approves the multi-signature associated account to execute transactions when it collects a sufficient number of valid signatures.
The advantage of this method lies in its transparency and verifiability; all multi-signature rules are explicitly encoded in the smart contract, and anyone can audit the code logic. Additionally, users can add modules to the multi-signature account to provide richer functionalities, such as limiting the funding cap for each transaction. However, this transparency also means that the details of the multi-signature wallet are completely public on the blockchain, potentially exposing the user's asset management structure.
In addition to Safe Wallet, a well-known multi-signature solution within the Ethereum ecosystem, there are also multi-signature wallets built using BTC scripts in the Bitcoin network, such as those based on the OP_CHECKMULTISIG opcode. This opcode can verify whether the number of signatures included in the UTXO unlocking script meets the requirements.
It is worth noting that the conventional multi-signature algorithms mentioned above all support "M-of-N," but the multi-signature based on specific cryptographic algorithms introduced later may only support "M-of-M" mode, meaning users must provide all keys to conduct transactions.
Cryptographic Level Multi-Signature Implementation
At the cryptographic level, multi-signature verification can be achieved through specific cryptographic algorithms, and this solution can sometimes operate without the involvement of on-chain smart contracts. We often categorize them as follows:
Multi-signature algorithms. This signature algorithm only supports "M-of-M" mode, requiring users to submit all signatures corresponding to the keys at once.
Threshold signature algorithms. This algorithm supports "M-of-N" mode, but generally, the construction difficulty is more complex than the aforementioned multi-signature algorithms.
Secret sharing algorithms. In the design of this algorithm, users can split a single private key into multiple parts. When users collect enough private key fragments, they can recover the original private key and generate signatures.
Bitcoin introduced the Schnorr algorithm after the SegWit upgrade, which naturally allows for multi-signature verification. The Ethereum consensus layer uses the BLS threshold algorithm to implement the core voting function within the PoS system.
This purely cryptographic multi-signature solution has better compatibility because it does not rely on smart contracts, allowing for pure off-chain solutions.
The signatures generated by pure cryptographic multi-signature solutions are identical in format to traditional single private key signatures and can be accepted by any blockchain that supports standard signature formats, thus possessing strong universality. However, multi-signature algorithms based on specific cryptography are relatively complex, making implementation very difficult, and often require reliance on specific facilities during use.
Real-World Challenges of Multi-Signature Technology
Although common multi-signature wallets significantly enhance asset security, they also introduce new risks. The most obvious issue is the increased operational complexity: each transaction requires coordination and confirmation from multiple parties, which can become a major obstacle in time-sensitive scenarios.
More seriously, multi-signature wallets often shift the risk from private key management to the signature coordination and verification stage. As seen in the recent Bybit theft case, attackers successfully deceived Bybit's multi-signature managers into signing phishing transactions by implanting phishing code for the Safe front-end interface in the AWS facilities relied upon by Safe. This indicates that even with advanced multi-signature technology, the security of the front-end interface and the signature verification and coordination stages remains fraught with vulnerabilities.
Moreover, not all signature algorithms used by blockchains natively support multi-signatures. For example, the secp256k1 curve used by the Ethereum execution layer has few multi-signature algorithms, limiting the application of multi-signature wallets across different ecosystems. For networks that require smart contracts to implement multi-signatures, there are additional considerations such as contract vulnerabilities and upgrade risks.
MPC: Revolutionary Breakthrough
If multi-signature wallets enhance security by dispersing private keys, then MPC (Multi-Party Computation) technology takes it a step further by fundamentally eliminating the existence of complete private keys. In the world of MPC, complete private keys never appear in any single location, not even during the key generation process. At the same time, MPC often supports more advanced functions, such as refreshing private keys or adjusting permissions.
In the application scenarios of cryptocurrencies, the workflow of MPC demonstrates unique advantages. During the key generation phase, multiple participants each generate random numbers, and then through complex cryptographic protocols, each party computes its own "key fragment." These shares have no meaning on their own, but they are mathematically related and can collectively correspond to a specific public key and wallet address.
When a signature is needed for a specific on-chain operation, each participant can use their key fragment to generate a "partial signature," which is then cleverly combined through the MPC protocol. The final signature generated is identical in format to a single private key signature, and external observers cannot even tell that this signature was generated by an MPC facility.
The revolutionary aspect of this design is that the complete private key never appears anywhere throughout the process. Even if an attacker successfully breaches a participant's system, they cannot obtain the complete private key because it essentially does not exist anywhere.
Essential Differences Between MPC and Multi-Signature
Although both MPC and multi-signature involve multiple parties, there are fundamental differences between the two. From the perspective of external observers, transactions generated by MPC cannot be distinguished from ordinary single-signature transactions, providing users with better privacy.
This difference is also reflected in compatibility. Multi-signature wallets require native support from the blockchain network or rely on smart contracts, which limits their use in certain areas. In contrast, signatures generated by MPC use the standard ECDSA format and can be used anywhere that supports this signature algorithm, including Bitcoin, Ethereum, and various DeFi platforms.
MPC technology also offers greater flexibility in adjusting security parameters. In traditional multi-signature wallets, changing the signature threshold or the number of participants usually requires creating a new wallet address, which can introduce risks. (Of course, multi-signature wallets based on smart contracts can conveniently modify participants and their permissions.) In an MPC system, these parameter adjustments can be completed more flexibly and simply without changing on-chain accounts and contract code, providing greater convenience for asset management.
Challenges Faced by MPC
However, while MPC is superior to ordinary multi-signature solutions, it still faces corresponding challenges. The first is implementation complexity. MPC protocols involve complex cryptographic computations and multi-party communications, making system implementation and maintenance more difficult. Any bug could lead to serious security vulnerabilities. In February 2025, Nikolaos Makriyannis and others discovered a method to steal keys within an MPC wallet.
Performance overhead is another challenge. MPC protocols require complex computations and data exchanges between multiple parties, consuming more computational resources and network bandwidth than traditional single-signature operations. Although this overhead is generally acceptable in most cases, it may become a limiting factor in scenarios with extremely high performance requirements. Additionally, MPC systems still require online coordination among participants to complete signatures. Although this coordination is transparent to users, it may affect system availability in cases of unstable network connections or when certain participants are offline.
Furthermore, MPC still cannot ensure decentralization. In the 2023 Multichain case, all 21 nodes participating in the MPC computation were controlled by a single individual, representing a typical Sybil attack. This incident is sufficient to prove that merely having dozens of nodes on the surface does not provide a high level of decentralization assurance.
DeepSafe: Building the Next Generation of Security Verification Networks
In the context of relatively mature multi-signature and MPC technologies, the DeepSafe team has proposed a more forward-looking solution: CRVA (Cryptographic Random Verification Agent). DeepSafe's innovation lies in the fact that it does not simply replace existing signature technologies but builds an additional security verification layer on top of the existing solutions.
Multi-Factor Verification of CRVA
The core idea of DeepSafe is "double insurance": users can continue to use their familiar wallet solutions, such as Safe Wallet. Once a multi-signature transaction is completed and submitted to the blockchain, it will automatically be sent to the CRVA network for additional verification, similar to the 2FA multi-factor verification of Alipay.
In this architecture, CRVA acts as a gatekeeper, reviewing each transaction based on user-defined rules. For example, limits on single transaction amounts, whitelists for target addresses, transaction frequency restrictions, etc. If any anomalies occur, the transaction can be interrupted at any time.
The advantage of this 2FA multi-factor verification is that even if the multi-signature process is manipulated (such as in the phishing attack on Bybit), the CRVA, as insurance, can still refuse risky transactions based on preset rules, protecting users' asset security.
Technological Upgrades Based on Traditional MPC Solutions
To address the shortcomings of traditional MPC asset management solutions, DeepSafe's CRVA solution has made significant improvements. First, the CRVA network nodes adopt an asset staking admission model, and the mainnet will only officially launch after reaching approximately 500 nodes. It is estimated that the assets staked by these nodes will be maintained at tens of millions of dollars or higher over the long term.
Secondly, to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm, for example, selecting 10 nodes every half hour to act as validators, verifying whether user requests should be approved, and then generating corresponding threshold signatures for release. To prevent internal collusion or external hacker attacks, CRVA's lottery algorithm uses an original circular VRF combined with ZK to hide the identities of the selected participants, making it impossible for outsiders to directly observe who has been selected.
Of course, achieving this level is not enough. Although outsiders do not know who has been selected, the selected participants themselves do know, so there is still a path for collusion. To further eliminate collusion, all nodes in CRVA must run core code within a TEE (Trusted Execution Environment), effectively placing core operations in a black box. This way, no one can know whether they have been selected, unless they can break the TEE trusted hardware, which is extremely difficult to achieve under current technological conditions.
The above describes the basic idea of DeepSafe's CRVA solution. In the actual workflow, there will be a significant amount of broadcast communication and information exchange among the nodes in the CRVA network, and the specific process is as follows:
1. Before entering the CRVA network, all nodes must first stake assets on-chain and leave a public key as registration information. This public key is also known as the "permanent public key."
2. Every hour, the CRVA network will randomly select several nodes. However, before this, all candidates must locally generate a one-time "temporary public key" and simultaneously generate a ZKP (Zero-Knowledge Proof) to prove that the "temporary public key" is associated with the on-chain recorded "permanent public key"; in other words, everyone must use ZK to prove their existence on the candidate list without revealing who they are.
3. The role of the "temporary public key" is to protect privacy. If the lottery were conducted directly from the "permanent public key" set, the results would directly reveal who was selected. If everyone only exposes their one-time "temporary public key" and then selects a few from the "temporary public key" set, you would at most know that you were selected but not who the other selected temporary public keys correspond to.
4. To further prevent identity leakage, CRVA intends to ensure that you do not even know what your "temporary public key" is. The generation process of the temporary public key is completed within the node's TEE environment, and those running the TEE cannot see what happens inside.
5. Then, the temporary public key is plaintext encrypted into "gibberish" within the TEE before being sent to the outside world, and only specific Relayer nodes can restore it. Of course, the restoration process also takes place within the TEE environment of the Relayer, and the Relayer does not know which candidates correspond to these temporary public keys.
6. After the Relayer restores all "temporary public keys," it collects them and submits them to the on-chain VRF function, from which the selected participants are drawn. These individuals then verify the transaction requests sent from the user front end and generate threshold signatures based on the verification results, which are finally submitted to the blockchain. (It should be noted that the Relayer here is also hidden in identity and selected periodically.)
Some may ask, if each node does not know whether it has been selected, how does the work proceed? In fact, as mentioned earlier, everyone will generate a "temporary public key" in their local TEE environment. After the lottery results are announced, we simply broadcast the list, and everyone just needs to input the list into the TEE to check whether they have been selected.
The core of DeepSafe's solution is that almost all important activities occur within TEE hardware, making it impossible to observe what happens from outside the TEE. Each node does not know who the selected validators are, preventing collusion and significantly increasing the cost of external attacks. To attack the CRVA committee based on DeepSafe, one would theoretically need to attack the entire CRVA network, and since each node has TEE protection, the difficulty of the attack increases significantly.
As for the possibility of CRVA acting maliciously, since CRVA is an automated node network system, as long as the initial code does not contain malicious logic, there will be no situation where CRVA actively refuses to cooperate with users, so this can be largely ignored.
If CRVA experiences a large number of node outages due to force majeure such as power outages or floods, users still have a way to safely withdraw their assets based on the processes mentioned above. The trust assumption here is that we trust CRVA to be sufficiently decentralized and will not act maliciously (the reasons have been fully explained earlier).
Conclusion
The development history of Web3 signature technology showcases humanity's relentless exploration in the field of digital security. From the initial single private key to multi-signature wallets, then to MPC, and emerging solutions like CRVA, each advancement opens new possibilities for the secure management of digital assets.
However, technological progress does not mean the elimination of risks. Each new technology may introduce new complexities and risk points while solving existing problems. As seen in the Bybit incident, even with advanced multi-signature technology, attackers can still bypass technical defenses through social engineering and supply chain attacks. This reminds us that technological solutions must be combined with good operational practices and security awareness.
Ultimately, the security of digital assets is not just a technical issue but a systemic challenge. Whether it is multi-signature, MPC, or CRVA, they are merely experimental solutions to potential risks. As the blockchain industry evolves, there is still a need for innovation to find safer and more trustless pathways in the future.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
