Bringing Privacy to Cosmos

The Zcash Foundation wants to bring privacy to the Cosmos ecosystem. Zcash is unique among privacy solutions in that it has strong network effects: new users gain anonymity from all prior transactions of existing users, while in turn contributing to a greater anonymity set for the entire system. Our plan is to take advantage of these network effects by giving Cosmos users access to this anonymity set through an IBC-enabled pegzone. This work will proceed in two phases, with the design of the first phase enabling the features of the second phase. In the first phase, the pegzone will provide tokens backed by ZEC in the existing Zcash shielded pool. These tokens can be sent throughout the Cosmos ecosystem, allowing Cosmos users to trade and use ZEC. In the second phase, we plan to add a shielded pool to the pegzone itself, providing shielded staking, shielded IBC assets, and shielded cross-chain transfers. This plan provides an increasingly useful privacy layer for the Cosmos ecosystem, while growing the anonymity set of Zcash.

What is a pegzone?

Cosmos is designed to enable cross-blockchain asset transfers. These transfers are accomplished by the Inter-Blockchain Communication (IBC) protocol, which provides a standardized way to lock up assets on one chain and provide bearer assets on another chain.

This provides horizontal scalability by allowing different “zones” – blockchains with sovereign consensus mechanisms – to easily interoperate, or, as the Cosmos slogan puts it, to provide an “internet of blockchains”.

IBC requires transaction finality on each of the chains. However, proof-of-work systems only have probabilistic finality: if miners produce a longer block chain, transactions could be removed. However, there's still a conceptual gap between absolute finality required by IBC and the probabilistic finality provided by a proof-of-work chain.

The gap is addressed by a pegzone, a blockchain that works as an adapter for probabilistic finality by declaring transactions to be final after some number of confirmations.

Project phasing

Our pegzone design proceeds in two phases, providing a minimum viable pegzone in the first phase with a path to a full privacy layer for Cosmos in the second phase.

• Phase 1. The Zcash pegzone will provide an IBC-compatible asset, called PZEC, backed 1:1 with ZEC held in the Zcash shielded pool. PZEC can be sent throughout the Cosmos ecosystem, traded and used in other zones, and redeemed for ZEC on the Zcash chain. This allows Cosmos users access to the anonymity set of the Zcash shielded pool, with PZEC in Cosmos functioning similarly to Zcash t-addresses, while laying the groundwork for full shielding in the second phase using a novel shielded-compatible staking mechanism described below.

• Phase 2. In the second phase, we'll add a Sapling-style shielded pool to the pegzone itself and implement shielded staking. This allows shielded transfers from the pegzone to Zcash and vice versa. We also intend to allow any IBC assets to move into the pegzone's shielded pool, coordinating to ensure that the ongoing Zcash user-defined-asset (UDA) support is IBC-compatible.

We plan to build the Zcash portions of this project using the Zebra libraries, which provide modular, reusable components for working with the Zcash chain.

Phase 1 mechanism design

The pegzone will be a proof-of-stake chain. The mechanism design for the pegzone has three parts: the staking mechanics, the peg mechanics, and the fee mechanics.

Staking mechanics

As a proof-of-stake chain, the pegzone requires a staking token, and the pegzone must be able to control the supply of the staking token.

However, rather than employ staking rewards as in the Cosmos Hub, we propose a new design based on a pair of tokens, “SZEC” and “DZEC”, with a predetermined, time-varying exchange rate. The key advantage of this mechanism is that it is future-compatible with shielded staking, by eliminating the requirement for delegators to claim rewards.

The staking token is a new token called SZEC. SZEC is obtained at a 1:1 ratio by burning ZEC on the Zcash chain. This avoids distributional issues about the initial holders of the staking token: all ZEC holders have the option to obtain SZEC if they choose to do so. SZEC is always freely transferable, as it represents an unstaked state of the staking token.

SZEC can be converted to DZEC by delegating it with a validator, and DZEC can be converted to SZEC by removing it from delegation. SZEC and DZEC are not exchanged at a 1:1 rate, but at a blockheight-dependent rate D(h) <= 1 which measures the cumulative depreciation of SZEC relative to DZEC from genesis to blockheight h and decreases monotonically in h.

Delegating 1 SZEC at height h_1 results in D(h_1) DZEC bonded to a particular validator. Undelegating 1 DZEC at height h_2 results in 1/D(h_2) SZEC. This transaction is only settled after some unbonding period, during which the DZEC may still be slashed in the event of validator misbehavior.

This can be thought of as treating all DZEC as if it had been delegated since (pegzone) genesis, and pre-debiting the staking rewards over the period before they began delegation, so that when they undelegate, they receive rewards only over the delegation period. Crucially, this means that all DZEC is fungible up to the choice of validator, because there is no need to track how long particular DZEC has been delegated.

This is economically equivalent to staking rewards as used on the Cosmos Hub, but because the staking reward is instead priced in to the SZEC/DZEC exchange rate, there is no requirement for delegators to claim rewards, and all delegators are rewarded at the same rate (e.g., there is no question about the compounding interval). Removing staking rewards makes it relatively easy to add shielded staking in phase 2 of the project, described in more detail below.

Peg mechanics

