Write Markers
Last updated
Last updated
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.
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.
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"`
}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.
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.
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.
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.
The challenge protocol ensures that blobbers are continuously storing data as per their agreement. Here’s how it works:
Random Challenges: The blockchain periodically issues random challenges to blobbers, asking them to provide proof that they still have the data.
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.
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.
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.
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.