Artikel
Bildungsmaterialien und Tutorials über Sui
Verdiene deinen Anteil an 1000 Sui
Sammle Reputationspunkte und erhalte Belohnungen für deine Hilfe beim Wachstum der Sui-Community.
Beiträge
44- ArtikelOwen15Jun 01, 2025
Sui Cetus DeFi Hack: Globale Auswirkungen auf das Ökosystem
Im Mai 2025 sah sich das Sui-Blockchain-System mit einer schwerwiegenden Sicherheitsverletzung konfrontiert, die Schockwellen in der Welt der dezentralen Finanzen (DeFi) auslöste.Cetus Protocol, eine führende dezentrale Börse (DEX) auf Sui, wurde bei einem verheerenden Hack ausgenutzt, der über220 Millionen $an digitalen Vermögenswerten verbrauchte. Dieser Vorfall warf nicht nur ernsthafte Bedenken hinsichtlich der Sicherheit der DeFi-Protokolle innerhalb des Sui-Netzwerks auf, sondern unterstrich auch umfassendere Sicherheitslücken in der globalen DeFi-Landschaft. Was ist während des Cetus-Hacks passiert? Cetus Protocolist das führende DEX- und Liquiditätsprotokoll auf Sui und dient als zentrale Infrastruktur für Token-Swaps, Yield Farming und konzentrierte Liquiditätsversorgung. Es wurde mit derMove-Programmierspracheentwickelt und für seine leistungsstarke Architektur und die tiefe Integration mit nativen SUI-Tokens gelobt. Am22. Mai 2025lösten abnormale Aktivitäten in den Liquiditätspools von Cetus Alarme aus. Die Pool-Tiefen sanken schnell und es wurde bald bestätigt, dass die Plattform gehackt worden war. Die Angreifer haben Vermögenswerte im Wert vonzwischen 220 und 260 Millionenaus den Liquiditätsreserven abgezogen. Die genaue Sicherheitslücke wird zwar noch untersucht, aber erste Analysen deuten darauf hin, dass der Exploit Folgendes beinhaltet haben könnte: Manipulation der Berechnungen des Liquiditätspools Umgehung der behördlichen Kontrollen Das Cetus-Team unterbrach den Handel schnell und leitete Wiederherstellungsmaßnahmen ein. Dabei arbeitete es eng mitSui-Validatoren und Blockchain-Analyseunternehmenzusammen, um gestohlene Gelder aufzuspüren und einzufrieren. Die unmittelbaren Folgen für Sui- und Cetus-Benutzer Die Auswirkungen waren unmittelbar und schwerwiegend: CETUS-Token-Absturz: Das native Governance-Token der Plattform verlor innerhalb weniger Stunden mehr als 60% seines Wertes**. Verluste beim Liquiditätsanbieter**: Bei vielen LPs wurde ihr eingezahltes Vermögen vernichtet. Ökosystemweite Panik**: Mehrere andere DeFi-Plattformen auf Sui stellten vorübergehend den Betrieb ein oder wurden Notfallprüfungen unterzogen. Trotzdem gab es einen Silberstreif am Horizont — dieSui-Validator-Community schaffte es, bis zu 160 Millionen Dollarder gestohlenen Gelder einzufrieren, was Hoffnung auf eine teilweise Wiederherstellung bot. Was der Cetus Hack für das Sui-Ökosystem bedeutet 1.Aufdeckung von Sicherheitslücken in Move Smart Contracts Obwohl dieMove-Programmiersprachemit starken Sicherheitsgarantien ausgestattet ist — einschließlich einer besseren Speicherverwaltung und Ressourcenkontrolle als Solidity —, enthüllte der Cetus-Hack, dass selbst gut strukturierte Systeme kritische Fehler aufweisen können, wenn es um komplexe DeFi-Logiken wie vertragsübergreifende Aufrufe, Governance-Module oder dynamische Preismechanismen geht. Diese Veranstaltung diente als Weckruf für Sui-Entwickler: Investieren Sie stärker informelle Überprüfungen und Prüfungen durch Drittanbieter Einführungstrengerer Steuerungs- und Modernisierungsmechanismen Verbessern Sie dieTransparenz bei der Offenlegung von Risiken 2.Potenzial einer verschärften behördlichen Kontrolle Da DeFi weltweit weiter wächst, beobachten die Aufsichtsbehörden genau. Ein aufsehenerregender Hack wie dieser könnte zu einer verstärkten Überprüfung der DeFi-Protokolle führen, insbesondere derjenigen, die auf neuen Blockchains wie Sui arbeiten. Die Behörden könnten auf Folgendes drängen: Obligatorische Meldung von Hacks Haftungsrahmen für Projektteams Compliance-Anforderungen für DeFi-Plattformen 3.Neubewertung des Vertrauens in neue DeFi-Ökosysteme Sui hat sich als skalierbare, leistungsstarke Layer-1-Blockchain positioniert und bei DeFi-Entwicklern und Investoren große Aufmerksamkeit auf sich gezogen. Der Vorfall in Cetus verdeutlichte jedoch die Risiken, die mit neueren Ökosystemen verbunden sind, in denen intelligente Vertragsinstrumente und Prüfungspraktiken noch ausgereift sind. Investoren und Entwickler überdenken jetzt, wie sie die Risikobewertung angehen, und viele fordern: Dezentrale Versicherungsmechanismen Verwahrung von Fonds mit mehreren Signaturen Tools zur Überwachung in Echtzeit Lektionen für die globale DeFi-Industrie 1.Komplexität erhöht das Risiko DeFi-Protokolle implementieren häufig neuartige Wirtschaftsmodelle und algorithmische Designs, die unbeabsichtigte Folgen haben können. Der Cetus-Hack zeigt, dass selbst gut konzipierte Systeme kompromittiert werden können, wenn Kernkomponenten wie Preisgestaltung oder Unternehmensführung nicht rigoros getestet und geprüft werden. 2.Transparenz schafft Vertrauen Während der Krise wurde das Cetus-Team für die zeitnahe Kommunikation und proaktive Zusammenarbeit mit dem Sui-Ökosystem gelobt. Transparente Updates trugen dazu bei, weitere Schäden zu mindern und das Vertrauen der Benutzer zu stabilisieren. 3.Erholung ist möglich — aber Vertrauen braucht Zeit Obwohl ein großer Teil der gestohlenen Gelder eingefroren wurde und möglicherweise wiedererlangt werden kann, wird der Wiederaufbau des Vertrauens einige Zeit in Anspruch nehmen. Benutzer werden wahrscheinlich stärkere Garantien verlangen, bevor sie erneut Geld in DeFi-Protokolle einzahlen. Dies könnte zu einer stärkeren Akzeptanz von: On-Chain-Versicherung Tools zur Überwachung in Echtzeit Open-Source-Codebasen für die öffentliche Überprüfbarkeit Ausblick: Was kommt als Nächstes für Sui und DeFi? Trotz des Rückschlags bleibt das Sui-Ökosystem widerstandsfähig. Die Fähigkeit der Validatoren, gestohlene Gelder einzufrieren und möglicherweise wiederzugewinnen, zeigt die Leistungsfähigkeit einer koordinierten On-Chain-Governance und schneller Reaktionsmechanismen. Für die Zukunft können wir Folgendes erwarten: Verstärkter Schwerpunkt aufSicherheitsaudits und formellen Überprüfungenbei Verträgen, die auf MOVE basieren MehrZusammenarbeit zwischen DeFi-Teams und Blockchain-Netzwerkenzur Verbesserung der Reaktionsfähigkeit auf Vorfälle Zunahme derInstrumente zur Risikominderung, einschließlich dezentraler Versicherungen und Multi-Sig-Treasury-Management Fazit: Eine schwierige Lektion für DeFi DerSui Cetus DeFi-Hackwar ein schmerzhafter, aber notwendiger Lernmoment für die gesamte Blockchain-Industrie. So wie sich DeFi weiterentwickelt, müssen sich auch unsere Ansätze in den Bereichen Sicherheit, Unternehmensführung und Risikomanagement weiterentwickeln. Nur durch kontinuierliche Verbesserung, Transparenz und gemeinsame Verantwortung kann das Ökosystem für alle Teilnehmer sicherer und vertrauenswürdiger werden.
- Sui
0 - Artikelharry phan421May 31, 2025
Analyse des Cetus-Protokoll-Exploits auf Sui
Am 22. Mai 2025 zielte ein großer Exploit auf das Cetus-Protokoll auf der Sui-Blockchain ab, was zu Schäden in Höhe von schätzungsweise 223 Millionen US-Dollar führte. Dieser Vorfall erregte aufgrund der ungewöhnlichen Mechanik sofortige Aufmerksamkeit im gesamten Ökosystem, insbesondere bei technischen Beobachtern. Was folgt, ist eine umfassende Analyse des Angriffs, angefangen bei Flash-Swaps und Tick-Manipulationen bis hin zu einer stillen Sicherheitslücke in der Logik zur Erkennung von Überläufen. https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x Das Setup Der Angreifer initiierte den Exploit, indem er flash_swap nutzte, um sich im Austausch gegen HasUI eine große Menge an SUI-Tokens auszuleihen. Im Gegensatz zu herkömmlichen Flashloans ermöglicht flash_swap in Cetus einem Benutzer, token1 (in diesem Fall SUI) im Voraus zu erhalten und dann token0 (hasUI) innerhalb derselben Transaktion zurückzuzahlen. Dieser Mechanismus ist von zentraler Bedeutung für das Setup des Angreifers. In diesem speziellen Fall erwarb der Angreifer erfolgreich 5,76 Millionen SUI und war verpflichtet, 10,02 Millionen SUI zurückzuzahlen. Während dieses Swaps wurde der Preis von HasUI im Liquiditätspool jedoch drastisch manipuliert. Der Kurs des Pools fiel von einem Tick, der einem Verhältnis von 1,056 entspricht, auf einen Tick, der so tief war, dass der Kurs lediglich 0,0000009977 erreichte — eine enorme Abwertung auf 0,00009% seines ursprünglichen Kurses. Die Preisspanne, die der Tick-Spanne entspricht, ist: Strategische Liquiditätsspritze Nach diesem Kursabsturz verwendete der Angreifer open_position, um eine Liquiditätsposition mit einer engen Spanne zu erstellen, wobei er einen hochspezifischen Tickbereich auswählte (TickLower: 300000, TickUpper: 300200). In dieses manipulierte Umfeld injizierten sie eine astronomische Menge an Liquidität: mehr als 10^34 Einheiten, alle innerhalb der extrem komprimierten Preisspanne, die durch den Tick-Kollaps entstanden war. Dies wurde durch eine scheinbar harmlose Funktion ermöglicht: get_amount_by_liquidity. Unter normalen Bedingungen berechnet diese Funktion, wie viel von Token A und Token B benötigt wird, um ein bestimmtes Liquiditätsniveau zu erreichen. Dazu verwendet sie Hilfsfunktionen wie get_delta_a, das auf get_sqrt_price_at_tick basiert. Da der manipulierte aktuelle Tick jedoch -138185 betrug und der gewählte Tickbereich weit außerhalb dieses Bereichs lag (ab 300000), sorgte der Logikpfad innerhalb von get_amount_by_liquidity dafür, dass Berechnungen einen anfälligen Codeabschnitt durchliefen, in dem eine Linksshift-Operation (checked_shlw) involviert war. Überlauf und Kürzung: Die Kernschwachstelle Hier wird der Exploit wirklich technisch. Die Funktion checked_shlw soll das Verschieben einer 256-Bit-Zahl um 64 Bit nach links bewältigen. In Solidity-ähnlichen Umgebungen ist eine solche Operation riskant, da sie überlaufen kann. Bei dieser speziellen Implementierung wurde versucht, Überläufe zu erkennen, indem überprüft wurde, ob die Eingabe einen vordefinierten Schwellenwert überschritten hat: 0xffffffffffffff << 192. Der tatsächliche Schwellenwert für die Erkennung einer sicheren Verschiebung um 64 Bit sollte 2^ (256 - 64) - 1 sein. (0xffffffffffffffff << 192) ist jedoch größer als 2^192. Dies bedeutet, dass eine sorgfältig gewählte Eingabe die Überlaufprüfung umgehen könnte, indem sie unter dem im Code verwendeten Schwellenwert liegt, aber immer noch groß genug ist, um während der Ausführung einen Überlauf zu verursachen. Der Angreifer lieferte eine solche Eingabe, bei der die Multiplikation von Liquidität und Preisdifferenz im Hintergrund überlief und ein viel kleinerer Wert als beabsichtigt zurückgegeben wurde — fast Null. Infolgedessen berechnete das Protokoll, dass der Angreifer nur einen unbedeutenden Betrag an Token A — im Wesentlichen eine Einheit — zahlen musste, um dem Pool massive Liquidität hinzuzufügen. Diese Fehlkalkulation ermöglichte es dem Angreifer, massive Liquidität ohne wirkliche Kosten zuzuführen. Anschließend entfernte der Angreifer die zusätzliche Liquidität über remove_liquidity und beendete den Angriff, indem er die unbezahlten Token von flash_swap über repay_flash_swap bezahlte. Der Angreifer erzielte einen Gewinn von 5.765.124 SUI und 10.024.321 HasUI. Schließlich hat das Cetus-Team die Sicherheitsanfälligkeit durch zwei PRs behoben: https://github.com/CetusProtocol/integer-mate/pull/6/files Cetus veröffentlichte schnell einen Patch in seinem Integer-Mate-Repository, wobei der erste Pull-Request versuchte, die Überlauferkennung zu verfeinern. Diese erste Korrektur war jedoch unzureichend. Es wurde eine Maske mit dem Wert 1 << 192 verwendet, sodass auch Groß-/Kleinschreibung durchrutschen konnte. Es folgte ein zweiter Pull-Request mit einem strengeren Vergleich, bei dem überprüft wurde, ob die Eingabe größer oder gleich 2^192 ist, um die richtigen Grenzen für sicheres Verschieben nach links sicherzustellen. Nur mit dieser Korrektur wurde die Sicherheitslücke effektiv gemindert. https://github.com/CetusProtocol/integer-mate/pull/7/files
- Sui
2 - Artikel0xduckmove308May 31, 2025
Verwandeln Sie Wallets in programmierbare, zusammensetzbare Smart Agents.
Account.tech ist ein Open-Source-Framework auf der Sui-Blockchain, das Smart Accounts sehr flexibel einführt Flexible, sichere und anpassbare Kontoobjekte, die mithilfe einer modularen, absichtsbasierten Architektur On-Chain-Aktionen ausführen können. Stellen Sie sich das wie programmierbare Wallets mit nativer Unterstützung für Multisig, DAO-Logik, geplante Ausführung, dynamische Zugriffskontrolle und mehr vor. Warum Smart Accounts? Herkömmliche Konten sind nur passive Container. Sie halten Vermögenswerte und unterzeichnen Transaktionen. Smart Accounts sind aktive, programmierbare Entitäten, die die Eigentümerlogik definieren, Arbeitsabläufe automatisieren und Vermögenswerte auf der Grundlage von Regeln verwalten können. Bei Account.tech sind diese Regeln in der Kette enthalten, können über Move-Module angepasst werden und werden über Intents durchgesetzt. Wichtige Konzepte Intelligente Kontostruktur public struct Account has key, store { id: UID, metadata: Metadata, deps: Deps, intents: Intents, config: Config, } Ein Smart Account ist ein gemeinsam genutztes Objekt, das Folgendes enthält: Metadaten: beschreibende Informationen Deps — verwendete Abhängigkeitspakete Absichten — ausstehende oder aktive Anfragen zur Ausführung von Aktionen Config — der benutzerdefinierte Regelsatz (z. B. multisig, rollenbasiert, DAO-Logik) Jedes Konto hat ein einzigartiges Config-Modul, das festlegt, wie Intents aufgelöst werden. Absichtsbasierte Ausführung Eine Absicht ist eine strukturierte Anforderung zur Ausführung einer oder mehrerer On-Chain-Aktionen. Sie durchläuft 3 Stufen: [ ] Aufforderung, dass der Benutzer die Absicht mit Aktionen erstellt [ ] Lösung — Das Config-Modul prüft, ob die Bedingungen erfüllt sind [ ] Ausführung — jeder kann die Absicht ausführen, wenn sie gültig ist Beispiel: Eine Absicht von mehreren Sigs, Gelder zu überweisen, wird erst ausgeführt, wenn genügend Mitglieder sie genehmigt haben. Aktionen = Modulare Ausführungseinheiten Jede Aktion ist eine eigenständige Move-Struktur, wie: struct WithdrawAction { object_id: ID } struct TransferAction { recipient: address } Sie können mehrere Aktionen in einer Absicht zusammenfassen. Zum Beispiel: Withdraw → Transfer → Withdraw → Transfer Dies ermöglicht erweiterte Workflows — wie Atomic Swaps, Batch-Transfers, zeitbasierte Tresorfreigaben usw. Konfiguration: Anpassbare Eigentümerlogik Der Config-Typ definiert, wie Absichten aufgelöst werden. Sie können Logik wie die folgende einbauen: ✅ Multisig mit gewichteten Stimmen 🔐 Rollenbasierte Zugriffskontrolle 🗳 DAO-Abstimmungslogik ⏳ Zeitverzögerungen oder wiederkehrende Aufgaben 💾 Abläufe bei der Wiederherstellung Jede Absicht verfolgt ein Ergebnis, das den Stand der Lösung darstellt (z. B. gesammelte Stimmen, erteilte Genehmigungen usw.). Erfahren Sie mehr 🔗 Dokumente: https://account-tech.gitbook.io/docs 🧑💻 GitHub: https://github.com/account-tech
- Sui
1 - Artikel0xduckmove308May 30, 2025
BCS-Codierung in Sui: Was es ist und warum es wichtig ist
Wenn Sie auf Sui aufbauen oder an Move herumbasteln, haben Sie wahrscheinlich den Begriff BCS gehört. Das ist die Abkürzung für Binary Canonical Serialization, die ursprünglich für die Diem-Blockchain entwickelt wurde und heute ein Eckpfeiler von Move-basierten Ökosystemen wie Sui, Aptos, Starcoin und 0L ist. Also ja, du solltest es dir besser gemütlich machen, wenn du ernsthaft daran denkst, in diesem Raum zu bauen. Was ist BCS? Binary Canonical Serialization (BCS) ist ein Format, das zum Serialisieren (Codieren) und Deserialisieren (Dekodieren) strukturierter Daten in Byte verwendet wird. Sie werden sehen, dass es verwendet wird, wenn: Verschlüsselung von Transaktionen vor dem Signieren. Ausgeben oder Analysieren von Ereignissen aus der Blockchain. Interagieren mit Move Smart Contracts außerhalb der Kette über JavaScript. BCS enthält jedoch keine Typinformationen in den Bytes. Das bedeutet, dass Sie bei der Dekodierung die Struktur im Voraus kennen müssen, im Gegensatz zu Formaten wie JSON oder Protocol Buffers, die eher selbstbeschreibend sind. Hauptmerkmale von BCS Metadaten ohne Typ Die serialisierte Ausgabe enthält keine Hinweise darauf, um welche Typen es sich bei den Feldern handelt. Sie müssen wissen, womit Sie es zu tun haben, wenn Sie dekodieren. Auftragsabhängige Serialisierung Strukturen werden in der exakten Reihenfolge ihrer Felder kodiert. Wenn Sie die Reihenfolge ändern, wird Ihre Deserialisierung unterbrochen. Aus diesem Grund müssen die peel_*-Funktionen in Move 1:1 dem Layout der Struktur entsprechen. Generischer Typ In einer Struktur wie: struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } Sie können nur bis zum Metafeld zuverlässig deserialisieren. Generische Typen bringen das BCS-Parsen durcheinander. Setzen Sie sie also immer an die letzte Stelle, wenn Sie möchten, dass Ihre Daten sicher dekodiert werden. Verwenden von BCS in JavaScript Dank der @mysten /bcs-Bibliothek können Sie mit BCS in JS wie ein Profi arbeiten. npm i @mysten/bcs und einfaches Beispiel: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); const ser = bcs.ser(BCS.U16, 10); console.log(ser.toBytes()); // [0x0a, 0x00] const des = bcs.de(BCS.U16, ser.toBytes()); console.log(des); // 10 Sie können auch Vektoren und Zeichenketten serialisieren: bcs.ser("vector", [1, 2, 3, 4]); // 04 01 02 03 04 bcs.ser(BCS.STRING, "test string"); // 0b7465737420737472696e67 Registrierung benutzerdefinierter Typen Nehmen wir an, Sie haben die folgenden Move-Strukturen: struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } Sie können sie so in JS registrieren: bcs.registerStructType("Metadata", { name: BCS.STRING, }); bcs.registerStructType("BCSObject", { id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Beispiel für Serialisierung und Deserialisierung JavaScript-Serialisierung: const bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: { name: "aaa" } }) .toString("hex"); console.log("Hex:", bytes); Die Ausgabe vielleicht: 0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 Dies kann jetzt in einen Move-Vertrag umgewandelt oder sogar manuell in Sui CLI getestet werden. BCS mag auf niedriger Ebene und bytelastig aussehen, aber wenn Sie erst einmal verstanden haben, wie es Daten kodiert, werden Sie ein tieferes Verständnis dafür gewinnen, wie Move-Smart-Contracts wirklich funktionieren — und wie Sie On-Chain ↔ Off-Chain-Systeme sicher verbinden können. Und wenn Sie BCS-Bytes im Sui Explorer debuggen (wie im Folgenden): BCS-Kodierung Binary Canonical Serialization, oder BCS, ist ein Serialisierungsformat, das im Kontext der Diem-Blockchain entwickelt wurde und heute in den meisten auf Move basierenden Blockchains (Sui, Starcoin, Aptos, 0L) ausgiebig verwendet wird. BCS wird nicht nur in der Move-VM verwendet, sondern auch bei der Transaktions- und Ereigniscodierung, z. B. beim Serialisieren von Transaktionen vor dem Signieren oder beim Analysieren von Ereignisdaten. Zu wissen, wie BCS funktioniert, ist entscheidend, wenn Sie die Funktionsweise von Move auf einer tieferen Ebene verstehen und ein Move-Experte werden möchten. Lass uns eintauchen. BCS-Spezifikation und Eigenschaften Es gibt einige allgemeine Eigenschaften der BCS-Codierung, die Sie im weiteren Verlauf der Lektion unbedingt berücksichtigen sollten: BCS ist ein Datenserialisierungsformat, bei dem die resultierenden Ausgabebytes keine Typinformationen enthalten. Aus diesem Grund muss die Seite, die die kodierten Bytes empfängt, wissen, wie die Daten deserialisiert werden In BCS gibt es keine Strukturen (da es keine Typen gibt); die Struktur definiert lediglich die Reihenfolge, in der Felder serialisiert werden Wrapper-Typen werden ignoriert, sodass OuterType und UnnestedType dieselbe BCS-Repräsentation haben: struct outerType { Besitzer: InnerType } struktur innerType { Adresse: Adresse } struktur UnnestedType { Adresse: Adresse } Typen, die generische Typfelder enthalten, können bis zum ersten generischen Typfeld analysiert werden. Es empfiehlt sich daher, die generischen Typfelder an die letzte Stelle zu setzen, wenn es sich um einen benutzerdefinierten Typ handelt, der sert/de'd wird. struct BCSObject hat drop, copy { id: ID, Besitzer: Adresse, meta: Metadaten, generisch: T } In diesem Beispiel können wir alles bis zum Metafeld deserialisieren. Primitive Typen wie Ganzzahlen ohne Vorzeichen sind im Little-Endian-Format kodiert Der Vektor wird als ULEB128-Länge (mit einer maximalen Länge von bis zu u32) serialisiert, gefolgt vom Inhalt des Vektors. Die vollständige BCS-Spezifikation finden Sie im BCS-Repository. Verwendung der @mysten /bcs JavaScript-Bibliothek Installation Die Bibliothek, die Sie für diesen Teil installieren müssen, ist die @mysten /bcs-Bibliothek. Sie können sie installieren, indem Sie in das Stammverzeichnis eines Node-Projekts Folgendes eingeben: npm i @mysten /bcs Grundlegendes Beispiel Lassen Sie uns zunächst die JavaScript-Bibliothek verwenden, um einige einfache Datentypen zu serialisieren und zu deserialisieren: importiere {BCS, getSUIMoveConfig} aus "@mysten /bcs „; //initialisiere den Serializer mit den Standardkonfigurationen von Sui Move const bcs = neues BCS (getSuiMoveConfig ()); //Definiere einige Testdatentypen konstante Ganzzahl = 10; const array = [1, 2, 3, 4]; const string = „Testzeichenfolge“ //benutze bcs.ser () um Daten zu serialisieren const ser_integer = bcs.ser (BCS.U16, integer); const ser_array = bcs.ser („Vektor „, Array); const ser_string = bcs.ser (BCS.STRING, Zeichenfolge); //benutze bcs.de () um Daten zu deserialisieren const de_integer = bcs.de (BCS.U16, ser_Integer.toBytes ()); const de_array = bcs.de („Vektor „, ser_Array.toBytes ()); const de_string = bcs.de (BCS.STRING, ser_String.toBytes ()); Wir können die Serializer-Instanz mit der integrierten Standardeinstellung für Sui Move initialisieren, indem wir die obige Syntax verwenden, new BCS (getsuiMoveConfig ()). Es gibt eingebaute ENUMs, die für Sui Move-Typen wie BCS.U16, BCS.STRING usw. verwendet werden können. Für generische Typen kann es mit derselben Syntax wie in Sui Move definiert werden, wie Vector im obigen Beispiel. Schauen wir uns die serialisierten und deserialisierten Felder genauer an: Ints sind Little-Endian-Hexadezimalzahlen 0a00 10 das erste Element eines Vektors gibt die Gesamtlänge an, dann ist es einfach das, was auch immer die Elemente im Vektor sind 0401020304 1,2,3,4 #-Strings sind nur Vektoren von u8, wobei das erste Element der Länge der Zeichenfolge entspricht 0b7465737420737472696e67 Zeichenfolge testen Geben Sie Registrierung ein Wir können die benutzerdefinierten Typen, mit denen wir arbeiten werden, mithilfe der folgenden Syntax registrieren: importiere {BCS, getsUIMoveConfig} aus "@mysten /bcs „; const bcs = neues BCS (getSUIMoveConfig ()); //Registriere den Metadatentyp bcs.registerStructType („Metadaten“, { Name: BCS.STRING, }); //Das Gleiche gilt für das Hauptobjekt, das wir lesen wollen bcs.registerStructType („bcsObject“, { //BCS.ADDRESS wird sowohl für ID-Typen als auch für Adresstypen verwendet id: BCS.ADDRESS, Besitzer: BCS.ADDRESS, meta: „Metadaten“, }); Verwendung von BCS in Sui Smart Contracts Lassen Sie uns unser Beispiel von oben mit den Strukturen fortsetzen. Definition der Struktur Wir beginnen mit den entsprechenden Strukturdefinitionen im Sui Move-Vertrag. { //.. struct Metadata hat drop, copy { Name: std: :ascii: :Zeichenfolge } struct BCSObject hat drop, copy { id: ID, Besitzer: Adresse, meta: Metadaten } //.. } Deserialisierung Schreiben wir nun die Funktion zum Deserialisieren eines Objekts in einem Sui-Vertrag. öffentlicher Spaß object_from_bytes (bcs_bytes: vector): BcsObject { //Initialisiert die BCS-Byte-Instanz let bcs = bcs: :new (bcs_bytes); //Verwende peel_*Funktionen, um Werte aus den serialisierten Bytes zu entfernen. //Die Reihenfolge muss dieselbe sein, die wir bei der Serialisierung verwendet haben! let (id, owner, meta) = ( bcs: :peel_address (&mute bcs), bcs: :peel_address (&bcs stummschalten), bcs: :peel_vec_u8 (&mute bcs) ); //Packen Sie eine BCSObject-Struktur mit den Ergebnissen der Serialisierung BCSObject {id: object: :id_from_address (id), owner, meta: Metadata {name: std: :ascii: :string (meta)}} Die verschiedenen peel_*-Methoden im Sui Frame bcs-Modul werden verwendet, um jedes einzelne Feld aus den serialisierten BCS-Bytes zu „schälen“. Beachten Sie, dass die Reihenfolge, in der die Felder abgezogen werden, exakt der Reihenfolge der Felder in der Strukturdefinition entsprechen muss. Quiz: Warum sind die Ergebnisse der ersten beiden peel_address-Aufrufe für dasselbe BCS-Objekt nicht dieselben? Beachten Sie auch, wie wir die Typen mit Hilfsfunktionen von Adresse nach ID und von Vector nach std: :ascii: :string konvertieren. Quiz: Was würde passieren, wenn BSObject einen UID-Typ anstelle eines ID-Typs hätte? Vollständiges Ser/De-Beispiel Die vollständigen Beispielcodes für JavaScript und Sui Move finden Sie im Ordner example_projects. Zuerst serialisieren wir ein Testobjekt mit dem JavaScript-Programm: //Wir konstruieren ein Testobjekt zum Serialisieren. Beachten Sie, dass wir das Format der Ausgabe in Hex angeben können let _bytes = bcs .ser („bcsobject“, { id: „0x000000000000000000000000000000000005", Besitzer: „0x00000000000000000000000000000000000a“, meta: {Name: „aaa"} }) .toString („hexadezimal“); Wir möchten, dass die Ausgabe des BCS-Writers diesmal im Hexadezimalformat vorliegt, das wie oben angegeben werden kann. Fügen Sie dem Hexstring des Serialisierungsergebnisses das Präfix 0x hinzu und exportieren Sie es in eine Umgebungsvariable: export Object_HexString=0x00000000000000000000000000000000000000000000000000000000000000000a03616161 Jetzt können wir entweder die zugehörigen Move-Unit-Tests ausführen, um die Richtigkeit zu überprüfen: Sui Move-Test Du solltest das in der Konsole sehen: GEBÄUDE bcs_move Move-Komponententests ausführen [PASS] 0x0: :bcs_object: :test_deserialization Testergebnis: OK. Gesamtzahl der Tests: 1; bestanden: 1; nicht bestanden: 0 Oder wir können das Modul veröffentlichen (und die PACKAGE_ID exportieren) und die Methode emit_object mit dem obigen serialisierten BCS-Hexstring aufrufen: sui client call --function emit_object --module bcs_object --package $PACKAGE_ID --args $OBJECT_HEXSTRING Wir können dann im Sui Explorer auf der Registerkarte Ereignisse der Transaktion nachschauen, ob wir das korrekt deserialisierte BCSObject ausgegeben haben:
- Sui
- SDKs and Developer Tools
1 - ArtikelVens.sui134May 29, 2025
Cetus Protocol Hack - Der größte DeFi-Exploit auf Sui
Im Mai 2025 wurde die DeFi-Welt von einer der bedeutendsten Sicherheitslücken der jüngeren Geschichte erschüttert. Cetus Protocol, eine führende dezentrale Börse (DEX) und ein Liquiditätsprotokoll auf der Sui-Blockchain, fiel einem ausgeklügelten Hack zum Opfer, der zu Verlusten von über 200 Millionen US-Dollar führte. Dieser Vorfall löste nicht nur Schockwellen in der DeFi-Community aus, sondern warf auch ernsthafte Bedenken hinsichtlich der Sicherheit intelligenter Verträge und der Robustheit von Protokollen auf, die auf neuen Blockchains wie Sui basieren. Das Cetus-Protokoll hatte sich als führendes DEX im Sui-Netzwerk etabliert und bietet Benutzern eine Plattform für den Austausch von Token und die Bereitstellung von Liquidität. Als wichtige Infrastrukturkomponente innerhalb des Sui-Ökosystems spielte Cetus eine entscheidende Rolle bei der Erleichterung des dezentralen Handels und trug zur Gesamtliquidität des Netzwerks bei. Aufgrund seiner Bekanntheit war es ein attraktives Ziel für böswillige Akteure, die Sicherheitslücken in seiner Codebasis ausnutzen wollten. Der Cetus Hack entfaltet sich Der Verstoß ereignete sich am 22. Mai 2025, als Angreifer einen kritischen Fehler in der intelligenten Vertragslogik von Cetus identifizierten und ausnutzten. Insbesondere war die Sicherheitslücke auf einen subtilen arithmetischen Overflow-Bug zurückzuführen, der es dem Hacker ermöglichte, die internen Abrechnungsmechanismen des Protokolls zu manipulieren. Durch den Einsatz gefälschter Token und die Manipulation von Preiskurven innerhalb von Liquiditätspools war der Angreifer in der Lage, riesige Geldbeträge abzuschöpfen, ohne sofortige Erkennungssysteme auszulösen. Gegen 3:52 Uhr PT (11:52 UTC) begannen Blockchain-Monitore, unregelmäßige Transaktionen in mehreren Liquiditätspools auf Cetus zu erkennen. Innerhalb weniger Stunden wurde das Ausmaß des Schadens klar — Vermögenswerte im Wert von über 260 Millionen US-Dollar waren aus dem Protokoll abgezogen worden. Die gestohlenen Gelder wurden schnell ausgetauscht und auf andere Blockchains übertragen, was die Wiederherstellungsmaßnahmen erschwerte. Auswirkungen auf den Markt und das Sui-Ökosystem Die Folgen des Hacks waren schnell und schwerwiegend. Der Handel auf Cetus wurde sofort eingestellt, als sich die Entwickler bemühten, die Situation einzuschätzen und weitere Verluste zu mindern. In der Zwischenzeit sank der Wert der mit der Plattform verbundenen nativen Token, wobei bei einigen innerhalb weniger Stunden ein Rückgang von bis zu 80% zu verzeichnen war. Investoren und Nutzer mussten massive Verluste hinnehmen, und das Vertrauen in das Sui-Ökosystem war erschüttert. Eine besonders alarmierende Entwicklung ereignete sich, als das Sui-Netzwerk eine umstrittene Gegenmaßnahme versuchte: Es stimmte dafür, die Brieftasche des Angreifers einzufrieren, in der sich 160 Millionen Dollar der gestohlenen Gelder befanden. Dieser Schritt demonstrierte zwar einen proaktiven Ansatz zur Wiedererlangung von Vermögenswerten, löste aber auch Debatten über die Prinzipien der Dezentralisierung aus und darüber, ob solche Maßnahmen das Vertrauen in die Unveränderlichkeit von Blockchain-Transaktionen untergraben. In einem Momentum verlor $SUI 5% und $CETUS +- 40%. Dieser Anstieg war sowohl unglaublich als auch erschreckend. Technische Details des Cetus Protocol Exploits Laut einer Analyse des Cybersicherheitsunternehmens Halborn lag die Hauptursache des Exploits darin, wie Cetus bestimmte Rechenoperationen bei Token-Swaps validierte. Ein Versehen beim Umgang mit großen Zahlen führte zu einem Überlauf, den der Angreifer geschickt manipulierte, um künstliche Ungleichgewichte in den Liquiditätspools zu erzeugen. Diese Ungleichgewichte wurden dann ausgenutzt, um dem System reale Vermögenswerte zu entziehen, ohne dass die Liquiditätsanbieter angemessen entschädigt wurden. Diese Art von Sicherheitslücke ist besonders heimtückisch, da sie sich nicht immer unter normalen Betriebsbedingungen manifestiert; stattdessen sind spezielle Grenzfälle mit sehr großen Werten oder ungewöhnlichen Transaktionssequenzen erforderlich, um ausgelöst zu werden. Solche Bugs sind bei Standardprüfungen und Testphasen bekanntermaßen schwer zu erkennen, weshalb sie die besten Kandidaten für die Ausnutzung durch gut ausgestattete Gegner sind. Reaktions- und Wiederherstellungsmaßnahmen der Cetus and Sui Foundation (auch bekannt als Mysten Labs) Während des Angriffs wurden Berichten zufolge rund 160 Millionen US-Dollar eingefroren und sollen an die Cetus-Pools zurückgegeben werden. Aus diesem Grund hat die gesamte Sui-Stiftung eine Abstimmung zur Freigabe dieser Tokens initiiert. Nach dem Angriff gab das Cetus-Team öffentliche Erklärungen ab, in denen es den Verstoß anerkannte und Schritte zur Behebung skizzierte. Sie arbeiteten eng mit Blockchain-Analyseunternehmen wie Elliptic und Chainalysis zusammen, um die Bewegung gestohlener Gelder zu verfolgen und mögliche Wege zur Wiederbeschaffung zu identifizieren. Darüber hinaus kam es zu Diskussionen über die Implementierung von Notfall-Upgrades, um bestehende Sicherheitslücken zu schließen und die zukünftige Widerstandsfähigkeit gegen ähnliche Angriffe zu verbessern. Die Mitglieder der Gemeinschaft äußerten gemischte Reaktionen auf diese Entwicklungen. Während viele die Transparenz lobten, die die Führung von Cetus nach dem Hack an den Tag gelegt hatte, kritisierten andere die mangelnde Vorbereitung auf solche Szenarien und stellten die Frage, ob vor dem Start ausreichende Schutzmaßnahmen getroffen worden waren.
- Sui
- Security Protocols
1 - ArtikelHaGiang164May 25, 2025
Mein erster Artikel zKat: Datenschutzwahrende Authentifizierung für öffentliche Blockchains
Weil Transparenz nicht bedeuten sollte, deine Geheimnisse preiszugeben. Auf den meisten öffentlichen Blockchains ist heute jede Transaktion und Benutzeridentität öffentlich sichtbar. Transparenz ist zwar eine der größten Stärken der Blockchain, geht aber auf Kosten des Datenschutzes, insbesondere wenn es um die Authentifizierung geht. ZKat, die Abkürzung für Zero-Knowledge-Authenticators, ist ein neuartiges kryptografisches Primitiv, das die Privatsphäre wahrende Authentifizierung in die Blockchain-Welt bringt. Mit zKat können Benutzer nachweisen, dass sie zur Durchführung einer Transaktion autorisiert sind, ohne die Regeln oder Richtlinien preiszugeben, die hinter dieser Autorisierung stehen. ##Das Problem mit traditionellen Ansätzen Frühere Versuche, bei der Authentifizierung auf Datenschutz zu achten, wie z. B. die Verwendung vonSchwellenwertsignaturen, konnten nur begrenzte Informationen verbergen. So könnten sie beispielsweise verschleiern, welche Benutzer eine Transaktion signiert haben, aber sonst nicht viel. Sie hatten auch Probleme mitkomplexeren Authentifizierungsrichtlinien(wie Kombinationen von Rollen, Identitäten oder Regeln). zKat verändert das Spiel durch: Unterstützungbeliebig komplexerpolitischer Maßnahmen Ermöglicht flexible Strukturen wieSignaturkombinationen mit mehreren Schema Diegesamte Richtlinie vor der Öffentlichkeit verheimlichen ##Wie funktioniert zKat Um zKat zu erstellen, entwarfen die Autoren einenCompiler, der das weit verbreiteteGroth16zk-SNARK-System in eine neue Art vonNon-Interactive Zero-Knowledge (NIZK)-Proof umwandelt — eines, daseindeutige Bestätigungsschlüsselunterstützt. Was heißt das? Das bedeutet, dass der Prüfernicht feststellenkann, welche Richtlinie verwendet wird, aber der Nachweis überzeugt ihn trotzdem davon, dass sie gültig ist. Dies ist eine brandneue kryptografische Eigenschaft, die in dem Artikel vorgestellt wurde. Sie ist die Grundlage dafür, wie ZKat denDatenschutz bei Richtliniensicherstellt. Aber die Autoren haben nicht bei zKat aufgehört. Sie gingen mitzKat, einer Version, dievergessene Aktualisierungenunterstützt, noch einen Schritt weiter. Kurz gesagt: Ein Richtlinienaussteller kann die Authentifizierungsrichtlinie aktualisieren ohne etwas Neues zu enthüllen Dies ist in realen Blockchain-Systemen, in denen sich die Richtlinien möglicherweise weiterentwickeln müssen, sehr mächtig — denken Sie an DAOs, die die Wahlregeln aktualisieren, oder an Institutionen, die die Schlüssel rotieren. Sie untersuchen auch die Verwendungrekursiver ZK-Proofs, um zKAt skalierbar und für die Blockchain-Integration geeignet zu machen. Die Forscher implementierten zKat in einem Prototyp für die schwellenwertbasierte Authentifizierung. Ihre Bewertung zeigt: Die Leistung liegt auf dem Niveau herkömmlicher Schwellenwertsignaturen zKat unterstütztweitaus komplexere Richtlinien Das alles mitminimalem Gemeinkosten
- Sui
- Architecture
1 - Artikel0xduckmove308May 19, 2025
Was ist IKA? „Nicht nur der Hype 👀“
(p/s: Keines dieser „Web3-Updates“, die dir 3 Zeilen Fluff geben und es Alpha nennen 😮💨) Lesen Sie den ganzen Artikel: https://x.com/InternSui81687/status/1897309368644985108 Haben Sie schon einmal Vermögenswerte zwischen Ketten bewegt und haben das Gefühl, Sie wären Indiana Jones, der Fallen ausweicht? Ja. Das liegt daran, dass Interoperabilität im Moment riskante Brücken und zentrale Fehlerquellen bedeutet. Ika sagt: „Nee, damit sind wir fertig.“ Sie bauen ein System, das vertrauenswürdig ist, einen schnellen Autofokus hat und deine Schlüssel an niemanden weitergibt. Es basiert auf Sui und verwendet Threshold-Verschlüsselung und 2PC-MPC Im Video hier sagt David Lash (Mitbegründer von Ika) direkt, was alle denken: Interoperabilität ist defekter AF. Und anstatt einen weiteren „Wir brauchen eine Lösung“ -Blog zu schreiben, wie es die meisten Teams tun, verbrachten sie zwei Jahre damit, Sicherheitsexperten, KI-Nerds und Akademiker hinzuzuziehen, um tatsächlich einen zu entwickeln. Was haben sie sich ausgedacht? Ein System, das 2PC-MPC und Schwellenwertverschlüsselung verwendet — ausgefallene Worte, die im Grunde bedeuten: Ihre Schlüssel bleiben bei Ihnen, Ihr Vermögen wird nicht wie bei einem Weihnachtsgeschenk von 2017 neu verpackt, und alles geht höllisch schnell. Zum Beispiel schützt Ika nicht nur deine Sachen. Es verarbeitet Transaktionen mit einer Latenz von unter einer Sekunde und bleibt trotzdem dezentralisiert. In der Zwischenzeit sind die Brücken hier draußen und es dauert 8 Minuten und deine Seele braucht nur, um einen Tausch zu bestätigen. Das haben sie auf Sui gebaut. Und wenn du bis jetzt auf Sui geschlafen hast, ist das Nickerchen vorbei. Suis objektzentriertes Modell, die blitzschnelle Finalität und der Mysticeti-Konsens (ja, das ist eine Sache, nein, sie ist nicht erfunden) sind perfekt für das, was Ika versucht zu tun. David sagte sogar, dass Sui aufgrund seiner Entwicklungserfahrung eine naheliegende Wahl war — was in der Kryptobranche, wo sich jedes Entwicklertool wie eine uralte Schriftrolle anfühlt, ein seltenes Lob ist. Aber was mich wirklich begeistert hat, war ihre Einstellung zu UX. Die beste Kryptowährung? Die Art, die langweilig ist. Nicht auf eine schlechte Art, sondern auf die Art „es funktioniert einfach“. Ika hofft auf eine Zukunft, in der du nicht einmal weißt, dass du kettenübergreifende Sachen machst. Keine Popups, keine Bridges, keine gefälschten Tokens. Öffne einfach deine Wallet, leihe dir deine BTC nativ, tausche zwischen den Ketten und bleib lebendig. Das ist es, wonach wir gefragt und irgendwie vergessen haben, es zu fordern. Und glaube nicht, dass das nur für Degen Bros ist. Ika ermöglicht es DAOs, Indie-Teams und Unternehmen, ihre eigenen Verwahrungslösungen auf den Markt zu bringen — denken Sie an das „Fireblocks-Starterpaket“, aber auf Steroiden und tatsächlich zugänglich. Sie benötigen kein 500.000-Dollar-Setup mehr, um eine sichere Infrastruktur aufzubauen. Nur Sui, Ika und ein bisschen Mut. Oh, und lass uns nicht auf Bitcoin schlafen. BTC sitzt seit Jahren am Spielfeldrand wie dieser Typ, der sich weigert, dem Spiel beizutreten. Aber Ika macht es spielbar. DeFi ohne Wrapping, ohne Bewegung — sperren Sie es einfach als natives Material und los geht's. Institutionen werden es lieben, weil sie dadurch konform und effizient bleiben. Keine Steuerflucht, keine Sorgerechtsfallen. Nur Kapital, das sauber fließt. Wenn dich also jemand fragt: „Was kommt als Nächstes mit Krypto?“ schicke ihnen keinen Tweet-Thread mit der Aufschrift „Interoperabilität ist die Zukunft“
- Sui
1 - ArtikelRogueRig134May 13, 2025
Was ist IKA und warum der Hype?
@ikadotxyz, das ultraschnelle parallele MPC-Netzwerk auf der Sui-Blockchain, sorgt aufgrund seines Potenzials, die Sicherheit und Interoperabilität von Web3 zu revolutionieren, für großes Aufsehen. Jüngste Beiträge auf X unterstreichen die optimistische Stimmung. Berichten zufolge wird IKA auf Plattformen wie Whales vor der Markteinführung zwischen 4,90 und 10 US-Dollar gehandelt, obwohl das Angebot an 1 Milliarde Tokens reicht. Dies deutet auf eine mögliche Marktkapitalisierung in Milliardenhöhe hin, sofern die Dynamik anhält, was auf eine strategische Investition der Sui Foundation in Höhe von 21 Mio. USD und eine rekordverdächtige SUI-NFT-Kunstkampagne von 1,4 Mio. USD zurückzuführen ist. Die Latenz von Ika unter einer Sekunde und die Fähigkeit, über Hunderte von Signierknoten zu skalieren, machen es zu einem Wendepunkt für DeFi, dezentrale Verwahrung und kettenübergreifende Anwendungen. Die bevorstehende Einführung des IKA-Tokens auf Sui wird voraussichtlich neue Funktionen eröffnen und die Akzeptanz weiter vorantreiben. X-Nutzer sind begeistert von der Rolle von IKA im @GiveRep -Treueprogramm, und einige nennen es eine der größten Airdrop-Möglichkeiten auf Sui. Allerdings können die Preise vor Markteinführung volatil und spekulativ sein, sodass es nicht garantiert ist, dass die Spanne zwischen 4,90 und 10$ auch nach der Markteinführung Bestand hat. Informieren Sie sich immer über die Fundamentaldaten des Projekts — schauen Sie auf den offiziellen Kanälen von Ika nach, um tiefere Einblicke zu erhalten — und wägen Sie die Risiken ab, bevor Sie loslegen. Das Sui-Ökosystem heizt sich auf, aber im Bereich Krypto ist nichts eine sichere Wette
- Sui
- Architecture
1 - ArtikelRogue129May 13, 2025
SUI Node Setup — Eine ausführliche Anleitung
Um einen Sui-Knoten einzurichten, müssen Sie die Sui-Binärdateien installieren, das Sui-Repository klonen und den Knoten konfigurieren. Sie können entweder aus dem Quellcode erstellen oder Docker verwenden. Sobald der Knoten läuft, können Sie seinen Status und den Synchronisierungsfortschritt überwachen. Detaillierte Schritte: Installieren Sie Sui Binaries: Folgen Sie den Anweisungen in der Sui-Dokumentation, um die Sui-Binärdateien zu installieren. Wenn Sie Docker verwenden, folgen Sie den Anweisungen in der Docker-Readme-Datei für den Sui Full Node. Wenn Sie aus dem Quellcode erstellen, müssen Sie das Sui-Repository klonen und kompilieren. Konfigurieren Sie den Knoten: Vollständiger Knoten: Sie können einen Sui Full-Node mithilfe von Docker oder durch Erstellen aus dem Quellcode konfigurieren, wie in der Sui-Dokumentation beschrieben. Validator Node: Folgen Sie den Anweisungen in der Sui Validator Node Configuration, um einen Validator-Knoten zu konfigurieren. Dazu gehören die Installation und Konfiguration von Sui, die Schlüsselverwaltung und die Speicherkonfiguration. Vollständige Knotenkonfiguration: Fahren Sie alle laufenden Full-Knoten herunter. Entfernen Sie die Datenbank und die Datei genesis.blob. Ruft die Quelle aus der neuesten Version ab. Setze deinen Zweig zurück. Laden Sie den neuesten Genesis-Blob herunter. Aktualisieren Sie bei Bedarf Ihre fullnode.yaml-Konfigurationsdatei. Starten Sie Ihren Sui Full-Node neu. Führen Sie den Knoten aus: Starten Sie den Sui-Knoten mit dem entsprechenden Befehl für Ihre Konfigurationsmethode (z. B. sui-node- oder Docker-Befehle). Überwachen Sie den Knoten: Überwachen Sie den Status, den Synchronisierungsfortschritt und die Protokolle Ihres Knotens, um sicherzustellen, dass er ordnungsgemäß läuft. Verwenden Sie Tools wie Logging, Tracing und Metriken, um den Knoten zu überwachen. Der Standardport für Metriken ist 9184, aber Sie können ihn in der Datei fullnode.yaml ändern. Zusätzliche Schritte: Registrierung als Komitee: Wenn Sie einen Validator-Knoten betreiben, müssen Sie sich beim Ausschuss registrieren. Liquid Staking: Wenn du einen Node betreibst, kannst du auch am Liquid Staking teilnehmen. Synchronisiere deinen Fork: Wenn du zum Sui-Projekt beiträgst, musst du deinen Fork mit dem Haupt-Repository synchronisieren. Wenn du diese Schritte befolgst, kannst du erfolgreich einen Sui-Knoten einrichten und ausführen.
- Sui
1 - ArtikelHaGiang164May 12, 2025
„Die Sui-Trilogie entschlüsseln: Die Zukunft der Web3-Infrastruktur ebnen
Bei der Erforschung der Web3-Welt tauchen neben dem allgemeinen Streben nach schnelleren Transaktionsgeschwindigkeiten und niedrigeren Gebühren zunehmend tiefere, strukturelle Herausforderungen auf. Wie können riesige Datenmengen wirtschaftlich gespeichert werden? Wie können sensible Informationen in einer dezentralen Umgebung sicher geschützt werden? Können komplexe Berechnungen effizient außerhalb der Kette ausgeführt werden, während ihre Ergebnisse dennoch vor Ort verifiziert und als vertrauenswürdig eingestuft werden? Viele Projekte versuchen, diese Probleme zu lösen, indem sie verschiedene Dienste von Drittanbietern kombinieren. Dieser Weg bringt jedoch häufig Integrationskomplexität, potenzielle Vertrauensprobleme und eine fragmentierte Benutzererfahrung mit sich. Angesichts dieser Herausforderungen auf Infrastrukturebene haben die Sui-Blockchain und ihr Kernentwicklungsteam Mysten Labs eine stärker integrierte Lösung vorgeschlagen. Anstatt sich auf einen Flickenteppich externer Tools zu verlassen, haben sie eine Blockchain mit einer einzigartigen Architektur entworfen — einschließlich ihres objektzentrierten Modells und der Programmiersprache Move — und gleichzeitig drei eng miteinander verbundene native Infrastrukturkomponenten aufgebaut: Walrus, Seal und Nautilus. Dieser Artikel zielt darauf ab, die Designkonzepte hinter diesen drei Komponenten zu entschlüsseln, zu untersuchen, wie sie funktionieren, wie sie zueinander in Beziehung stehen und welche wirklichen Änderungen sie für Web3-Anwendungen mit sich bringen könnten. Suis einzigartige Architektur Um zu verstehen, wie diese drei Tools auf Sui funktionieren, müssen wir uns zunächst einige wichtige Merkmale der Sui-Plattform selbst ansehen. Eine der wichtigsten Innovationen von Sui ist das objektorientierte Modell, eine grundlegende Abkehr von der traditionellen kontobasierten Architektur. Sui behandelt Token, NFTs und sogar komplexe Datenstrukturen als eigenständige „Objekte“. Stellen Sie sich vor, Sie verwalten jedes Asset als separate Box, anstatt alles in einem einzigen Ledger zu protokollieren. Dieses Design ermöglicht die parallele Verarbeitung von Aktionen, die nichts miteinander zu tun haben — wie die Handhabung zweier unabhängiger NFTs —, wodurch der Durchsatz erhöht wird. Diese Objektgranularität schafft eine natürliche Synergie mit Walrus und Seal: Walrus behandelt gespeicherte Daten als Objekte, während Seal Berechtigungsregeln direkt an einzelne Objekte anhängen kann. Darüber hinaus verwendet Sui die Programmiersprache Move, die speziell für die Verwaltung digitaler Assets entwickelt wurde. Move legt Wert auf Sicherheit und zielt darauf ab, viele häufig auftretende Sicherheitslücken in intelligenten Verträgen auf Sprachebene zu reduzieren. Aufgrund dieser starken Grundlage eignet es sich gut für den Aufbau robuster Infrastrukturkomponenten. Durch die Zusammenführung von Kettendesign und Infrastrukturentwicklung unter einem Dach (Mysten Labs) will Sui ein nahtloseres, synergetisches Entwicklererlebnis bieten. Walrus: Wirtschaftlicher, programmierbarer dezentraler Speicher Das Speichern großer Dateien (Bilder, Videos, KI-Modelle — zusammenfassend als Blobs bezeichnet) direkt in der Kette ist bekanntermaßen teuer. Bestehende dezentrale Speicherlösungen haben jeweils Kompromisse, aber Walrus strebt ein neues Gleichgewicht zwischen Kosteneffizienz und intelligenter Vertragsinteraktivität an und beseitigt direkt die Kostenbarrieren umfangreicher On-Chain-Daten. Das Herzstück von Walrus ist Erasure Coding, eine clevere Technik, bei der eine Datei „zerteilt“ und „Hinweise zur Wiederherstellung“ hinzugefügt werden, sodass die Datei auch dann rekonstruiert werden kann, wenn Teile verloren gehen. Walrus nennt diese zusätzlichen Fragmente „Red Stuff“. Stellen Sie sich das so vor: Wenn Sie zwei Zahlen haben, sagen wir 3 und 5, und Sie beide sowie ihre Summe (8) speichern, ist es nicht katastrophal, die 3 zu verlieren — Sie können sie mit 8 - 5 = 3 wiederherstellen. Die zusätzlichen Wiederherstellungsfragmente spielen eine ähnliche Rolle, da sie mathematisch mit den Originalen verknüpft sind. Nach der Fragmentierung und Kodierung verteilt Walrus diese Shards auf viele Knoten. Selbst wenn einige Shards verloren gehen, kann das System die Originaldatei rekonstruieren, solange eine bestimmte Anzahl von Fragmenten abgerufen wird. Das spart im Vergleich zur vollständigen Dateireplikation erheblich Speicherplatz. Dieser Ansatz reduziert die Speicherkosten drastisch und könnte die Preise für dezentralen Speicher denen zentralisierter Cloud-Anbieter näher bringen. Noch interessanter ist, dass Walrus das Objektmodell von Sui nutzt: Jede gespeicherte Datei wird zu einem programmierbaren On-Chain-Objekt. Entwickler können Move verwenden, um intelligente Verträge zu schreiben, die diese Speicherobjekte verwalten — indem sie Zugriffsregeln festlegen, Metadaten automatisch aktualisieren usw. Speicher ist nicht mehr nur passiv, sondern wird zu einer nativ programmierbaren Ressource. Es gibt auch eine Token-Utility-Ebene: Für die Interaktion mit Walrus-Daten auf Sui sind SUI-Tokens erforderlich, um Metadaten (wie Dateinamen, Größen, Speicherorte) aufzuzeichnen und möglicherweise Tokens für Speichergebühren zu sperren. Wenn die Akzeptanz von Walrus zunimmt, könnte die Nachfrage nach SUI steigen und das Angebot knapper werden. Seal: Der dezentrale Tresor- und Access-Gatekeeper Viele Web3-Apps befassen sich mit sensiblen Daten: Benutzer-IDs, Finanzdaten, Paywall-Inhalte. Wie speichert man Geheimnisse in einem dezentralen Kontext sicher und kontrolliert den Zugriff darauf? Seal ist eine DSM-Lösung (Decentralized Secrets Management), die entwickelt wurde, um diese Frage zu beantworten. Eine der Kerntechnologien ist die Threshold Encryption. Stellen Sie sich einen Tresor vor, für dessen Öffnen zwei Schlüssel erforderlich sind, die jeweils von einer anderen Person gehalten werden. Ähnlich teilt die Schwellenwertverschlüsselung die Entschlüsselungsschlüssel in mehrere Teile auf und verteilt sie an unabhängige Schlüsselserver. Nur wenn eine vordefinierte Anzahl von ihnen zusammenarbeitet (der Schwellenwert), können die Daten entschlüsselt werden — kein einzelner Server kann das alleine tun, was Vertrauen verbreitet und die Fehlertoleranz erhöht. Das andere clevere Feature von Seal ist, dass die Zugriffskontrolllogik als Move Smart Contracts On-Chain geschrieben ist. Entwickler können klare Regeln definieren: Beispielsweise können nur Benutzer, die eine bestimmte NFT besitzen oder eine Gebühr bezahlt haben, auf bestimmte Daten zugreifen. Diese Transparenz und Überprüfbarkeit unterscheidet Seal von herkömmlichen zentralisierten Zugangssystemen. Wenn ein Benutzer oder eine App ein Geheimnis entschlüsseln möchte, sendet sie eine Anfrage an die Schlüsselserver. Diese Server überprüfen die On-Chain-Regeln. Nur wenn die Bedingungen erfüllt sind, geben sie ihre Schlüsselfragmente frei. Die eigentliche Entschlüsselung erfolgt auf dem Client-Gerät, sodass Schlüsselserver niemals die Originaldaten berühren. Seal kann Daten schützen, die überall gespeichert sind — auf Walrus, anderen dezentralen Netzwerken oder sogar zentralisierten Clouds. Dies macht es ideal für sicheres Messaging, private Benutzerdaten, kostenpflichtiges Content Gating, vertrauliche Abstimmungen und mehr. Nautilus: Off-Chain-Berechnungen auf der Kette verifizierbar machen Blockchains eignen sich nicht besonders für komplexe oder ressourcenintensive Aufgaben. Diese On-Chain zu erledigen ist langsam, teuer und beeinträchtigt die Privatsphäre. Lösungen wie Layer 2 oder Oracles helfen, aber Nautilus geht einen anderen Weg: die Bereitstellung vertrauenswürdiger Off-Chain-Berechnungen. Nautilus verwendet eine hardwarebasierte Lösung namens Trusted Execution Environments (TEEs). Stellen Sie sich ein TEE als eine sichere, isolierte Zone innerhalb einer CPU vor. Code und Daten in dieser Zone sind vom Rest des Systems, einschließlich des Betriebssystems selbst, abgeschirmt. Der grundlegende Arbeitsablauf sieht wie folgt aus: Ein Entwickler stellt eine Rechenaufgabe (z. B. Finanzmodelle, KI-Inferenz, Spiellogik) für ein von ihm kontrolliertes TEE bereit. Wenn die Aufgabe abgeschlossen ist, erstellt das TEE eine kryptografische Bestätigung — eine Art fälschungssichere „Quittung“, die Folgendes belegt: Die Aufgabe wurde in einem TEE ausgeführt Der Code wurde nicht manipuliert Der Vorgang wurde erfolgreich abgeschlossen. Diese Bescheinigung und das Ergebnis werden einem Move-Smart-Vertrag auf Sui unterzogen. Der Vertrag bestätigt die Bestätigung (z. B. Gültigkeit der Signatur und Hash des Codes). Nur wenn die Überprüfung erfolgreich ist, akzeptiert der Vertrag das Ergebnis und fährt mit On-Chain-Aktionen fort. Nautilus verbindet leistungsstarkes Off-Chain-Computing mit Überprüfbarkeit und Vertrauen innerhalb der Kette, ohne sensible Daten preiszugeben. Nautilus in Aktion: Der Fall Bluefin Ein konkretes Beispiel ist Bluefin, eine dezentrale unbefristete Handelsplattform. Die meisten leistungsstarken Handelsplattformen stehen vor einem Dilemma: Orderbücher vollständig auf der Kette zu führen, bietet Transparenz, ist aber langsam und teuer; sie aus der Kette zu verlagern, verbessert die Geschwindigkeit, führt aber zu Vertrauensproblemen. Bluefin nutzt Nautilus, um diese Lücke zu schließen: • Der Auftragsabgleich läuft innerhalb eines TEE und gewährleistet so eine sichere, isolierte Bearbeitung. • Nautilus liefert den kryptografischen Beweis, dass die Matching-Logik korrekt lief. • Beweise und Ergebnisse werden in der Kette eingereicht, wo intelligente Verträge sie überprüfen, bevor die Abrechnung ausgeführt wird. Dieser Ansatz ermöglicht es Bluefin, ein schnelles Off-Chain-Matching mit On-Chain-Vertrauensgarantien anzubieten, was es für den leistungsintensiven DeFi-Handel wie den Derivatehandel rentabel macht. Dadurch wird natürlich ein gewisses Vertrauen vom reinen Blockchain-Konsens hin zur TEE-Hardware und -Implementierung verlagert.
- Sui
- Architecture
1

- 0xduckmove... SUI+88
1
- harry phan... SUI+61
2
- MiniBob... SUI+57
3
- ... SUIHaGiang+56
- ... SUIRogue+47
- ... SUIRogueRig+44
- ... SUIPeera Admin+25
- ... SUIVens.sui+20
- ... SUIMarlKey+20
- ... SUIdudley_smith+16
- Sui
- Architecture
- SDKs and Developer Tools
- Move
- Security Protocols
- NFT Ecosystem
- Transaction Processing