Sui Move Intro Course

repository·main·Indexed 25 days ago

https://github.com/sui-foundation/sui-move-intro-course

An introductory educational course maintained by the Sui Foundation for the Move programming language tailored for the Sui blockchain. The curriculum covers environment setup, Sui objects, fungible tokens, marketplace contracts, Sui Kiosk, Programmable Transaction Blocks, and advanced topics such as BCS encoding.

Tokens
22.5K
Snippets
73
Records
120
Agent score
83%

What's inside sui-move-intro-course

  1. Overview of the Move Intro Course

    main
    The Move Intro Course is an educational resource maintained by the Sui Foundation designed to teach the Move programming language. The course is structured into progressive units covering everything from environment setup to advanced topics like BCS encoding and Sui Kiosk.
  2. Use the `Bag` type for heterogeneous collections

    main
    In Sui Move, use the Bag type when you need a map-like collection that holds objects of different types, or when the types are not known at compile time. Unlike Vector or Table, which are homogeneous, a Bag allows for heterogeneous key-value pairs. The Bag struct acts as a handle to the Sui object system, where keys and values are stored as objects rather than within the Bag value itself.
  3. Understand Sui Kiosk components and architecture

    main

    Sui Kiosk is a decentralized system for onchain commerce on Sui. It is composed of two primary shared object components that manage asset storage and trade conditions:

    • Kiosk + KioskOwnerCap: The Kiosk acts as a shared safe that stores assets and displays them for sale. The person holding the KioskOwnerCap is the Kiosk Owner, maintaining logical ownership of the assets even when they are physically stored within the kiosk.
    • TransferPolicy + TransferPolicyCap: The TransferPolicy is a shared object that defines the rules and conditions for trading assets. Rules (such as royalty fee requirements) can be enabled or disabled by the holder of the TransferOwnerCap.
  4. Identify user roles in Sui Kiosk

    main

    Sui Kiosk operations are categorized into three user roles:

    • Kiosk Owner (Seller/KO): Holds the KioskOwnerCap. They can place assets in the kiosk, withdraw non-locked assets, list assets for sale, withdraw sales profits, and borrow/mutate owned assets.
    • Buyer: Any user attempting to purchase listed items. A successful trade requires the buyer to satisfy the requirements defined in the TransferPolicy.
    • Creator: The party that creates and controls the TransferPolicy for a specific type (e.g., a specific NFT collection). Creators can set rules, manage multiple rule tracks, enable/disable trades via policy, and enforce royalties globally.
  5. Learn Sui Kiosk and Programmable Transaction Blocks (Unit Five)

    main
    Unit Five of the Sui Move Intro Course provides instruction on advanced Sui features including Programmable Transaction Blocks (PTBs), the 'hot potato' design pattern, Sui Kiosk fundamentals, and Transfer Policies. The unit is divided into five specific lessons covering these topics.
  6. Understand Programmable Transaction Blocks (PTB)

    main

    A Programmable Transaction Block (PTB) is a native feature of the Sui Network and Sui VM that allows developers to batch multiple individual commands into a single atomic transaction. This enables high composability and scalability by allowing the output of one command to be used as the input for a subsequent command within the same block.

    Key Features:

    • Chaining Commands: PTBs are composed of multiple commands (such as MoveCall) executed in order.
    • Atomicity: If any single command within the PTB fails, the entire transaction fails, and no effects are applied to the blockchain.
    • Scalability: A single PTB can contain up to 1024 unique operations, reducing gas fees and latency compared to sequential individual transactions.
    • Resource Management: If a command returns a non-drop value, that value must be consumed by a subsequent command within the same PTB, or the transaction will fail.
  7. Understand Dynamic Fields vs. Dynamic Object Fields

    main

    Sui Move provides two ways to attach heterogeneous fields to an object at runtime:

    1. Dynamic Fields (sui::dynamic_field):

      • Can store any value with the store ability.
      • Values are considered wrapped. They are not directly accessible via their ID by external tools like explorers or wallets.
      • Use these when the child type does not need the key ability.
    2. Dynamic Object Fields (sui::dynamic_object_field):

      • Values must be Sui objects (must have key and store abilities, and id: UID as the first field).
      • Values remain directly accessible via their object ID even after being attached to a parent.
      • Use these when the child is a Sui object that needs to be independently addressable.
  8. Create a new Kiosk

    main

    You can create a new Kiosk using two different methods. A Kiosk is a shared object, and the owner receives a KioskOwnerCap to manage it.

    Method 1: Custom Implementation

    Deploy a contract that calls kiosk::new(ctx), shares the Kiosk object via transfer::public_share_object, and transfers the KioskOwnerCap to the sender via transfer::public_transfer.

    Method 2: Using kiosk::default()

    Use the entry kiosk::default() function to automatically handle the creation, sharing of the Kiosk, and transfer of the KioskOwnerCap in one step.

    To interact via the CLI, use:

    sui client call --package $KIOSK_PACKAGE_ID --module kiosk --function new_kiosk

    After creation, export the resulting object IDs for subsequent operations:

    export KIOSK=<Object id of newly created Kiosk>
    export KIOSK_OWNER_CAP=<Object id of newly created KioskOwnerCap>
  9. Define and emit custom events in Sui Move

    main

    Custom events allow indexers to track specific on-chain actions. When defining custom events, follow these conventions:

    1. Naming: Use past tense for event names (e.g., TranscriptRequested) because they describe actions that have already occurred.
    2. Abilities: Event types must have the copy and drop abilities. They are not assets; they are used solely for data logging.
    3. Emission: Use the sui::event::emit method to trigger the event.

    Example of defining and emitting a custom event:

    // 1. Define the event struct with copy and drop abilities
    public struct TranscriptRequested has copy, drop {
        wrapper_id: ID,
        requester: address,
        intended_address: address,
    }
    
    // 2. Emit the event within a function
    public fun request_transcript(
        transcript: WrappableTranscript,
        intended_address: address,
        ctx: &mut TxContext,
    ) {
        let folder_object = Folder {
            id: object::new(ctx),
            transcript,
            intended_address,
        };
    
        event::emit(TranscriptRequested {
            wrapper_id: object::id(&folder_object),
            requester: ctx.sender(),
            intended_address,
        });
    
        transfer::transfer(folder_object, intended_address);
    }
    public struct TranscriptRequested has copy, drop {
        wrapper_id: ID,
        requester: address,
        intended_address: address,
    }
    
    public fun request_transcript(
        transcript: WrappableTranscript,
        intended_address: address,
        ctx: &mut TxContext,
    ) {
        let folder_object = Folder {
            id: object::new(ctx),
            transcript,
            intended_address,
        };
    
        event::emit(TranscriptRequested {
            wrapper_id: object::id(&folder_object),
            requester: ctx.sender(),
            intended_address,
        });
    
        transfer::transfer(folder_object, intended_address);
    }