☁️
Zus Docs
  • About Züs
  • System
    • Providers and Services
      • Miner
      • Sharder
      • Blobber
      • Validator
      • Authorizer
      • Node Locator (0DNS)
    • Storage
      • Architecture and Data Management
      • Protocol
        • Allocations
        • Reference Objects
        • Challenges
        • Write Markers
          • Chain Hashing
          • Two Commit
        • Blobber Repair Protocol
      • ZS3 Server
        • Backup, Recovery and Replication
        • Encryption and Compression
        • S3FS Setup and Usage
        • Backup & Recovery with Restic on Blimp + ZS3 Server
        • Backup & Recovery with Veeam on Blimp + ZS3 Server
      • File Operations
        • Upload
        • Download
        • File Sharing
        • Partial Error Recovery
        • Streaming
        • Rent a Blobber
    • Smart Contracts
      • Storage S.C.
      • Miner S.C.
      • ZCN S.C.
      • ERC-20 S.C.s
      • Bridge Protocol
    • Blockchain & Consensus
      • Entities
    • User Authentication and Wallet Management System
      • OKTA Integration
      • Key Management System (KMS)
  • APIs
    • 0DNS API
    • JS API
    • Mobile API
  • CLIs
    • Storage CLI
      • Quickstart
      • Configuring the tool
    • Wallet CLI
      • Wallet Configuration
      • Quickstart
      • Configuring the tool
  • SDKs
    • Go SDK
      • GO SDK Microservices
    • JS SDK
  • Tokenomics
    • Staking
    • Reward & Penalty
  • ✨Züs Apps
    • 🗝️Vult
      • Getting Started
        • Web
        • Mobile
      • Vult AI
        • Batch Processing
        • Memory Retention
        • Technical Implementation
        • Architecture Overview
      • Login / Register
      • File Management Pages
      • File Sharing
      • Storage Management Dashboard
      • Storage Maintenance and Troubleshooting
      • Züs Subscription
      • Wallet Management
      • Refer a friend
      • Settings
    • 🏗️Blimp
      • Getting Started
      • Login / Register
      • Configure Storage
        • Create Standard Storage Allocation
        • Create Enterprise Allocation
        • Create S3 Server Allocation
        • Create Cloud Migration Allocation
        • Allocation Maintenance and Troubleshooting
      • File Management Pages
      • File Sharing
      • Manage Allocations
      • Upgrade Storage
      • Blimp Vault
      • Refer a friend
      • Settings
      • Launching ZS3 Server
      • Using CLI to backup files into Blimp + ZS3 Server
    • 🏠Chimney
      • Getting Started
      • Login / Register
      • Create New Deployment
      • Manage Your Deployments
      • Homepage
      • Staking Dashboard
      • Rank Dashboard
      • Monitor Dashboard
      • Stats Dashboard
      • Logs Dashboard
      • Wallet Dashboard
      • Operations on your Deployments
      • Restricted Blobbers
      • Settings
        • Manage Profile
        • Wallet Settings
        • Update Blobber Settings
        • Update Blobber Version
        • Refer a friend
        • Help
    • 🌐Atlus
      • Getting Started
      • Home page
      • Service Providers Page
      • Charts Page
        • Market Charts
        • Network Charts
        • Storage Charts
      • Blockchain Page
      • Server Map Page
      • Storage Explainer Page
      • Details Pages
        • Block Details Page
        • Transaction Details Page
        • Wallet Details Page
        • Miner Details Page
        • Sharder Details Page
        • Blobber Details Page
        • Validator Details Page
        • Authorizer Details Page
        • Allocation Details Page
      • Appendix: Common Components
    • ⚡Bolt
      • Getting Started
        • Web
        • Mobile
      • Login / Register
      • Sign In with external wallet
      • Staking Dashboard
      • Staking/Unstaking a provider
      • Claiming Rewards
      • Send/Receive ZCN tokens
      • Buy ZCN
      • Deposit/Withdraw ZCN tokens
      • Activity Dashboard
      • Refer a friend
      • Settings
  • Releases
    • Hardfork
Powered by GitBook
On this page
  • Purpose of Write Markers
  • Structure
  • How Write Markers Work
  • Key Token Pools
  • Challenge Protocol
  • Stake Pools and Penalties
  • Write Marker Example
  1. System
  2. Storage
  3. Protocol

Write Markers

Write markers play a critical role in the Züs decentralized storage system, acting as a proof of data uploads and ensuring blobbers are compensated for storing data over time. Through write markers, Züs links the compensation of blobbers to their performance, verified through storage challenges, ensuring data integrity and decentralized storage management.

This section provides an in-depth explanation of how write markers function within the Züs ecosystem, ensuring secure, decentralized, and efficient storage management.

Purpose of Write Markers

Write markers serve several important purposes in the Züs ecosystem:

  • Proof of Data Storage: They provide verifiable proof that data has been uploaded and stored with the blobber.

  • Payment Commitment: Blobbers use write markers to claim rewards for storage. Payment occurs over time, based on the successful completion of storage challenges.

  • Incentivizing Blobber Performance: Payments are released only after the blobber passes storage challenges, ensuring they maintain proper data storage practices.

