<
Back to arcticles
How We’re Building Penumbra
We’re building Penumbra, a fully shielded layer-1 network within the Cosmos ecosystem. Penumbra brings privacy to proof-of-stake, allowing users to transact, stake, swap, and marketmake without disclosing their personal information, account activity, or trading strategies to the entire world – while still permitting selective disclosure to appropriate parties.
Building the first fully shielded proof-of-stake blockchain is a challenge. Here’s our plan for how to do it.
Shielded blockchains use zero-knowledge proofs to allow public verification of private data. Because it’s somewhat incredible that this is possible at all, people often focus on zero-knowledge proofs as the primary distinction between shielded and transparent blockchains. However, there’s a much more important distinction at play in the state models.
In a transparent blockchain, all participants maintain a copy of the application state, and use a consensus algorithm to agree on batches of state changes (in the form of blocks containing transactions). Participants can examine each state change to check that it is allowed by the application rules, then apply the changes to the application state directly.
On a shielded blockchain, however, the state is fragmented across all the users of the application, with each user only having a view of their “local” state fragments, rather than the full global state. Instead of making a state change directly, transactions create new state fragments, invalidate old state fragments, and use a zero-knowledge proof to prove to all other participants that the transition from the old state to the new state was allowed by the application rules.
The reason for this distinction was succinctly expressed by Barry Whitehat: “zero-knowledge proofs allow you to prove the state of some data that you know. They do not let you prove about things that you do not know.” So, a shielded blockchain must be designed around localized, per-user updates to specific fragments of the application state, because global, shared state cannot easily be made private using zero-knowledge proofs.
These constraints mean that we have two challenges to solve simultaneously:
Of these challenges, the first challenge is more foundational, and requires a rethink of system and mechanism design. For instance, our private staking design reshapes the staking mechanics to preserve the economic incentives for staking, while avoiding the need to pay out staking rewards to delegators, which cannot easily be done privately. And ZSwap, our shielded swap mechanism, allows users to transmute one asset type to another, avoiding the need for interaction or transfer of funds between users, but maintaining consistency with a common market-clearing price. On the other hand, the second challenge requires a large amount of detailed cryptographic design work up-front (e.g., nailing down all the details of a state update circuit), with little flexibility after deployment.
Frontloading the cryptographic design work makes it difficult to develop the application iteratively, and get rapid feedback on what aspects work well, but deferring it entirely risks creating a situation where our application is designed incompatibly with private functionality. It would be unfortunate to build a cool mechanism, then discover too late we couldn’t easily make it private, but it would also be unfortunate to build a perfect cryptographic implementation of a state update proof, then discover too late that it provided the wrong functionality.
To tread a middle ground between these extremes, our strategy is to build a working scaffold of the application state as if we were already fully private, but replacing the zero-knowledge proofs with “transparent proofs” containing the secret witness data in cleartext. These act as trivial proofs-of-knowledge, with a verification algorithm that takes the public inputs to the proof and checks the statements against the witness data directly.
While these transparent proofs do not provide privacy, they do have the same interface as a real zero-knowledge proof, so as long as we treat them as opaque blobs, we can ensure that the data flows in the system are compatible with a fully private implementation, without requiring that we frontload the cryptographic implementation work before we work out the details of our mechanism design.
This means we can rapidly iterate towards a working system with a complete implementation of our desired functionality, and nail down exactly what we need to prove.
We’ve created five intermediate milestones along the way to complete functionality:
We’re building Penumbra in public, so we’ll be launching (and crashing) early testnets soon, prioritizing rapid iteration at the beginning and gradually moving towards stability as the system becomes fully formed. Stay tuned to the #announcements channel in our Discord for updates!
