Crosslink Design in a Nutshell

This chapter covers the major components of the design. This presents the design positively, without rationales, trade-offs, safety anlyses, or other supporting information. This will eventually be entirely redundant with, or simply link to, a canonical Zcash Improvement Proposal submission. Treat this chapter as a provisional sketch.

It assumes and leverages familiarity with Zcash PoW and only describes new differences from today's mainnet.

CAVEATS: A lot of the terminology and descriptions will be adjusted as we go to follow conventions and specifications in the Zcash Protocol Specification and the Zcash Improvement Proposals.

Roles and Capabilities

We rely on several roles described in the Five Component Model in this nutshell section along with their intended capabilities. The absence of an explicit capability description for a role implies that role should not be able to perform that capability

Changes to Transactions

Changes to the Coinbase Transaction

The coinbase transaction is an exceptional transaction Zcash inherited from Bitcoin which follows exceptional rules, including the distribution of newly issued tokens. This transaction is created by a block's miner.

The consensus rules are updated to require this transaction to make transfers of a portion of newly issued ZEC dedicated to Crosslink rewards only when this block updates finality to a greater height, and then as the sum of all pending finalization rewards since the previous finalization.

For each block produced which does not update finality, the per-block Crosslink rewards are collected into a running total, and a block which updates finality must then distributed this entire pending amount to the stakers and finalizers determined from the active set used to produce the finality update.

The pending finalizaiton rewards, $R$, in a block which updates finality must be distributed by the coinbase transaction to finalizers and stakers proportionally to their reward slice, $S_{participant}$, where the active set (defined below) refers to the state as of the most recent final block, prior to this update.

This is calculated as follows where we let $W_{participant}$ be the total stake weight for that participant:

• For finalizers in the active set: $S_{finalizer}=COMMISSIO{N}_{F}E{E}_{R}ATE\ast \frac{W_{finalizer}}{W_{t}otal}$

  The constant $COMMISSIO{N}_{F}E{E}_{R}ATE=0.1$ is a fixed protocol parameter called the commission fee rate.

• For all stakers: $S_{staker}=(1.0-COMMISSIO{N}_{F}E{E}_{R}ATE)\frac{W_{staker}}{W_{t}otal}$

  The constant $1.0-COMMISSIO{N}_{F}E{E}_{R}ATE=0.9$ is called the staker reward rate.

  Note that $W_{staker}$ is the total weight of all staking positions of the given staker regardless of whether or not it is assigned to an finalizer in the active set.

Another nuance: the sum of all commission fees and staker rewards adds up to $S_{t}otal$ or less, with the difference coming from stake assigned to finalizers outside the active set.

New Transaction Format & Staking Actions

A new transaction format is introduced which contains a new optional field for staking actions, which enable operations such as staking ZEC to a finalizer, beginning or completing an unstaking action, or redelegating an existing staking position to a different delegator.

The ZEC flowing into staking actions, or flowing out of completing unstaking transactions must balance as part of the transactions chain value pool balancing. See The Zcash Protocol §4.17 Chain Value Pool Balances.

Additionally, we introduce a new restricting consensus rule on context-free transaction validity¹:

Crosslink Staking Orchard Restriction:

A transaction which contains any staking actions must not contain any other fields contributing to or withdrawing from the Chain Value Pool Balances except Orchard actions, explicit transaction fees, and/or explicit ZEC burning fields.

Abstractly, the staking actions include:

• _stake - This creates a new staking position assigning a transparent ZEC amount, which must be a power of 10, to a finalizer and including a cryptographic signature verification key intended for only the signing-key holder of the position to redelegate or unstake.
• redelegate - This identifies a specific staking position, a new finalizer to reassign to, and a signature valid with the position's published verification key to authorize the transition.
• unbond - This initiates an "unbonding process" which puts the staking position into an unbonding state and includes the ZEC amount, the current block height, and the signature verification key to authorize a later claim. Once in this state, redelegations are not valid and the ZEC amount does not contribute to staking weight for finalizers or the staker.
• claim - This action removes a position in the unbonding state and contributes the bonded ZEC into the transaction's Chain Value Pool Balance, where because of the "Crosslink Staking Orchard Restriction, it may only be distributed into an Orchard destination and/or transaction fees.

Further Restrictions on Staking Actions

We furthermore introduce the following consensus rule restrictions on transactions involving staking actions which rely on a staking epoch design:

Staking Epoch Definition:

Once Crosslink activates at block height $H_{crosslin{k}_{a}ctivation}$, staking epochs begin, which are continguous spans of block heights with two phases: staking day and the locked phase. The number of blocks for staking day is a protocol parameter constant roughly equivalent to 24 hours given assumptions about the Difficulty Adjustment Algorithm. The number of blocks for the locked phase is also a constant roughly equivalent to 6*24 hour periods, so that staking day is approximately one day per week.

Given the staking epoch definition, we introduce the following restrictions in the consensus rules:

Locked Staking Actions Restriction:

If a transaction includes any staking actions except for redelegate, and that transaction is in a block height in a locked phase of the staking epoch, then that block is invalid.

Also:

Unbonding Delay:

If a transaction is block height $H$ includes any claim staking actions which refer to unbonding state positions which have not existed in the unbonding state for at least one full staking epoch, that block is invalid.

