☁️
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
  • Problem Statement
  • Chain Hashing Mechanism
  • Chain Hash Calculation Code
  • Process Flow Diagrams
  1. System
  2. Storage
  3. Protocol
  4. Write Markers

Chain Hashing

Chain Hashing in Write Markers is a mechanism designed to enhance the efficiency and security of data verification and payment settlement on the blockchain. Instead of submitting individual Write Markers sequentially—which increases transaction costs and slows down processing speeds—blobbers create a chain of Write Markers. This chain is verified using cryptographic hashing, ensuring data correctness and reducing blockchain congestion.

Problem Statement

Blobbers must submit Write Markers to the blockchain to prove they have stored a specific amount of data. This proof is essential for:

  • Enabling challenges that verify data integrity.

  • Processing payments for storage services.

  • Maintaining an auditable record of data transactions.

However, submitting each Write Marker individually introduces inefficiencies:

  1. High Blockchain Transaction Costs

    • Each Write Marker submission incurs a gas fee, making frequent submissions expensive.

  2. Increased Blockchain Load

    • Processing multiple individual transactions burdens the network, slowing down other operations.

  3. Slower Processing & Payment Verification

    • Storing and validating each Write Marker separately delays payment settlements for blobbers.

To address these challenges, the Chained Write Marker Structure enables blobbers to aggregate multiple Write Markers into a single submission transaction, reducing overhead and improving efficiency.

Chain Hashing Mechanism

The Chained Write Marker Structure is based on cryptographic hashing to ensure the integrity of stored data while reducing the blockchain footprint.

1. Chaining Write Markers

Each Write Marker contains a Chain Hash, which is computed as:

Chain Hash = SHA-256(Previous Chain Hash || Allocation Root)

Where:

  • Previous Chain Hash: The hash of the last committed Write Marker.

  • Allocation Root: The unique root hash representing the current allocation state.

Initial Condition: If no previous Write Marker exists (i.e., for the first marker in the chain), the Allocation Root alone is used.

2. Submission Process

  1. The blobber accumulates up to 128 uncommitted Write Markers.

  2. The latest Write Marker is submitted along with the allocation roots of all uncommitted markers.

  3. The blockchain computes the chain hash using the stored previous marker and verifies the integrity of the entire chain.

  4. Once verified, the new Write Marker is appended to the chain, making it an auditable, tamper-resistant record.

3. Cryptographic Verification

The Write Marker Signature Payload includes:

  • Chain Hash (to maintain link integrity).

  • Previous Chain Hash (to establish sequential proof).

  • Chain Size (ensuring proper aggregation).

  • Allocation Root (tracking the latest storage state).

  • Previous Allocation Root (for validation).

  • Client ID and Blobber ID (ensuring authenticity).

  • Timestamp (preventing replay attacks).

  • Allocation ID (linking to the correct storage allocation).

  • Write Marker Size (preventing data tampering).

  • File Meta Root (ensuring metadata integrity).

The blockchain and validators perform rigorous checks to validate:

  1. The correctness of the chain hash using SHA-256.

  2. The integrity of chain size to prevent tampering.

  3. The validity of the user signature, ensuring the Write Marker is authentic.

If any inconsistency is detected (e.g., mismatched chain hash or incorrect chain size), the blobber's submission is rejected.

Chain Hash Calculation Code

Below is the implementation for computing the Chain Hash:

import (
    "crypto/sha256"
    "encoding/hex"
)

func CalculateChainHash(prevChainHash, newRoot string) string {
    hasher := sha256.New()
    if prevChainHash != "" {
        prevBytes, _ := hex.DecodeString(prevChainHash)
        hasher.Write(prevBytes) //nolint:errcheck
    }
    newBytes, _ := hex.DecodeString(newRoot)
    hasher.Write(newBytes) //nolint:errcheck
    return hex.EncodeToString(hasher.Sum(nil))
}

If a previous chain hash exists, it is included in the calculation. The new allocation root is hashed along with it. The resulting SHA-256 digest is returned as the new chain hash.

Process Flow Diagrams

1. Chaining Process

This sequence diagram represents how Write Markers are chained together.

Each Write Marker carries the previous chain hash. The chain size grows cumulatively, ensuring an ordered record. The final marker is submitted to the blockchain for validation.

2. Verification Process

This flow illustrates how blockchain validation ensures correctness.

  1. The blobber submits the latest Write Marker Chain.

  2. The Blockchain compute Chain hash and verify Chain size

  3. If it is valid, the blockchain accepts and if it is invalid, the blockchain rejects.

The Chained Write Marker Protocol is a critical efficiency improvement in decentralized storage, ensuring faster, cheaper, and more secure Write Marker submissions.

By using chain hashing and batch processing, blobbers can optimize storage operations, improve payment turnaround times, and maintain data integrity on the blockchain.

PreviousWrite MarkersNextTwo Commit

Last updated 1 month ago