With the successful activation of Sapling, the Zcash Company engineering team is focused on two strategic priorities in 2019: facilitating the adoption of a shielded standard throughout the ecosystem and, designing and implementing our next protocol upgrade—dubbed Zcash Blossom.
We’re in the early phases of defining the technical goals for Blossom, which we plan to activate in October of 2019. If you’re eager to dig into those feature goals, I recommend reading my forum post, Announcing Zcash Blossom and proposed feature goals.
For this post, I’d like to focus on the process we’re using to safely ship new protocol upgrades in Zcash, which we call the Zcash Network Upgrade Pipeline. We’ve developed this process to meet a variety of goals, based on everything we’ve learned from the Zcash launch and the Overwinter and Sapling upgrades. The primary goals are to ship safely—with plenty of time for ecosystem partner integration, in collaboration across multiple organizations—in a governance agnostic manner, all while pipelining concurrent upgrades.
The Pipeline at a Glance
The Network Upgrade Pipeline defines a scheduled sequence of coordination points to bring consensus features from the speculative realm down into the production Zcash network.
This process is time-based and designed to ensure the consensus upgrades shipped to Zcash meet our historic standards for safety and quality. It is intended to support the development of multiple subsequent upgrades concurrently, thus the term “pipeline.” The Zcash Company aims to set a consistent pace of two upgrades per year, indicated as Upgrade A and Upgrade B in the diagram.
The coordination points, represented by red-outlined diamonds in this chart, signify essential, high-level milestones that must be fulfilled for a given feature set to ship on-time, in every case embodied as a deliverable. These milestones represent “input points” for protocol changes for the Company, the Foundation and the wider community. If someone from the Foundation or community wants to submit a change to Zcash that requires a network upgrade, they need to ensure their ZIPs hit each of these milestones.
The colors and vertical separation for different phases distinguishes a division of roles. Many of these coordination points involve a hand-off from a submitting role to an accepting role. For example, an R&D Lead delivers a set of feature requirements to a Specification Lead. For these hand-offs, it’s the responsibility of the accepting role to ensure the deliverable meets the requirements before proceeding with their subsequent responsibility.
We intend to simplify the logistics of collaboration across development teams by clarifying these roles, the deliverables, the hand-offs, and which role has the ability to ensure the process is on-track and meets our quality standards.
Open Collaboration and Evolving Governance
The Network Upgrade Pipeline is an execution process, not a governance or evaluation process. It doesn’t define how decisions are made, although it does clarify roles for making “execution decisions,” such as if a proposed specification meets the criteria to begin implementation and design audits.
We believe that by nailing down the execution process, we can clarify and simplify the much harder and crucial concerns of decision making, governance, and stakeholdership. The Zcash Company is following this process for the Blossom upgrade while collaborating with development teams outside the company. We’ll share more as those collaborations develop.
We anticipate the Network Upgrade Pipeline will work well while running continuously, even while governance evolves across the Zcash ecosystem.