Correct management of MPC wallets from the perspective of the Multichain incident
MPC wallet management in light of the Multichain incident
Author: Loki, Senior Researcher at New Fire Technology
1. What are the problems with MPC wallet management exposed behind the Multichain incident?
On July 14th, Multichain tweeted that its CEO Zhaojun was taken away by the police on May 21st and has since lost contact with the Multichain global team. The team contacted the MPC node operator and learned that the operational access keys to its MPC node servers had been revoked.
This tweet reveals the reason for the abnormal operation of Multichain and also raises a question: Why does Multichain still face such risks even when using MPC? The answer is simple. Multichain adopts MPC technology to manage the treasury, but using decentralized technology does not mean decentralization; it requires centralized management in terms of technology adoption and management methods.
There are many similar cases. BTC is decentralized, but if a miner monopolizes 100% of the computing power, the decentralization of the algorithm becomes meaningless. ETH is decentralized, but Vitalik Buterin still emphasizes the importance of DVT (Distributed Verification Technology) to avoid centralization trends.
- Exclusive interview with the Father of Move Language Why is the Sui...
- LianGuai Daily | Uniswap launches cross-AMM protocol UniswapX; Arkh...
- Next-generation DeFi Protocol Cornerstone Tamper-proof Data Solution
In the case of Multichain, if we further examine the announcement, we can find that the reason for Multichain’s problems is that all node servers are actually running under Zhaojun’s personal cloud server account. This centralized nature of node servers is similar to a miner monopolizing 100% of the computing power. The management method of Multichain is equivalent to Zhaojun controlling all assets using a single-signature wallet. Based on this, the problem with Multichain is that Zhaojun should not control all MPC shards and did not provide a backup solution in extreme force majeure situations.
The next question is how to effectively utilize the characteristics of MPC technology? There are three main points:
(1) Provide stronger transparency to prevent conflicts of interest;
(2) Strictly adhere to decentralized custody methods to avoid excessive centralization of power;
(3) Prepare contingency plans for extreme force majeure situations.
- [Preventing conflicts of interest: Rejecting black boxes]
One thing to note is that Fantom was also greatly affected by this incident. AC, the founder of FTM, stated on the forum: Multichain’s failure is a “major blow,” and they had received many assurances from the team about server decentralization, access, and geographic distribution. In hindsight, Multichain did not fulfill the guarantees of “server, access, and geographic distribution,” and Fantom did not verify or have a way to verify, choosing to simply trust Multichain, which ultimately resulted in being affected as well.
It can be seen that Multichain’s MPC solution is essentially a “black box,” and the reason for this “black box” is that Multichain is both the builder and the user of the service, which centralized attributes bring opacity and room for misconduct. The solution to this problem is to introduce a completely neutral third party that does not involve conflicts of interest, that is, to use a third-party MPC service with sufficient credibility instead of self-built MPC services.
In addition to cross-chain bridges, conflicts of interest are widespread in Web3. For example, centralized exchanges simultaneously provide trading services and custody of user assets, and exchanges can benefit from using these funds, such as on-chain mining, market-making, and investment. In fact, this is also the starting point for Sinohope to build Openloop. Trust cannot be verified, and reliable mechanisms are the only way to avoid misconduct.
Returning to this incident, if Multichain had used a third-party MPC service with sufficient credibility, the service provider could have provided information verification for stakeholders such as Fantom, eliminating the “black box” situation, at least in the case permitted by Multichain.
- [Decentralized custody: Rejecting single point risks]
In hindsight, Zhaojun’s single point risk was the direct cause of the incident, and AC’s response also provides the correct approach: ensuring the guarantees of “server, access, and geographic distribution.” These factors are also the principles followed by Sinohope when building products.
First, Sinohope adopts a 3-3 multi-signature scheme (also supports t-n threshold signature settings), where 2 shards are co-managed by the platform, ensuring security through high-strength encryption and trusted execution environments. Three parties must participate together to complete transaction signing, avoiding single point risks for users.
Image: Sinohope MPC-TSS technical principle
Second, business processes are usually hierarchical, so access should also be hierarchical. Therefore, Sinohope adopts a design of multi-level private key derivation, which allows administrators to control the overall situation while also accommodating specific permissions for frontline operators, avoiding the halt of all business processes under single point risks.
Finally, Sinohope uses online distributed storage with multi-site redundancy, three-level offline cold storage backups, and integrated backup and recovery services from professional institutions, ensuring the highest level of “geographic distribution guarantees.” This series of mechanisms maximally avoids asset losses or service unavailability caused by single point risks, including at the levels of private keys, personnel, and external environments.
- [Preparing for social recovery in extreme situations]
It is undeniable that no solution is perfect. Decentralization of servers, access, and geographical locations can solve some of the problems, but not all. We must acknowledge that many risks still exist, such as force majeure factors in the physical world. In unavoidable situations, we need to consider how to respond when such extreme force majeure situations occur.
Based on this, Sinohope has conceived the 【SOS Mode】 for mitigating the risk of force majeure in the physical world. This service will be provided as a non-standard, optional service to users who need it, and will be customized based on actual needs. In addition to the traditional private key sharding, this mode will also include several SOS shards, which will be managed separately from the normal private key shards.
Under normal circumstances, the SOS shards will not have any effect. However, in certain situations, the SOS shards will be activated. For example, the private key shard manager/owner can manually activate them in emergency situations, when the private key shards have been disconnected for a certain period of time, when the SOS shards initiate an emergency event, or when a governance vote is passed according to established rules. After activating the 【SOS Mode】, the SOS shards will replace the private key shards to facilitate asset transfer or disposal in emergency situations.
Of course, to prevent malicious behavior by SOS shard holders, several restrictions can be added. For example, a delay in activating the 【SOS Mode】 can be set, during which the normal private key shards can overturn the 【SOS Mode】; or a lock-up period can be set after the emergency asset transfer in the 【SOS Mode】, during which further transfer is not allowed to prevent asset loss.
