🌱
Dev Compendium
  • Ethereum
    • Solidity
      • EVM
      • Architecture
      • Execution Context
      • Transactions
      • Gas
      • Calldata, Memory & Storage
      • Gas Optimisation
      • Function Declarations
      • receive() & fallback()
      • CALL vs. DELEGATE CALL
    • Yul
      • Introduction
      • Types
      • Basic Operations
      • Storage
      • Memory
        • Arrays
        • Structs
        • Tuples, revert, keccak256
        • Logs and Events
        • Gotchas
        • abi.encode
      • Calldata
        • External Calls
        • Dynamic Length Inputs
        • Transferring Value
        • Receiving Contract Calls
      • Contracts in Yul
      • Other Yul Functions
    • Foundry
    • Security
      • Common Vulnerabilities
      • Best Practices
      • Development Workflow
      • Contract Migration
    • Auditing Tools
      • Slither
      • Mythril
      • Fuzzing
    • Upgradable Contracts
      • Upgrade Patterns
      • ERC-1967 Implementation
      • Deployment
    • MEV
    • Tooling
      • Chainlink
      • IPFS
      • Radicle
    • Frontend
      • Contract Hooks
      • Wallet Connection
        • wagmi.sh
        • Rainbow Kit
      • thirdweb
    • Protocol Research
      • Uniswap v2
      • Uniswap v3
      • Curve
      • GMX
  • Starkware
    • Fundamentals
    • Account Abstraction
    • Universal Deployer
    • Cairo 1.0
    • starknet.js
    • Security Model
  • Zero Knowledge
    • Group Theory
    • ECDSA
  • Rust
    • Basic Operations
    • Set up
    • Primitives
    • Control Flow
    • Mutability & Shadowing
    • Adding Behavior
    • Lifetimes
    • Std Library
  • SUI
    • Architecture
    • Consensus Mechanism
    • Local Node Setup
    • Sui Client CLI
    • Move Contracts
      • Move
      • Move.toml
      • Move.lock
      • Accessing Time in Sui Move
      • Set up Development Framework
      • Debug & Publish
      • Package Upgrades
      • Sui Move Library
      • Difference from Core Move
    • Object Programming
      • Object Basics
      • Using Objects
      • Immutable Objects
      • Object Wrapping
      • Dynamic Fields
      • Collections
      • Unit Testing
      • Deployment with CLI
  • NEAR
    • Architecture
    • Contract Standards
      • Fungible Token (NEP-141)
      • Non-Fungible Token (NEP-171)
      • Storage Management (NEP-145)
      • Events (NEP-297)
      • Meta-Transactions
    • Rust Contracts
      • Development Workflow
      • Smart Contract Layout
      • Storage Management
      • Events & Meta-transactions
      • Method Types
      • Upgrading Contracts
      • Unit Testing
    • NEAR Libraries
    • Environment Variables
    • Serialisation
    • Security Concepts
    • Collections
    • JS SDK
Powered by GitBook
On this page
  1. SUI

Architecture

PreviousStd LibraryNextConsensus Mechanism

Last updated 1 year ago

There are three different types of objects (in Sui):

  • owned objects

  • shared objects

  • immutable objects

Owned objects are objects which belong to users. Only the user who owns the object can use it in a transaction. The ownership metadata is fully transparent and handled by the runtime. It’s implemented using public key cryptography — each owned object is associated with a public key (stored in the object’s metadata in the runtime) and anytime you want to use an object in a transaction, you need to provide the corresponding signature (Ed25519 is supported now with ECDSA and K-of-N multisig support coming soon).

Shared objects are similar to owned objects but they don’t have an owner associated with them. Therefore you don’t have to possess any private keys to be able to use them in a transaction (anyone can use them). Any owned object can be shared (by its owner) and once an object is shared it will forever remain shared — it can never be transferred or become an owned object again.

Immutable objects are objects which cannot be mutated. Once an object has been marked immutable, its fields can never again be modified. Similar to shared objects, these don’t have an owner and can be used by anyone.

Horizontal Scaling

On the Sui network, each group of transactions process in parallel, as opposed to the bottlenecking that occurs in some earlier blockchains due to any lack of distinction between the various objects, resources, accounts, and other components.

Composability

In Sui, unlike most other blockchains, one can directly pass an asset (such as an NFT), directly into a function argument. Sui’s object-centric approach also allows for more esoteric data structures, and the ability to store assets inside such data structures, or in an asset itself.

Sparse Replay

Naturally, a blockchain provides a ledger of every single transaction. For a Sui-specific example, game builders don’t need to track transactions interacting with unrelated dApps. Because querying on-chain data can be expensive, products on Sui will be able to follow the evolution of the objects in this game, without digging out the data from the .

Merkle tree