Skip to content

Commit

Permalink
Add v2 plan
Browse files Browse the repository at this point in the history
  • Loading branch information
@hdevalence
hdevalence committed May 2, 2020
1 parent 97d86e6 commit f8e22c4
Showing 1 changed file with 230 additions and 102 deletions.
332 changes: 230 additions & 102 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,106 +1,234 @@
# Zcash/Cosmos Pegzone

This repo will eventually contain an implementation of a [Cosmos] [peg
zone][pegzone] that bridges the Cosmos ecosystem to the Zcash shielded pool.
For now it contains design notes and planning.

## Zcash-to-Cosmos Peg

This will produce Cosmos-ZEC on a Cosmos pegzone, connected by [IBC] to the
rest of the Cosmos network. Each unit of Cosmos-ZEC is backed 1:1 by ZEC in
the Sapling shielded pool, and secured by capital staked with the pegzone
validators. Zcash users can send ZEC to a pegzone z-addr with a Cosmos address
in the transaction's memo field. The pegzone z-addr is controlled by a set of
Tendermint validators, who can detect that the transaction occurred and come to
consensus that coins have been received. When this happens, they mint an
identical amount of Cosmos-ZEC and send it to the specified Cosmos address.

## Cosmos-to-Zcash Peg

Cosmos-ZEC holders create a transaction that specifies a z-addr and burns
Cosmos-ZEC. As the pegzone validators reach consensus on the Cosmos-ZEC
transaction, they use distributed signing on the spend authorization key to
prepare a Zcash transaction that releases the burned amount of ZEC to the
z-addr specified in the Cosmos transaction.

# Components

## Distributed Key Generation for RedJubjub

The validators for the pegzone need to perform distributed key generation (DKG)
for the pegzone address's spend authorization key. This will use a forthcoming
construction by Chelsea Komlo.

Because the validators collectively control the pegzone address, the validator
set cannot change without changing the pegzone address. This means that unlike
other Cosmos chains (e.g., the Cosmos Hub), the validator set cannot change at
any block but only at specified epochs. This will likely involve some kind of
3-phase key rotation schedule (previous/current/next), with mechanisms to
ensure that funds sent to the previous pegzone address (e.g., close to the
rollover boundary or by mistake) are not permanently lost, and that the next
pegzone address is available in advance (so that software using the pegzone can
have continuity).

## Distributed Signing for RedJubjub

The validators for the pegzone need to perform distributed signing (DKG) to
produce signatures with the pegzone address's spend authorization key. This
will use a forthcoming construction by Chelsea Komlo.

Transaction generation should be integrated with the pegzone's consensus
mechanism, but the details are yet unspecified. Ideally, as the pegzone
validators come to consensus on transactions burning Cosmos-ZEC, they should
also come to consensus on the signature for the withdrawal transaction.

## Transaction Monitoring

The validators for the pegzone need to be able to scan the Zcash chain for
pegzone-related transactions and determine whether or not they occurred. In
the first iteration of the design this will use a light client approach, and in
a later iteration, reuse the components of [Zebra] as libraries.

To determine whether funds have been sent to the pegzone address, the
validators share an [incoming viewing key (IVK)][ivk]. To monitor outgoing
transactions, the validators also share an [outgoing viewing key (OVK)][ovk].
The Zcash protocol does not enforce that transactions have a valid OVK, so
validators must also monitor for improperly published note nullifiers.

## Security / Fraud

The pegzone is secured by capital staked on the behaviour of the pegzone
validators, whose stake can be slashed in the event of misbehavior, such as
unauthorized sends or failure to mint Cosmos-ZEC. Because some behaviour may
not be traceable to a particular validator, overslashing may be required to
ensure correct incentives for each validator. Validators will collect fees on
Cosmos-ZEC transactions in the pegzone to cover the cost of the capital
required to secure it. Multiple pegzones can compete on fees.

Because each pegzone pegs *shielded* ZEC, not transparent ZEC, it acts as an
additional gateway between a transparent world (in this case, Cosmos) and the
shielded pool. This increases the operational complexity of monitoring all
transactions in and out of the shielded pool, as those now happen in multiple
places. It also provides increased privacy for all Zcash users, not just the
users of the pegzone, by increasing the size of the shielded pool.

However, `Cosmos->Zcash->Cosmos` transfers are likely to have similar problems
as `t->z->t` transfers. For this reason, the pegzone will provide a
transaction planner tool that can prepare a transfer strategy (sharding over
transparent addresses and time) and produce audit proofs that it executed
correctly. This allows users to maintain some amount of privacy outside of the
shielded pool while still retaining the ability to privately disclose proofs of
their behaviour to relevant authorities.

## Cosmos State Machine Components

1. Asset issuance module.
2. User Account balance module.
3. Asset burning module.
4. IBC implementation.
5. IBC fungible token transfer application protocol implementation.
6. On-chain processing of fraud proofs.
# 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 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][saplingkeys],
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.

[Cosmos]: https://cosmos.network
[pegzone]: https://blog.cosmos.network/the-internet-of-blockchains-how-cosmos-does-interoperability-starting-with-the-ethereum-peg-zone-8744d4d2bc3f
[Zebra]: https://github.com/ZcashFoundation/zebra
[ivk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
[ovk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
[saplingkeys]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
[FROST]: https://crysp.uwaterloo.ca/software/frost/

0 comments on commit f8e22c4

Please sign in to comment.