zecfoundation
/
zcash-pegzone
mirror of https://github.com/ZcashFoundation/zcash-pegzone.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

wip

This commit is contained in:
Henry de Valence 2020-05-01 15:57:19 -07:00
parent 28c87fc33b
commit f47fd400b6
1 changed files with 214 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

215
README.md
View File

@ -1,4 +1,215 @@
# Zcash/Cosmos Pegzone
# 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.
## 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,
removing the requirement 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.
Its validators will share control of the spend authorization key of a z-addr
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 in more detail below.
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. 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. 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.
- implementation components
- frost
- key rotation
- zebra libraries
- inspect state of the zcash chain
- watch for transactions
- send transactions to the network
- hold zec
- cosmos integration
- choice of language (go or rust)
- determine exchange rates
- consensus integration
- token issuance
- delegation mechanism
- fraud reporting
- IBC implementation
This repo will eventually contain an implementation of a [Cosmos] [peg
zone][pegzone] that bridges the Cosmos ecosystem to the Zcash shielded pool.
@ -104,3 +315,5 @@ their behaviour to relevant authorities.
[Zebra]: https://github.com/ZcashFoundation/zebra
[ivk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
[ovk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
[FROST]: https://crysp.uwaterloo.ca/software/frost/