Structure

type WriteMarker struct {
    AllocationRoot         string `json:"allocation_root"`
    PreviousAllocationRoot string `json:"prev_allocation_root"`
    FileMetaRoot           string `json:"file_meta_root"`
    AllocationID           string `json:"allocation_id"`
    Size                   int64  `json:"size"`
    ChainSize              int64  `json:"chain_size"`
    ChainHash              string `json:"chain_hash"`
    ChainLength            int    `json:"chain_length"`
    BlobberID              string `json:"blobber_id"`
    Timestamp              int64  `json:"timestamp"`
    ClientID               string `json:"client_id"`
    Signature              string `json:"signature"`
}

How Write Markers Work

  1. Creating an Allocation:

    • A client initiates a storage contract by creating an allocation with one or more blobbers. This allocation defines:

      • Storage Size: How much space the client requires.

      • Pricing: The price the client is willing to pay for reads and writes.

      • Duration: How long the client needs the storage.

    • The client also sets up a write pool, which contains tokens that will be used to pay the blobbers for storage.

  2. Uploading Data:

    • During an upload, the client sends data to the blobber along with a write marker.

    • A write marker includes:

      • File Size: The size of the file being uploaded.

      • Allocation ID: The unique identifier for the storage allocation.

      • Merkle Root Hash: A cryptographic hash to verify data integrity.

      • Timestamp: The time of the upload.

    • The blobber stores the data and commits the write marker to the blockchain.

  3. Blockchain Interaction:

    • After receiving the write marker, the blobber submits it to the blockchain. This action:

      • Locks tokens from the client’s write pool into the challenge pool.

      • Represents a public commitment by the blobber to store the data.

    • Blobbers are not immediately paid. Tokens in the challenge pool are released gradually as blobbers pass storage challenges.

Key Token Pools

Write Pool:

The client’s write pool holds tokens designated to pay blobbers for storing data. Tokens are transferred from the write pool to the challenge pool as data is uploaded. Any unused tokens are returned to the client if the allocation is canceled.

Challenge Pool:

Tokens in the challenge pool serve as a financial guarantee that blobbers will store data correctly. Blobbers earn these tokens over time by passing challenges that verify they are storing the client’s data as agreed.

Challenge Protocol

The challenge protocol ensures that blobbers are continuously storing data as per their agreement. Here’s how it works:

  1. Random Challenges: The blockchain periodically issues random challenges to blobbers, asking them to provide proof that they still have the data.

  2. Responding to Challenges: Blobbers must respond by submitting the requested data within a specific timeframe. If the blobber passes the challenge, they receive a portion of the tokens from the challenge pool.

  3. Failed Challenges: If the blobber fails to respond or provides incorrect data, they forfeit the payment for that challenge period. Additionally, the blobber may be penalized by having tokens deducted from their stake pool.

Stake Pools and Penalties

To further incentivize blobbers to maintain proper storage practices, Züs requires them to lock tokens in a stake pool. The stake pool serves as a financial safety net in case the blobber fails to meet their obligations.

  • Stake Pool: Blobbers (and optionally, their delegates) lock tokens into a stake pool to back their storage capacity.

  • Staked Capacity: The amount of storage a blobber can offer is proportional to the tokens they’ve locked in their stake pool. If they have insufficient tokens, they cannot offer storage.

  • Penalties: If a blobber fails a challenge, they are penalized by having tokens deducted from their stake pool. This penalty serves to further ensure that blobbers act responsibly and maintain data integrity.

Write Marker Example

Step 1: Setting Up an Allocation

  • A client creates a storage allocation for 100 GB of data, with the total cost of storage set at 100 ZCN for a 1-year duration. The client funds the write pool with 100 ZCN.

Step 2: Uploading Data

  • The client uploads 50 GB of data to the blobber. A write marker is generated for the upload, containing:

    • The Allocation ID identifying the contract.

    • The Merkle Root Hash proving the integrity of the 50 GB file.

    • A Timestamp marking when the file was uploaded.

  • The blobber stores the file and commits the write marker to the blockchain. At this point, 50 ZCN (proportional to the uploaded data) is locked into the challenge pool.

Step 3: Challenge Process

  • Over the course of the next year, the blobber faces periodic challenges from the blockchain. For each challenge, the blobber must submit fragments of the stored file.

  • If the blobber passes a challenge, they receive a portion of the 50 ZCN locked in the challenge pool.

Step 4: Penalty for Failing a Challenge

  • After 6 months, the blobber fails a challenge. As a result:

    • They lose the ZCN that would have been released from the challenge pool.

    • They are penalized 10% of their stake pool balance.

Step 5: Completion of Allocation

  • At the end of the year, if the blobber has passed the remaining challenges, they receive the remaining ZCN from the challenge pool. The allocation expires, and the client can either renew or delete their data.

PreviousChallengesNextChain Hashing

Last updated 1 month ago