Sui.

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

  • 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
  • Peera Admin.Peera.
    Peera Admin36
    FürSuiMar 05, 2025
    +10

    Fehler bei der Überprüfung mehrerer Quellen“ in den Veröffentlichungen des Sui Move-Moduls — Automatisierte Fehlerbehebung

    Entwickler, die mit Sui Move arbeiten, stoßen beim Versuch, Module zu veröffentlichen oder zu aktualisieren, häufig auf Probleme im Zusammenhang mit „Fehler bei der Überprüfung mehrerer Quellen gefunden“. Diese Fehler treten aufgrund von Diskrepanzen zwischen lokalen Abhängigkeiten und ihren Gegenstücken in der Kette auf, was zu fehlgeschlagenen Veröffentlichungen und Problemen bei der Bereitstellung führt. Im Folgenden finden Sie ein konsolidiertes Beispiel für die Fehler, mit denen Entwickler konfrontiert sind: Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk Dieses Problem tritt häufig auf aufgrund von: Die Versionen zwischen der lokalen Entwicklungsumgebung (z. B. Sui CLI) und dem On-Chain-Status stimmen nicht überein. Unterschiede in den Paketkonfigurationen zwischen Netzwerken (z. B. Mainnet vs. Testnet). Fehlende oder veraltete Abhängigkeiten in der On-Chain-Umgebung. Wichtige Fragen Wie können wir die Erkennung und Behebung dieser Abhängigkeiten während des Veröffentlichungsprozesses automatisieren? Welche Tools oder Skripte können entwickelt werden, um sicherzustellen, dass lokale Abhängigkeiten immer mit denen auf der Kette übereinstimmen? Gibt es eine Möglichkeit, diesen Prozess zu rationalisieren, indem man Abhängigkeitsprüfungen in bestehende CI/CD-Pipelines integriert oder das Sui SDK erweitert? Ihre Aufgabe ist es, eine Lösung vorzuschlagen, die diese Herausforderungen bewältigt und eine reibungslosere und zuverlässigere Bereitstellung für Sui Move-Entwickler gewährleistet. Stellen Sie sicher, dass Sie Ihre Lösung unten veröffentlichen.

    4
    1

Neueste

  • Pluto Dev👽.Peera.
    Pluto Dev👽10
    FürWalrusMay 01, 2025

    Where else can I get SUI from a faucet?

    I've been using a SUI faucet for some transactions, but I'm looking for alternative options to receive SUI tokens. Are there other faucets or methods I can try?

    0
    1
  • McMMoKing.Peera.
    McMMoKing175
    FürSuiMay 01, 2025

    Wie behebe ich Verbindungsprobleme mit Sui Wallet und Ledger?

    Ich habe Probleme mit meiner Sui-Wallet im Brave-Browser, der durch mein Ledger-Gerät geschützt ist. Wenn ich versuche, Geld an eine Börse zu senden, werde ich aufgefordert, eine Verbindung zum Ledger herzustellen, aber es wird behauptet, dass die Verbindung unterbrochen wurde. Wie kann ich dieses Problem lösen? Und benötige ich die Seed-Recovery-Phrase, um mein Ledger wieder zu verbinden?

    0
    2
  • elfDani.Peera.
    elfDani10
    FürWalrusMay 01, 2025

    Is my file private when uploaded to Walrus?

    I'm thinking of using Walrus for storing some files. My main concern is whether my files are private by default when I upload them. I don't really want my personal or sensitive data out in the open for everyone to see. Can someone let me know if there's a way to keep my files private, or should I be looking into alternatives?

    0
    1

