Startseite
Willkommen im Sui Community Forum
Verdiene deinen Anteil an 1000 Sui
Sammle Reputationspunkte und erhalte Belohnungen für deine Hilfe beim Wachstum der Sui-Community.
Kopfgeldbeiträge
+10
Experten Q&AMay 29, 2025Warum benötigt BCS eine genaue Feldreihenfolge für die Deserialisierung, wenn Move-Strukturen benannte Felder haben?
Warum erfordert BCS eine exakte Feldreihenfolge für die Deserialisierung, wenn Move-Strukturen benannte Felder haben? Ich habe mich eingehend mit der BCS-Kodierung/Dekodierung in Move befasst, insbesondere für die kettenübergreifende Kommunikation und die Off-Chain-Datenverarbeitung. Beim Durcharbeiten der Beispiele in der Sui Move-Dokumentation bin ich auf ein Verhalten gestoßen, das kontraintuitiv erscheint, und ich versuche, die zugrunde liegenden Designentscheidungen zu verstehen. Gemäß der BCS-Spezifikation „gibt es in BCS keine Strukturen (da es keine Typen gibt); die Struktur definiert lediglich die Reihenfolge, in der Felder serialisiert werden.“ Das bedeutet, dass wir beim Deserialisieren peel_*Funktionen in exakt derselben Reihenfolge wie in der Strukturfelddefinition verwenden müssen. Meine spezifischen Fragen: Entwurfsbegründung: Warum erfordert BCS eine exakte Übereinstimmung der Feldreihenfolge, wenn Move-Strukturen benannte Felder haben? Wäre es nicht robuster, Feldnamen zusammen mit Werten zu serialisieren, ähnlich wie bei JSON oder anderen selbstbeschreibenden Formaten? Generische Typinteraktion: In den Dokumenten wird erwähnt, dass „Typen, die generische Typfelder enthalten, bis zum ersten generischen Typfeld analysiert werden können“. Betrachten Sie diese Struktur: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Wie genau funktioniert die partielle Deserialisierung hier? Kann ich bis zu more_metadata deserialisieren und beide generischen Felder ignorieren, oder blockiert das erste generische Feld (generic_data) die weitere Deserialisierung vollständig? Sprachübergreifende Konsistenz: Was passiert, wenn Sie die @mysten /bcs JavaScript-Bibliothek verwenden, um Daten zu serialisieren, die von Move-Verträgen verwendet werden, wenn: Ich ordne versehentlich Felder im JavaScript-Objekt neu an? Die Move-Strukturdefinition ändert die Feldreihenfolge bei einem Vertrags-Upgrade? Ich habe verschachtelte Strukturen mit ihren eigenen generischen Parametern? Praktische Implikationen: Wie gehen Teams in Produktionssystemen mit der Entwicklung des BCS-Schemas um? Versionieren Sie Ihre BCS-Schemas oder gehen Sie davon aus, dass die Reihenfolge der Strukturfelder nach der Bereitstellung unveränderlich ist?
- Sui
- Move
51+10
Experten Q&AMar 05, 2025Fehler bei der Überprüfung mehrerer Quellen“ in den Veröffentlichungen des Sui Move-Moduls — Automatisierte Fehlerbehebung
Entwickler, die mit Sui Move arbeiten, stoßen beim Versuch, Module zu veröffentlichen oder zu aktualisieren, häufig auf Probleme im Zusammenhang mit „Fehler bei der Überprüfung mehrerer Quellen gefunden“. Diese Fehler treten aufgrund von Diskrepanzen zwischen lokalen Abhängigkeiten und ihren Gegenstücken in der Kette auf, was zu fehlgeschlagenen Veröffentlichungen und Problemen bei der Bereitstellung führt. Im Folgenden finden Sie ein konsolidiertes Beispiel für die Fehler, mit denen Entwickler konfrontiert sind: Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk Dieses Problem tritt häufig auf aufgrund von: Die Versionen zwischen der lokalen Entwicklungsumgebung (z. B. Sui CLI) und dem On-Chain-Status stimmen nicht überein. Unterschiede in den Paketkonfigurationen zwischen Netzwerken (z. B. Mainnet vs. Testnet). Fehlende oder veraltete Abhängigkeiten in der On-Chain-Umgebung. Wichtige Fragen Wie können wir die Erkennung und Behebung dieser Abhängigkeiten während des Veröffentlichungsprozesses automatisieren? Welche Tools oder Skripte können entwickelt werden, um sicherzustellen, dass lokale Abhängigkeiten immer mit denen auf der Kette übereinstimmen? Gibt es eine Möglichkeit, diesen Prozess zu rationalisieren, indem man Abhängigkeitsprüfungen in bestehende CI/CD-Pipelines integriert oder das Sui SDK erweitert? Ihre Aufgabe ist es, eine Lösung vorzuschlagen, die diese Herausforderungen bewältigt und eine reibungslosere und zuverlässigere Bereitstellung für Sui Move-Entwickler gewährleistet. Stellen Sie sicher, dass Sie Ihre Lösung unten veröffentlichen.
- Sui
- SDKs and Developer Tools
41Beste Antwort

