If there is a problem with the team, DApp cannot be used. Many people question whether multichain is pseudo-decentralized, and some people even begin to question web3. So what is going on?
Cross-chain bridge issues raise questions about the decentralization of DApps
Here's what happened. On the afternoon of May 24, 0xscope tweeted that a wallet address related to multichain transferred 3.17M of MULTI to gateio. Previously, DC users reported that their cross-chain assets had not been received for a long time. Then the community rumored that multichain's office in Shanghai was arrested by Yunnan police, and cross-chain was restricted, resulting in the inability to receive cross-chain assets. This incident caused panic in the community for a while, and the price of MULTI also fell by 30%. Later, at midnight, Brother Sun proposed his USDD. At around 3 o'clock, the co-founder of the multichain team said that the team was normal and encountered force majeure. Many people questioned that force majeure may represent that the rumors may be true from the side, because the general premise of cross-chain bridge problems is either a failure caused by a code bug or a hacker attack. If these two occur, the team will announce it positively. If the team hides it, then it may face legal problems. Therefore, the credibility of rumors is relatively high.
So far, the team has not responded directly to the true circumstances of this incident. There is also a lot of discussion in the market, and many token prices have fallen. Although the multichain team later stated that it would compensate users for the loss of assets, people still questioned the decentralization of DApp. If something goes wrong with the team, can they still get their money back in the contract? In other words, what is causing their assets to be unable to cross-chain normally? Decentralized smart contracts should be automatically executed. If they are controlled by humans, then decentralization may be in vain.
Behind decentralization—authority management
In fact, for DApps, absolute decentralization is difficult to exist. Decentralization guarantees the assets in the user’s personal wallet. It may not be fully applicable to the smart contract addresses of interactive DApps, especially contracts in certain scenarios.
First of all, the DApp we interact with is deployed on the blockchain. The decentralization of the blockchain is mainly determined by the nodes. The more dispersed the nodes are, the stronger the decentralization is. If the nodes collude to do evil or have the ability to do evil, then it is not called decentralization. DApp relies on the blockchain, just like a house on the land, and the authority is like the key to the house. In principle, the wallet that deploys the DApp has the control authority over the DApp, which is the highest authority. Generally, DApp developers have three strategies:
1. Hard-code permissions, that is, when deploying a contract, do not give anyone, including yourself, the permission to operate, modify, or upgrade the contract. Such a contract is our impression of a completely decentralized DApp, and no one can modify or control the contract. Of course, if a hacker discovers a loophole in the contract and steals funds, no one can recover them.
2. After reserving permissions, throw away the permissions. Generally, this applies to currency issuance contracts, especially liquidity pool LP. Some currency issuance contracts stipulate a total upper limit in the early stages of deployment, while others may not stipulate an upper limit or The upper limit can be modified by the deployer, causing people to distrust the token. Therefore, it is a common practice to lose the permission or change the ownership of the permission to a black hole address. For example, if the AMM pool lp is sent to an all-0 wallet, then the lp pool's No one can retrieve the funds, or change the permissions to an all-0 wallet. Then, except for the all-0 wallet, no other wallet can be modified. The all-0 address is called a black hole address, and its private key is not accessible to anyone. Yes, so this operation has the same effect as hard-coding the permissions.
Of course, once the all-0 address private key is cracked, it will be a different matter, but this probability is currently very small and almost impossible. Generally, developers will reserve permissions when the contract is first deployed and trial-launched. After the contract has been tested by the market and has no loopholes or has passed the audit, they can consider throwing away the permissions. Since this method may be questioned by the community, so The items used will be relatively few.
3. Multi-signature management permissions. Managing the permissions of smart contracts by using multi-signature addresses is currently the practice of most projects. There are two main starting points for this approach. One is to upgrade and improve the new functions of the contract, including bug modifications. etc. The second one is to deal with sudden accidents, such as the loss of user assets that may be caused by hackers stealing coins or other vulnerabilities. Multi-signature custodians are generally participated by well-known community members and project parties, and third parties such as exchanges, code audit institutions, DAO communities, etc. can also participate.
Multichain uses multiple signatures to manage permissions. If there is a problem with the project, they also have the ability to suspend cross-chain. This design was originally intended to prevent abnormal behaviors such as code bugs or hacker attacks. However, if project members are controlled, they may be forced to suspend cross-chain. Therefore, this approach is strictly speaking not truly decentralized, but it is also related to security and is a compromise. We can see it as a manifestation of the impossible triangle.
Generally speaking, the more complex a DApp is, the more difficult it is to achieve true decentralization. If it only performs the simplest functions, it is possible to be completely decentralized. Complexity, decentralization and security are unlikely to coexist at the same time. Complexity has already determined the functional requirements at the beginning of DApp design, and security cannot be underestimated. Therefore, the degree of decentralization can only be sacrificed. Developers will not throw away contract permissions, but hand them over to multi-signature management, thereby introducing another form of decentralization. However, if multi-signature management is not perfect and is too centralized, there will be certain problems.
For the above-mentioned form, there is actually no solution. You can provide users with asset extraction channels by adding functions such as asset recovery switches. This will facilitate the occurrence of problems such as abnormalities that cannot be recovered during the cross-chain process, such as before. zklink conducted a Dunkirk asset recovery test. Essentially, when there is a problem with the contract, users can submit recovery requirements through the recovery node, thereby avoiding risks like FTX and ensuring that they can get it back through self-service as soon as possible. Assets and DApps are also constantly improving and evolving in this process, ultimately promoting the popularity of decentralization.