Vergleichen wir Sui Move mit Aptos Move. Diese beiden sind wie Geschwister aus der Move-Sprachfamilie, aber sie haben definitiv ihre eigene Persönlichkeit:

#Wie funktionieren sie? Die Laufzeitunterschiede: Leistung, Skalierbarkeit und Entwicklererfahrung

Sowohl Sui als auch Aptos implementieren benutzerdefinierte Move-VMs (VMs), die als Laufzeiten dienen und die Leistung, Skalierbarkeit und das Entwicklererlebnis beeinflussen.

Untersuchungen haben ergeben, dass Sui Move wie ein Freund ist, der immer herumeilt und Dinge schnell erledigt.Die virtuelle Maschine ist auf Geschwindigkeit ausgelegt — denken Sie etwa 0,5 Sekunden nach, um eine Transaktion abzuschließen, dank einiger ausgeklügelter Tricks zur parallelen Ausführung mit einem DAG-Setup (z. B. 0,5 Sekunden, wie in Aptos vs. Sui vs. Movement: Move Blockchains Compared beschrieben)

Im Gegensatz dazu verwendet Aptos eine lineare Architektur mit Funktionen zur parallelen Ausführung, aber der Konsens bei jeder Transaktion kann zu Engpässen im großen Maßstab führen, deren Endgültigkeit etwa 0,9 Sekunden beträgt.

Die kausale Reihenfolge von Sui bedeutet, dass für viele Transaktionen kein vollständiger Konsens erforderlich ist, wodurch die Latenz reduziert wird. Aptos verwendet AptosBFT, ein Derivat von HotStuff, und gewährleistet so eine schnelle Finalisierung, aber potenziell einen höheren Rechenaufwand.

Das Modell von Sui beinhaltet einen Referenzgaspreis, der zu Beginn jeder Epoche auf der Grundlage von Validator-Eingaben festgelegt wird, wodurch Vorhersagbarkeit und niedrige Gebühren gewährleistet werden (z. B. eine durchschnittliche Transaktionsgebühr von 0,0001$, gemäß Sui vs. Aptos: Welche Blockchain ist die richtige für Sie?).

Standardbibliotheken: Module, Funktionen und Anwendungsfälle

Da Sui und Aptos unterschiedliche architektonische Designs haben — Sui ist objektzentriert und behandelt Vermögenswerte als übertragbare Objekte, während Aptos kontobasiert ist und Vermögenswerte mit Konten verknüpft — unterscheiden sich ihre Standardbibliotheken erheblich in Struktur und Verwendung.

Ein benutzerdefiniertes Token erstellen

In Aptos bietet das Modul managed_coin aus der Standardbibliothek aptos_framework eine einfache Möglichkeit, fungible Token zu erstellen und zu verwalten. Hier ist ein Beispiel:

module example::MyToken {
    use aptos_framework::managed_coin;
    use std::signer;

    /// Struct representing the custom token
    struct MyToken has key { }

    /// Initialize the token with name, symbol, decimals, and monitoring option
    public entry fun initialize(account: &signer) {
        managed_coin::initialize<MyToken>(
            account,
            b"MyToken",           // Name
            b"MTK",              // Symbol
            6,                   // Decimals
            true,                // Enable monitoring
        );
    }

    /// Mint tokens to the caller's account
    public entry fun mint(account: &signer, amount: u64) {
        managed_coin::mint<MyToken>(account, amount);
    }
}

In diesem Anwendungsfall wird ein fungibles Token erstellt, das an ein Konto gebunden ist, was typisch für kontobasierte Systeme wie Aptos ist.

In Sui verwaltet das coinModul aus der Sui-Standardbibliothek Tokens als Objekte. Sie erstellen eine Währung und verwenden ein TreasuryCapObjekt, um Münzen zu prägen. Hier ist ein Beispiel:

module example::MyToken {
    use sui::coin::{Self, Coin, TreasuryCap};
    use sui::transfer;
    use sui::tx_context::{Self, TxContext};

    /// Struct defining the custom token type (with `drop` for currency creation)
    struct MY_TOKEN has drop { }

    /// Create a new currency and transfer its TreasuryCap and metadata
    public entry fun create_currency(ctx: &mut TxContext) {
        let (treasury_cap, metadata) = coin::create_currency(
            MY_TOKEN {},         // Token type witness
            6,                   // Decimals
            b"MTK",              // Symbol
            b"MyToken",          // Name
            b"A custom token",   // Description
            option::none(),      // Optional icon URL
            ctx,
        );
        transfer::public_transfer(treasury_cap, tx_context::sender(ctx));
        transfer::public_transfer(metadata, tx_context::sender(ctx));
    }

    /// Mint new coins using the TreasuryCap
    public fun mint(
        treasury_cap: &mut TreasuryCap<MY_TOKEN>,
        amount: u64,
        ctx: &mut TxContext
    ): Coin<MY_TOKEN> {
        coin::mint(treasury_cap, amount, ctx)
    }
}

Ein NFT prägen

Aptos verwendet das Token-Modul, um nicht fungible Token (NFTs) innerhalb von Sammlungen zu verwalten. So erstellen Sie eine Sammlung und prägen ein NFT:

module example::MyNFT {
    use aptos_framework::token;
    use std::string;
    use std::signer;

