Peera.

Erkunden

Verbinde dich mit Gemeinschaften und entdecke neue Ideen.

Sui.X.Peera.

Verdiene deinen Anteil an 1000 Sui

Sammle Reputationspunkte und erhalte Belohnungen für deine Hilfe beim Wachstum der Sui-Community.

Gemeinschaften

Filter:Alle Blockchains

Prämie

  • Xavier.eth.Peera.
    Xavier.eth313
    FürSuiJun 27, 2025
    +15

    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!

    2
    4
  • Xavier.eth.Peera.
    Xavier.eth313
    FürSuiJun 17, 2025
    +15

    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.

    0
    4
  • Peera Admin.Peera.
    Peera Admin37
    FürSuiMay 29, 2025
    +10

    Warum 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?

    5
    3

Neueste

  • CarlkawIy.Peera.
    CarlkawIy259
    FürSuiJul 01, 2025

    Wie kann ich SUI-Münzen aus einer alten Brieftasche wiederherstellen?

    Ich habe versucht, meine SUI-Münzen zu finden, als ich ein neues Slush-Konto einrichte, aber ich sehe sie nicht. Wie kann ich überprüfen, ob ich den richtigen Begriff verwende, um mein altes Wallet zu importieren?

    0
    0
  • MiniBob.Peera.
    MiniBob701
    FürSuiJul 01, 2025

    Beherrschen von Move-Sprachkonzepten — Kurs #2

    ImKurs #1, den ich bereits gemacht habe, wurden Sie zwar in die Grundlagen des Schreibens intelligenter Verträge in Move und der Erstellung einfacher DApps auf der Sui-Blockchain eingeführt, aber dieser Kurs konzentriert sich darauf,Ihr Verständnis der Move-Sprache selbst zu vertiefen— von ihrem leistungsstarken Typsystem bis hin zu fortgeschrittenen Mustern wie Generics, Ereignissen, Modulen und Zugriffskontrollmechanismen. Am Ende dieses Kurses werden Sie in der Lage sein: Schreiben Sie modularen, wiederverwendbaren und sicheren Move-Code Nutze Generika, Fähigkeiten und Ressourcentypen effektiv Implementieren Sie mithilfe von Funktionen eine differenzierte Zugriffskontrolle Senden Sie Ereignisse aus und hören Sie sich diese an, um eine Integration außerhalb der Kette zu ermöglichen Arbeiten Sie mit komplexen Datenstrukturen wie Tabellen und Vektoren Verstehe, wie sich Move von anderen intelligenten Vertragssprachen wie Solidity unterscheidet Tauchen wir in das Herz der Move-Sprache ein! Schritt 1: Die wichtigsten Sprachfunktionen von Move verstehen Move wurde unter Berücksichtigung von Sicherheit und Klarheit entwickelt. Lassen Sie uns einige der wichtigsten Funktionen untersuchen, die Move als intelligente Vertragssprache einzigartig machen. 1.1 Ressourcenorientierte Programmierung (überarbeitet) Im Mittelpunkt von Move steht das Konzept derRessourcen. Dabei handelt es sich um spezielle Typen, die nicht kopiert oder gelöscht werden können, sofern dies nicht ausdrücklich erlaubt ist. Dies erzwingt den sicheren Umgang mit digitalen Assets wie Token oder NFTs. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } In diesem Beispiel: MyToken- keyist eineRessource, weil sie die Fähigkeit hat. store- Sie kann gespeichert (id) und anhand ihrer Eigenschaft eindeutig identifiziert werden. Es kann nicht dupliziert oder gelöscht werden, sofern nicht anders angegeben. Dadurch wird garantiert, dass jede MyTokenInstanz einzigartig verwaltet und verwaltet wird, sodass versehentliches Duplizieren oder Löschen verhindert wird. 1.2 Fähigkeitensystem Jeder Move-Typ hat eine Reihe vonFähigkeiten, die definieren, welche Operationen er unterstützt: | Fähigkeit | Bedeutung | | --------| ---------| | copy| Kann dupliziert werden | | drop| Kann zerstörungsfrei weggeworfen werden | | store| Kann im globalen Speicher gespeichert werden | | key| Kann als Struktur mit einem ID-Feld (d. h. einem Objekt) verwendet werden | Beispiel: struct Example has copy, drop { value: u64 } Das Verständnis dieser Fähigkeiten ist für die Gestaltung sicherer und vorhersehbarer intelligenter Verträge unerlässlich. Warum Fähigkeiten wichtig sind Fähigkeiten setzen bei der Kompilierung strenge Regeln durch. Zum Beispiel: Eine Struktur mit nur keyund storekann nicht kopiert oder gelöscht werden. Sie können keine Struktur aus einer Funktion zurückgeben, die nicht gelöscht werden kann, es sei denn, sie wird gespeichert oder übertragen. Dies verhindert Fehler wie doppelte Ausgaben oder versehentlichen Token-Verlust. 1.3 Generische Daten und Typparameter Move unterstützt generische Typen, sodass Entwickler flexiblen und wiederverwendbaren Code schreiben können. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } Hier `ist einTypparameter, der die Box`Arbeit mit jedem Typ ermöglicht und gleichzeitig sicher und effizient ist. Hinweis: Das phantomSchlüsselwort gibt an, dass Tsich dies nicht auf die Laufzeitdarstellung der Struktur auswirkt — nützlich für die abstrakte Modellierung. Schritt 2: Modulare Entwicklung und Paketmanagement Wenn Ihre Move-Projekte immer komplexer werden, wird die Organisation Ihres Codes von entscheidender Bedeutung. 2.1 Move-Pakete erstellen und veröffentlichen EinMove-Paketenthält ein oder mehrere Module und definiert Abhängigkeiten. Es ist die Einheit für Bereitstellung und Versionierung in Move. Verzeichnisstruktur: sources/ place.move user.move Move.toml Definieren Sie Abhängigkeiten inMove.toml: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } Sie können Pakete im Sui-Netzwerk veröffentlichen und sie in mehreren DApps wiederverwenden. 2.2 Wiederverwendung vorhandener Module cointransfertx_contextDasSui Frameworkbietet praxiserprobte Module wie, und. Prüfen Sie immer, was verfügbar ist, bevor Sie benutzerdefinierte Logik schreiben. Um beispielsweise ein Objekt zu übertragen: use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } Die Verwendung von Standardbibliotheken gewährleistet eine sicherere, schnellere Entwicklung und bessere Interoperabilität. Schritt 3: Ereignisse und Off-Chain-Kommunikation Um reale Anwendungen zu erstellen, müssen Ihre Move-Verträge mit Off-Chain-Systemen wie Frontends oder Indexern kommunizieren. 3.1 Ausstrahlende Ereignisse Move ermöglicht die Ausgabe vonEvents, die von externen Diensten indexiert werden können. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } Dieses Ereignis wird in der Blockchain erscheinen und kann von Explorern oder Indexierungstools aufgegriffen werden. 3.2 Ereignisse anhören Verwenden Sie Tools wieSuite Explorer,Subsquidoder die Sui JSON-RPC-API, um auf ausgegebene Ereignisse zu warten und in Ihrer Anwendung entsprechend zu reagieren. In JavaScript/TypeScript: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); Schritt 4: Zugriffskontrolle und Sicherheitsmuster Sicherheit ist beim Umgang mit intelligenten Verträgen von größter Bedeutung. Move bietet verschiedene Tools zur Implementierung einer robusten Zugriffskontrolle. 4.1 Modell des Objektbesitzes Sui setzt das Eigentum auf Protokollebene durch. Nur der Besitzer eines Objekts kann es ändern oder übertragen. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } Nur der aktuelle Besitzer kann diese Funktion aufrufen. 4.2 Funktionsmuster Für detailliertere Berechtigungen verwenden Sie dasCapability Pattern— erstellen Sie spezielle Objekte, die eingeschränkten Zugriff auf bestimmte Funktionen gewähren. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } Jetzt AdminCapkönnen nur Benutzer ausführen, die das besitzenrestricted_action. Dieses Muster wird in DeFi und DAOs häufig verwendet, um Befugnisse sicher zu delegieren. Schritt 5: Arbeiten mit komplexen Datenstrukturen Move unterstützt strukturierte Datentypen, die es Entwicklern ermöglichen, komplexe Logik und Beziehungen zu modellieren. 5.1 Vektoren Vektoren werden verwendet, um geordnete Sammlungen von Objekten desselben Typs zu speichern. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; Sie sind nützlich, um Listen von NFTs, Benutzerrollen oder dynamischen Metadaten zu speichern. Beispiel für die Verwendung: vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 Tabellen (über die Sui Standard Library) Move unterstützt zwar keine nativen Maps oder Hash-Tabellen, aber Sui stellt den TableTyp in seiner Standardbibliothek bereit. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } Verwenden Sie Tabellen, um große Datensätze effizient zu verwalten. Schritt 6: Testen und Debuggen Ihrer Verträge Durch das Testen wird sichergestellt, dass sich Ihr Move-Code unter verschiedenen Bedingungen wie erwartet verhält. 6.1 Komponententests in Move Schreiben Sie Komponententests mithilfe des Test-Frameworks direkt in Ihre Move-Module. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } Führen Sie Tests durch mit: sui move test 6.2 Sui Explorer verwenden Verwenden Sie nach der Bereitstellung Ihres Vertrags den Sui Explorer, um Transaktionen zu überprüfen, Objektstatus einzusehen und Probleme zu debuggen. Schritt 7: Reale Anwendungen von Advanced Move-Konzepten Nachdem Sie nun die wichtigsten Sprachfunktionen verstanden haben, wollen wir untersuchen, wie sie sich auf reale Szenarien anwenden lassen. 7.1 NFT Minting Platform Erstellen Sie eine Plattform, die es Benutzern ermöglicht, NFTs zu minten, die durch Move-Ressourcen unterstützt werden, und nutzen Sie dabei die Eigentums- und Ressourcenmodelle. 7.2 DAO-Wahlsystem Implementieren Sie eine dezentrale autonome Organisation (DAO), die Move für Abstimmungen, Vorschläge und Verwaltung nutzt und Ereignisse und Funktionen für sichere Aktionen nutzt. 7.3 Token-Swaps und AMMs Erstellen Sie eine dezentrale Börse (DEX) mithilfe von Move-Modulen zur Darstellung von Liquiditätspools und Token-Swaps. Verwenden Sie Generics und Tabellen für ein effizientes Zustandsmanagement.

    2
  • Evgeniy CRYPTOCOIN.Peera.
    Evgeniy CRYPTOCOIN196
    FürSuiJun 30, 2025

    Was sind dynamische NFTs und warum zeichnet sich Sui dadurch aus?

    Der NFT-Raum entwickelt sich über statische Bilder und Profilbilder (PFPs) hinaus. Die nächste Grenze? Dynamische NFTs (dNFTs) — Token, die sich aufgrund realer Daten, Benutzerinteraktionen oder On-Chain-Ereignisse ändern können. Während viele Blockchains NFTs unterstützen, ist Sui Network dank seiner innovativen Architektur einzigartig positioniert, um die Zukunft von DNFTs voranzutreiben. Dieser Artikel befasst sich mit: Was macht einen NFT „dynamisch“? Warum die Technologie von Sui perfekt für DNFTs ist Reale Anwendungsfälle heute Die Zukunft interaktiver digitaler Assets #1. Was sind dynamische NFTs? Im Gegensatz zu herkömmlichen NFTs (die statisch und unveränderlich sind) können dynamische NFTs Folgendes aktualisieren: Metadaten (z. B. ein Sport-NFT, das sich je nach Spielstatistik ändert) Aussehen (z. B. ein Kunstwerk, das sich im Laufe der Zeit weiterentwickelt) Nützliches Tool (z. B. ein Treue-NFT, das neue Vorteile freischaltet) Wie funktionieren sie? DNFTs verwenden intelligente Vertragslogik und externe Dateneingaben (Orakel, Benutzeraktionen usw.), um Änderungen auszulösen. Beispiel: Ein wetterempfindliches NFT-Kunstwerk, das die Farben auf der Grundlage von Echtzeit-Klimadaten ändert. Ein NFT für einen Spielcharakter, der beim Spielen aufsteigt. #2 Warum Sui die beste Blockchain für dynamische NFTs ist Während Ethereum und Solana auch DNFTs unterstützen, bietet das Design von Sui wichtige Vorteile: On-Chain-Speicher (keine externen Abhängigkeiten) Die meisten Blockchains speichern NFT-Metadaten außerhalb der Kette (z. B. IPFS), wodurch dynamische Updates umständlich werden. Sui speichert alles in der Kette und ermöglicht so sofortige, vertrauenswürdige Änderungen. Move Language: Sichere und flexible Upgrades Die Solidity von Ethereum erfordert komplexe Proxyverträge für aufrüstbare NFTs. Die Move-Sprache von Sui ermöglicht native Wandelbarkeit — ohne umständliche Problemumgehungen. Parallele Verarbeitung (enorme Skalierbarkeit) Tausende von DNFTs gleichzeitig aktualisieren? Ethereum hat mit Staus zu kämpfen. Die parallele Ausführung von Sui verarbeitet Millionen von Updates ohne Verzögerungen. Objektzentriertes Modell (granulare Steuerung) Jedes NFT ist ein unabhängiges Objekt mit anpassbarer Logik. Ermöglicht eine fein abgestimmte Interaktivität (z. B. kann nur der Besitzer Änderungen auslösen). #3. Reale Anwendungsfälle von DNFTs auf Sui Gaming und Metaverse Sich entwickelnde Gegenstände im Spiel (z. B. ein Schwert-NFT, das bei Gebrauch Fähigkeiten gewinnt). Spielübergreifende Interoperabilität (Suis Objekte können sich zwischen DApps bewegen). Beispiel: *SUI-basierte Spiele wie Panzerdogs verwenden DNFTs für anpassbare Avatare. * Generative und reaktive Kunst KI-gestützte NFTs, die ihren Stil je nach Markttrends ändern. Kollaborative Kunst, bei der Sammler das endgültige Stück beeinflussen. Beispiel: *Kunstlabore wie die Sui Gallery veranstalten DnFT-Ausstellungen. * Nachverfolgung von Vermögenswerten in der realen Welt (RWA) Geben Sie NFTs an, die mit Immobiliendatensätzen aktualisiert werden. Zertifizierungsabzeichen, die automatisch ablaufen oder sich verlängern. Treue- und Mitgliedschaftsprogramme Dynamische Rabatt-NFTs, die sich mit den Kundenausgaben verbessern. VIP-Zugangspässe, die im Laufe der Zeit neue Stufen freischalten. Beispiel: *Die Einzelhandelspartner von Sui testen dNFT-Treueprogramme. * #4 Die Zukunft von DNFTs auf Sui Erwarte zu sehen: KI-integrierte DNFTs (z. B. Chatbots, die in NFT-Avataren leben). Mit DeFi besicherte DNFTs (der Wert passt sich den Marktbedingungen an). Vollständige On-Chain-Spiele, bei denen jedes Asset ein veränderbares dNFT ist. Fazit: Sui gestaltet die Zukunft der NFTs Während statische NFTs 2021-2023 dominierten, werden dynamische NFTs den nächsten Bullenlauf dominieren — und Suis Technologie macht sie zur idealen Plattform. Mit**On-Chain-Speicher, der Sicherheit von Move und unübertroffener Skalierbarkeit ist Sui auf dem besten Weg, die Heimat fortschrittlicher DNFTs zu werden.

    5

