WIP

Author: daira

zips/zip-0001.md

@@ -0,0 +1,125 @@
+
+    ZIP: 1
+    Title: Network Upgrade Policy and Scheduling
+    Owners: Kris Nuttycombe <kris@nutty.land>
+            Daira-Emma Hopwood <daira-emma@electriccoin.co>
+    Status: Draft  
+    Category: Process
+    Created: 2025-08-25
+    License: MIT
+    Discussions-To: <https://github.com/zcash/zips/issues/343>
+
+
+# Terminology
+
+The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this
+document are to be interpreted as described in BCP 14 [^BCP14] when, and
+only when, they appear in all capitals.
+
+The terms "Mainnet" and "Testnet" in this document are to be interpreted as
+defined in the Zcash protocol specification [^protocol-networks].
+
+
+# Abstract
+
+This document aims to describe the process of preparing and executing a
+Zcash Network Upgrade, including:
+
+- The interaction of EoS halts with the release of NU-supporting software.
+  - When must nodes halt by that do not support an upcoming NU?
+- How NU activation heights are chosen, and the point at which they're made
+  public in sw releases.
+- The minimum time that the ecosystem needs to have to upgrade to an
+  NU-supporting release.
+- Audit requirements for upgrades.
+- Boilerplate requirements:
+  - activation ZIP
+  - consensus branch ID (partially covered by ZIP 200)
+  - version group ID if needed
+  - protocol spec changes
+  - differences between Testnet and Mainnet
+  - peer protocol versions
+- ZIP Editors' responsibilities for an NU
+- Governance issues
+- What happens if there is a security issue or other problem that necessitates a change
+  to the NU-supporting release?
+  - before Testnet activation
+  - after Testnet activation & before release of node s/w that sets the Mainnet activation height
+  - after the release of node s/w that sets the Mainnet activation height & before Mainnet activation
+  - after Mainnet activation
+
+
+# Motivation
+
+The Zcash network performs hard-forking upgrades following the full node coordination mechanism specified in ZIP 200 [^zip-0200] when changes are made to the consensus rules. In order for the network to continue operating without interruption at network upgrade boundaries, node implementers must coordinate in order to ensure that the nodes that are active on the network at the time of such an upgrade are all running compatible software.
+
+Various documents have been written in the past that attempted to provide frameworks or documentation for the network upgrade process at an "engineers working on the Zcash protocol" level:
+
+- [Network Upgrade Pipeline 1.0](https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/)
+- Network Upgrade Pipeline 1.1
+- [Network Upgrade Pipeline 1.2](https://docs.google.com/drawings/d/1WAvIkVBv_fC4L4wDoAJaMTYVh3dJbwhR5YuP5HgOjFw/edit)
+  - This was followed for NU3 and NU4.
+- [Network Upgrade Pipeline 2.0](https://electriccoin.co/blog/network-upgrade-pipeline-2-0/)
+  - This was followed for NU5 and (to some extent) NU6.
+- [Deadlines for ZIPs that want to be activated in NU7](https://forum.zcashcommunity.com/t/important-deadline-for-zips-that-want-to-be-activated-in-nu7/48998)
+
+These past attempts have suffered from several issues:
+- They were designed and used at a time when there was either one single feature being deployed in a network upgrade, or one single entity (usually the Electric Coin Company) developing all the NU's features. As such, and despite best efforts, they were ntot well-suited for parallelization.
+- TODO: Document other issues from past attempts that this ZIP is trying to solve.
+
+By following the steps specified by this ZIP, and ensuring that the required timelines are adhered to by node implementers, the Zcash network can maintain uninterrupted continuity of service.
+
+
+
+# Requirements
+
+
+
+# Non-requirements
+
+
+
+# Specification
+
+## End-Of-Service Halts
+
+Prior to a network upgrade, all nodes that do not support the network upgrade MUST have reached their end-of-service halt height at least 16384 blocks prior to the network upgrade's ac
+ho do not upgrade their node software until the end-of-service halt occurs have ample ivation height. This ensures that entities w
+
+## Timeline
+
+### Research and Development
+
+### ZIP Review
+
+### Specification
+
+### Auditing
+
+#### Auditor selection
+
+#### Specification auditing
+
+#### Implementation auditing
+
+### Testing
+
+### Partner adoptio
+
+# Reference implementation
+
+
+
+# References
+
+[^BCP14]: [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14)
+
+[^protocol]: [Zcash Protocol Specification, Version 2024.5.1 or later](protocol/protocol.pdf)
+
+[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks)
+
+[^zip-0000]: [ZIP 0: ZIP Process](zip-0000.rst)
+
+[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst)
+
+[^zip-0201]: [ZIP 201: Network Peer Management for Overwinter](zip-0201.rst)