Proof of Stake: Approach, focus, and next steps

As we described in our initial blog on Proof-of-Stake Research, we are releasing updates to the Zcash community as we go.

In this post we describe major technical research areas we intend to focus on moving forward. We will go over a number of topics, including these focus areas, approach, and next steps. We’ll adjust throughout the process as we discover new needs.

As the cryptocurrency ecosystem continues to evolve, it’s important to understand how ZEC might be best suited to find its niche in the overall marketplace. The core of this research is to improve the overall use experience, and broader use case, for Zcash and ZEC.

Approach

With ECC’s North Star and research goals in mind, we are adopting this broad approach to developing a successful proposal:

Go-to-market process

This status update is focused on an initial technical research phase as part of a comprehensive go-to-market process. The broader process has these components:

  1. Requirements definition to establish specific goals for a PoS transition proposal
  2. Market research to identify the target market, user needs, and market landscape
  3. Technical research to identify the range of feasible technical designs
  4. Engineering R&D to develop a concrete design and deployment roadmap
  5. Zcash proposal (with a specific decision) to present to the Zcash community
  6. Go-to-market execution, for an accepted proposal, to ship usable and valuable products to users

In practice, the first three components are interleaved: As we explore technical designs and learn more from market research, we will refine our requirements, which may require further technical and market research. We will iterate these three efforts until we develop high confidence that we have the best requirements.

Technical research process

The technical research process has three main components:

Protocol survey

First, we’ll focus on researching existing proof-of-stake (PoS) protocols to understand trade-offs and risks. From there, we’ll select our preferred candidate, using our vision for ZEC and Zcash to guide our choice of trade-offs. We’ll share this comparative analysis and our preferred candidate protocol early in our research process to get review and feedback from the broader community.

Our preferences: We have a strong bias toward protocols that have significant pre-existing deployments that have matured and hardened in the market, as well as strong theoretical underpinnings. Protocols that have both of these traits present the least possible risk for this emerging technology.

Zcash specialization

Second, with a preferred protocol candidate in hand, we’ll carefully investigate which design facets may need customization or alteration to support ZEC. We’ll especially consider usability, safety, privacy, and monetary policy constraints that serve as ZEC’s strengths.

Our preferences: We maintain a security and technical strategy that minimizes changes or innovations, and we strongly prefer to use proven designs as much as possible. The ideal candidate would require no changes. As stated in our research goals, our aim is to target a minimum viable protocol, with the assumption of future improvements, rather than aim to include all valuable potential Zcash specializations up-front.

Transition plan

Finally, after developing a proposal for this minimally customized candidate PoS protocol, we’ll develop a more comprehensive proposal, including a transition plan, for safely migrating Zcash from its current proof-of-work (PoW) network to the new target PoS protocol. The transition plan is likely to require significant effort, and there are a range of feasible approaches. We intend to present several possibilities earlier in the research process to get community input on their trade-offs.

Our preferences: We prefer to select an ideal target protocol independent of developing a transition plan to that protocol. If we find the transition plan introduces new constraints or requirements on the target protocol, we will refine the target protocol requirements later in the process.

Research areas

Given our goals and approach, we’ve currently identified a number of major areas of technical research for the protocol survey and Zcash specialization phases. These research areas do not yet focus on the transition plan. We will turn our attention to the transition plan as other areas, and broader market research and requirements, become clearer.

Shielded wallet UX and security

A high priority for our technical research is to consider shielded wallet usability and security, especially for mobile devices. We do not expect the consensus protocol to directly impact shielded storage and transfer functionality or usability. Beyond that, participants in a PoS protocol also may contribute ZEC to staking bonds, validate blocks, propose blocks, and select blocks.

The interaction between the shielded pool and staking is an essential interface of the design. Staked capital must be in bonds visible to the protocol to select block producers and potentially slash for misbehavior. A plausible simple design for this interface would be to support single-use bond positions with a public amount and no associated addresses. These can only be funding from, or withdrawn to, the shielded pool.

In this simpler design, block producers are likely to operate using the target PoS protocol mechanics with minimal Zcash customization.

Our preferences:

  • We prefer to enable any number of shielded mobile wallet users to delegate ZEC to staking bonds with a first-class user experience.
  • We prefer the plausible, simple integration between stake delegation and the shielded pool described above for the initial PoS protocol.

Cross-chain interoperability

A key pillar of our vision for ZEC’s value in Web3 is to enable interoperability between the Zcash blockchain and any number of other blockchains.