- 0xduckmove... SUI+68
1
- MiniBob... SUI+57
2
- harry phan... SUI+51
3
- ... SUIRogue+47
- ... SUIRogueRig+44
- ... SUIHaGiang+36
- ... SUIPeera Admin+25
- ... SUIVens.sui+20
- ... SUIMarlKey+20
- ... SUIdudley_smith+16
Neue Artikel
- Verwandeln Sie Wallets in programmierbare, zusammensetzbare Smart Agents.Artikel0xduckmove288May 31, 2025
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
1 - BCS-Codierung in Sui: Was es ist und warum es wichtig istArtikel0xduckmove288May 30, 2025
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:
1 - Cetus Protocol Hack - Der größte DeFi-Exploit auf SuiArtikelVens.sui134May 29, 2025
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.
1 - Mein erster Artikel zKat: Datenschutzwahrende Authentifizierung für öffentliche BlockchainsArtikelHaGiang144May 25, 2025
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
1 - Was ist IKA? „Nicht nur der Hype 👀“Artikel0xduckmove288May 19, 2025
(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“
1 - Was ist IKA und warum der Hype?ArtikelRogueRig134May 13, 2025
@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
1 - SUI Node Setup — Eine ausführliche AnleitungArtikelRogue129May 13, 2025
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.
1 - „Die Sui-Trilogie entschlüsseln: Die Zukunft der Web3-Infrastruktur ebnenArtikelHaGiang144May 12, 2025
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.
1 - Im Kiosk von Sui: So bauen Sie sichere NFT-MarktplätzeArtikelHaGiang144May 01, 2025
Was ist Suis Kiosk? Kiosk ist ein natives Smart-Contract-Modul auf der Sui-Blockchain, das entwickelt wurde, um die Art und Weise, wie NFTs gespeichert, verwaltet und gehandelt werden, zu standardisieren und zu vereinfachen. Es fungiert als programmierbares NFT-Storefront — ideal für Entwickler, die vermeiden möchten, das Rad für jedes NFT-Projekt neu zu erfinden. Egal, ob Sie einen Marktplatz, eine Börse für Spielinhalte oder eine Galerie für digitale Sammlerstücke aufbauen, Kiosk bietet Ihnen sichere, anpassbare Bausteine. 🛠️ Hauptmerkmale von Kiosk 📦 NFT-Speicher und -Display: Benutzer können NFTs in Kiosk-Smart-Contracts hinterlegen, um sie zu speichern, vorzuzeigen oder zu tauschen 🔐 Sichere Eigentumsübertragung: Alle Kauf-/Verkaufsabläufe sind standardisiert und überprüfbar — auf Wiedersehen mit zwielichtigen Swaps 👋 🎛️ Feingranulare Berechtigungen: Mit Kiosk können Entwickler genau definieren, wer was mit jedem NFT machen kann. 📈 Erweiterbarkeit für Entwickler: Plug-in-Auktionen, Batch-Angebote, Bundles und mehr. 🤔 Warum mit Kiosk bauen? Stellen Sie sich vor, Sie starten eine NFT-App. Sie benötigen wahrscheinlich eine Möglichkeit für Benutzer, Vermögenswerte sicher zu speichern. Eine Möglichkeit, Vermögenswerte aufzulisten und zu kaufen. Kiosk erledigt das alles für Sie. Anstatt all diese Abläufe von Grund auf neu zu schreiben (und Bugs 🐛 oder Exploits zu riskieren), verwenden Sie die kampferprobte API von Kiosk. 🧪 Beispiel-App: Gebäude mit Kiosk Kommen wir zu einem echten Beispiel. Sie erstellen ein einfaches NFT-Modul und verwenden dann das Kiosk-Modul, um es abzulegen, aufzulisten und anderen zu ermöglichen, es zu kaufen. Schrittweise Codeaufschlüsselung module 0xNFT::simple_nft { use sui::object::{UID}; use sui::tx_context::TxContext; struct SimpleNFT has key { id: UID, name: String, description: String, url: String, } public entry fun mint( name: String, description: String, url: String, ctx: &mut TxContext ): SimpleNFT { SimpleNFT { id: UID::new(ctx), name, description, url, } } } Befehle (Sui CLI) Compile your package sui move build Deploy to network sui client publish --gas-budget 10000 Mint NFT sui client call --function mint --module simple_nft \ --args "My NFT" "Desc" "https://example.com/img.png" --gas-budget 1000 Initialize Kiosk sui client call --function init_kiosk --module kiosk_example --gas-budget 1000 Deposit NFT to Kiosk sui client call --function deposit_nft --module kiosk_example \ --args --gas-budget 1000 List for sale sui client call --function list_nft_for_sale --module kiosk_example \ --args 100 --gas-budget 1000 Purchase NFT sui client call --function purchase_nft --module kiosk_example \ --args --gas-budget 1000 Kiosk ist eines der mächtigsten Primitive im Sui-Ökosystem für NFT-Entwickler. Es abstrahiert sich wiederholende Logik und verleiht Ihrem App-Stack Sicherheit und Modularität. Mit nur wenigen Codezeilen erstellen Sie vollständige NFT-Marktplatzabläufe, die produktionsbereit und kampferprobt sind.
2 - Move Programming Language — Die Geschichte dahinterArtikelMiniBob406Apr 30, 2025
In der sich ständig weiterentwickelnden Landschaft der Blockchain-Technologie sind intelligente Vertragsprogrammiersprachen zum Rückgrat dezentraler Anwendungen (DApps) geworden. Unter diesen hat sich Move als bahnbrechende Innovation herausgestellt und bietet einzigartige Funktionen, die es von traditionellen Sprachen wie Solidity oder Vyper unterscheiden. Move wurde unter Berücksichtigung von Sicherheit und Skalierbarkeit entwickelt, um viele der Sicherheitslücken und Ineffizienzen früherer Blockchain-Ökosysteme zu beheben. Dieser Artikel befasst sich mit den Ursprüngen, Funktionen und Auswirkungen der Programmiersprache Move und untersucht ihren Weg von ihren Anfängen zu einem der vielversprechendsten Tools für den Aufbau robuster dezentraler Systeme. Die Ursprünge von Move: Eine Lösung für Blockchain-Herausforderungen Die Programmiersprache Move wurde erstmals von Meta (ehemals Facebook) im Rahmen seines ehrgeizigen Diem-Projekts (ursprünglich Libra genannt) eingeführt. Diem zielte darauf ab, eine globale digitale Währungs- und Finanzinfrastruktur zu schaffen, die auf Blockchain-Technologie basiert. Das Team stellte jedoch schnell fest, dass die vorhandenen intelligenten Vertragssprachen für ihre Vision nicht ausreichten. In traditionellen Sprachen fehlten häufig Mechanismen, um häufige Sicherheitslücken wie Wiedereintrittsangriffe, Ganzzahlüberläufe und unbefugte Duplizierung von Ressourcen zu verhindern. Diese Probleme hatten bereits in anderen Ökosystemen erheblichen Schaden angerichtet, allen voran der berüchtigte DAO-Hack auf Ethereum. Um diese Herausforderungen zu bewältigen, entwickelte das Engineering-Team von Meta Move, eine neue Sprache, die speziell für ressourcenorientiertes Programmieren entwickelt wurde. Im Gegensatz zu herkömmlichen Programmiersprachen behandelt Move digitale Ressourcen als erstklassige Ressourcen und stellt sicher, dass sie nicht dupliziert, unbeabsichtigt gelöscht oder missbraucht werden können. Dieser Ansatz wurde von linearer Logik inspiriert, einem mathematischen Rahmen, der strenge Eigentumsregeln für Ressourcen durchsetzt. Durch die Einbettung dieser Prinzipien in den Kern der Sprache führte Move einen Paradigmenwechsel in der Art und Weise ein, wie Entwickler mit digitalen Assets auf der Blockchain interagieren. Obwohl das Diem-Projekt aufgrund behördlicher Kontrollen schließlich auf Eis gelegt wurde, fand Move in unabhängigen Blockchain-Projekten wie Aptos und Sui neues Leben. Diese Plattformen übernahmen Move als ihre primäre intelligente Vertragssprache und erkannten das Potenzial, die Art und Weise, wie dezentrale Anwendungen erstellt und gesichert werden, zu revolutionieren. Hauptmerkmale von Move: Warum es auffällt 1. Ressourcenorientiertes Programmieren Eines der prägenden Merkmale von Move ist der Fokus auf ressourcenorientiertes Programmieren. In Move werden digitale Vermögenswerte wie Token, NFTs oder sogar benutzerdefinierte Objekte als Ressourcen behandelt, die strengen Eigentumsregeln folgen. Einmal erstellt, kann eine Ressource nicht kopiert oder zerstört werden, es sei denn, ihr Modul erlaubt dies ausdrücklich. Dadurch wird gewährleistet, dass wichtige Vorgänge, die Vermögenswerte betreffen — wie Übertragungen oder Statusaktualisierungen — sicher und geschützt ausgeführt werden. Stellen Sie sich zum Beispiel eine einfache Token-Übertragungsfunktion vor, die in Move geschrieben wurde: Beispiele für Module: :token { benutze sui: :object:: {Self, UID}; benutze sui: :transfer; struct Token hat den Schlüssel, store { ID: UID, Wert: u64, } public fun mint (ctx: &mut txContext, Wert: u64): Token { Token { id: Objekt: :neu (ctx), Wert, } } public fun transfer_token (Token: Token, Empfänger: Adresse) { transfer: :public_transfer (Token, Empfänger); } } Hier stellt die Token Struktur eine Ressource dar, die nur mit der Funktion public_transfer übertragen werden kann. Jeder Versuch, das Token außerhalb dieser Funktion zu duplizieren oder zu manipulieren, würde zu einem Kompilierungsfehler führen. Dieses Design eliminiert ganze Klassen von Bugs und Exploits, die häufig in anderen Sprachen vorkommen. 2. Modularität und Kapselung Move fördert das modulare Design, das es Entwicklern ermöglicht, Funktionen in eigenständigen Modulen zusammenzufassen. Jedes Modul definiert seine eigenen Typen, Funktionen und Zugriffskontrollen und gewährleistet so eine klare Trennung zwischen den verschiedenen Komponenten eines intelligenten Vertrags. Beispielsweise könnte ein Entwickler separate Module für die Token-Erstellung, Handelspaare und die Governance-Logik erstellen. Diese Modularität verbessert die Lesbarkeit, Wartbarkeit und Wiederverwendbarkeit des Codes. 3. Unterstützung bei der formellen Überprüfung Ein weiteres herausragendes Merkmal von Move ist die Unterstützung der formalen Überprüfung, ein Verfahren, mit dem die Richtigkeit eines Programms mathematisch nachgewiesen wird. Die formale Überprüfung hilft dabei, subtile Fehler und Randfälle zu identifizieren, die mit herkömmlichen Testmethoden möglicherweise nicht erkannt werden. Zwar erfordern nicht alle MOVE-basierten Projekte eine formelle Überprüfung, aber die Struktur der Sprache macht es einfacher, diese Technik bei Bedarf anzuwenden. 4. Objektzentriertes Design (SUI-spezifische Verbesserungen) Auf der Sui-Blockchain wurde Move um ein objektzentriertes Modell weiter verbessert. Jede Ressource in Sui Move hat eine global eindeutige Kennung (UID), die eine direkte Referenzierung und Interaktion mit Objekten ermöglicht. Dieses Design vereinfacht komplexe Arbeitsabläufe wie die Verwaltung von NFTs oder die Verfolgung benutzerspezifischer Daten und gewährleistet gleichzeitig eine hohe Leistung und Skalierbarkeit. Reale Anwendungen von Move Seit seiner Einführung durch Aptos und Sui wurde Move zur Erstellung einer Vielzahl dezentraler Anwendungen verwendet. Zu den bemerkenswerten Beispielen gehören: 1. Protokolle für dezentrale Finanzen (DeFi) Move legt großen Wert auf Sicherheit und ist daher ideal für DeFi-Anwendungen, bei denen Vermögenswerte im Wert von Milliarden von Dollar auf dem Spiel stehen. Projekte wie Cetus — eine dezentrale Börse (DEX), die auf SUI basiert — nutzen die ressourcenorientierte Programmierung von Move, um fortschrittliche Handelsfunktionen zu implementieren und gleichzeitig die mit der Manipulation von Vermögenswerten verbundenen Risiken zu minimieren. 2. Nicht fungible Token (NFTs) NFT-Marktplätze profitieren in hohem Maße von der Fähigkeit von Move, einzigartige digitale Assets zu definieren und zu verwalten. Entwickler können ausgefeilte NFT-Standards mit granularer Kontrolle über Eigentum, Lizenzgebühren und Metadaten erstellen. Darüber hinaus ermöglichen die objektzentrierten Verbesserungen von Sui eine nahtlose Integration dynamischer NFTs, die sich auf der Grundlage vordefinierter Bedingungen weiterentwickeln können. 3. Gaming- und Metaverse-Plattformen Blockchain-Gaming erfordert einen effizienten Umgang mit In-Game-Assets, Spielerinteraktionen und Echtzeit-Updates. Dank der modularen Architektur und der Ausführung mit niedriger Latenz eignet sich Move hervorragend für den Aufbau immersiver Spielerlebnisse. Plattformen wie Blockus, ein Web3-Gaming-Ökosystem, nutzen Move, um ihre dezentralen Spiele und Volkswirtschaften voranzutreiben. Vergleich von Move mit anderen Smart Contract-Sprachen Move weist zwar einige Ähnlichkeiten mit anderen intelligenten Vertragssprachen auf, seine einzigartigen Funktionen verschaffen ihm jedoch einen Wettbewerbsvorteil: Solidity: Als Hauptsprache von Ethereum ist Solidity weit verbreitet, leidet jedoch unter älteren Problemen wie der Anfälligkeit für Wiedereintrittsangriffe. Move behebt diese Schwächen durch sein ressourcenorientiertes Modell und eine strengere Typensicherheit. Rust (wird in Solana verwendet): Rust bietet eine hervorragende Leistung und Speichersicherheit, aber Moves native Unterstützung für Ressourcenmanagement und formale Überprüfung fehlt. Darüber hinaus kann die steile Lernkurve von Rust Neulinge im Vergleich zur intuitiveren Syntax von Move abschrecken. Clarity (wird in Stacks verwendet): Clarity legt Wert auf Transparenz und Vorhersagbarkeit, arbeitet jedoch in einem begrenzten Umfang, der an das Bitcoin-Ökosystem gebunden ist. Move hingegen unterstützt breitere Anwendungsfälle über mehrere Blockchains hinweg. Die Zukunft von Move: Einführung und Weiterentwicklung Da die Blockchain-Technologie weiter ausgereift ist, wird die Nachfrage nach sicheren und skalierbaren intelligenten Vertragssprachen nur noch zunehmen. Move ist bereit, dank seines innovativen Designs und der wachsenden Unterstützung durch die Community eine zentrale Rolle bei der Gestaltung der nächsten Generation dezentraler Anwendungen zu spielen. Projekte wie Aptos und Sui investieren aktiv in die Ausbildung von Entwicklern, in Tools und in die Infrastruktur, um die Einführung von Move zu beschleunigen. Initiativen wie die Move eLearning-Plattform bieten umfassende Tutorials und Ressourcen für angehende Entwickler und senken so die Einstiegshürde. Darüber hinaus treibt die Zusammenarbeit mit akademischen Einrichtungen und Branchenführern die Forschung zu fortgeschrittenen Themen wie formaler Verifizierung und kettenübergreifender Interoperabilität voran. Mit Blick auf die Zukunft können wir davon ausgehen, dass Move über seine aktuellen Anwendungsfälle hinaus expandieren und alles unterstützen wird, von Supply-Chain-Lösungen auf Unternehmensebene bis hin zu dezentralen sozialen Netzwerken. Seine Anpassungsfähigkeit und Robustheit stellen sicher, dass es in einem zunehmend vielfältigen und vernetzten Blockchain-Ökosystem relevant bleibt.
3
Beiträge
304- Artikel0xduckmove288May 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 - Experten Q&AOwen15May 31, 2025
Fehler bei der Typprüfung, wenn eine benutzerdefinierte Struktur als Typparameter in coin: :Coin von Sui Move verwendet wird?
Frage: In meinem Sui Move-Code tritt bei der Typprüfung ein Fehler auf, den ich nicht verstehe. Hier ist eine vereinfachte Version meines Codes: module my_module::mymodule { use sui::coin; use sui::wallets; struct MyCoin has drop {} public fun create_coin(): coin::Coin { coin::mint(1000) } } Wenn ich versuche zu kompilieren, erhalte ich die folgende Fehlermeldung: Invalid type parameter instantiation. Expected type 'phantom type T' but found 'MyCoin' Was mache ich falsch? Warum kann ich ihn nicht MyCoinals Typparameter für verwendencoin::Coin, und wie kann ich dieses Problem mit der Typprüfung beheben?
- Sui
- Architecture
01 - Artikel0xduckmove288May 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 - DiskussionDRAMA32May 30, 2025
Wie verwalte ich den DApp-Zugriff auf SUI Wallet ohne Sperrfunktion?
Ich habe das SUI Wallet verwendet und festgestellt, dass es keine Option gibt, den Zugriff auf dApps zu widerrufen, wie es bei EVM-Ketten der Fall ist. Wie kann ich verhindern, dass dApps unbefristet auf meine Wallet zugreifen, wenn in der Chrome-Erweiterung kein klares Widerrufssystem vorhanden ist?
- Sui
02 +10
Experten Q&AMay 29, 2025Warum benötigt BCS eine genaue Feldreihenfolge für die Deserialisierung, wenn Move-Strukturen benannte Felder haben?
Warum erfordert BCS eine exakte Feldreihenfolge für die Deserialisierung, wenn Move-Strukturen benannte Felder haben? Ich habe mich eingehend mit der BCS-Kodierung/Dekodierung in Move befasst, insbesondere für die kettenübergreifende Kommunikation und die Off-Chain-Datenverarbeitung. Beim Durcharbeiten der Beispiele in der Sui Move-Dokumentation bin ich auf ein Verhalten gestoßen, das kontraintuitiv erscheint, und ich versuche, die zugrunde liegenden Designentscheidungen zu verstehen. Gemäß der BCS-Spezifikation „gibt es in BCS keine Strukturen (da es keine Typen gibt); die Struktur definiert lediglich die Reihenfolge, in der Felder serialisiert werden.“ Das bedeutet, dass wir beim Deserialisieren peel_*Funktionen in exakt derselben Reihenfolge wie in der Strukturfelddefinition verwenden müssen. Meine spezifischen Fragen: Entwurfsbegründung: Warum erfordert BCS eine exakte Übereinstimmung der Feldreihenfolge, wenn Move-Strukturen benannte Felder haben? Wäre es nicht robuster, Feldnamen zusammen mit Werten zu serialisieren, ähnlich wie bei JSON oder anderen selbstbeschreibenden Formaten? Generische Typinteraktion: In den Dokumenten wird erwähnt, dass „Typen, die generische Typfelder enthalten, bis zum ersten generischen Typfeld analysiert werden können“. Betrachten Sie diese Struktur: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Wie genau funktioniert die partielle Deserialisierung hier? Kann ich bis zu more_metadata deserialisieren und beide generischen Felder ignorieren, oder blockiert das erste generische Feld (generic_data) die weitere Deserialisierung vollständig? Sprachübergreifende Konsistenz: Was passiert, wenn Sie die @mysten /bcs JavaScript-Bibliothek verwenden, um Daten zu serialisieren, die von Move-Verträgen verwendet werden, wenn: Ich ordne versehentlich Felder im JavaScript-Objekt neu an? Die Move-Strukturdefinition ändert die Feldreihenfolge bei einem Vertrags-Upgrade? Ich habe verschachtelte Strukturen mit ihren eigenen generischen Parametern? Praktische Implikationen: Wie gehen Teams in Produktionssystemen mit der Entwicklung des BCS-Schemas um? Versionieren Sie Ihre BCS-Schemas oder gehen Sie davon aus, dass die Reihenfolge der Strukturfelder nach der Bereitstellung unveränderlich ist?
- Sui
- Move
51- DiskussionMay 29, 2025
Wie finde ich die Treasury-Cap-Objekt-ID für einen Münztyp?
Ich möchte wissen, wie ich die Objekt-ID einer Treasury-Cap für eine Münze erhalten kann, wenn ich nur den Namen des Münztyps nenne. Derzeit rufe ich das Metadatenobjekt ab und überprüfe die vorherigen Transaktionen, um das Treasury-Cap-Objekt zu finden, aber diese Methode scheint ineffizient zu sein. Ich suche nach einer einfacheren und effizienteren Methode, um anhand des Namens des Münztyps festzustellen, ob eine Münzprägeanstalt eingefroren ist. Irgendwelche Vorschläge?
- Sui
04 - DiskussionTheoremus175May 29, 2025
Wie kopiere ich einfach eine nicht kopierbare Wallet-Adresse?
Ich hatte Schwierigkeiten, meine Wallet-Adresse zu kopieren, da sie nicht direkt kopierbar ist. Ich bin mir nicht sicher, ob es einen schnellen Weg oder eine versteckte Funktion gibt, die mir fehlt. Kann mir jemand helfen, wie das geht?
- Sui
02 - 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 - Experten Q&Aderiss159May 28, 2025
Wird meine Transaktion abgeschlossen, wenn das Limit nahe ist?
Ich habe eine Benachrichtigung mit der Aufschrift „Das globale Transaktionslimit nähert sich“ erhalten. Wenn ich jetzt eine Transaktion initiiere, wird sie trotzdem innerhalb von 24 Stunden bearbeitet?
- Move
03 - Diskussioncod31May 27, 2025
Probleme beim Tauschen der Sui Wallet bei Cetus & Turbo Finance
Ich versuche, meine Sui-Wallet mit Cetus und Turbo Finance auszutauschen, aber es funktioniert nicht. Ich habe ungefähr 0,002 SUI als Benzin. Welche Schritte sollte ich unternehmen, um das Problem zu lösen?
- Transaction Processing
03
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
- Security Protocols
- NFT Ecosystem
- Transaction Processing