Note: An implication of the Unbonding Delay is that the same staking day cannot include both an unbond and claim for the same position.

A final restriction (already mentioned above in introducing the staking action is:

Stake Action Amount Quantization:

If a transaction includes any staking actions with an amount which is not a power of 10 ZEC (or ZAT), that transaction is invalid.

Changes to Ledger State

The Ledger State is a conceptual and practical data structure which can be computed by fully verifying nodes solely from the sequence of blocks starting from the genesis block.² To this Ledger State, Crosslink introduces the roster which is a table containing all of the information about all ZEC staked to finalizers.

The Roster

Crosslink's addition to Ledger State is embodied in the PoS roster, aka the roster for short. Which tracks staking positions created by Stakers, and attached to specific Finalizers. A Finalizer has a "voting weight" equal to the sum of all staking positions attached to it (see below in FIXME).

Each staking position is composed of at least a single specific target finalizer verification key, a staked ZEC amount, and a unstaking/redelegation verification key. The finalizer verification key designates a cryptographic signature verification key which serves as the sole on-chain reference to a specific finalizer³. People may mean a specific person, organization, entity, computer server, etc... when they say "finalizer", but for the rest of this document we will use the term finalizer as a shorthand for "whichever entity controls the verification key for a given finalizer verification key.

The unstaking/redelegation verifying key enables unstaking or redelegating that position from the participant that created that position (or more precisely anyone who controls the associated verifying key, which should be managed by a good wallet on behalf of users without their need to directly know or care about these keys for safe operation). These are unique to the position itself (and not linked on-chain to a user's other potential staking positions or other activity).

The sum of outstanding staking positions designating a specific finalizer verification key at a given block height is called the stake weight of that finalizer. At a given block height the top K (currently 100) finalizers by stake weight are called the active set of finalizers.

Ledger State Invariants

We adopt a design invariant around the Ledger State changes Crosslink makes against mainnet Zcash:

General Ledger State Design Invariant:

All changes to Ledger State can be computed entirely from (PoW) blocks, transactions, and data transitively referred to by such. This includes all existing Ledger State in mainnet Zcash today, the PoS and BFT roster state (see below), and the finality status of blocks and transactions.

All current mainnet Zcash Ledger State and almost all Crosslink Ledger State is height-immediate Ledger State: the value for height $H$ can be computed from height $H$ itself (and implicitly all prior heights and contents). Some examples of height-immediate values are the total ZEC issued, the UTXOs spendable by the same P2PKH t-addr, the block's zero-knowledge commitment anchor values, and so on. In Crosslink examples include all of the roster state (e.g. the active set, finalizer verification keys, staking positions, ...).

Height-Eventual Ledger State

Crosslink introduces a novel category of Ledger State not present in Zcash mainnet, which is height-eventual Ledger State. This is a property or value about height $H$ which is only computable at a later larger height (of which the implicit block at $H$ must be an ancestor). The sole example of this is finality status.

The finality status of a block at height $H$ (and by extension any transactions it contains and all previous block contents) is a property which guarantees[^guarantees] to the verifying node that this block (and all txns and previous content) is final and cannot be reverted or rolled back. Furthermore, the presence of this property also provides a guarantee that a majority of finalizers already agree on the finality status of this block and also that all verifying nodes which see a sufficient number of subsequent blocks will also agree on the finality status.

[^guarantees] In this book, whenever we say a protocol "guarantees" some condition, we mean that so long as the security assumptions truly hold verifying nodes can and should safely rely on that condition.

The finality status of a block at height $H$ (which we'll call a finality-candidate block here for precision) is computable from a block at a later height $>H$ (which we'll call the attesting block). All verifying nodes who have observed the that attesting block will agree on the finality of the candidate block even though they may observe the attesting block rollback. In the event of such a rollback, the protocol guarantees that an alternative block will eventually attest to the finality status of the same candidate block.

Finality, Transaction Semantics, Ledger State, and the Roster

It bears pointing out a nuance: the Ledger State, including the Roster and the Active Set are all determined by valid transactions within PoW blocks. Every PoW block height thus has a specific unambiguous Ledger State. This comes into play later when we consider finality which is a property of a given block height which is only verifiable at a later block height.

The BFT Sub-Protocol

TODO: Flesh out this section

TODOS from deep dive:

• rewards distribution to stakers and finalizers requires changes to the Coinbase transaction.
• how finality status is calculated
• how BFT operates, votes, network, etc...
• active set selection
• quantization of amounts / time
• the power of 10 restriction on amount is only applied to "stake" (create position)
• how do staking actions pay fees?

1. A context-free transaction validity check may be performed on the bytes of the transaction itself without the need to access any chain state or index. ↩

2. Theoretically all of the Ledger State could be purely computed on demand from prior blocks, so literal Ledger State representations in memory can be thought of as chain indices or optimizing caches for verifying consensus rules. In some cases components of the Ledger State must be committed to within the blockchain state itself (for example, commitment anchors) which constrains how lazy a theoretical implementation can be. Real implementations trade off caching vs lazy-computation in a fine-grained way to achieve practical goals. ↩

3. Any particular entity may produce any number of finalizer verifying keys of course, although for economic or social reasons, we expect many finalizers to be motivated to hang their reputation on 1 or just a few well-known finalizer verifying keys. ↩