wip
This commit is contained in:
parent
28c87fc33b
commit
f47fd400b6
215
README.md
215
README.md
|
@ -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
|
This repo will eventually contain an implementation of a [Cosmos] [peg
|
||||||
zone][pegzone] that bridges the Cosmos ecosystem to the Zcash shielded pool.
|
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
|
[Zebra]: https://github.com/ZcashFoundation/zebra
|
||||||
[ivk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
|
[ivk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
|
||||||
[ovk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
|
[ovk]: https://zips.z.cash/protocol/protocol.pdf#addressesandkeys
|
||||||
|
|
||||||
|
[FROST]: https://crysp.uwaterloo.ca/software/frost/
|
||||||
|
|
Loading…
Reference in New Issue