#sui链 As a DeFi project in the ecosystem, although I am not a tech expert, I would like to share with you the background of this incident.
① One of the reasons Sui attracted us to develop on it is that it allows most transactions to be processed in parallel. When users only operate on their own objects, transactions can occur simultaneously, which is very important for DeFi projects.
② However, when multiple users need to access the same shared object simultaneously, such as accessing the same liquidity pool in a DEX, it needs to be processed in order. To avoid overwhelming the system, Sui has designed a 'congestion control mechanism' to manage such transactions.
③ This downtime issue was caused by a numerical overflow when calculating transaction costs. In simple terms, it's like when a computer does not have enough digits to display, and a number that is too large resets to zero for recalculation. The system gets caught in an infinite loop in such cases, ultimately leading to the entire network going down.
④ To put it simply:
When the numerical value calculated by the system exceeds the range that can be stored:
- Original design: errors in calculations when exceeding limits, causing the system to repeatedly compute.
- After correction: set the correct calculation limits to avoid this situation.
⑤ Many people are discussing whether this will become the next Solana. But the situation is completely different!
The issue with Solana is:
- Network congestion causes system crashes
- Requires large-scale architectural improvements
- Difficult to fundamentally resolve in the short term
And for Sui this time:
- It is a clear technical problem
- There are direct solutions available
- Does not affect the system's underlying architecture
In summary: the key to this incident is that the problem occurred in the program logic for calculating transaction costs, not in Sui's consensus mechanism or system architecture design. This also explains why the fix was able to be so quick and direct.