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