Unbeantwortet

  • Rogue.Peera.
    Rogue82
    FürSuiApr 25, 2025

    Beste Memecoin auf SUI

    Schick mir ein paar SUI-Memecoins

    2
    0
  • RogueRig.Peera.
    RogueRig82
    FürSuiApr 25, 2025

    Walrus Protocol — Das versteckte Juwel auf SUI

    Der Begriff „Walrus“ im Zusammenhang mit den von Ihnen bereitgestellten Dokumenten bezieht sich auf eine dezentrale Speicherplattform, die von Mysten Labs entwickelt wurde und Teil des Sui-Ökosystems ist. Walrus wurde entwickelt, um umfangreiche Datenspeicheranforderungen zu erfüllen, die herkömmliche Blockchains nicht effizient verwalten können. Es bietet eine kostengünstige, skalierbare und programmierbare Speicherlösung und stärkt damit Suis Position als globale Koordinationsebene. Die Walrus-Plattform ist auch mit dem WAL-Token verknüpft, das eine entscheidende Rolle bei der Stromversorgung des Netzwerks durch delegierte Proof-of-Stake und der Sicherstellung einer zuverlässigen Datenspeicherung durch neuartige Bestätigungsherausforderungen spielt. Darüber hinaus wird Walrus zum Speichern von Medieninhalten verwendet, wie Decrypt, ein führendes Web3-Medienunternehmen, gezeigt hat, das seine gesamte Inhaltsbibliothek auf Walrus veröffentlicht. Weitere Informationen finden Sie im Walrus Whitepaper.

    1
    0
  • 1 Luca.Peera.
    1 Luca186
    FürSuiApr 09, 2025

    Was passiert, wenn ich die ETH nicht über die Sui Bridge beanspruche?

    Ich habe die Sui-Brücke benutzt, um einige ETH zu überweisen, habe sie aber noch nicht beansprucht, da die Gebühren ziemlich hoch sind. Was passiert, wenn ich es nicht beanspruche?

    0
    0