Unbeantwortet

  • CarlkawIy.Peera.
    CarlkawIy259
    FürSuiJul 01, 2025

    Wie kann ich SUI-Münzen aus einer alten Brieftasche wiederherstellen?

    Ich habe versucht, meine SUI-Münzen zu finden, als ich ein neues Slush-Konto einrichte, aber ich sehe sie nicht. Wie kann ich überprüfen, ob ich den richtigen Begriff verwende, um mein altes Wallet zu importieren?

    0
    0
  • Owen.Peera.
    Owen496
    FürSuiJun 11, 2025

    Wie aktualisiere ich den Schlüssel eines Händlers in ObjectTable, wenn er sich in der Struktur ändert?

    Hallo zusammen, ich fange gerade mit dem Schreiben intelligenter Verträge an und arbeite an meinem allerersten Projekt. Ich hätte gerne Hilfe bei einem Problem, bei dem ich nicht weiterkomme. Bisher habe ich eine MerchantStruktur erstellt, die so aussieht: -id: eine eindeutige Kennung (UID) -owner: die Adresse des Händlers -key: eine Zeichenfolge, die als eindeutiger Schlüssel verwendet wird -balance: ein u64, das ihr Gleichgewicht darstellt Ich habe auch eine MerchantRegistryStruktur erstellt, um alle Händler zu verwalten: -id: eine andere UID -merchant_to_address: und die ObjectTableZuordnung von Adressen zu Händlern -merchant_to_key: eine ObjectTableZuordnung von Schlüsseln zu Händlern Ich möchte in der Lage sein, einen Händler entweder anhand seinerAdresseoder anhand seinesSchlüsselszu finden. MerchantWenn ein Benutzer seinen Schlüssel innerhalb der merchant_to_keyStruktur aktualisiert, aktualisiert die Änderung nicht automatisch den Schlüssel in der Tabelle. Das bedeutet, dass der alte Schlüssel immer noch auf den Händler zeigt, was Dinge kaputt macht. Ich habe versucht, den Eintrag aus der Tabelle zu entfernen und ihn mit dem neuen Schlüssel wieder einzufügen, aber ich stoße immer wieder auf Fehler wie: „Werte ohne Drop-Funktion können nicht ignoriert werden“ Ich bin mir ziemlich sicher, dass dies ein Anfängerfehler ist, aber ich konnte nirgends eine klare Erklärung oder Lösung finden. Gibt es eine richtige Methode, um den Schlüssel sowohl in der Struktur als auch in der Lookup-Tabelle zu aktualisieren?

    5
    0
  • 0xduckmove.Peera.
    0xduckmove613
    FürSuiJun 06, 2025

    Was ist das einfachste Frontend, um Walross-Blobs hochzuladen?

    nur eine einfache Benutzeroberfläche zum Hochladen auf Walrus? (außer Tusky)

    2
    0

Trendend

  • Vens.sui.Peera.
    Vens.sui211
    FürSuiApr 29, 2025

    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

    8
    2
  • 0xduckmove.Peera.
    0xduckmove613
    Fü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
  • MarlKey.Peera.
    MarlKey61
    FürSuiApr 30, 2025

    Ist die einzige Möglichkeit, Move-Pakete über eine EOA zu veröffentlichen?

    Ich gehe davon aus, dass es in der Sui-Kette keine Möglichkeit gibt, da es in der Kette kein Modul gibt, das Pakete veröffentlicht.

    7
    3