Our preferences:

  1. We prefer protocol interoperability features with the best balance of current and future potential reach against complexity. For example, interoperability with Bitcoin may have the largest current reach in terms of market capitalization, yet interoperability with the Cosmos ecosystem may have more reach with lower complexity.
  2. To that end, we have a preference for a protocol with finality, as described below in the Dynamic availability vs finality section.
  3. We prefer to target existing, standard cross-chain mechanisms without requiring privacy innovations. We prefer to design the interface between the shielded pool and cross-chain mechanisms similarly to our preference for the interface between the shielded pool and stake delegation.

Proof-of-stake security

While we strongly favor protocols that are proven via real-world production hardening, we additionally require a strong theoretical foundation.

Incentives and resource cost security

A core concept in security arguments for cryptocurrency protocols is incentive alignment: If it’s in the best interest of independent block producers to follow reinforcing consensus rules, the protocol should be robust against deviations (aka attacks). This is an important departure from earlier work in Byzantine consensus protocols, which typically only distinguished between “honest” or altruistic nodes versus malicious nodes.

If security relies on incentives, then feasibility of an attack depends on the payoff given the cost. So, for example, a proof-of-work attacker with a tiny fraction of mining capacity is unlikely to execute a long rollback within some window. However, as an attacker’s resources scale up, their ability to successfully execute attacks improves (despite the larger cost of the attack).

So, arguments for security in cryptocurrency consensus analyses often rely on the cost to maliciously control a key resource: hashpower for proof-of-work and staked tokens for proof-of-stake. Sites like crypto51.app provide cost estimates for 51 percent attacks against PoW chains, which exemplifies this mode of reasoning about security.

In Ethereum 2.0 Economic Review by Hoban & Borgers, the authors compare the estimated 51 percent attack cost against ETH1 (PoW) to the cost of controlling sufficient validators for a safety attack against ETH2 (PoS) as a heuristic to determine whether the newer protocol is as safe as the previous protocol.

Our preference: We believe the “attack cost comparison” used in the Hoban & Borgers paper is one useful guideline in analyzing the safety of a transition from PoW to PoS, as long as we exercise caution in not relying too heavily on this single heuristic.

A key safety mechanism in PoS protocols is an “unbonding period” during which a staker cannot access their staked funds without some delay. This delay underpins security guarantees, for example, by ensuring a bond may be slashed some time after a slashable behavior occurs.

Our preference: We don’t anticipate deviating from an existing candidate protocol’s design for unbonding period length, while ensuring it is tuned to a conservative value for our security requirements.

Wrinkles in incentive space

While the notion of relying on participants to follow incentives seems reasonable, we are acutely aware of three big risks in the “cost of resource” attack reasoning from the last section:

  • Attack costs may be overestimated
  • Pay-offs may be underestimated
  • Or more generally, real incentives for participants may not be correctly modeled

Attack costs can be overestimated in the simple “cost of consensus resource” security model due to financial mechanisms, as well as combined attack modalities. For example, Why buy when you can rent? explores how an attacker can use “bribery” to gain temporary control of PoW mining capacity to execute an attack, without incurring the larger and longer term capital cost of acquiring the mining equipment. A similar case could occur in PoS if, for example, an attacker acquires staking capital through a financial mechanism that lowers their direct cost.

Pay-offs may be underestimated, especially because the attack-cost models tend to ignore payoffs altogether. If an attack costs the equivalent of $X billion USD, that may seem reassuring, but what if an attack can net $10X billion in proceeds?

Finally, those two problems are more specific cases of the real incentives of participants being incorrectly modeled. On this more general point, evolving real-world incentives may threaten the security of consensus protocols even when there is no “attacker” with malicious intent. In Competitive equilibria between staking and on-chain lending the researchers analyze how the amount staked in a PoS protocol interacts with a model defi lending platform. In that analysis, staking security may become perilously low through self-interested behavior of participants, none of whom intends to “attack” the network. The meltdown of the Terra staking token Luna, as described by Bloomberg columnist Matt Levine, would seem to be a real-life event related to this research that is likely to become a canonical example of how financialization mechanisms when attached to a proof-of-stake token can lead to security disasters.

So, many kinds of financialization or financial mechanics can impact security, including defi, bridging, multi-asset support, and off-chain custodial financial services impact security.

