Walrus Documentation

repository·main·Indexed 18 days ago

https://github.com/mystenlabs/walrus

A decentralized blob store utilizing the Sui blockchain for coordination and governance. This documentation covers the Walrus Upload Relay, the orchestrator CLI for geo-distributed deployments, performance testing with k6-tests, and setting up local testbeds using Docker Compose.

Tokens
195.5K
Snippets
507
Records
882
Agent score
64%

What's inside Walrus

  1. Overview of Walrus Testnet Move contracts

    main
    This repository contains the Move source code used by the current Walrus Testnet instance. These contracts are deployed on the Sui Testnet. To find the specific version information for the currently deployed contracts, refer to the walrus/Move.lock file.
  2. Overview of Walrus Decentralized Storage

    main

    Walrus is a decentralized storage and data availability protocol designed for blockchain applications and autonomous agents. It uses erasure coding to split unstructured data blobs into smaller "slivers" distributed across a network of storage nodes.

    Key characteristics:

    • High Robustness: Data can be reconstructed even if up to two-thirds of the slivers are missing.
    • Efficient Replication: Maintains a low replication factor (4x-5x) compared to traditional blockchain state replication (100x+).
    • Scalability: Powered by the Sui Network and designed to scale horizontally to thousands of nodes.
    • Use Cases: Ideal for NFT media, AI training datasets, blockchain history archival, L2 data availability, and hosting decentralized web content (HTML/JS/CSS).
  3. Overview of Walrus Python Example Scripts

    main

    The Python examples directory contains scripts demonstrating different ways to interact with Walrus:

    • hello_walrus_jsonapi.py: Demonstrates storing and reading blobs using the Walrus client's JSON API.
    • hello_walrus_webapi.py: Demonstrates storing and reading blobs using the Walrus client's HTTP API.
    • track_walrus_events.py: A utility script used to track all Walrus-related events occurring on the Sui network.
  4. Identify Walrus service provider roles

    main

    Walrus infrastructure is composed of several distinct service provider roles. Depending on your hardware and operational goals, you can choose to operate one or more of the following:

    • Storage Nodes: Responsible for hosting and maintaining the actual data shards.
    • Aggregators: Responsible for aggregating data/shards.
    • Publishers: Responsible for publishing data to the network.

    Refer to the specific guides for each role to understand their individual requirements and setup procedures.

  5. Changes in Walrus v1.47.1

    main

    Walrus v1.47.1 introduces several improvements to storage node and aggregator behavior:

    • Storage Pool Support: Enables storage pool support within the storage node.
    • Improved Error Handling: The aggregator now returns a retryable HTTP 503 BLOB_UNAVAILABLE instead of a 500 error when a blob is only temporarily unretrievable. This allows clients to implement retry logic more effectively.
    • Enhanced Range Requests: When reading by object ID, blob attribute headers such as Content-Type are now correctly included in range requests.
  6. New features in Walrus v1.38.2

    main

    Walrus v1.38.2 (Testnet build) introduces several performance improvements and new API capabilities:

    • Performance: Major memory-usage reductions across the aggregator, publisher, and CLI.
    • Latency: Reduced upload latency.
    • New APIs:
      • Byte-range read API.
      • Alpha /v1alpha/blobs/concat endpoint.
    • Deprecations:
      • The get_recovery_symbol endpoint has been removed.
  7. New features in Walrus v1.38.3

    main

    Walrus v1.38.3 introduces several performance improvements and new API capabilities:

    • Performance: Significant memory-usage reductions in the aggregator, publisher, and CLI.
    • Latency: Lower upload latency achieved by reducing the number of Sui RPC requests.
    • New API - Byte-range reads: A new API for reading specific byte ranges of blobs.
    • New API - Blob concatenation: An alpha /v1alpha/blobs/concat endpoint is now available.
    • Deprecation: The long-unused get_recovery_symbol endpoint has been removed.
  8. What is the Walrus Upload Relay and when should I use it?

    main

    An upload relay is a server-side service that simplifies the blob upload process by handling the complexity of writing to multiple storage nodes on behalf of your application. Instead of your client making many parallel requests to different storage nodes (potentially 10+), you make a single request to the relay.

    When to use the relay

    • Web applications in browsers: Removes the need for a browser to maintain dozens of outbound connections. The relay handles encoding, sliver uploads, and certificate collection via a single POST to /v1/blob-upload-relay.
    • Low-powered or mobile devices: Reduces the networking and compute burden on the client.
    • High-volume backend uploads: Centralizes the work of encoding and confirmation aggregation.
    • Simplified error handling: Collapses complex node-level failures into a single response, making application code easier to maintain.

    When NOT to use the relay

    • Server-side applications: If you require full control over the upload process, custom retry/error handling strategies, or want to avoid relay tip costs, you should use direct node communication.
  9. What is Quilt and when should I use it?

    main

    Quilt is a batch storage feature in Walrus designed to optimize the storage cost and efficiency of large numbers of small blobs. It encodes multiple blobs (up to 666 for QuiltV1) into a single unit called a quilt, significantly reducing Walrus storage overhead and lowering costs for Walrus/Sui storage and Sui computation gas fees.

    When to use Quilt

    Use Quilt when:

    • You have many small blobs that can be grouped into batches (e.g., AI agent memory, conversation turns, embeddings, or NFT collections).
    • The items in a batch share a similar lifetime (you can store, extend, and retire them together).
    • You want individual retrieval of items and the use of Walrus-native metadata (identifiers and tags) without paying the full per-blob overhead for every single item.

    When to use a regular blob instead

    Use a regular blob when:

    • An item is large (approaching or exceeding the per-blob size limit).
    • Items require independent lifetimes (you need to delete, extend, or share an item on its own schedule, as these operations apply to the entire quilt).
    • You require a content-derived BlobId (items in a quilt are addressed by a QuiltPatchId which depends on the composition of the entire quilt).
  10. Manage Site Name and Object ID

    main

    Site Name

    Set the site name using the site_name field. If the --site-name CLI flag is used during deployment, it takes priority and overwrites the value in ws-resources.json.

    Site Object ID

    The object_id field stores the Sui object ID of your deployed site.

    • For Updates: The site-builder deploy command uses this field to identify an existing site. If a valid object_id is present, deploy updates that site.
    • For New Sites: If object_id is missing and no --object-id flag is provided, deploy publishes a new site and automatically populates the object_id in your ws-resources.json.

    Caution: Do not delete ws-resources.json after your first deployment. If it is missing during a subsequent deployment, the site-builder will create a brand new site object instead of updating your existing one.

  11. Understand the Walrus blob storage response

    main

    The HTTP API returns different JSON structures depending on whether the blob is being created for the first time or already exists.

    Newly created blobs

    If the blob is new, the response contains a newlyCreated field. This includes the blobObject (the Sui object representing the blob) and resourceOperation details.

    Already certified blobs

    If the publisher finds a certified blob with the same ID and sufficient validity, it returns an alreadyCertified structure. This contains the blobId, the endEpoch, and an event object containing the txDigest and eventSeq used to track the original transaction on Sui.

    Tip: If you are reading a blob immediately after upload via a CDN-fronted aggregator, you may encounter a brief 404 due to propagation delay. Implement a retry with backoff.

    # Example response for a newly created blob
    {
      "newlyCreated": {
        "blobObject": {
          "id": "0xe91eee8c5b6f35b9a250cfc29e30f0d9e5463a21fd8d1ddb0fc22d44db4eac50",
          "registeredEpoch": 34,
          "blobId": "M4hsZGQ1oCktdzegB6HnI6Mi28S2nqOPHxK-W7_4BUk",
          "size": 17,
          "encodingType": "RS2",
          "certifiedEpoch": 34,
          "storage": {
            "id": "0x4748cd83217b5ce7aa77e7f1ad6fc5f7f694e26a157381b9391ac65c47815faf",
            "startEpoch": 34,
            "endEpoch": 35,
            "storageSize": 66034000
          },
          "deletable": false
        },
        "resourceOperation": {
          "registerFromScratch": {
            "encodedLength": 66034000,
            "epochsAhead": 1
          }
        },
        "cost": 132300
      }
    }
    
    # Example response for an already certified blob
    {
      "alreadyCertified": {
        "blobId": "M4hsZGQ1oCktdzegB6HnI6Mi28S2nqOPHxK-W7_4BUk",
        "event": {
          "txDigest": "4XQHFa9S324wTzYHF3vsBSwpUZuLpmwTHYMFv9nsttSs",
          "eventSeq": "0"
        },
        "endEpoch": 35
      }
    }