piplabs/story v1.6.0

Story v1.6.0

on GitHub

This release introduces Distributed Key Generation (DKG) and Confidential Data Rails (CDR) to the Aeneid testnet — Story's foundation for on-chain confidential data management.

DKG enables a committee of validators to collectively generate and manage threshold cryptographic keys inside TEE enclaves, where no single validator ever holds the complete key. The committee operates in epochs with automatic rotation and proactive resharing, ensuring key continuity even as validators join or leave.

CDR is the user-facing protocol built on top of DKG. It provides a complete confidential data lifecycle on-chain — users encrypt data against the committee's public key, store it in on-chain vaults, and authorized parties request threshold decryption where each committee member contributes a partial decryption from their enclave. The plaintext is never exposed on-chain; only the requester can reconstruct it locally.

Distributed Key Generation (DKG)

The DKG protocol proceeds through a structured sequence of rounds — registration, dealing, response, finalization — coordinated automatically by the chain. Once the committee reaches agreement, a global public key is established and the network is ready to process encryption and decryption requests.

Key capabilities included in this release:

• Committee formation and key generation — Validators register their enclaves on-chain, exchange cryptographic material through consensus, and collectively finalize a shared key.
• Epoch-based committee rotation — DKG operates in epochs. Each epoch has its own round, its own committee, and its own set of key shares. At the end of each epoch, the committee is refreshed through a resharing process: the new committee takes over the key shares while the global public key stays the same. This means data encrypted in one epoch can still be decrypted in future epochs, even as validators join or leave.
• On-chain upgrade coordination — When a new version of the enclave software is needed, the upgrade can be scheduled and activated on-chain, with a transition window where both old and new versions are supported simultaneously.
• Committee rewards — Active committee members earn rewards for their participation in key generation and decryption services.

Confidential Data Rails (CDR)

The flow works as follows:

1. A user allocates a vault on-chain and encrypts their data using the committee's public key.
2. To read the data back, the user submits a decryption request on-chain.
3. Each committee member independently computes a partial decryption inside their secure enclave and submits it to the chain.
4. Once enough partials are collected (meeting the threshold), the user retrieves them and reconstructs the plaintext locally — the plaintext is never exposed on-chain.

Each partial decryption is encrypted specifically to the requester's key, so only the requester can use it. The chain verifies each submission before accepting it, and late or invalid submissions are rejected.