All of this complexity not only complicates analysis of a protocol, but it also opens the design space to incorporating financialization mechanisms. Existing networks are exploring this area of design space with staking derivatives, such as staking-backed derivative tokens (often simply called “staking derivatives” or “liquid staking”), superfluid staking, and more. On Staking Pools and Staking Derivatives mentions a common argument that liquid staking may lower security and it then presents an argument that for some given assumptions it can actually increase security.

Finally, all of this discussion of incentives has skirted around a core economic design component impacting PoS security, the Issuance Policy, which we discuss separately below. 

Our preference: Our preferences around issuance are described in the Issuance policy section. Our belief around financialization is that it generally produces value, is inevitable, and that ZEC can be safely incorporated into it, so long as we understand and mitigate risks as they develop. Our preference for incorporating financialization into the consensus protocol is to be extremely conservative and only consider such mechanisms, such as liquid staking, when there is a strong argument for their benefit versus their risk and complexity. We prefer to propose a simpler “V1” protocol and may consider such mechanisms in later iterations of future PoS protocol improvements.

Dynamic availability vs finality

The research literature highlights a fundamental trade-off in consensus protocols between “dynamic availability” vs “finality”. This extends earlier research from distributed computing around a similar trade-off popularized as the CAP theorem.

Dynamically available protocols can continue making progress during network partitions, at the cost of reverting transactions when the partitions later reconnect. Finalizing protocols ensure that once a transaction is final it cannot be reverted, at the cost of halting the network during a partition.

Both transaction reversion (aka “rollbacks”) and network halts cause economic damage to participants. A protocol which allows transaction reversion can lead to “half-executed” economic exchanges, which leave one party harmed. Protocols that can halt will prevent the users from accessing their capital, introducing opportunity costs.

An example of a half-executed exchange in a dynamically available protocol (such as Zcash PoW), is when Alice sends Bob 0.001 ZEC, and Bob makes and gives Alice a latte, then Alice consumes it. If there is subsequently a network rollback that reverts the transfer, Bob will not receive the 0.2 ZEC, thus causing Bob to not be compensated for their work. By contrast, in a finalizing protocol, if Bob receives the payment he has a guarantee it cannot be reverted, and can safely sell the latte. Meanwhile, if a finalizing protocol halts, Alice cannot pay Bob at all. Neither party loses out in direct terms, but they cannot complete an exchange which has opportunity costs. (For example, should Alice wait in the cafe? For how long?)

However, it’s important to note that network halts in finalizing protocols can be particularly damaging for financialized mechanics that should respond in real-time to market conditions, such as collateralized systems that may liquidate positions when real-time prices cross some threshold.

Our preference: We have a strong preference for finalizing protocols. A network halt affects all users consistently whereas a rollback only reverts a portion of transactions (those on one of multiple partitions) and harms one participant in every economic exchange for all reverted transactions. Currently, the Zcash network has minimal programmability enabling use cases such as financial systems that respond to real-time price oracles, so we suspect that class of harm from network halts is lower than other crypto networks. Finally, we believe, separate consensus protocols which provide finality can interoperate more safely with less complexity.

Block producer decentralization and resilience

Because permissionlessness is a key property of Zcash, we need to consider how resilient the consensus infrastructure is.

The infrastructure that selects from proposed blocks is critical to censorship resistance and capture resistance, although shielded transactions and the possibility of a community-organized chain split are even more fundamental protections. If entrance to the set of block selectors can be limited outside of freely open, nondiscretionary competition, that presents a capture risk.

Among proof-of-stake protocols with nondiscretionary rules for becoming a block selector, there are several constraints to entry:

  • Participation has capital and operational costs beyond staking bond capital itself, such as network connectivity, operations & maintenance, executive functions, etc… We refer to this as “out-of-band costs”.
  • Participation has competitive in-band staking bond capital requirements, or “in-band costs”.
  • Different protocols may have resource constraints on the number of participants. For example, Ethereum Consensus Layer aims to support thousands of block selector nodes, while Tendermint has a practical limit of hundreds of block selectors.
  • If entry is in-band, the existing block selectors must accept in-band transactions that allow new entrants to register. There is a risk that existing block selectors could censor these registrations to prevent their competitors from freely entering the system.

