Erkunden
Verbinde dich mit Gemeinschaften und entdecke neue Ideen.
Verdiene deinen Anteil an 1000 Sui
Sammle Reputationspunkte und erhalte Belohnungen für deine Hilfe beim Wachstum der Sui-Community.
Gemeinschaften
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
Top-BeiträgeTop-Mitglieder- 4622
- 4200
- 4038
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Top-BeiträgeTop-Mitglieder- 271
- 260
- 251
Peera is a decentralized questions and answers protocol for Web3 where users can organize and store their interests and skills, creating a common community platform
Top-Mitglieder- 328
- 286
- 225
The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system.
Top-BeiträgeTop-Mitglieder- 25
- 20
- 20
Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"
Top-BeiträgeTop-Mitglieder- 41
- 40
- 38
Prämie
Sui Move Error - Transaktion kann nicht verarbeitet werden Keine gültigen Gasmünzen für die Transaktion gefunden
Wenn ich das mache: //Zahlung von der Primärmünze trennen const [PaymentCoin] = tx.SplitCoins ( tx.object (PrimaryCoin.CoinObjectID), [tx.pure.u64 (erforderlicher Zahlungsbetrag)] ); //Verwende die Originalmünze für die Gaszahlung tx.setGasPayment ([{ ObjektID: PrimaryCoin.CoinObjectID, Version: PrimaryCoin.Version, verdauen: PrimaryCoin.digest }]); tx.setGasBudget (10_000_000); Es beschwert sich darüber, dass veränderbare Objekte nicht mehr als eines in einer Transaktion vorkommen können. Wenn ich die Gaszahlung entferne, beschwert es sich: „Transaktion kann nicht verarbeitet werden Für die Transaktion wurden keine gültigen Gasmünzen gefunden.“. Meine Vertragsfunktion akzeptiert 0,01 Sui als Gegenleistung für eine NFT
29- +15Xavier.eth308FürSuiJun 27, 2025
Sui-Transaktion schlägt fehl: Objekte sind für eine andere Transaktion reserviert
JsonRpcErrorBeim Versuch, Transaktionen auf Sui auszuführen, stoße ich auf eine persistente Störung. Der Fehler weist darauf hin, dass Objekte für eine andere Transaktion reserviert sind, obwohl ich eine sequentielle Transaktionsverarbeitung mit Verzögerungen implementiert habe. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 Ich habe versucht: Sequentielle Transaktionsausführung (Warten auf den Abschluss der vorherigen Transaktion) Es wurden Verzögerungen von 3 Sekunden zwischen Transaktionen hinzugefügt Und immer noch der gleiche Fehler. Verwendung von Sui RPC für die Übermittlung von Transaktionen. Dieselbe Objekt-ID erscheint mehrfach in der Sperrliste. Selbst bei sorgfältiger Transaktionssequenzierung tritt ein Fehler auf. Was bewirkt, dass Objekte für andere Transaktionen „reserviert“ werden? Wie kann ich richtig überprüfen, ob ein Objekt verfügbar ist, bevor ich es in einer Transaktion verwende? Gibt es bewährte Methoden für den Umgang mit Objektsperren in Sui? Könnte das mit dem Zeitpunkt der Finalität der Transaktion zusammenhängen? Ist jemand schon einmal auf dieses Problem gestoßen? Alle Einblicke in das richtige Objektmanagement bei Sui-Transaktionen wären sehr willkommen!
48 - +15Xavier.eth308FürSuiJun 17, 2025
Wie interagieren Fähigkeitsbeschränkungen mit dynamischen Feldern in heterogenen Sammlungen?
Ich baue einen Marktplatz auf, der mit mehreren Asset-Typen mit unterschiedlichen Fähigkeitsanforderungen umgehen muss, und ich bin auf einige grundlegende Fragen zum Typensystem von Move gestoßen. Ich möchte verschiedene Asset-Typen in derselben Sammlung speichern, aber sie haben unterschiedliche Fähigkeiten: Reguläre NFTs: key + store(übertragbar) key Nur Soulbound-Token (nicht übertragbar) Benutzerdefinierte Vermögenswerte mit Übertragungsbeschränkungen public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Die wichtigsten Fragen: Anforderungen an die Fähigkeiten: Wird bei der Verwendung dynamic_field::add()Vimmer store zur Kompilierzeit benötigt? Können Wrapper-Typen das umgehen? Heterogener Speicher: Kann ein einziger Beutel Objekte mit unterschiedlichen Fähigkeiten (key + store + copyvskey + store) speichern und sie zur Laufzeit unterschiedlich handhaben? Typsicherheit: Da dynamische Felder eine Typlöschung durchführen, wie kann ich die Typsicherheit beim Abrufen von Werten gewährleisten? Nach welchem Muster werden Typmetadaten gespeichert? Zeugenmuster: Wie funktionieren Fähigkeitsbeschränkungen bei Phantomtypen? Kann ich AssetAssetInformationen zum Typ speichern und in derselben Sammlung speichern und zu einem späteren Zeitpunkt extrahieren? Aufbau eines Systems, in dem NFTs, Soulbound-Token und eingeschränkte Vermögenswerte alle Marktplatzfunktionen benötigen, jedoch mit unterschiedlicher Übertragungssemantik. Ich habe Wrapper-Typen ausprobiert, mehrere Sammlungen pro Fähigkeitssatz, separate Typ-Metadatenspeicherung. Jede hat Kompromisse zwischen Typsicherheit, Gaskosten und Komplexität.
07
Neueste
Suis Rolle bei der Rationalisierung der globalen Handels- und Lieferketteninfrastruktur
Einführung: Der Welthandel ist ein Vertrauensengpass Die moderne Lieferkette umfasst Dutzende von Ländern, Hunderte von Anbietern und unzählige Dokumente — viele davon in Papierform, fehleranfällig oder nicht verifizierbar. Von der Nachverfolgung von Containern bis hin zu Zollanmeldungen und Ursprungszeugnissen wird der Welthandel von folgenden Problemen geplagt: • Datenfragmentierung zwischen Ländern und Systemen • Betrügerische Dokumente und Fälschungen • Ineffiziente Streitbeilegung • Kostspielige Schlichtung und mangelnde Transparenz Sui bietet eine programmierbare, transparente und skalierbare Blockchain-Plattform, mit der der gesamte globale Handelsprozess modelliert werden kann — mit sicherer Automatisierung, Rückverfolgbarkeit und modularer Steuerung. Warum sollten Sie Sui für Handel und Lieferkette verwenden? Im Gegensatz zu vielen Allzweck-Blockchains ermöglichen die objektorientierte Architektur und die parallele Ausführung von Sui Unternehmen Folgendes: Funktionsvorteil bei Handelsanwendungen Objektbasierte Modellierung Modellieren Sie reale Vermögenswerte wie Container, Sendungen, Dokumente Horizontale Skalierbarkeit Erledigen Sie die Verfolgung und Aktualisierung großer Mengen von Ereignissen zkLogin-Authentifizierung Identifizieren Sie Benutzer (Zollagenten, Lieferanten) sicher Protokollierung von Ereignissen und Emissionen Verfolgen Sie die gesamte Lieferkette netzwerkübergreifend Custom Move-Module kodieren die Vertragslogik (z. B. Ursprungsregeln, Tarife) Sui wandelt Handelsdokumente in überprüfbare digitale Vermögenswerte um — und Prozesse in transparente, sich selbst ausführende Workflows. Anwendungsfall: Internationaler Versand mit Ursprungszeugnis Lassen Sie uns einen vereinfachten Anwendungsfall durchgehen. 👟 Szenario: Sneaker-Versand von Vietnam in die EU Interessengruppen: • Hersteller in Ho Chi Minh • Frachtführer • Zollagenten • EU-Importeur SUI-basierter Arbeitsablauf: Vom Hersteller erstelltes ShipmentObject (Herkunft, Chargennummer, Inhalt) Von der vietnamesischen Handelsbehörde ausgestelltes Ursprungszeugnis Das Frachtunternehmen aktualisiert TransitStatusObject, während sich die Sendung bewegt Der Zollagent überprüft Dokumente und signiert die Abfertigung digital Der Einzelhändler in der EU erhält überprüfbare Produkt- und Metadaten zur Kette Vorteile: • Alle Beteiligten haben Zugang zu einem manipulationssicheren Audit-Trail • Kein E-Mail-basiertes Teilen von Dokumenten oder das Fälschen von PDF-Dateien • Sofortige Einhaltung der Import-/Exportregeln Architektur eines auf Sui basierenden Handelsprotokolls Jeder Vermögenswert oder jedes Dokument in der Lieferkette wird zu einem erstklassigen Mitglied der Lieferkette. 🔩 Kernmodule: • ShipmentObject — beinhaltet Artikel, Gewicht, Herkunft und eindeutige ID • CertificateModule — überprüft die Echtheit von Dokumenten und die Rollen des Ausstellers • CustomsApprovalModule — Zollagenten können Sendungen genehmigen/ablehnen • TransitEventModule — gibt Standort-Updates aus (z. B. Anschluss gescannt, geladen) 🔐 Beispiel: Move-Modul zur Zertifikatsverifizierung Modul trade: :CertificateModule { Das Strukturzertifikat hat den Schlüssel { origin_country: Vektor, Emittent: Adresse, gültig_bis: u64, } public fun issue_certificate (Aussteller: &Unterzeichner, Land: Vector) { let cert = Zertifikat { origin_country: Land, Emittent: signer: :address_of (Aussteller), gültig_bis: 1690000000, }; move_to (Emittent, Zertifikat); } public fun validate (cert: &Certificate): bool { timestamp: :now () < cert.valid_until } } Diese Logik stellt sicher, dass nur vertrauenswürdige Behörden Handelsdokumente ausstellen und validieren können. Interoperabilität: Grenzüberschreitende Zusammenarbeit in Echtzeit Die modulare Identitäts- und Objektlogik von Sui ermöglicht eine länderübergreifende Zusammenarbeit ohne zentrale Kontrolle: Maßnahmen der Interessengruppen im Zusammenhang mit Sui Die Hafenbehörde hängt das Scanereignis an ShipmentObject an Das nationale Exportamt stellt ein digital signiertes Zertifikat aus Der Spediteur aktualisiert die voraussichtliche Ankunftszeit und die Zustandsberichte für die Lieferung Der Zollagent überprüft die Echtheit und die Einhaltung der Vorschriften in der Kette Der Einzelhändler ruft eine überprüfbare Produkthistorie und CO2-Metadaten ab Mit APIs und Dashboards, die auf Sui basieren, können auch Akteure ohne technische Kenntnisse sicher am Protokoll teilnehmen. Betrugsprävention und Rückverfolgbarkeit Globaler Handelsbetrug führt jährlich zu Umsatzeinbußen in Milliardenhöhe. Sui bekämpft dies mit: • Digital signierte Dokumente, die über zkLogin an die Identität gebunden sind • Unveränderliche Kontrollkette mit Ereignissen mit Zeitstempel • NFT-basierte Warentoken mit verknüpften Zertifizierungen • Intelligente Auslöser, die Manipulationen oder unbefugte Übertragungen verhindern Beispiel: Fälschungsschutz Jedes Schmuckstück für ein Luxusprodukt (z. B. eine Designer-Handtasche) kann: • Link zum Ursprungszertifikat und zur Chargennummer des Herstellers • Fügen Sie einen QR-Code hinzu, der an ein Objekt in der Kette gebunden ist • Verhindern Sie den Weiterverkauf, sofern Sie nicht durch ein verifiziertes Konto authentifiziert wurden Emissionsgutschriften und ESG-Integration Unternehmen stehen unter dem Druck, nachhaltige Lieferketten nachzuweisen. Sui kann: • Notieren Sie die CO2-Emissionen pro Sendung oder Produkteinheit • Ermöglichen Sie Dritten (Auditoren, NGOs), die CO2-Werte zu überprüfen • Hängen Sie ESG-Berichte an die Versand-NFTs an • Ermöglichen Sie den On-Chain-Handel oder die Geltendmachung von CO2-Kompensationen Beispiel: Die Bewegungsprotokolle eines Versandcontainers werden zur Schätzung der Emissionen verwendet, und ein CarbonScoreObject ist an das Produkt-Token angehängt. Käufer können es vor dem Kauf überprüfen. Überlegungen zur Skalierung globaler Netzwerke Die parallelisierte Ausführung und die niedrige Latenz machen Sui für Unternehmen geeignet: Skalieren Sie die Anforderungen der Sui-Funktion 100.000 tägliche Updates Parallele Objektverarbeitung Über 100 Beteiligte pro Kette Genehmigungen auf Objektebene Die Echtzeit-API benötigt RPCs mit hohem Durchsatz und Veranstaltungsabonnements Datenspeicherung Objektverlauf + On-Chain-Protokolle Sui kann so schnell skalieren, wie die globale Logistiknachfrage wächst. Herausforderungen und Einsatzstrategien Strategie zur Eindämmung von Herausforderungen Juristische Datenbeschränkungen Verwenden Sie regionsspezifische Module und Objekt-Tags Eingeschränkte Blockchain-Kenntnisse Erstellen Sie benutzerfreundliche DApps und Web-Benutzeroberflächen Integration mit älteren Systemen Middleware + Off-Chain-Konnektoren Sicherheit + Konformitätsprüfung Emissionsprotokolle + unterschriebene Bescheinigungen Beginnen Sie mit einer Branche oder Produktlinie und erweitern Sie dann schrittweise die Protokolle und Integrationen. Fazit: Die Zukunft des Welthandels auf Sui aufbauen Die objektzentrierte, programmierbare und skalierbare Architektur von Sui bietet die Grundlage für ein globales, überprüfbares Handelsprotokoll. Mit Sui können Unternehmen: • Reduzieren Sie Papierkram, Verzögerungen und Betrug • Automatisieren Sie Workflows mit mehreren Parteien • Erzielen Sie vollständige Rückverfolgbarkeit und ESG-Konformität • Erstellen Sie gemeinsam genutzte Datenebenen ohne zentrale Server In einer Welt, in der Vertrauen, Transparenz und Geschwindigkeit den Handelserfolg bestimmen, ist Sui mehr als eine Blockchain — es ist die Vertrauensinfrastruktur für die Lieferketten von morgen.
0🔒 Schützen Sie Ihre Sui-App: Eine praktische Sicherheitscheckliste
Es ist aufregend, auf Sui aufzubauen — das objektzentrierte Modell ermöglicht neue Entwurfsmuster und schnellere Parallelität. Aber ⚠️ neue Modelle = neue Fehler. Besitzfehler, undichte Treuhandkonten oder unvorsichtige Administratorschlüssel können zu kostspieligen Verlusten führen. In diesem Leitfaden finden Sie eine schrittweise Sicherheitscheckliste 📝 sowie ein praktisches Beispiel für den Marktplatz, das zeigt, wie Sie die häufigsten Fallstricke vermeiden können. ✅ 1) Die Sui-Sicherheitscheckliste 🔑 Geringste Privilegien • Verlassen Sie sich nicht auf einen einzigen globalen „Admin-Schlüssel“. • Verwenden Sie Funktionsobjekte als Autoritätsquelle. • Schützen Sie wichtige Verwaltungsbefugnisse mit Multisig- oder On-Chain-Governance. ⚖️ Atomare Treuhandüberweisungen • Verwahren Sie Vermögenswerte immer innerhalb der dafür vorgesehenen Listing-Objekte. • Verwenden Sie Programmable Transaction Blocks (PTBs) für Atomic Swaps → verhindert Front-Running und doppelte Ausgaben. 🛡️ Alle Eingaben validieren • Prüfen Sie unter Move die Längen, Grenzen und Beschränkungen von Vektoren. • Validieren Sie die Deserialisierung und weisen Sie falsch geformte Objekte zurück. • Gehen Sie niemals von einer Eingabesicherheit aus, nur weil das Objekt in der Kette existiert. 🧪 Aggressiv testen und fuzzen • Schreiben Sie negative Tests: ungültige Eingaben, gleichzeitige Aktualisierungen, Gasüberlastung. • Fügen Sie Fuzzing für unerwartete Transaktionsabläufe hinzu. • Automatisieren Sie in CI, um Regressionen frühzeitig zu erkennen. 🔐 Schlüsselverwaltung • Speichern Sie Admin-Schlüssel in Hardware-Wallets. • Verwenden Sie Multisig für Verwaltungsmaßnahmen. • Wechseln Sie die Schlüssel, wenn die Teammitglieder das Team verlassen. 👀 Prüfungen und Anreize • Lassen Sie wichtige Move-Module prüfen. • Starte ein Bug-Bounty-Programm für Community-Tests. • Denke daran: Äußere Augen fangen ein, was du verpasst. 🏪 2) Beispiel aus der Praxis: Ein sicherer Marktplatz So wenden Sie die Checkliste in einer Marketplace-DApp an: • NFTs sicher hinterlegen: Der Verkäufer verschiebt die NFT in ein Listing-Objekt. Der Marktplatzvertrag kann ohne Zustimmung des Verkäufers keine Gelder entgegennehmen. • Gehen Sie korrekt mit Tantiemen um: Berechne die Tantiemen innerhalb der PTB und achte dabei auf eine korrekte Gebührenaufteilung (achte auf die Rundung!). • Wiedereintritt? Nicht hier: Das Ressourcenmodell von Move verhindert das Kopieren/Wiederaufrufen von vornherein. Testen Sie dennoch alle Abläufe, um sicherzustellen, dass keine logischen Lücken bestehen. 📚 Quellen und weiterführende Literatur • Sui Docs: Konzepte und Transaktionen • Sui Whitepaper (objektzentriertes Modell) • TypeScript SDK-Dokumente von Mysten Labs • Buch verschieben • Auf GitHub Repo ✨ Fazit: Bei Sui geht es bei der Sicherheit weniger um Fehler beim Wiedereintritt im EVM-Stil als vielmehr um Eigenverantwortung, Autorität und Atomarität. Wenn Sie die Checkliste befolgen, reduzieren Sie Ihre Angriffsfläche drastisch und schützen gleichzeitig die Ressourcen Ihrer Benutzer.
0Von der Neuinstallation bis zu Ihrem ersten On-Chain-Objekt, ohne stecken zu bleiben
Sie installieren zunächst die Sui CLI und die Move-Toolchain, damit Sie Code erstellen und veröffentlichen können, dann führen Sie sui client active-address aus, um ein funktionierendes Schlüsselpaar zu bestätigen, und drücken den Wasserhahn, um Test-SUI abzurufen. Danach erstellen Sie ein neues Move-Paket mit der Vorlage, damit Sie nicht gegen die Ordnerstruktur kämpfen, dann bearbeiten Sie ein einzelnes Modul, um ein einfaches Objekt mit einem Eigentümerfeld und einigen Methoden wie Init, Update und Transfer zu definieren damit Sie das Objektmodell von Sui schnell trainieren können, kompilieren Sie als Nächstes mit sui move build und korrigieren alle Fehler, die der Compiler anzeigt, denn das ist Ihr schnellste Feedback-Schleife, dann veröffentlichst du mit sui client publish --gas-budget und holst dir die Paket- und Modul-IDs aus der Ausgabe, damit du Funktionen aufrufen kannst, danach rufst du deine Init-Eingabefunktion auf, um ein Objekt zu minten und kopierst die Objekt-ID aus den Transaktionseffekten, dann führst du sui client object aus, um Version, Besitzer und Felder zu sehen, damit du bestätigst, dass die Kette geschrieben hat, was du erwartest, wenn du auf „zu wenig Gas“ stößt, schrumpfst du das Gasbudget oder forderst mehr an Testen Sie SUI, da jede Veröffentlichung und jeder Anruf Benzin kostet. Wenn Sie „Modul nicht gefunden“ erhalten, haben Sie es wahrscheinlich verwendet die falsche Paket-ID oder Sie haben vergessen, es neu zu erstellen. Wenn Ihre Übertragung mit einem Capability-Fehler fehlschlägt, haben Sie das Objekt wahrscheinlich geteilt, obwohl Sie es meinten, besitzen, oder Sie haben vergessen, die richtige Argumentform zu übergeben. Sobald die Grundlagen funktionieren, skripten Sie den Flow in einer Shell oder einem JavaScript-Skript, sodass ein Befehl erstellt, veröffentlicht, mintet, aktualisiert und überträgt, was Zeit spart und Tippfehler verhindert, und schließlich pushen Sie dieses Minimalbeispiel in ein Repo, damit Teammitglieder dieselben Schritte klonen und ausführen können innerhalb von Minuten; indem Sie das Objekt als Denkeinheit behandeln und nicht als einen einzigen globalen Vertrag, den Sie Passen Sie Ihren Code daran an, wie Sui den Status speichert, wodurch Ihr mentales Modell sauber bleibt und schwer zu debuggende Wiedereintritte oder globale Staatenrennen verhindert werden, denen Sie auf anderen Ketten begegnen könnten. Da Sui Transaktionen mit eigenen Objekten parallelisiert, erhalten Sie auch eine schnelle Bestätigung, während Sie iterieren, was das Onboarding viel angenehmer macht.
0
Unbeantwortet
Trendend
AMM-Bot im Sui-Ökosystem
Was sind die wichtigsten Merkmale und Funktionen von AMM-Bots im Sui-Ökosystem? Wie verbessern sie traditionelle Handelsmechanismen und welche Vorteile bieten sie Benutzern, die sich mit DeFi-Protokollen im Sui-Netzwerk beschäftigen? Muss ich einen bauen oder kann ich zum Beispiel Turbos Finance verwenden
94- 0xduckmove2038FürSuiApr 08, 2025
👀 SEAL- Ich denke, der Datenschutz bei Web3 wird sich bald ändern
👀 SEAL ist live auf Sui Testnet — ich denke, der Datenschutz bei Web3 wird sich bald ändern Im Web3 hört man häufig Ausdrücke wie* „Die Nutzer besitzen ihre Daten“* oder* „von Natur aus dezentralisiert“*. Aber wenn Sie genau hinschauen, verlassen sich viele Anwendungen immer noch auf zentralisierte Infrastrukturen, um sensible Daten zu verarbeiten — und nutzen Dienste wie AWS oder Google Cloud für die Schlüsselverwaltung. Dies führt zu einem Widerspruch: Dezentralisierung an der Oberfläche, Zentralisierung unter der Oberfläche. Aber was wäre, wenn es eine Möglichkeit gäbe, Geheimnisse sicher zu verwalten, ohne die Dezentralisierung aufzugeben? Wir stellen vor: SEAL — Decentralized Secrets Management (DSM), das jetzt live im Sui Testnet verfügbar ist. SEAL hat sich zum Ziel gesetzt, eine der größten Heucheleien von Web3 zu beheben: die Zurufe nach Dezentralisierung und der heimlichen Nutzung von AWS Du fragst mich vielleicht: Was ist SEAL? SEAL ist ein Protokoll, mit dem Sie sensible Daten sicher unddezentralverwalten können — speziell für die Web3-Welt entwickelt. Stellen Sie sich das als eine Zugriffskontrollschicht vor, bei der der Datenschutz an erster Stelle steht und in Ihre DApp integriert wird. Du kannst dir SEAL als eine Art programmierbares Schloss für deine Daten vorstellen. Sie sperren und entsperren Dinge nicht einfach manuell — Sieschreiben mithilfe von Move on Sui Richtlinien direkt in Ihre Smart Contracts. Nehmen wir an, Sie erstellen eine dApp, bei der: Nur NFT-Inhaber können ein Premium-Tutorial freischalten Oder vielleicht muss ein DAO abstimmen, bevor sensible Dateien aufgedeckt werden Oder Sie möchten, dass Metadaten zeitgebunden sind und erst nach einem bestimmten Datum zugänglich sind SEAL macht all das möglich. Die Zugriffskontrolle erfolgt onchain, vollständig automatisiert, sodass kein Administrator sie verwalten muss. Nur Logik, direkt in die Blockchain integriert. SEAL macht all das möglich. Die Zugriffskontrolle erfolgt onchain, vollständig automatisiert, sodass kein Administrator sie verwalten muss. Nur Logik, direkt in die Blockchain integriert. Ein weiterer interessanter Artikel ist, wie SEAL mitVerschlüsselungumgeht. Es verwendet eine sogenannteSchwellenwertverschlüsselung, was bedeutet: Kein einzelner Knoten kann die Daten entschlüsseln. Es braucht eine Gruppe von Servern, um zusammenzuarbeiten — quasi wie Multi-Sig, nur um Geheimnisse zu entsperren. Das verteilt Vertrauen und vermeidet das übliche Single-Point-of-Failure-Problem. Und um die Dinge wirklich geheim zu halten, verschlüsselt und entschlüsselt SEAL allesauf der Clientseite. Ihre Daten sind für kein Backend sichtbar. Sie bleiben — im wahrsten Sinne des Wortes — in Ihren Händen auf Ihrem Gerät. und SEAL ist es egal, wo Sie Ihre Daten speichern. Ob es sich um IPFS, Arweave, Walrus oder eine andere Plattform handelt, SEAL versucht nicht, diesen Teil zu kontrollieren. Es konzentriert sich nur darauf,wer was sehen darf, nicht darauf, wo Dinge aufbewahrt werden. Also ja, es ist nicht nur eine Bibliothek oder API — es ist eineonchain first, zugriffskontrollierte, standardmäßige Datenschutzebenefür deine dApp. SEAL füllt eine ziemlich kritische Lücke. Lassen Sie uns das etwas genauer aufschlüsseln. Wenn Sie eine dApp erstellen, die sich mitjeder Form vertraulicher Datenbefasst — geschützte Inhalte, Benutzerdokumente, verschlüsselte Nachrichten, sogar zeitgesperrte NFT-Metadaten —, werden Sie auf dasselbe Problem stoßen: ➡️ Wie verwalten Sie den Zugriff sicher, ohne sich auf einen zentralen Dienst verlassen zu müssen? Ohne so etwas wie SEAL können die meisten Teams entweder: Verwenden Sie zentralisierte Tools wie AWS KMS oder Firebase, was eindeutig gegen die Dezentralisierung verstößt Oder versuchen Sie, eine unausgegorene Verschlüsselungslogik selbst zusammenzusetzen, was sich in der Regel als spröde herausstellt und schwer zu überprüfen ist https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Keines davon skaliert gut. Vor allem nicht, wenn Sie versuchen, vertrauenswürdige Apps über mehrere Ketten oder Communities hinweg zu entwickeln. SEAL macht den gesamten Prozess modular und programmierbar. Sie definieren Ihre Zugriffsregeln in Move Smart Contracts, und SEAL kümmert sich um den Rest — Schlüsselgenerierung, Entschlüsselungsgenehmigungen und Zugriffsdurchsetzung — alles, ohne dass jemand manuell Schlüssel ausstellt oder Backend-Checks durchführt. Und was noch besser ist: Diese Regeln sindüberprüfbar und unveränderlich— sobald sie online sind, folgen sie dem Vertrag, nicht einem menschlichen Administrator. Anstatt also zu fragen, „wer sollte den Zugriff auf diese Daten verwalten?“ du fragst einfach: „Welche Logik sollte den Zugriff definieren?“ > ... und lass die Kette das erledigen. Sauber und skalierbar. Das macht SEAL für mehr als nur „Sicherheitstools“ relevant — es ist eine Basisebene fürjede dApp, die Wert auf Datenschutz, Compliance oder dynamische Zugriffslogik legt. Es ist eine kleine Veränderung — aber sie ändert viel daran, wie wir Daten in Web3 betrachten. Anstatt nach der Bereitstellung zu verschlüsseln oder sich auf externe Dienste zu verlassen,beginnen Sie mit integriertem Datenschutz — und der Zugriff wird vollständig über eine intelligente Vertragslogik abgewickelt. Und genau das braucht Web3 gerade. Wie funktioniert SEAL eigentlich? Wir haben behandelt, was SEAL istundwarum Web3 es braucht**. Schauen wir uns an, wie es tatsächlich unter der Haube aufgebaut ist. In diesem Teil werden die Dinge technischer — aber auf eine gute Art und Weise. Die Architektur ist elegant, wenn man sieht, wie alle Teile zusammenpassen. Auf einer hohen Ebene kombiniert SEALOnchain-Access-LogikmitOff-Chain-Schlüsselmanagement. Dabei wird eine Technik namensIdentity-Based Encryption (IBE) verwendet. Auf diese Weise können Entwickler Daten zu einer Identität verschlüsseln und sich dann auf intelligente Verträge verlassen, um zu definieren, wer sie entschlüsseln dürft. Schritt 1: Zugriffsregeln in Smart Contracts (auf Sui) Alles beginnt mit dem Smart Contract. Wenn Sie SEAL verwenden, definieren Sie in Ihrem Move-Vertrag eine Funktion namens seal_approve — hier schreiben Sie Ihre Bedingungen für die Entschlüsselung. Hier ist zum Beispiel eine einfache Time-Lock-Regel, die in Move geschrieben wurde: entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Einmal eingesetzt, fungiert dieser Vertrag als Gatekeeper. Immer wenn jemand Daten entschlüsseln möchte, wird seine Anfrage anhand dieser Logik überprüft. Wenn es erfolgreich ist, wird der Schlüssel freigegeben. Wenn nicht, sind sie blockiert. Niemand muss eingreifen. ##Schritt 2: Identitätsbasierte Verschlüsselung (IBE) Hier passiert die Magie. Anstatt Daten für eine bestimmte Wallet-Adresse zu verschlüsseln (wie bei PGP oder RSA), verwendet SEALIdentitätszeichenfolgen— das heißt, Sie verschlüsseln mit etwas wie: 0 x Wallet-Adresse dao_voted:proposal_xyz pkgID_2025_05_01 (eine auf Zeitstempeln basierende Regel) oder sogar game_user_nft_holder Wenn die Daten verschlüsselt sind, sieht das so aus: Encrypt(mpk, identity, message) mpk = öffentlicher Hauptschlüssel (allen bekannt) Identität = der durch die Logik definierte Empfänger Nachricht = die tatsächlichen Daten Wenn später jemand entschlüsseln möchte, prüft der Schlüsselserver, ob sie der Richtlinie entsprechen (über den Aufruf seal_approve in der Kette). Wenn es genehmigt wird, gibt es einen abgeleiteten privaten Schlüssel für diese Identität zurück. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) Der Benutzer kann den Inhalt dann lokal entschlüsseln. Die Verschlüsselung erfolgt also, ohne dass man im Voraus wissen muss, wer entschlüsselt. Sie definieren einfach die Bedingungen und SEAL findet den Rest später heraus. Es ist dynamisch. ##Schritt 3: Der Schlüsselserver — Offchain, aber nicht zentralisiert Sie fragen sich vielleicht: Wer besitzt diese Hauptschlüssel? An dieser Stelle kommt derKey Servervon SEAL ins Spiel. Stellen Sie sich das als ein Backend vor, das: Enthält den geheimen Hauptschlüssel (msk) Überwacht On-Chain-Verträge (wie deine seal_approve-Logik) Gibt abgeleitete Schlüssel nur aus, wenn die Bedingungen erfüllt sind Aber — und das ist entscheidend — SEAL ist nicht nur auf einen Schlüsselserver angewiesen. Sie können ihn imSchwellenwertmodusausführen, in dem sich mehrere unabhängige Server einigen müssen, bevor ein Entschlüsselungsschlüssel ausgegeben wird. Beispiel: 3 von 5 Schlüsselservern müssen die Anfrage genehmigen. Dadurch werden zentrale Fehlerquellen vermieden und eine Dezentralisierung auch auf der Schlüsselverwaltungsebene ermöglicht. Und was noch besser ist: SEAL wird in ZukunftMPC (Multi-Party Computation) undEnklave-basierte Setups(wie TEE) unterstützen — so können Sie noch bessere Garantien erhalten, ohne die Benutzerfreundlichkeit zu beeinträchtigen. ##Schritt 4: Clientseitige Entschlüsselung Sobald der Schlüssel an den Benutzer zurückgegeben wurde, erfolgt die eigentliche Entschlüsselungauf seinem Gerät. Das bedeutet: Der Server sieht niemals deine Daten Das Backend speichert niemals entschlüsselte Inhalte Nur der Benutzer kann auf die endgültige Nachricht zugreifen Es ist ein solides Datenschutzmodell. Selbst wenn jemand die Speicherebene (IPFS, Arweave usw.) kompromittiert, kann er die Daten immer noch nicht lesen, ohne die Zugriffslogik zu übergeben. Hier ist das schnelle mentale Modell: Diese Struktur macht es einfach, DApps zu erstellen, bei denen die Zugriffsregeln nicht fest codiert sind — sie sind dynamisch, überprüfbar und vollständig in Ihre Kettenlogik integriert. ##Das Team hinter SEAL SEAL wird vonSamczsungeleitet, einer bekannten Persönlichkeit in der Blockchain-Sicherheitsgemeinschaft. Ehemals Forschungspartner bei Paradigm hat er mehrere Ökosysteme geprüft und vor größeren Exploits bewahrt. Jetzt konzentriert er sich in Vollzeit darauf, SEAL zu einem Kernstück der Datenschutzinfrastruktur von Web3 zu machen. Mit seinem Hintergrund und seiner Glaubwürdigkeit ist SEAL nicht nur ein weiteres experimentelles Tool — es ist ein ernsthafter Versuch, den dezentralen Datenschutz sowohl praktisch als auch skalierbar zu machen. Da SEAL im Sui Testnet live geht, wird ein neuer Standard dafür eingeführt, wie Web3-Anwendungen Geheimnisse verwalten können. Durch die Kombination von On-Chain-Zugriffskontrolle, Schwellenwertverschlüsselung und clientseitigem Datenschutz bietet SEAL eine vertrauenswürdigere Grundlage für die dezentrale Datenverarbeitung. Egal, ob Sie DApps, DAOs oder dezentrale Spiele entwickeln — SEAL bietet ein leistungsstarkes Toolkit, um die Zugriffskontrolle durchzusetzen und Benutzerdaten zu schützen, ohne Kompromisse bei der Dezentralisierung einzugehen. Wenn Web3 voranschreiten soll, ist eine sichere Infrastruktur wie SEAL nicht optional — sie ist unerlässlich
8 Wie füge ich zwei Münz-Objekte in Move zusammen?
*Ich versuche, diesen Aspekt des Sui-Netzwerks zu verstehen, weil ich entweder etwas baue, debugge oder implementiere, das diesen Bereich betrifft. Ich benötige eine detaillierte Erklärung, wie dieser Mechanismus oder diese Funktion funktioniert, zusammen mit der relevanten CLI-Verwendung, der Move-Codestruktur oder den Architekturkonzepten. Mein Ziel ist es, genügend Klarheit zu gewinnen, um dieses Wissen in einem echten Projekt anzuwenden — egal, ob es sich um einen benutzerdefinierten Smart Contract, ein NFT-System, eine Wallet-Integration oder ein DeFi-Tool handelt. Das Sui-Netzwerk hat im Vergleich zu EVM-Ketten einzigartige Funktionen, daher bin ich besonders daran interessiert, was es auszeichnet und wie sich das auf bewährte Entwicklungspraktiken auswirkt. Es wäre hilfreich, Beispielcode, Befehlszeilenbeispiele oder typische Fehler zu haben, auf die Sie achten sollten, insbesondere wenn Sie die Sui CLI, das SDK oder die Bereitstellung auf localnet/testnet verwenden. Letztlich möchte ich häufige Fehler vermeiden, die besten Sicherheitsprinzipien befolgen und sicherstellen, dass sich die Funktionen, an denen ich gerade arbeite, unter realistischen Bedingungen wie erwartet verhalten. *
715