Proof of Storage (Ziggy)

Hippius uses a zero-knowledge proof system called Ziggy to verify that miners actually hold the data they claim to store. It allows miners to cryptographically prove possession of specific data chunks without revealing the data itself.

The short version

1. When a file is uploaded, each shard is hashed into a Merkle tree and a commitment (the tree root) is stored
2. A Warden periodically challenges miners by asking them to prove they hold specific random chunks
3. The miner generates a STARK proof that their chunks match the original commitment
4. The Warden verifies the proof — if it fails, the miner's reputation is penalized

No data is ever revealed during this process. The proof is purely mathematical.

Cryptographic stack

Ziggy is built on three layers:

Layer	Technology	Purpose
Field arithmetic	BabyBear (p = 2³¹ - 2²⁷ + 1)	Fast finite-field math for proof generation
Hashing	Poseidon2 (width=16, 8 digest elements)	ZK-friendly hash function for Merkle trees
Proof system	Plonky3 STARK with FRI	Generates and verifies succinct proofs

How it works

1. Commitment phase (upload)

When a shard is stored on a miner, the system generates a commitment — a fingerprint of the data:

1. The shard is split into 1 KB chunks
2. Each chunk is hashed using Poseidon2
3. The hashes are assembled into a binary Merkle tree
4. The resulting commitment contains the merkle_root, chunk_count, and shard_hash

The Merkle root is sent to the Warden. The miner keeps the full tree cached for fast proof generation.

2. Challenge phase (audit)

Wardens run an audit loop (every 30 seconds) that selects shards round-robin and generates challenges:

1. A deterministic nonce is derived from BLAKE3(shard_hash || block_hash || warden_id)
2. The nonce seeds a PRNG that picks 4 random chunk indices
3. The challenge is sent to the miner with a 60-second deadline

The deterministic nonce ensures challenges are verifiable and non-repeatable.

3. Prove phase (miner response)

The miner receives the challenge and:

1. Reads the shard from disk
2. Retrieves the cached Merkle tree (or rebuilds it)
3. Extracts the challenged chunks and generates Merkle proofs for each
4. Produces a STARK proof that the chunks match the committed Merkle root
5. Sends the proof back to the Warden

4. Verify phase (Warden)

The Warden verifies:

1. The Merkle root in the proof matches the stored commitment
2. The chunk indices match the original challenge
3. The challenge hasn't expired
4. All Merkle proofs are valid
5. The STARK proof is sound

Audit results and reputation

Result	Meaning	Reputation penalty
Passed	Proof verified successfully	None
Failed	Proof verification failed	+1.0
Timeout	No response within 60 seconds	+0.3
Invalid Proof	Malformed or corrupt proof	+1.0

• At a reputation score of ≥ 3.0, a miner is banned from the cluster
• Successful proofs gradually recover reputation (+0.05 decay after 10 consecutive passes)

Security properties

Property	Mechanism
Soundness	STARK proofs guarantee the prover knows the chunk data at challenged indices
Freshness	Nonce + expiry + block hash prevent replay attacks
Privacy	Shard contents are never revealed — only mathematical possession is proven
Determinism	Same challenge inputs always produce the same indices, making audits verifiable