Our preferences: For each of the above constraints, our preferences are:

  • We prefer to prioritize permissionless entry and competition into block producer infrastructure.
  • We prefer in-band staking bonds to be delegatable with low cost and ease of use by a very large number of users. We believe the ability for users to freely redelegate their stake to different block selectors enables free competition between the selectors.
  • We prefer the practical “floor” amount of ZEC for delegating stake to be as low as feasible, ideally less than $1 USD.
  • We prefer not to prioritize having a large number of block selectors based on the belief that delegatable stake supports free competition sufficiently. We also believe finalizing protocols tend to have lower limits on the number of block selectors supported, and our preference for finality supersedes the desire for a large number of block selectors.
  • We strongly prefer protocols that protect the permissionless entry of new validators in free competition to preserve overall consensus permissionlessness, resist capture, and lower validation fees.
  • We believe with this combination of properties, delegator returns should approach block producer returns through open competition.

Other security risks

There are a multitude of other security risks related to PoS which we anticipate will be shared between Zcash and other PoS networks, including long-range attacks, a variety of network attacks (eclipse attacks, Denial-of-Service, initial node introduction risks), and more.

Our preference: Based on the belief that these risks will not be unique to Zcash, we optimistically anticipate existing PoS protocol designs have been hardened against them. Where we discover weaknesses we intend to collaborate with the broader PoS protocol design ecosystem to address those.

Issuance policy

For cryptocurrencies, beginning with Bitcoin’s breakthrough design, monetary policy sits firmly in the intersection of macro- and micro-economic dynamics, protocol security, governance, usage, and adoption. This area of protocol design is truly multidisciplinary and novel.

We aim to publish a more detailed exploration of issuance policies and PoS security in an upcoming blog post.

Issuance rate security

Existing proof-of-stake protocols have a variety of issuance policies. We’re just beginning to familiarize ourselves with research related to how issuance relates to Proof-of-Stake Security.

Our Preference: We aim to provide supporting arguments from research around the protocol security for the specific issuance policy we propose.

Issuance policy discretion

There are several design options around issuance policy involving discretion and the schedule itself.

Issuance could be more or less discretionary. A prime example of a schedule with minimal discretion is Bitcoin’s issuance schedule, which is fixed. The only way to alter it would be a core protocol change that would require an economically dominant majority of users to adopt a hardforking consensus rule change. An example of a protocol with discretion over monetary parameters would be MakerDAO or many other DAOs which can alter rates, fees, or other economic parameters through on-chain governance. A middle-ground example might be Ethereum, where the current issuance schedule is fixed in the protocol, yet there is precedent to alter this through consensus rule upgrades.

Our Preference: We prefer an issuance policy with as minimal discretion as possible. Because Zcash already has a culture and precedent for backwards incompatible protocol upgrades, this is likely to include social norms about the “Overton window” of acceptable issuance changes, placing a high burden on proposals to motivate changes to issuance. An example from Zcash history of the threshold to enact a significant change was the establishment of the Development Fund which involved a multiyear referendum-like process.

Issuance rate schedule

There are four major possibilities for issuance schedules:

  • Keep the current Bitcoin-like schedule completely unchanged.
  • Adopt a schedule that’s strictly equal or lower than the current schedule, thus keeping the 21M ZEC cap.
  • Adopt a “reasonable” well-known schedule that doesn’t maintain the Bitcoin-like limit.
  • Something else further afield.

Our preference: We have a preference for the second option, a rate that’s lower than the current Bitcoin-like schedule. If this is feasible from a security perspective, we believe it would be acceptable to the vast majority of current and potential future Zcash users, while lowering the costs paid by holders for the security of the network. This option would maintain the 21M ZEC cap. We may find in our research phase that this option cannot support sufficient security, in which case we’ll surface the issue for Zcash users as soon as we formulate the concern.

On-chain governance

Proof-of-stake protocols track the amounts of tokens in bonds, and use that information for making consensus decisions (such as which nodes are able to become block producers). Thus, it’s very natural to also enable on-chain governance mechanisms, where the amount of coins are used for other decisions outside of direct block production consensus.

Our preference: We prefer not to propose binding governance on Zcash protocol development using coin-weighted polling. However we do have a strong preference to enable non-binding coin-weighted polling where anyone can submit petitions or polls and ZEC holders can weigh in using on-chain coin-weighting data. We believe this gives the best balance between capture resistance and governance signaling, and follows the Zcash tradition of incrementally improving governance in safe and sensible stages.

Reducing protocol complexity

Zcash has successfully evolved throughout its lifetime with Bitcoin-compatible functionality through Transparent Addresses, and three separate shielded protocols (Sprout, Sapling, and Orchard). The benefit of this has been to enable wider technical adoption and backwards compatibility. There are several drawbacks to this “technical debt”:

<

Recent blog posts: