On May 29, the voting results were announced, with more than 2/3 of the verification nodes supporting it; the protocol upgrade was ready to be implemented. From May 30 to early June, the protocol upgrade took effect, the designated transaction hash was executed, and the hacker's assets were "legally transferred away". 2. Attack Principle. There have been many articles on the principle of the incident in the industry, and here we only give an overview of the core principles: From the attack process: The attacker first used a flash loan to borrow about 10,024,321.28 haSUI, instantly dropping the price of the trading pool by 99.90% . This huge sell order caused the target pool price to drop from about 1.8956×10^19 to 1.8425×10^19, almost clearing the bottom.
Then, the attacker created a liquidity position on Cetus with an extremely narrow range (Tick lower limit 300000, upper limit 300200, and the range width is only
1.00496621%). Such a narrow range amplifies the impact of subsequent calculation errors on the required number of tokens. The core principle of the attack:
There is an integer overflow vulnerability in the get_delta_a function used by Cetus to calculate the required number of tokens. The attacker deliberately declared that a huge amount of liquidity (about 10^37 units) would be added, but only 1 token was actually invested in the contract.
Due to the error in the overflow detection condition of checked_shlw, the contract truncates the high bit when calculating the left shift, causing the system to seriously underestimate the amount of haSUI required, thereby exchanging a huge amount of liquidity for a very small cost.
Technically, the above vulnerability stems from the use of incorrect masks and judgment conditions by Cetus in the Move smart contract, resulting in any value less than 0xffffffffffffffff << 192 being able to bypass detection; and the high bit data is truncated after the 64-bit left shift, and the system only charges a few tokens to think that it has obtained huge liquidity.
After the incident, two official operations were derived:"Freeze" vs "Recovery", which has two stages:
3.Sui's freezing mechanism
There is a special Deny List mechanism in the Sui chain itself, which realizes the freezing of hacker funds. Not only that, in fact, Sui's token standard also has a "regulated token" mode with a built-in freezing function.
This emergency freeze took advantage of this feature: the validator node quickly added the addresses related to the stolen funds in the local configuration file. Theoretically, each node operator can modify TransactionDenyConfig to update the blacklist by themselves, but in order to ensure network consistency, Sui Foundation, as the initial configuration publisher, conducted centralized coordination.
The foundation first officially released a configuration update containing the hacker's address, and the validator took effect simultaneously according to the default configuration, thereby temporarily "sealing" the hacker's funds on the chain. There is actually a high degree of centralization behind this.
In order to rescue the victims from the frozen funds, the Sui team immediately launched The whitelist (Whitelist) mechanism patch.
This is for the subsequent operation of transferring funds back. Legal transactions can be constructed in advance and registered in the whitelist, and they can be enforced even if the fund address is still on the blacklist.
This new feature allows specific transactions to be pre-added to the "exempt list", allowing these transactions to skip all security checks, including signatures, permissions, blacklists, etc.
It should be noted that the whitelist patch cannot directly rob hacker assets; it only gives certain transactions the ability to bypass freezing, and the real asset transfer still requires legal signatures or additional system permission modules to complete.
In fact, the mainstream freezing schemes in the industry often occur at the token contract level and are controlled by the issuer's multi-signature.
Take the USDT issued by Tether as an example. Its contract has a built-in blacklist function. The issuing company can freeze the illegal address and make it unable to transfer USDT. This scheme requires multiple signatures to initiate a freezing request on the chain, and it is actually executed after the multiple signatures reach a consensus, so there is an execution delay.
Although Tether's freezing mechanism is effective, statistics show that there are often "window periods" in the multi-signature process, leaving opportunities for criminals.
In contrast, Sui's freezing occurs at the underlying protocol level, which is collectively operated by the validator nodes and is executed much faster than ordinary contract calls.
Under this model, to execute quickly, it means that the management of these validator nodes themselves is highly unified.
4.Sui’s “transfer-based recovery” implementation principle
What’s even more surprising is that Sui not only froze the hacker’s assets, but also planned to “transfer and recover” the stolen funds through on-chain upgrades.
On May 27, Cetus proposed a community voting plan, requiring an upgrade to the protocol to send the frozen funds to a multi-signature escrow wallet. The Sui Foundation then initiated an on-chain governance vote.
On May 29, the voting results were announced, and about 90.9% of the weighted validators supported the plan. Sui officially announced that once the proposal is passed, "all funds frozen in the two hacker accounts will be recovered into a multi-signature wallet without the need for the hacker's signature."
No need for the hacker's signature, what a different feature, there has never been such a repair method in the blockchain industry.
From Sui's official GitHub PR, the protocol introduced the address aliasingmechanism. The upgrade includes: pre-specifying alias rules in ProtocolConfigso that some allowed transactions can regard legitimate signatures as being sent from hacker accounts.
Specifically, the rescue transaction hash list to be executed is bound to the target address (ie, the hacker address), and any executor who signs and publishes these fixed transaction summaries is deemed to have initiated a transaction as a valid hacker address owner. For these specific transactions, the validator node system will bypass the Deny List check .
From the code level, Sui added the following judgment to the transaction verification logic: When a transaction is intercepted by the blacklist, the system traverses its signers and checks whether protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest)is true.
As long as there is a signer that meets the alias rule, the transaction is marked as allowed to pass, and the previous interception error is ignored, and normal packaging and execution continue.
5. Viewpoint
160 million yuan tore apart the industry's deepest underlying beliefs
Cetus incident. From the author's personal point of view, this storm may pass quickly, but this model will not be forgotten, because it subverted the foundation of the industry and broke the traditional consensus that blockchain cannot be tampered with under the same set of ledgers.
In blockchain design, the contract is the law and the code is the referee.
But in this incident,code failure, governance intervention, power overrideformed a "voting behavior determines the code results" model.
It is because Sui's approach ofdirectly misappropriating transactionsis very different from the mainstream blockchain's approach to dealing with hacker issues.
This is not the first time that consensus has been tampered with, but it is the most silent one.
Historically:
Ethereum used a hard fork to roll back the transfer to make up for the loss in The DAO incident in 2016, but this decision led to the split of the Ethereum and Ethereum Classic chains. The process was controversial, but in the end, different groups formed different consensus beliefs.
The Bitcoin community has also experienced similar technical challenges: the value overflow vulnerability in 2010 was urgently repaired by developers and the consensus rules were upgraded, completely erasing about 18.4 billion illegally generated bitcoins.
These are all the same hard fork model, rolling back the ledger to before the problem, and then users can still decide for themselves which ledger system to continue using.
Compared to the DAO hard fork, Sui did not choose to split the chain, but instead targeted this incident precisely through protocol upgrade plus configuration alias. In doing so, Sui maintained the continuity of the chain and most of the consensus rules unchanged, but at the same time also showed that the underlying protocol can be used to implement targeted "rescue operations".
text="">The problem is, historical "fork rollback" is the user's choice of belief; Sui's "protocol amendment" is the chain making the decision for you.
Not Your Key, Not Your Coin? I'm afraid Not Anymore.
In the long run, this means that the concept of "Not your keys, not your coins"is disintegrated on the Sui chain: even if the user's private key is intact, the network can still prevent the flow of assets and redirect assets through collective agreement changes.
If this becomes a precedent for blockchains to deal with large-scale security incidents in the future, or even is considered a practice that can be followed again.
“When a chain can break the rules for justice, it also has a precedent for breaking any rules. ”
Once there is a success of "charity money grabbing", the next time may be an operation in the "moral gray area"
What will happen then?
The hacker did steal the user's money, so can the group vote take his money?
Is the voting based on who has more money (pos) or more people? The one with more money will win, and the end producer described by Liu Cixin will soon arrive. If the one with more people wins, then the mob will also make waves.
Under the traditional system, it is very normal that illegal income is not protected, and freezing and transfer are routine operations of traditional banks.
But the fact that this cannot be done from a technical theoretical perspective is the root of the development of the blockchain industry.
Now the big stick of industry compliance continues to ferment. Today, you can freeze and modify account balances for hackers, and tomorrow you can make arbitrary modifications for geographical factors and conflicting factors. If the chain becomes a partial tool for the region.
Then the value of the industry will be greatly compressed, and at best it will be another set of less useful financial systems.
This is also the reason why the author is determined to stay in the industry: "Blockchain is not valuable because it cannot be frozen, but because even if you hate it, it will not change for you. ”
Regulation is the general trend. Can the chain keep its own soul?
Once upon a time, the alliance chain was more popular than the public chain because it met the regulatory needs of that era. Now the decline of the alliance actually means simply complying with this demand, not the needs of real users.The lost regulated users, then what about the need for regulatory tools?
From the perspective of industry development
"Efficient centralization", is it a necessary stage in the development of blockchain? If the ultimate goal of decentralization is to protect the interests of users, can we tolerate centralization as a transitional means? ”
The word "democracy", in the context of on-chain governance, is actuallytoken weighted. So if a hacker holds a large amount of SUI (or one day the DAO is hacked and the hacker controls the voting rights),can he also "legally vote to whitewash himself"?
Ultimately, the value of the blockchain does not lie in whether it can be frozen, but in whether the group chooses not to do so even if it has the ability to freeze.
text="">The future of a chain is not determined by its technical architecture, but by the set of beliefs it chooses to protect.
Brian
Joy
Alex
Kikyo
Hui Xin