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