Now that Sapling has activated and active work on ecosystem adoption is underway, we’ve begun early planning for our next protocol upgrade, codenamed Zcash Blossom.

Upgrade Development Process

A lot of my personal effort in planning for this upgrade has been initially focused on the process itself with several important process design goals: improving quality/safety, avoiding rushing or cramming, aiming to enable the Foundation to “hook in” the ZIP process, providing synchronization points to allow multiple dev teams to contribute to upgrades, and so forth. I intend to write more about the process itself in the future. But now let’s talk about Blossom:

We plan to have Zcash Blossom activate approximately around October 28th, 2019 (one year after Sapling activation). The new development process we are following begins with a set of potential goals for an upgrade, and the first milestone is a set of feature requirements. Over the next few weeks, we’re going to be gathering feedback on these goals and vetting these goals with a product-focused mindset (ie: to ensure they help real users and advance our overall strategy).

Potential Blossom Upgrade Goals

Here’s the current set of feature goals we’re looking into for Blossom. Keep in mind that these goals and actual design details that go into these goals are likely to shift as we do our initial R&D into them.

Note: The actual goals for Blossom will evolve with during our research and product validation work. The current list of goals live at the Blossom Goal github label.

Harmony Mining

Github: zcash #3672

zcash #3672 What is it? A dual-proof-of-work scheme, where one algorithm is backwards compatible with current mining equipment, and another is designed to work well with GPUs on a temporary time scale.

A dual-proof-of-work scheme, where one algorithm is backwards compatible with current mining equipment, and another is designed to work well with GPUs on a temporary time scale. Who does this affect? miners

miners Why is this a goal? By attracting distinct mining userbases (ASIC & GPU owners) we aim to make the Zcash ecosystem more resilient by spreading issuance and political influence among distinct kinds of stakeholders.

Split Founders’ Reward

Github: zcash #3673

zcash #3673 What is it? Alter the consensus rules so that there are distinct FR addresses for the Zcash Foundation, Zcash Company Strategic Reserve, and the remainder.

Alter the consensus rules so that there are distinct FR addresses for the Zcash Foundation, Zcash Company Strategic Reserve, and the remainder. Who does this affect? FR Recipients and Governance/Transparency focused public

FR Recipients and Governance/Transparency focused public Why is this a goal? This decouples these three funding streams organizationally, legally, and operationally. It further reinforces transparency as to the structure of the Founders’ Reward.

Transaction Confirmation Usability and Security Improvements

Github: zcash #3674

zcash #3674 What is it? Improve usability and security of fees and confirmations while accounting for growing transaction volume, demand spikes, and transaction-based DOS scenarios.

Improve usability and security of fees and confirmations while accounting for growing transaction volume, demand spikes, and transaction-based DOS scenarios. Who does this affect? Transaction senders and receivers.

Transaction senders and receivers. Why is this a goal? We cannot prevent demand shocks or growth approaching scalability limits, but we can and should help users understand what is happening and help them protect themselves.

Light Client Protocol Dovetailing

Github: zcash #3675

zcash #3675 What is it? Alter the base consensus protocol to reinforce light client support.

Alter the base consensus protocol to reinforce light client support. Who does this affect? (Future potential) Zcash light client end users.

(Future potential) Zcash light client end users. Why is this a goal? We anticipate more light client users than full node users in the future (all other things being equal), so any streamlining of this use case in the base consensus protocol is potentially valuable.

BOLT Support

Github: zcash #3676

zcash #3676 What is it? Base consensus support for the BOLT second-layer protocol (see our introductory blog post).

Base consensus support for the BOLT second-layer protocol (see our introductory blog post). Who does this affect? (Future potential) Users of BOLT-enabled light wallets.

(Future potential) Users of BOLT-enabled light wallets. Why is this a goal? Second-layer channel-based protocols may enable use cases that allow substantially more transactions with minimized capacity impact on the base consensus protocol. A direct BOLT integration with Zcash would have stronger privacy protections than existing second layer systems, which may be especially important if service providers centralize.

Retire Sprout Addresses

Github: zcash #3677

zcash #3677 What is it? Turn off all support for Sprout addresses and funds stored at those addresses except the ability to transfer funds out of those addresses.

Turn off all support for Sprout addresses and funds stored at those addresses except the ability to transfer funds out of those addresses. Who does this affect? Sprout users.

Sprout users. Why is this a goal? This removes technical debt and simplifies the ecosystem moving forward. Additionally it prompts usage of the Sprout→Sapling turnstile.

Rollback Protection and Hardening

Github: zcash #3678

zcash #3678 What is it? Add protections against rollbacks larger than some predetermined length.

Add protections against rollbacks larger than some predetermined length. Who does this affect? All transactors, especially multi-user service providers.

All transactors, especially multi-user service providers. Why is this a goal? All users would reject a large enough rollback. Some users would reject a smaller rollback. By codifying a well-known standard for the maximum acceptable rollback depth, we reduce economic uncertainty across the ecosystem. Other consensus features as well as external products and services can begin relying on this design decision. (Nuance: this does not answer the question of what people should or will do in the event of such a rollback. It simply ensures that no one will naively or accidentally proceed in a business-as-usual manner in this event thus protecting them from harm.)

Custodian Reinforcement

Github: zcash #3679

zcash #3679 What is it? This includes a variety of potential features that can potentially protect typical end-users as well as specialized custodians. This may include recipient address verification, “vault functionality”, “I Got Burgled Button”, transaction cancellation, or transfer rate limiting functionality.

This includes a variety of potential features that can potentially protect typical end-users as well as specialized custodians. This may include recipient address verification, “vault functionality”, “I Got Burgled Button”, transaction cancellation, or transfer rate limiting functionality. Who does this affect? All users.

All users. Why is this a goal? A substantial weakness of cryptocurrencies is how difficult self-custody is for wide user bases. By introducing protocol features that can help users protect themselves against theft or loss and/or enable custodian providers to reduce their operational risk, we aim to make Zcash safer for a larger user base.

What’s Next?

I’m going to be making “feature requirements” github tickets for these goals, and then we will move the feature requirements gathering and feature selection processes into github.

After that, I’ll be working with Zcash developers (both inside and outside the Zcash Company) to work on feature requirements for specific goals, while we also begin a new “product validation” process. Additionally, I’ll be seeking out feedback from a variety of sources.

Scope

What about other upgrades, other potential goals, or non-consensus features? These are all out of scope for this early Blossom planning. That doesn’t mean they aren’t important!

We’re aiming to start longer ranging R&D for future upgrades in early 2019. As feedback and ideas flow in around Blossom goals, we might incorporate those into Blossom or later ugprades.

Additionally, there are key feature areas outside of consensus rules we plan to put on our roadmap, such as improvements to the networking layer.

Thanks and carry on with encrypting things,

Nathan