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.eth301
    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
    2
  • 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
    2
  • Peera Admin.Peera.
    Peera Admin31
    FürMoveMar 11, 2025
    +10

    Sui Move vs Aptos Move - What is the difference?

    Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?

    2
    1

Neueste

  • HaGiang.Peera.
    HaGiang169
    FürSuiJun 18, 2025

    Building with Rust on Sui

    I saw this repo recently when checking on the Mysten_Labs's GitHub: https://github.com/MystenLabs/move-binding Move Binding is a Rust library that provides a way to interact with Sui Move packages on-chain. It reads Move packages from the Sui blockchain and generates corresponding Rust structs and function entry points, allowing for seamless integration between Move and Rust. To use Move Binding in your project, add the following dependency to your Cargo.toml: [dependencies] move-binding-derive = { git = "https://github.com/MystenLabs/move-binding" } move-types = { git = "https://github.com/MystenLabs/move-binding" } `

    1
    0
  • harry phan.Peera.
    harry phan456
    FürSuiJun 18, 2025

    Aufbau eines Marktplatzes mit heterogenen Vermögenswerten

    Beim Aufbau eines Marktplatzes auf einer Blockchain mithilfe der Programmiersprache Move besteht eine der faszinierendsten Herausforderungen darin, Vermögenswerte mit unterschiedlichen Leistungseinschränkungen in einer einzigen Sammlung zu verwalten. Egal, ob Sie es mit übertragbaren NFTs, nicht übertragbaren Soulbound-Token oder benutzerdefinierten Assets mit einzigartigen Übertragungsbeschränkungen zu tun haben, das strenge Typsystem von Move erfordert ein sorgfältiges Design, um Typsicherheit und Effizienz zu gewährleisten. In diesem Beitrag werden wir untersuchen, wie Leistungsbeschränkungen mit dynamischen Feldern in heterogenen Sammlungen interagieren, praktische Lösungen untersuchen und einen soliden Ansatz für den Aufbau eines Marktplatzes vorstellen, der verschiedene Anlagearten abwickelt. Die Fähigkeiten von Move verstehen Move, das für Blockchains wie Sui und Aptos entwickelt wurde, verwendet Fähigkeiten, um zu definieren, welche Operationen ein Typ unterstützt. Die beiden wichtigsten Fähigkeiten, die für unseren Marktplatz relevant sind, sind: Schlüssel: Ermöglicht das Speichern eines Typs im globalen Speicher als Objekt. Speichern: Ermöglicht die Einbettung eines Typs in ein anderes Objekt, z. B. eine Struktur oder Sammlung. Unser Marktplatz muss sich mit Folgendem auseinandersetzen: Reguläre NFTs: Haben Key + Store, wodurch sie übertragbar und speicherbar sind. Soulbound-Token: Sie haben nur Schlüssel, was bedeutet, dass sie nicht übertragbar sind und nicht in anderen Objekten gespeichert werden können. Benutzerdefinierte Vermögenswerte: Sie verfügen über unterschiedliche Fähigkeiten, möglicherweise mit Übertragungsbeschränkungen. Ziel ist es, diese Vermögenswerte in einer einzigen Sammlung, wie einer Tasche, zu speichern und ihre Angebote unter Berücksichtigung des Typsystems von Move zu verwalten. Die Herausforderung: Dynamische Felder und Fähigkeitsbeschränkungen Die dynamic_field::add()Funktion von Move ermöglicht das dynamische Hinzufügen von Feldern zu Objekten, was für eine heterogene Sammlung ideal erscheint. Der Wertetyp V muss jedoch die Fähigkeit zum Speichern haben. Dies stellt ein Problem für Soulbound-Token dar, denen es an Speicherplatz mangelt. Wie speichern und verwalten wir also Vermögenswerte mit unterschiedlichen Fähigkeiten auf einem Marktplatz? Die wichtigsten Fragen Muss V in dynamischen Feldern immer gespeichert werden? Können wir Wrapper-Typen verwenden, um dies zu umgehen? Kann eine einzelne Tasche Objekte mit unterschiedlichen Fähigkeiten aufbewahren (z. B. Schlüssel plus Speicher gegen Schlüssel)? Wie gewährleisten wir die Typsicherheit bei der Typlöschung dynamischer Felder? Wie helfen Phantomtypen und das Zeugenmuster bei der Verwaltung heterogener Ressourcen? Lassen Sie uns jede Frage angehen und eine Lösung finden. Anforderungen an die Fähigkeiten dynamischer Felder Die Move-Dokumentation bestätigt, dass dynamic_field: :add () V benötigt, um die Speicherfähigkeit zu haben. Dies liegt daran, dass dynamische Felder in einem Objekt gespeichert werden und Move erzwingt, dass eingebettete Werte speicherbar sein müssen. Bei normalen NFTs mit Schlüssel und Speicher ist das einfach — wir können sie direkt in einer Tasche oder einem dynamischen Feld speichern. Für Soulbound-Token mit nur Schlüssel ist eine direkte Speicherung nicht möglich. Ein Wrapper-Typ, wie struct Wrapper has store {asset: T}, funktioniert nicht, weil T keinen Speicher hat. Stattdessen können wir Metadaten wie die ID des Assets und die Angebotsdetails speichern, für die es einen Speicher gibt. Zum Beispiel: struct Metadata has store { id: ID, price: u64, asset_type: String, } Heterogener Speicher in einer einzigen Sammlung Ein Bag in Move ist so konzipiert, dass es Werte mit der Speicherfähigkeit speichert, aber alle Werte müssen denselben Typbeschränkungen entsprechen. Das bedeutet, dass ein einzelner Bag nicht sowohl NFTs (Schlüssel + Speicher) als auch Soulbound-Token-Metadaten speichern kann, es sei denn, sie sind in einen gemeinsamen Typ mit Store verpackt. Das Mischen von Typen in einer Sammlung führt jedoch häufig zu Komplexität und potenziellen Problemen mit der Typsicherheit. Ein besserer Ansatz besteht darin, separate Sammlungen für unterschiedliche Fähigkeiten zu verwenden: Vermögenswerte: Speichere die Vermögenswerte direkt in einem Vektor oder einer Tasche. - Soulbound Tokens: Speichere ihre IDs und Metadaten in einem Vektor. Diese Trennung berücksichtigt die Leistungsbeschränkungen von Move und sorgt gleichzeitig dafür, dass das System modular und wartbar bleibt. Aufrechterhaltung der Typsicherheit Dynamische Felder löschen Typinformationen zur Laufzeit, daher erfordert das Abrufen eines Werts die Angabe des Typs bei der Kompilierung, wie bei dynamic_field: :remove (). Dies gewährleistet die Typsicherheit, erschwert jedoch den Umgang mit heterogenen Typen. Um verschiedene Asset-Typen zu verwalten, speichern Sie ein Typ-Tag (z. B. einen String wie „NFT“ oder „SoulBoundToken“) in den Metadaten. Überprüfen Sie zur Laufzeit das Tag, um zu ermitteln, wie das Listing verarbeitet werden soll. Zum Beispiel: public struct ListingMetadata has store { asset_id: ID, price: u64, asset_type: String, } Verwenden Sie beim Abrufen die, asset_typeum zu entscheiden, ob das Asset als NFT- oder Soulbound-Token behandelt werden soll, um die korrekte Handhabung sicherzustellen und gleichzeitig die Typsicherheit der gespeicherten Metadaten bei der Kompilierung aufrechtzuerhalten. Phantomtypen und das Zeugenmuster Phantomtypen in Move, wie struct Asset, sind nützlich, um verschiedene Asset-Typen ohne Laufzeitaufwand zu taggen. Sie können beispielsweise Asset und Asset definieren, um Varianten zu unterscheiden. Die Struktur selbst muss jedoch noch Speicherplatz haben, um in einer Sammlung gespeichert zu werden, und die Typinformationen werden zur Laufzeit gelöscht. Um die Typinformationen später zu extrahieren, speichern Sie ein Metadatenfeld wie asset_type neben dem Asset oder seiner ID. Auf diese Weise können Sie bei der Verarbeitung zwischen Asset und Asset unterscheiden, z. B. bei der Ausführung von Transfers oder der Anzeige von Auflistungen. Ein praktisches Marktplatz-Design Hier ist eine praktische Implementierung für einen Marktplatz, der sowohl übertragbare als auch seelengebundene Vermögenswerte verwaltet: Struktur des Marktplatzes use sui::object::{Self, UID, ID}; use sui::vec_map::{Self, VecMap}; struct Marketplace has key { id: UID, transferable_listings: VecMap, soulbound_listings: VecMap, } struct ListingWithAsset has store { asset: T, // T must have key + store price: u64, } struct ListingMetadata has store { asset_id: ID, price: u64, asset_type: String, } Übertragbare Vermögenswerte: public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { let id = object::id(&asset); let listing = ListingWithAsset { asset, price }; vec_map::insert(&mut marketplace.transferable_listings, id, listing); } Soulbound-Token: ublic fun list_soulbound( marketplace: &mut Marketplace, asset: &T, price: u64 ) { let id = object::id(asset); let listing = ListingMetadata { asset_id: id, price, asset_type: "SoulboundToken" }; vec_map::insert(&mut marketplace.soulbound_listings, id, listing); } Durch den Aufbau eines Marktplatzes in Move habe ich gelernt, wie wichtig es ist, sich an das Typsystem der Sprache anzupassen. Funktionen wie Speichern sind für dynamische Felder nicht verhandelbar. Daher ist eine frühzeitige Planung der Metadatenspeicherung für nicht speicherbare Assets von entscheidender Bedeutung. Separate Sammlungen vereinfachen die Handhabung verschiedener Fähigkeiten, während Metadaten-Tags eine flexible Laufzeit ermöglichen. Phantomtypen eignen sich hervorragend für Unterscheidungen bei der Kompilierung, für die Verarbeitung von Laufzeittypen sind jedoch explizite Metadaten erforderlich.

    1
  • Xavier.eth.Peera.
    Xavier.eth301
    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
    2

Unbeantwortet

  • HaGiang.Peera.
    HaGiang169
    FürSuiJun 18, 2025

    Building with Rust on Sui

    I saw this repo recently when checking on the Mysten_Labs's GitHub: https://github.com/MystenLabs/move-binding Move Binding is a Rust library that provides a way to interact with Sui Move packages on-chain. It reads Move packages from the Sui blockchain and generates corresponding Rust structs and function entry points, allowing for seamless integration between Move and Rust. To use Move Binding in your project, add the following dependency to your Cargo.toml: [dependencies] move-binding-derive = { git = "https://github.com/MystenLabs/move-binding" } move-types = { git = "https://github.com/MystenLabs/move-binding" } `

    1
    0
  • Owen.Peera.
    Owen212
    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?

    2
    0
  • 0xduckmove.Peera.
    0xduckmove408
    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)

    1
    0

Trendend

  • 0xduckmove.Peera.
    0xduckmove408
    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
  • Vens.sui.Peera.
    Vens.sui176
    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

    6
    2
  • Foksa.Peera.
    Foksa225
    FürPeera MetaJul 25, 2022

    How to create an account

    To create an account on the Peeranha website you need to log in first. Peeranha supports four wallets you can log in with: Torus, MetaMask, WalletConnect, and Coinbase. Note: If you are new to Web3 we recommend you to use Torus. Log in with Torus Click Log in. Select the checkbox I agree to the Terms and Conditions and Privacy Policy. Choose Torus in the pop-up window. Select any of the suggested ways you want to sign in or enter your email address. You are now logged in and have an account. In your profile section, you can add more detailed information about yourself and track your progress and achievements. To edit your profile, click Profile and select Edit. Enter all the information that you want to be visible in your profile.

    5