<
Back to arcticles
Shielded Staking on Penumbra
On a proof-of-stake chain, users stake tokens to help secure the network, and inreturn, the network issues staking rewards for their participation. On everyother proof-of-stake chain, this requires each user to publicly record theirtoken holdings. Penumbra is built different. Penumbra is the first chain tocreate private proof-of-stake, providing privacy for delegators whileretaining accountability for validators.
Why is this important?
First, without private staking, holders of the staking token would have tochoose between maintaining privacy or helping to secure the network, participatein governance, and receiving staking rewards. Instead, users should haveprivacy by default, with no loss of capability.
Second, there is no alternative, because Penumbra records all user dataprivately in a single multi-asset shielded pool. Unlike other privatetransaction systems, there are no transparent addresses to use. Instead, theentire interchain is our transparent pool.
Third, it follows a key design principle for Penumbra: privacy forindividuals, transparency for aggregates or organizations. Penumbra validatorshave public identities and are accountable for their behavior, but individualdelegators can maintain privacy -- or disclose their activity to whomever theywish.
As we described in one of our very first posts, however, shieldedstaking presents an immediate challenge: how can the network pay out stakingrewards, without knowing who the delegators are?
Unlike a transparent chain, where all delegations are public, and the chain cansimply credit delegators' accounts with staking rewards, if the delegations areprivate, the chain has no way to know the amount and duration of eachdelegation.
Our solution is delegation tokens: protocol-native, validator-specific liquidstaking tokens.
Rather than treating "unstaked" and "staked" as different possible states of asingle staking token, which the chain must track for each holder, we representdifferent states as different tokens. Delegating stake to a validator exchangesstaking tokens for that validator's delegation token, similarly to shares of aliquidity pool. Undelegating exchanges delegation tokens back for stakingtokens. And the exchange rate between staking tokens and delegation tokensprices in what would be a staking reward in other systems.
This design makes all delegations to a particular validator completely fungible.But because delegation tokens are not fungible between validators, the networkcan still individually slash misbehaving validators. Individual delegators gainprivacy, but validators retain accountability.
Some users may want an LST that does create fungibility between validators, bypooling stake over multiple different validators and redistributing slashingrisk. Whether a protocol designer likes it or not, this demand exists, and themarket will find a way to meet it. Because Penumbra's staking is nativelyimplemented with per-validator LSTs, staked funds are already tokenized, sostake pools can be implemented just by a contract that pools those tokens,rather than having to introduce additional trust assumptions like multisigs.
How does the exchange rate mechanism allow the chain to handle shielded stakingrewards?
Instead of tracking staking rewards directly, the chain tracks an exchange ratebetween the staking token and each validator's delegation token. This exchangerate prices in the cumulative staking rewards since genesis. When a userdelegates stake to a validator, they exchange their stake for delegation tokensat the current rate. This discounts their share of the delegation pool forthe rewards from genesis up to their delegation, which they didn't earn. Butnow, they are on an equal footing as every other delegator. And later, whenthey undelegate stake from that validator, the exchange rate will credit themfor all of that validator's cumulative staking rewards since genesis.
Since they discounted their share on delegation, this nets out to thecontinuously compounded staking reward exactly over the period they delegated,without requiring the chain to track that information!
For a proof-of-stake system to provide security, it must have a way to slash(penalize) validators who violate the rules of the protocol. The exchange ratemechanism makes slashing extremely easy to implement: to slash a particularvalidator, the chain just adjusts the exchange rate of their delegation token.
Unbonding is slightly more challenging. If a validator could break the rules,then immediately withdraw their stake, they could escape consequences for theirmisbehavior. To prevent this, proof-of-stake chains have an unbondingmechanism that delays withdrawals of staked tokens. Like other Cosmos chains,Penumbra has a fixed unbonding delay, tied to the IBC security parameters.
Unlike a Cosmos chain, however, Penumbra's unbonding delay does not lock tokenswhile they are unbonding. Instead, we add an additional token state: instead ofconverting delegation tokens directly into staking tokens, an undelegationaction converts them into unbonding tokens. These are nominally 1:1 withstaking tokens but remain bound to a specific validator and exposed to slashing.Once the unbonding period ends, unbonding tokens can be converted to ordinarystaking tokens, accounting for any slashing that occured while the tokens wereunbonding.
Because unbonding tokens are liquid, users can transfer or sell them, butbecause they remain exposed to the validator's behavior, slashing risk isconserved. A user who wants to undelegate sooner than the unbonding period cando so by selling their unbonding tokens to someone else who's willing to take onthe slashing risk -- and the discount should reflect the market price for thatrisk.
Alternatively, an undelegation queue could be implemented using the DEX:delegators who want to undelegate faster can create auto-closing limit orderswith their delegation tokens with a slight discount to the protocol-nativeexchange rate, and be matched against users who want to delegate and see thatthey can do slightly better than native delegations by taking the other side ofthe trade.
This system is live on the Penumbra testnet, and you can use it today, either asa delegator or as a validator. Testnet tokens have no value, and testnetactivity is not incentivized in any way, but this is a great way to play withthe software and test it out.
Staking actions are fully supported in the Penumbra web interface using PraxWallet, the browser wallet for Penumbra. Use the Discordfaucet to request tokens and thetestnet frontend to stake, swap, or sendtokens. Unlike frontends for transparent chains, this frontend runs entirely onyour computer, using an ultralight node embedded in your wallet to index onlythe data your wallet can view.
To run a validator node, check out the Penumbra guide. Unlike Cosmoschains, Penumbra validators have separate identity keys and consensus keys.This allows the validator's long-term identity keys to be defined and kept incold storage, independently of the mechanism used to sign blocks for aparticular network. The Penumbra testnet is a good environment to practicevalidator key management setups.
