Beliebte Version: Eine einfache "Übersetzung" zur Interpretation der Analyse des @CetusProtocol Hackers durch den Tech-Chef: Dieser Angriff legt ein klassisches Problem des Ganzzahlüberlaufs offen, das sich in der Datenkürzung während der Typkonvertierung manifestiert. Technische Details demontiert: 1) Schwachstelle Location: Das Problem tritt im Typkonvertierungsmechanismus der Funktion get_amount_by_liquidity auf, und die Cast-Konvertierung von U256 in U64 führt zu Datenverlust auf hoher Ebene. 2) Ablauf des Angriffs: 1. Der Angreifer gibt eine große Menge an Liquiditätsparametern über die Funktion add_liquidity ein; 2. Die Anzahl der B-Token, die für die Berechnung des Systemaufrufs get_delta_b der Funktion erforderlich sind; 3. Bei der Berechnung werden die beiden Daten des Typs U128 multipliziert, und das theoretische Ergebnis sollte Typ U256 sein. Hauptfehler: Das u256-Ergebnis wird bei der Rückgabe der Funktion in u64 umgewandelt, was zu einer Kürzung der 128-Bit-Daten auf hoher Ebene führt. 3) Auslastungseffekt: Die Liquiditätsquote, die ursprünglich eine große Anzahl von Token zum Minzen erforderte, kann nun mit nur einer sehr geringen Anzahl an Token vervollständigt werden. Der Angreifer erhält einen großen Teil der Liquidität zu sehr geringen Kosten und realisiert dann die Arbitrage des Pools, indem er einen Teil der Liquidität zerstört. Einfache Analogie: Genau wie bei der Verwendung eines Taschenrechners, der nur 8 Ziffern anzeigen kann, um 1 Milliarde × 1 Milliarde zu berechnen, kann das Ergebnis einer 20-stelligen Berechnung nur die letzten 8 Ziffern anzeigen, und die ersten 12 Ziffern verschwinden direkt. Der Angreifer nutzt diese Sicherheitsanfälligkeit aus. Um es klar zu sagen: Diese Schwachstelle hat nichts mit der zugrunde liegenden Sicherheitsarchitektur von @SuiNetwork zu tun, und der Sicherheits-"Ruhm" der Move-Sprache ist vorerst noch glaubwürdig. Warum? Die Move-Sprache bietet erhebliche Vorteile in Bezug auf die Ressourcenverwaltung und die Typsicherheit und kann Sicherheitsprobleme auf niedriger Ebene, wie z. B. doppelte Ausgaben und Ressourcenverluste, effektiv verhindern. Diesmal handelt es sich bei dem Cetus-Protokoll jedoch um einen mathematischen Fehler auf der Ebene der Anwendungslogik und nicht um einen Designfehler in der Move-Sprache selbst. Das Typsystem von Move ist zwar streng, beruht aber bei der expliziten Umwandlung immer noch auf dem richtigen Urteilsvermögen des Entwicklers. Wenn ein Programm aktiv eine Typkonvertierung von U256 nach U64 durchführt, kann der Compiler nicht erkennen, ob es sich um eine Absicht oder einen logischen Fehler handelt. Darüber hinaus hat dieser Sicherheitsvorfall nichts mit den zugrunde liegenden Kernfunktionen von Sui wie dem Konsensmechanismus, der Transaktionsverarbeitung und der Zustandsverwaltung zu tun. Sui Network führt nur die vom Cetus-Protokoll übermittelten Transaktionsanweisungen originalgetreu aus, und die Schwachstelle beruht auf den logischen Fehlern des Anwendungsschichtprotokolls selbst. Um es ganz offen zu sagen: Keine noch so fortschrittliche Programmiersprache kann logische Fehler auf der Anwendungsebene vollständig beseitigen. Die Verschiebung kann die meisten der zugrunde liegenden Sicherheitsrisiken verhindern, aber sie kann Entwickler nicht durch die Überprüfung der Grenzen der Geschäftslogik und den Überlaufschutz mathematischer Vorgänge ersetzen.