Regarding the operation of freezing hacker addresses by SUI, we have briefly sorted out its blacklist and whitelist mechanism.
1. How is freezing implemented?
First of all, the SUI chain has always had a feature called Deny List (blacklist for denial of service). Any address that enters the blacklist will not be able to execute related transactions on the nodes.
It is precisely because this feature has long existed in the client that this emergency freeze of hacker addresses was possible. Otherwise, although SUI has only 113 nodes, even if Cetus called each one, it would still be too late.
SUI has not suddenly become a centralized chain since yesterday; it has always been one, at least since the blacklist feature was added.
2. Who has the authority to change the blacklist?
In theory, TransactionDenyConfig is a YAML/TOML configuration loaded locally by each validator.
Anyone running a node can change the list by modifying the file, hot loading, or restarting the node.
It seems to be a free expression of the values of the nodes.
However, in order to ensure the consistency of the network and the effectiveness of security policies, updates to such critical configurations are usually done through coordination.
The so-called coordination process is where the centralization aspect comes into play.
Given that this is the 'SUI official emergency update code,' Sui Foundation (or its authorized developers) is essentially the initial creator and updater of this configuration list.
Sui officially released the blacklist first, and the nodes theoretically have the freedom to choose whether to follow it or not, but based on our understanding of the nodes, this basically happens by default.
So, although this feature temporarily protects the funds of many people, it is actually centralized.
3. What was the new patch released yesterday?
Yesterday, SUI urgently launched a whitelist (transaction_allow_list_skip_all_checks) feature.
Any transaction on the whitelist can skip all security checks (including signature count, permissions, banned objects, etc.).
4. What is the purpose of the whitelist?
If funds need to be reclaimed or returned in the future, the authorities can pre-construct a specific 'rescue transaction' and put it into transaction_allow_list_skip_all_checks, so even if it is locked by the blacklist, it can bypass all checks and be executed at once.
5. Does the whitelist have the power to take the hacker's money directly?
No. It can only allow the money to bypass the blacklist.
The patch itself cannot sign the hacker's private key and will not call privileged Move functions. It can only block or allow. To actually transfer the money, it must be done by:
(1) possessing the hacker's private key, or
(2) additionally releasing a restoration module (system-level privileges) and adding that upgrade transaction to the whitelist.
6. So what is the current situation of SUI?
SUI has taken centralized action
Freezing part of the money stolen by the hacker
But it cannot be withdrawn for now (due to underlying level modifications)
So now we are paving the way to recover this money
But the cost is that SUI will become more centralized
Hope everyone can successfully get their money back soon.