The Zcash pegzone will provide an IBC-compatible asset, called PZEC, backed 1:1 with ZEC held in the Zcash shielded pool. PZEC can be sent throughout the Cosmos ecosystem, traded and used in other zones, and redeemed for ZEC on the Zcash chain.

Zcash Sapling addresses have a capability-based key hierarchy, splitting each logical capability related to that address's funds into a different key. The incoming and outgoing viewing keys will be replicated across all validators, allowing any validator to individually inspect the pegzone funds. To authorize spending, the validators will share control of the address' spend authorization key using FROST, a round-optimized threshold multi-signature scheme designed in collaboration between the Zcash Foundation and the University of Waterloo.

Upon receipt and confirmation of a z2z transaction on the Zcash chain, the validators issue PZEC to a pegzone address specified in the transaction's memo field. Pegzone users can redeem PZEC in the pegzone to obtain ZEC on the Zcash chain, less some fees described below. To do this, they create a transaction on the pegzone that burns PZEC and specifies a destination z-addr on the Zcash chain. As the pegzone validators reach consensus on the PZEC transaction, they perform distributed signing on the spend authorization key to prepare a shielded Zcash transaction that sends ZEC from the pegzone address to the user-specified address.

We handle key rotation and validator set changes using a single epoch mechanism. The system fixes an epoch length parameter, measured in pegzone blocks, and chosen to be a relatively short interval (e.g., approximately one day). A relatively short key rotation interval is preferable to a long one, because it makes the key rotation mechanism impossible to ignore in client software, reducing the risk of unexpected surprises.

Validator set changes can only occur at epoch boundaries, not at every block (as in the Cosmos Hub). Each epoch has a primary z-addr controlled by that epoch's validator set. The previous epoch's z-addr stays active until the end of the current epoch, and its validators are responsible for rolling any funds sent to it by mistake to the current epoch's address, while the next epoch's z-addr is generated at the beginning of the current epoch so that it is available in advance. This provides a constant, pre-coördinated key rotation mechanism, without requiring precise alignment between the pegzone blockheight and users' clocks.

Fee mechanics

The security of the pegzone is provided by the strength of the validator's incentives for correct behaviour: their stake. This means that the cost of providing PZEC is the cost of capital staked to insure its security, integrated over the length of time the PZEC is held in the pegzone. It's important for the fee structure to respect that cost structure, to prevent perverse incentives for behavior on the part of validators or pegzone users.

As an example, someone who sends 100 ZEC to the pegzone, holds it in the pegzone for a year, then redeems for ZEC should pay essentially the same fees as someone who sends 100 ZEC to the pegzone and moves the corresponding PZEC back and forth once per month.

In particular, the fee structure should not penalize movement across the peg and into the shielded pool, because the first phase of the pegzone is unshielded, so PZEC will function similarly to t-addrs in Zcash, where privacy requires careful movements into and out of the Zcash shielded pool.

The proposed fee mechanism for PZEC is therefore similar to the staking mechanism. Rather than a 1:1 rate, PZEC is converted to ZEC at rate F(h) < 1, which measures cumulative fees from genesis to blockheight h and decreases monotonically in h.

Sending 1 ZEC to the pegzone at (pegzone) height h_1 results in issuance of 1/F(h_1) PZEC. Redeeming 1 PZEC at (pegzone) height h_2 results in distribution of F(h_2) ZEC.

This can be thought of as treating all PZEC as if it had been pegged since (pegzone) genesis, and pre-crediting the user for fees up to the time of creation. This design removes the requirement to track how long PZEC has been held in the pegzone, while ensuring that the fees charged are related to the cost of capital required to secure the peg.

The excess ZEC withheld in distribution is kept by the validators and their delegators.

One disadvantage is that fees are not collected on an ongoing basis, but only when assets move through the peg. However, because the fee amount is not affected by when and how assets move through the peg, avoiding moving funds does not help users avoid paying fees.

The fee rate should be as low as possible (to incentivize pegzone usage), but high enough to cover the cost of capital required for security. One mechanism to accomplish this would be an automatic fee adjustment analogous to the one used on the Cosmos Hub to control staking rewards. This would fix a minimum collateralization ratio for the pegzone, and increase the fee rate to incentivize staking as the collateralization ratio declines towards the minimum.

Phase 2 mechanism design

In the second phase, we plan to add a Sapling-style multi-asset shielded pool to the pegzone itself and implement shielded staking. Shielded staking will provide delegator privacy, not validator privacy. Each validator will have a publicly-visible stake weight, but unlike on the Cosmos Hub, the identities of their delegators and the distribution of delegators to each validator will be protected. Validators can be pseudonymous, if there is market demand for pseudonymous validators – no strong identity is required. The shielding design follows straightforwardly from the SZEC/DZEC design, which ensures that all DZEC staked with the same validator is fungible.

The pegzone has a main multi-asset shielded pool for SZEC and any other IBC assets moved into the shielded zone, as well as a single-asset shielded delegation pool for each validator's DZEC. Delegation transactions move SZEC from the main shielded pool into the validator's delegation pool, escrowing the portion of the delegated funds that will be slashed in case of validator misbehavior. A user can undelegate their funds by moving funds back to the main shielded pool. The unbonding period of the Cosmos Hub can be replicated by requiring a long settlement period for this transaction. Slashing is implemented by burning all of the escrowed portion of the delegated funds, allowing users to withdraw the rest.