    /// Create a new NFT collection
    public entry fun create_collection(creator: &signer) {
        token::create_collection(
            creator,
            string::utf8(b"MyCollection"),       // Collection name
            string::utf8(b"A collection of NFTs"), // Description
            string::utf8(b"https://example.com"), // URI
            true, true, true, true, true, true, true, true, true, // Mutability flags
        );
    }

    /// Mint an NFT within the collection
    public entry fun mint_nft(
        creator: &signer,
        collection: &string::String,
        name: &string::String,
        uri: &string::String
    ) {
        token::create_token(
            creator,
            *collection,
            *name,
            string::utf8(b"Description"), // Token description
            1,                            // Maximum supply (1 for NFT)
            *uri,                         // Token URI
            0, 0, 0,                      // Royalty settings
            vector::empty(),              // Property keys
            vector::empty(),              // Property values
            vector::empty(),              // Property types
        );
    }
}```


 Verwaltung einzigartiger digitaler Vermögenswerte (z. B. Kunstwerke) innerhalb einer strukturierten Sammlung, wie sie in kontobasierten NFT-Systemen üblich ist.

`objects``object`In Sui sind NFTs eigenständig `transfer`mit eindeutigen IDs, die mithilfe der Module und verwaltet werden. Hier ist ein Beispiel:

```rust
module example::MyNFT {
    use sui::object::{Self, UID};
    use sui::transfer;
    use sui::tx_context::{Self, TxContext};
    use std::string;

    /// Struct representing an NFT
    struct MyNFT has key {
        id: UID,
        name: string::String,
        uri: string::String,
    }

    /// Mint an NFT and transfer it to the sender
    public entry fun mint(
        ctx: &mut TxContext,
        name: string::String,
        uri: string::String
    ) {
        let nft = MyNFT {
            id: object::new(ctx),  // Generate a unique ID
            name,
            uri,
        };
        transfer::transfer(nft, tx_context::sender(ctx));
    }
}

Erstellung und Übertragung einzigartiger Vermögenswerte (z. B. Sammlerstücke) als unabhängige Objekte unter Nutzung der objektzentrierten Flexibilität von Sui. Aufgrund dieser Unterschiede müssen Entwickler den Code anpassen, was sich auf die Entwicklungszeit und die Interoperabilität des Ökosystems auswirkt.

Datenspeicherung: Objektzentrierte oder kontobasierte Modelle

Einer der wichtigsten Unterschiede besteht in der Datenspeicherung. Sui verwendet ein objektzentriertes Modell, bei dem jedes Asset (z. B. Token, NFTs) ein Objekt mit Metadaten, Eigentum und Berechtigungen ist, das in der Kette mit eindeutigen IDs gespeichert wird ([Objektmodell | Sui-Dokumentation](Das https://docs.sui.io/concepts/object-model)).This Modell ermöglicht parallele Statusaktualisierungen, wodurch die Zusammensetzbarkeit und Gaseffizienz verbessert werden, da Transaktionen oft nur eine Ledger-Aktualisierung erfordern (z. B. aktualisiert die Übertragung eines Objekts seinen Status, nicht mehrere Konten).

Aptos hingegen verwendet ein kontobasiertes Modell, ähnlich wie Ethereum, bei dem Konten eigene Ressourcen im globalen Speicher besitzen, sodass Aktualisierungen sowohl der Absender- als auch der Empfängerkonten pro Transaktion erforderlich sind (Aptos vs. Sui - The Tie).

Näher an EVM oder SVM?

Die Frage, ob Aptos EVM (Ethereum Virtual Machine) näher steht und Sui SVM (wahrscheinlich Solana Virtual Machine) näher steht, bedarf einer Klärung. Das kontobasierte Modell von Aptos entspricht dem von EVM und aktualisiert den Kontostatus pro Transaktion, sodass es Ethereum-Entwicklern vertraut ist (Aptos vs. Sui: Vergleich zweier wachsender Layer-1-Blockchains).

Das objektzentrierte Modell von Sui ist jedoch einzigartig und nicht direkt vergleichbar mit SVM, das wie Solana auf Konten basiert. Einige Entwickler argumentieren, dass Sui Solana in Bezug auf Skalierbarkeit ähnelt, aber hier geht es mehr um Leistung als um Datenmodelle. Man kann also mit Fug und Recht sagen, dass Aptos EVM näher ist, während das Modell von Sui anders ist und nicht mit SVM übereinstimmt, was die Analogie in Frage stellt.

Universalpakete: Kompatibilität und Barrieren

Angesichts ihrer gemeinsamen Ursprünge würde eine ideale Interoperabilität universelle Pakete beinhalten. Untersuchungen deuten jedoch darauf hin, dass solche Pakete nicht existieren, da Unterschiede in den Standardbibliotheken und Datenmodellen Hindernisse darstellen.

Beispielsweise würde ein Paket, das Aptos_coin von Aptos verwendet, auf Sui nicht funktionieren, ohne es für sui: :coin (GitHub - pentagonxyz/movemate: Bibliothek mit Modulbausteinen für Move) umzuschreiben. Zu den Hindernissen gehören plattformspezifische APIs, Objekt- und Kontenmodelle und unterschiedliche VM-Implementierungen, sodass eine nahtlose Kompatibilität ohne signifikante Anpassungen unwahrscheinlich ist.