Trendend

  • 0xduckmove.Peera.
    0xduckmove220
    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
  • harry phan.Peera.
    harry phan360
    FürSuiApr 24, 2025

    Modulübergreifende Kinderverwaltung mit public_receive

    Dies ist Teil 3 der Reihe „Eltern-Kind-Objekte in Sui Move“. Manchmal sind Ihre Eltern- und Kindertypen in verschiedenen Modulen oder sogar in verschiedenen Paketen definiert. Beispielsweise könnten Sie ein generisches Warehouse-Objekt haben, das jede Art von Parcel-Objekten speichern kann. Das Warehouse-Modul möchte ein untergeordnetes Paket abrufen, aber der Flurstückstyp ist an anderer Stelle definiert. In solchen Fällen verwenden wir transfer: :public_receive, den modulübergreifenden Cousin von receive. ###receive gegen public_receive Wie wir gesehen haben, kann transfer: :receive nur in dem Modul aufgerufen werden, das T (oder einen Freund) definiert, da T: store nicht benötigt wird. Der Move-Bytecode-Verifier stellt tatsächlich sicher, dass bei jedem zu empfangenden Anruf der Typ T vom aktuellen Modul stammt. Dies ist eine Sicherheitsbeschränkung für Objekte, die nur Schlüssel enthalten. transfer: :public_receive ist eine Variante, die einen T: key+-Speicher erfordert, aber den Empfang außerhalb des Moduls von T ermöglicht. Mit anderen Worten, wenn der Objekttyp die Fähigkeit zum Speichern hat (was bedeutet, dass er im globalen Speicher frei existieren darf), dann kann jedes Modul (mit einer &mut-UID des übergeordneten Objekts) ihn mit public_receive empfangen. Dies ist perfekt für Fälle, in denen sich das Modul des Elternteils vom Modul des Kindes unterscheidet. Warum brauchen Sie ein Geschäft? Weil Store bedeutet, dass das Objekt sicher gespeichert und außerhalb seines Definitionsmoduls weitergegeben werden kann. Objekte, die nur Schlüssel enthalten, können benutzerdefinierte Invarianten haben, die das Originalmodul beim Übertragen/Empfangen erzwingen möchte. Indem Sui diese aus public_receive ausschließt, zwingt Sui die Entwickler, sie im Modul zu behandeln (wie wir bei soul-gebundenen Objekten sehen werden). Wenn ein Objekt einen Speicher hat, ist es freizügiger, und Sui ermöglicht eine generische Übertragungs-/Empfangslogik, um es extern zu verwalten. ###Beispiel: Separate Eltern- und Untermodule Lassen Sie uns das anhand eines einfachen Szenarios veranschaulichen: einem Warehouse, das Parcel-Objekte speichert. Der Flurstückstyp ist in einem eigenen Modul definiert und das Warehouse in einem anderen. Wir zeigen, wie Warehouse mithilfe von public_receive ein untergeordnetes Paket empfangen kann. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Lassen Sie uns aufschlüsseln, was in withdraw_parcel passiert: Wir rufen public_receive (&mut warehouse.id, parcel_ticket) auf. Da Parcel die Fähigkeit hat, zu speichern, ist dieser Aufruf zulässig, auch wenn wir uns nicht im Paketmodul befinden. Unter der Haube führt dies die gleiche Prüfung und Extraktion durch wie Receive, aber es ist modulübergreifend zulässig, da Store angibt, dass dies sicher ist. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T Wir übertragen das empfangene Paket dann sofort an die Adresse des Anrufers (tx_context: :sender (ctx)). Dieser Schritt stellt sicher, dass das Paket das Lager verlässt und an den Benutzer geht, der die Auszahlung veranlasst hat. Wir hätten auch einfach Parcel von der Funktion zurückgeben können, und Sui würde es als eine Ausgabe behandeln, die der Adresse des Anrufers gehört (da es sich um eine Eingabefunktionsausgabe handelt). Eine explizite Übertragung ist ausführlicher, macht aber deutlich, was passiert (und ermöglicht es uns, alle Überprüfungen durchzuführen, bevor wir das Objekt freigeben). Warum sollte „Shop“ in das Paket aufgenommen werden? Wenn Parcel nicht speichern kann (d. h. es hat nur den Schlüssel), würde der public_receive -Aufruf in demo: :warehouse nicht kompiliert werden — Sui erzwingt, dass T Speicher für public_receive hat. In diesem Fall wären wir gezwungen, das Paket mithilfe von Receive im Paketmodul selbst abzurufen (oder eine Freundschaftsbeziehung zu nutzen), was das modulübergreifende Design erschwert. Indem wir dem Paket Speicher hinzufügen, sagen wir quasi: „Dieses Objekt kann frei bewegt und von externen Modulen empfangen werden“, was wir für ein generisches Containermuster brauchen. Muster für Funktionsaufrufe: Um diese in einer Transaktion zu verwenden, würde der Ablauf wie folgt aussehen: 1.Einzahlung (Transfer zum Objekt) :Rufen Sie transfer: :public_transfer (parcel_obj, @warehouse_id) auf, um ein Paket in ein Warehouse zu schicken. Dies kennzeichnet den Eigentümer des Pakets als das Lagerhaus. (Wir verwenden hier public_transfer, weil es sich außerhalb des Paketmoduls befindet und Parcel einen Speicher hat. Innerhalb des Paketmoduls würde auch eine einfache Übertragung funktionieren.) Abheben (zurückerhalten) :Rufen Sie später withdraw_parcel (warehouse_obj, Receiving (parcel_id,...)) auf. Die Empfangsbestätigung kann vom SDK abgerufen werden, indem die ID des Pakets und die neueste Version angegeben werden. Die Funktion ruft public_receive auf und überträgt dann das Paket an Sie. Nach dem Aufruf von withdraw_parcel hat der Besitzer des Pakets wieder eine Adresse (Ihre), es handelt sich also wieder um ein normales Objekt, das der Adresse gehört. Das Lagerhaus besitzt es nicht mehr. Modulübergreifende Überlegungen: Beachten Sie, dass das Warehouse-Modul den Pakettyp kennen musste (wir verwenden demo: :parcel: :Parcel). Das liegt daran, dass wir „Empfangen“ explizit als „Empfangen“ eingeben. Wenn Sie einen wirklich generischen Container wollten, der jede Art von Objekt aufnehmen kann, müssten Sie generische oder einen anderen Ansatz verwenden (möglicherweise dynamische Felder mit Typlöschung). In den meisten Anwendungsfällen wissen Sie jedoch, welche Arten von Kindern Sie erwarten. Warum public_receive, anstatt nur receive aufzurufen? Wenn wir transfer: :receive (&mut warehouse.id, parcel_ticket) im Warehouse-Modul versuchen würden, würde der Move-Verifier dies ablehnen, da Parcel in demo: :warehouse nicht definiert ist. Sui bietet Public_Receive als gesegnete Möglichkeit, dies zu tun, mit einer zusätzlichen Fähigkeitsprüfung (Speicherplatz erforderlich). In ähnlicher Weise hat Sui transfer vs public_transfer, freeze_object vs public_freeze_object usw., und zwar nach demselben Muster: Die public_-Versionen sind für die Verwendung außerhalb des definierenden Moduls vorgesehen und benötigen Speicher. Vergessen Sie nicht die Erlaubnis der Eltern: Selbst mit public_receive benötigen Sie immer noch die &mut warehouse.id. Wir haben sie bekommen, weil withdraw_parcel im Modul von Warehouse ist und &mut Warehouse akzeptiert. Somit kann nur jemand, der das anrufen kann (der Besitzer des Lagers), das Paket zurückziehen. Wenn das Warehouse-Modul eine solche Funktion nicht öffentlich zur Verfügung stellen würde, könnte auch niemand extern public_receive für seine untergeordneten Elemente aufrufen. Das Cross-Modul umgeht also nicht die Steuerung des übergeordneten Elements; es ermöglicht lediglich, dass der Code des Elternteils mit untergeordneten Typen funktioniert, die es nicht definiert hat. Ein Hinweis zur Speicherfähigkeit: Wenn Sie einen Objektspeicher angeben, ist er flexibler, aber etwas weniger eingeschränkt — jedes Modul mit der übergeordneten Referenz kann ihn mit public_receive abrufen. Wenn Sie die Art und Weise, wie ein Objekt abgerufen wird,einschränkenmöchten (z. B. eine benutzerdefinierte Logik erzwingen oder ein einfaches Extrahieren verhindern), können Sie es bewusst nur als Schlüssel verwenden. Wir werden uns ein Beispiel dafür mit seelengebundenen Objekten ansehen. In diesen Fällen könnten Sie eine benutzerdefinierte Empfangsfunktion implementieren, anstatt sich auf public_receive zu verlassen. Um diesen Teil zusammenzufassen: public_receive ist Ihr Freund für die Verwaltung untergeordneter Objekte, die in anderen Modulen definiert sind, solange diese Objekte die Fähigkeit zum Speichern haben. Es ermöglicht Ihnen, modulübergreifende Systeme (wie unser Lager/Paket) zu erstellen und gleichzeitig die Eigentums- und Zugriffskontrolle zu respektieren. Denken Sie nur daran, Store bei untergeordneten Typen anzugeben und public_transfer zu verwenden, wenn Sie sie von außerhalb ihres Moduls an ein übergeordnetes Objekt senden.

    5
  • 0xduckmove.Peera.
    0xduckmove220
    FürSuiApr 25, 2025

    Zusammenfassen: Das Video kann deine Sui Dev Journey noch einmal aufpeppen

    Seien wir ehrlich, wenn du schon einmal aufSuigebaut hast, bist du wahrscheinlich gegen einige Wände gestoßen. Von kryptischen Objekt-IDs über das Jonglieren mit CLIs bis hin zum Aufbau von Localnets — es ist, als bereitest du dich auf einen Bosskampf vor, bevor du überhaupt deine erste Geschäftslogik geschrieben hast. Während eines kürzlich im Rahmen der Road to Overflow-Reihe durchgeführten Workshops erläuterte Moven von der Dubhe Foundation, wie Dubhe Engine funktioniert, welche Probleme sie löst und warum Dubhe Engine mehr ist als nur ein Tool — es ist eine wachsende Bewegung. Videolink: https://www.youtube.com/watch?v=CHkOS-TYehM Das Problem: Fragmentierte Werkzeuge, aufwändiger Aufbau Moven begann mit einem echten Gespräch über die aktuelle Sui-Entwicklerlandschaft: Neulinge stehen vor einer steilen Lernkurve: Wallets einrichten, Test-Tokens beanspruchen, Pakete erstellen, die Move-Syntax erlernen, lokale Testnetze einrichten, SDKs konfigurieren und vieles mehr. Selbst erfahrene Entwickler verschwenden Zeit mit sich wiederholenden Einrichtungsaufgaben, anstatt sich auf die eigentliche DApp-Logik zu konzentrieren. Codebasen werden schnell monolithisch — große, unordentliche .move-Dateien mit Datenstrukturen, Konstruktoren, Hilfsprogrammen und Eingabefunktionen, die alle zusammengepfercht sind. Kurzum: Das Ökosystem wächst schnell, aber die Tools haben bis jetzt nicht Schritt gehalten. ##Die Lösung: Schemabasierte Codegenerierung Im Mittelpunkt vonDubhe Enginesteht eine zentrale Idee:Schema-First-Entwicklung. Mit nur einer Konfigurationsdatei (d.config.ts) können Entwickler Folgendes definieren: Ihre On-Chain-Datenstrukturen Ereignisse Fehler Benutzerdefinierte Typen (sogar 2D-Vektoren selbstdefinierter Strukturen!) Von dort aus pnpm dub schema:gengeneriert ein Befehl () automatisch ein vollständig strukturiertes Move-Paket und eine Frontend-Integration, komplett mit: Modularisierte Dateistruktur Kombinierbarkeit innerhalb der Kette (durch Importe aus den veröffentlichten Paketen von Sui) Localnet-Setup, Build, Deployment und Frontend-Unterstützung (Next.js bereit) Sie schreiben die Logik.Dubhekümmert sich um das Boilerplate. ##* ⏱️ Echte Wirkung: 80% weniger sich wiederholender Code* In internen Experimenten zeigten Dubb-generierte Projekte, dass nur* 20% des Code*manuell geschrieben werden mussten — der Rest bestand aus automatisch über Schemas generierten Gerüsten. Das bedeutet schnelleres Prototyping, weniger Bugs und mehr Zeit, um sich auf das zu konzentrieren, was wirklich wichtig ist: den Kernwert Ihrer App. ##Eine Entwickler-Ökosystem Dubb macht nicht vor einem Gerüst halt. Movin hat es deutlich gemacht: Das istInfrastruktur für eine neue Entwickler-Wirtschaft. So entwickelt sich die Dubb Engine-Community: Gassubventionen:** Für neue Bauherren, die mit Dubb experimentieren Task Bounties:** Wie die „guten ersten Ausgaben“ von GitHub, aber mit Belohnungen Governance Layer (D-OS) :**On-Chain-Abstimmung für die Priorisierung von Projekten Launchpad-Support:** Unterstützung ausgereifter Projekte bei der Sicherung der Finanzierung DApp Staking:** Benutzer können D-Token einsetzen, um ihre Lieblings-DApps zu unterstützen und über Roadmap-Entscheidungen abzustimmen Diese Feedback-Schleife treibt das gesamte Sui-Ökosystem an: mehr Entwickler → mehr Apps → mehr Benutzer → mehr Entwickler.

    5
Wir verwenden Cookies, um sicherzustellen, dass Sie die beste Erfahrung auf unserer Website haben.
Mehr Infos