diff --git a/.github/workflows/render.yml b/.github/workflows/render.yml index 11fbb8ccc..817429aaa 100644 --- a/.github/workflows/render.yml +++ b/.github/workflows/render.yml @@ -13,8 +13,8 @@ jobs: steps: - name: Checkout repository uses: actions/checkout@v4.1.7 - with: - token: ${{ secrets.CI_TOKEN }} + # with: + # token: ${{ secrets.CI_TOKEN }} - name: Compile ZIPs and Zcash Protocol Specification uses: ./.github/actions/render diff --git a/Makefile b/Makefile index 660e2d7aa..67edd0845 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ # Dependencies: see zip-guide.rst and protocol/README.rst -.PHONY: all all-zips tag-release protocol discard +.PHONY: all-zips all tag-release protocol all-protocol discard all-zips: .Makefile.uptodate echo "$(patsubst zips/%,%,$(sort $(wildcard zips/zip-*.rst) $(wildcard zips/zip-*.md)))" >.zipfilelist.new diff .zipfilelist.current .zipfilelist.new || cp -f .zipfilelist.new .zipfilelist.current @@ -11,13 +11,16 @@ all-zips: .Makefile.uptodate $(MAKE) README.rst $(MAKE) rendered/index.html $(addprefix rendered/,$(addsuffix .html,$(basename $(patsubst zips/%,%,$(sort $(wildcard zips/*.rst) $(wildcard zips/*.md)))))) -all: all-zips protocol +all: all-zips all-protocol tag-release: $(MAKE) -C protocol tag-release protocol: - $(MAKE) -C protocol + $(MAKE) -C protocol protocol + +all-protocol: + $(MAKE) -C protocol all discard: git checkout -- 'rendered/*.html' 'README.rst' 'rendered/protocol/*.pdf' @@ -50,11 +53,13 @@ rendered/%.html: zips/%.md edithtml.sh README.rst: .zipfilelist.current .draftfilelist.current makeindex.sh README.template $(wildcard zips/zip-*.rst) $(wildcard zips/zip-*.md) $(wildcard zips/draft-*.rst) $(wildcard zips/draft-*.md) ./makeindex.sh | cat README.template - >README.rst -.PHONY: linkcheck -linkcheck: all-zips - $(MAKE) -C protocol all-specs - ./links_and_dests.py --check $(filter-out $(wildcard rendered/draft-*.html),$(wildcard rendered/*.html)) rendered/protocol/protocol.pdf rendered/protocol/canopy.pdf rendered/protocol/heartwood.pdf rendered/protocol/blossom.pdf rendered/protocol/sapling.pdf +.PHONY: linkcheck clean all-clean +linkcheck: all + ./links_and_dests.py --check $(filter-out $(wildcard rendered/draft-*.html),$(wildcard rendered/*.html)) $(filter-out rendered/protocol/sprout.pdf,$(wildcard rendered/protocol/*.pdf)) -.PHONY: clean clean: rm -f .zipfilelist.* README.rst rendered/index.html $(addprefix rendered/,$(addsuffix .html,$(basename $(patsubst zips/%,%,$(sort $(wildcard zips/*.rst) $(wildcard zips/*.md)))))) + +all-clean: + $(MAKE) clean + $(MAKE) -C protocol clean diff --git a/README.rst b/README.rst index 6a9101c99..79183863e 100644 --- a/README.rst +++ b/README.rst @@ -72,7 +72,7 @@ Released ZIPs 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 221 FlyClient - Consensus-Layer Changes Final @@ -84,6 +84,7 @@ Released ZIPs 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Final 252 Deployment of the NU5 Network Upgrade Final + 253 Deployment of the NU6 Network Upgrade Proposed 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 308 Sprout to Sapling Migration Final @@ -93,6 +94,8 @@ Released ZIPs 321 Payment Request URIs Proposed 401 Addressing Mempool Denial-of-Service Active 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed Draft ZIPs @@ -124,9 +127,10 @@ written. 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Decouple Memos from Transaction Outputs Reserved + 233 Establish the Zcash Sustainability Fund on the Protocol Level Draft + 234 Smooth Out The Block Subsidy Issuance Draft 236 Blocks should balance exactly Draft 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft - 253 Deployment of the NU6 Network Upgrade Draft 302 Standardized Memo Field Format Draft 303 Sprout Payment Disclosure Reserved 304 Sapling Address Signatures Draft @@ -150,7 +154,6 @@ written. 402 New Wallet Database Format Reserved 403 Verification Behaviour of zcashd Reserved 416 Support for Unified Addresses in zcashd Reserved - 2001 Lockbox Funding Streams Draft guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft @@ -232,7 +235,7 @@ Index of ZIPs 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 217 Aggregate Signatures Reserved @@ -247,6 +250,8 @@ Index of ZIPs 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Decouple Memos from Transaction Outputs Reserved + 233 Establish the Zcash Sustainability Fund on the Protocol Level Draft + 234 Smooth Out The Block Subsidy Issuance Draft 236 Blocks should balance exactly Draft 239 Relay of Version 5 Transactions Final 243 Transaction Signature Validation for Sapling Final @@ -255,7 +260,7 @@ Index of ZIPs 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Final 252 Deployment of the NU5 Network Upgrade Final - 253 Deployment of the NU6 Network Upgrade Draft + 253 Deployment of the NU6 Network Upgrade Proposed 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 302 Standardized Memo Field Format Draft @@ -302,7 +307,8 @@ Index of ZIPs 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 2001 Lockbox Funding Streams Draft + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft diff --git a/protocol/Makefile b/protocol/Makefile index 72b82bdab..c24798d95 100644 --- a/protocol/Makefile +++ b/protocol/Makefile @@ -20,12 +20,16 @@ PDFDIR=../rendered/protocol # Use EXTRAOPT=-pvc for "continuous preview" mode. For example, "make auxblossom EXTRAOPT=-pvc". # In this case the updated .pdf will be in the aux/ directory. -.PHONY: all all-specs release discard +.PHONY: all protocol all-specs tag-release discard all: .Makefile.uptodate - $(MAKE) nu5 canopy heartwood blossom sapling + $(MAKE) $(PDFDIR)/nu6.pdf $(PDFDIR)/nu5.pdf $(PDFDIR)/canopy.pdf $(PDFDIR)/heartwood.pdf $(PDFDIR)/blossom.pdf $(PDFDIR)/sapling.pdf + $(MAKE) protocol + +protocol: $(PDFDIR)/nu5.pdf + cp -f $(PDFDIR)/nu5.pdf $(PDFDIR)/protocol.pdf all-specs: .Makefile.uptodate - $(MAKE) $(PDFDIR)/nu5.pdf $(PDFDIR)/canopy.pdf $(PDFDIR)/heartwood.pdf $(PDFDIR)/blossom.pdf $(PDFDIR)/sapling.pdf + $(MAKE) nu6 nu5 canopy heartwood blossom sapling tag-release: ifeq ($(shell git tag --points-at HEAD |wc -l),0) @@ -47,22 +51,25 @@ discard: $(MAKE) clean touch .Makefile.uptodate -$(PDFDIR)/sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/sapling.pdf: protocol.tex zcash.bib jubjub.png key_components_sapling.png key_components_orchard.png incremental_merkle.png $(MAKE) sapling -$(PDFDIR)/blossom.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/blossom.pdf: protocol.tex zcash.bib jubjub.png key_components_sapling.png key_components_orchard.png incremental_merkle.png $(MAKE) blossom -$(PDFDIR)/heartwood.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/heartwood.pdf: protocol.tex zcash.bib jubjub.png key_components_sapling.png key_components_orchard.png incremental_merkle.png $(MAKE) heartwood -$(PDFDIR)/canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/canopy.pdf: protocol.tex zcash.bib jubjub.png key_components_sapling.png key_components_orchard.png incremental_merkle.png $(MAKE) canopy -$(PDFDIR)/nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png +$(PDFDIR)/nu5.pdf: protocol.tex zcash.bib jubjub.png key_components_sapling.png key_components_orchard.png incremental_merkle.png $(MAKE) nu5 -.PHONY: auxsapling +$(PDFDIR)/nu6.pdf: protocol.tex zcash.bib jubjub.png key_components_sapling.png key_components_orchard.png incremental_merkle.png + $(MAKE) nu6 + +.PHONY: auxsapling sapling auxsapling: printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver mkdir -p aux @@ -70,12 +77,11 @@ auxsapling: cp mymakeindex.sh aux $(LATEXMK) -jobname=sapling -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) -.PHONY: sapling sapling: $(MAKE) auxsapling mv -f aux/sapling.pdf $(PDFDIR) -.PHONY: auxblossom +.PHONY: auxblossom blossom auxblossom: printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver mkdir -p aux @@ -83,12 +89,11 @@ auxblossom: cp mymakeindex.sh aux $(LATEXMK) -jobname=blossom -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) -.PHONY: blossom blossom: $(MAKE) auxblossom mv -f aux/blossom.pdf $(PDFDIR) -.PHONY: auxheartwood +.PHONY: auxheartwood heartwood auxheartwood: printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver mkdir -p aux @@ -96,12 +101,11 @@ auxheartwood: cp mymakeindex.sh aux $(LATEXMK) -jobname=heartwood -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) -.PHONY: heartwood heartwood: $(MAKE) auxheartwood mv -f aux/heartwood.pdf $(PDFDIR) -.PHONY: auxcanopy +.PHONY: auxcanopy canopy auxcanopy: printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver mkdir -p aux @@ -109,12 +113,11 @@ auxcanopy: cp mymakeindex.sh aux $(LATEXMK) -jobname=canopy -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) -.PHONY: canopy canopy: $(MAKE) auxcanopy mv -f aux/canopy.pdf $(PDFDIR) -.PHONY: auxnu5 +.PHONY: auxnu5 nu5 auxnu5: printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver mkdir -p aux @@ -122,73 +125,22 @@ auxnu5: cp mymakeindex.sh aux $(LATEXMK) -jobname=nu5 -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) -.PHONY: nu5 nu5: $(MAKE) auxnu5 mv -f aux/nu5.pdf $(PDFDIR) - cp -f $(PDFDIR)/nu5.pdf $(PDFDIR)/protocol.pdf -.PHONY: nolatexmk-sapling -nolatexmk-sapling: - printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - # If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time. - rm -f sapling.aux sapling.bbl sapling.blg sapling.brf sapling.bcf - $(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; } - biber sapling - $(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; } - $(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; } - sh mymakeindex.sh -o sapling.ind sapling.idx - $(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; } - -.PHONY: nolatexmk-blossom -nolatexmk-blossom: - printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - # If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time. - rm -f blossom.aux blossom.bbl blossom.blg blossom.brf blossom.bcf - $(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; } - biber blossom - $(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; } - $(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; } - sh mymakeindex.sh -o blossom.ind blossom.idx - $(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; } - cp -f blossom.pdf protocol.pdf - -.PHONY: nolatexmk-heartwood -nolatexmk-heartwood: - printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - # If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time. - rm -f heartwood.aux heartwood.bbl heartwood.blg heartwood.brf heartwood.bcf - $(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; } - biber heartwood - $(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; } - $(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; } - sh mymakeindex.sh -o heartwood.ind heartwood.idx - $(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; } - -.PHONY: nolatexmk-canopy -nolatexmk-canopy: - printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - # If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time. - rm -f canopy.aux canopy.bbl canopy.blg canopy.brf canopy.bcf - $(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; } - biber canopy - $(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; } - $(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; } - sh mymakeindex.sh -o canopy.ind canopy.idx - $(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; } - -.PHONY: nolatexmk-nu5 -nolatexmk-nu5: - printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - # If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time. - rm -f nu5.aux nu5.bbl nu5.blg nu5.brf nu5.bcf - $(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; } - biber nu5 - $(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; } - $(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; } - sh mymakeindex.sh -o nu5.ind nu5.idx - $(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; } +.PHONY: auxnu6 nu6 +auxnu6: + printf '\\toggletrue{isnusix}\n\\renewcommand{\\docversion}{Version %s [\\NUSixSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver + mkdir -p aux + rm -f aux/nu6.* + cp mymakeindex.sh aux + $(LATEXMK) -jobname=nu6 -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) + +nu6: + $(MAKE) auxnu6 + mv -f aux/nu6.pdf $(PDFDIR) .PHONY: clean clean: - rm -f aux/* html/* protocol.ver $(PDFDIR)/protocol.pdf $(PDFDIR)/nu5.pdf $(PDFDIR)/canopy.pdf $(PDFDIR)/heartwood.pdf $(PDFDIR)/blossom.pdf $(PDFDIR)/sapling.pdf + rm -f aux/* protocol.ver $(PDFDIR)/protocol.pdf $(PDFDIR)/nu6.pdf $(PDFDIR)/nu5.pdf $(PDFDIR)/canopy.pdf $(PDFDIR)/heartwood.pdf $(PDFDIR)/blossom.pdf $(PDFDIR)/sapling.pdf diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 53f3a283e..bf9e6c1cf 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -552,6 +552,7 @@ \newcommand{\HeartwoodSpec}{Overwinter+Sapling+Blossom+Heartwood} \newcommand{\CanopySpec}{Overwinter+Sapling+Blossom+Heartwood+Canopy} \newcommand{\NUFiveSpec}{NU5} +\newcommand{\NUSixSpec}{NU6} \newtoggle{issapling} \togglefalse{issapling} \newtoggle{isblossom} @@ -562,6 +563,8 @@ \togglefalse{iscanopy} \newtoggle{isnufive} \togglefalse{isnufive} +\newtoggle{isnusix} +\togglefalse{isnusix} \InputIfFileExists{protocol.ver}{}{} \newcommand{\doctitle}{Zcash Protocol Specification} @@ -594,10 +597,26 @@ \newcommand{\canopycolorname}{purple} \newcommand{\nufivecolor}{black!25!blue!65!green!65} \newcommand{\nufivecolorname}{slate blue} +\newcommand{\nusixcolor}{magenta!75} +\newcommand{\nusixcolorname}{pink} \newcommand{\labelcolor}{yellow!20} -\iftoggle{isnufive}{ +\iftoggle{isnusix}{ \providecommand{\baseurl}{https://zips.z.cash/protocol/protocol.pdf} + \toggletrue{isnufive} + \newcommand{\setnusix}{\color{\nusixcolor}} + \newcommand{\nusix}[1]{\texorpdfstring{{\setnusix{#1}}}{#1}} + \newcommand{\notnusix}[1]{} + \newcommand{\notbeforenusix}[1]{#1} +} { + \newcommand{\setnusix}{} + \newcommand{\nusix}[1]{} + \newcommand{\notnusix}[1]{#1} + \newcommand{\notbeforenusix}[1]{} +} + +\iftoggle{isnufive}{ + \providecommand{\baseurl}{https://zips.z.cash/protocol/nu5.pdf} \toggletrue{iscanopy} \newcommand{\setnufive}{\color{\nufivecolor}} \newcommand{\nufive}[1]{\texorpdfstring{{\setnufive{#1}}}{#1}} @@ -725,17 +744,13 @@ \newcommand{\Sprout}{\termbf{Sprout}} \newcommand{\SproutText}{\textbf{Sprout}} \newcommand{\Overwinter}{\termbf{Overwinter}} -\newcommand{\OverwinterText}{\textbf{Overwinter}} \newcommand{\Sapling}{\termbf{Sapling}} \newcommand{\SaplingText}{\textbf{Sapling}} \newcommand{\Blossom}{\termbf{Blossom}} -\newcommand{\BlossomText}{\textbf{Blossom}} \newcommand{\Heartwood}{\termbf{Heartwood}} -\newcommand{\HeartwoodText}{\textbf{Heartwood}} \newcommand{\Canopy}{\termbf{Canopy}} -\newcommand{\CanopyText}{\textbf{Canopy}} \newcommand{\NUFive}{\readasunicode{004e200b0055200b0035}{\termbf{NU5}}\xspace} -%\newcommand{\NUFiveText}{\textbf{NU5}} +\newcommand{\NUSix}{\readasunicode{004e200b0055200b0036}{\termbf{NU6}}\xspace} \newcommand{\Orchard}{\termbf{Orchard}} \newcommand{\OrchardText}{\textbf{Orchard}} \newcommand{\SaplingOrOrchard}{\Sapling{}\nufive{ or \Orchard{}}\xspace} @@ -2451,6 +2466,8 @@ \newcommand{\consensusrule}[1]{\needspace{4ex}\vspace{2ex}\callout{}{Consensus rule:}{#1}} \newenvironment{consensusrules}{\introlist\callout{}{Consensus rules:}\begin{itemize}}{\end{itemize}} +\newcommand{\prenusixitem}[1]{\item \prenusix{#1}} +\newcommand{\nusixonwarditem}[1]{\nusix{\item {[\NUSix onward]}\, {#1}}} \newcommand{\prenufiveitem}[1]{\item \prenufive{#1}} \newcommand{\nufiveonwarditem}[1]{\nufive{\item {[\NUFive onward]}\, {#1}}} \newcommand{\precanopyitem}[1]{\item \precanopy{#1}} @@ -2470,6 +2487,8 @@ \newcommand{\overwinterprenufiveitem}[1]{\overwinter{\item \overwinterprenufive{#1}}} \newcommand{\sproutspecificitem}[1]{\item \sproutspecific{#1}} +\newcommand{\prenusix}[1]{\notbeforenusix{\nusix{[Pre-\NUSix\!]\,}} {#1}} +\newcommand{\nusixonward}[1]{\nusix{[\NUSix onward]\, {#1}}} \newcommand{\prenufive}[1]{\notbeforenufive{\nufive{[Pre-\NUFive\!]\,}} {#1}} \newcommand{\nufiveonward}[1]{\nufive{[\NUFive onward]\, {#1}}} \newcommand{\precanopy}[1]{\notbeforecanopy{\canopy{[Pre-\Canopy\!]\,}} {#1}} @@ -2497,6 +2516,8 @@ \newcommand{\nnote}[1]{\needspace{4ex}\vspace{2ex}\callout{}{Non-normative note:}{#1}} \newenvironment{nnotes}{\introlist\callout{}{Non-normative notes:}\begin{itemize}}{\end{itemize}} +\newcommand{\nusixonwardnnote}[1]{\nusix{\callout{[\NUSix onward]\,\,}{Non-normative note:}{#1}}} +\newcommand{\nusixonwardpnote}[1]{\nusix{\callout{[\NUSix onward]\,\,}{Note:}{#1}}} \newcommand{\nufiveonwardnnote}[1]{\nufive{\callout{[\NUFive onward]\,\,}{Non-normative note:}{#1}}} \newcommand{\nufiveonwardpnote}[1]{\nufive{\callout{[\NUFive onward]\,\,}{Note:}{#1}}} \newcommand{\canopyonwardnnote}[1]{\canopy{\callout{[\Canopy onward]\,\,}{Non-normative note:}{#1}}} @@ -2544,26 +2565,15 @@ memory-hard \proofOfWork algorithm. \vspace{1.5ex} -\notblossom{\sapling{\noindent This specification defines the \Zcash consensus protocol -at launch; after the upgrade codenamed \Overwinter; and after the -subsequent upgrade codenamed \Sapling. It is a work in progress. -Protocol differences from \Zerocash and \Bitcoin are also explained.}} -\notheartwood{\blossom{\noindent This specification defines the \Zcash consensus protocol -at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, and -\Blossom. It is a work in progress. Protocol differences from \Zerocash and -\Bitcoin are also explained.}} -\notcanopy{\heartwood{\noindent This specification defines the \Zcash consensus protocol -at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom, -and \Heartwood. It is a work in progress. Protocol differences from \Zerocash and -\Bitcoin are also explained.}} -\notnufive{\canopy{\noindent This specification defines the \Zcash consensus protocol -at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom, -\Heartwood, and \Canopy. It is a work in progress. Protocol differences from \Zerocash and -\Bitcoin are also explained.}} -\nufive{\noindent This specification defines the \Zcash consensus protocol -at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom, -\Heartwood, \Canopy, and \NUFive. It is a work in progress. Protocol differences from -\Zerocash and \Bitcoin are also explained.} +\newcommand{\thisspecdefines}[1]{This specification defines the \Zcash consensus protocol at launch, and after each of the upgrades codenamed {#1}.} +\noindent \notblossom{\sapling{\thisspecdefines{\Overwinter and \Sapling}}}% +\notheartwood{\blossom{\thisspecdefines{\Overwinter, \Sapling, and \Blossom}}}% +\notcanopy{\heartwood{\thisspecdefines{\Overwinter, \Sapling, \Blossom, and \Heartwood}}}% +\notnufive{\canopy{\thisspecdefines{\Overwinter, \Sapling, \Blossom, \Heartwood, and \Canopy}}}% +\notnusix{\nufive{\thisspecdefines{\Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, and \NUFive}}}% +\nusix{This specification defines the \Zcash consensus protocol at launch; after each of the upgrades +codenamed \Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, and \NUFive; and proposed changes for \NUSix.} % +It is a work in progress. Protocol differences from \Zerocash and \Bitcoin are also explained. \vspace{2.5ex} \noindent \textbf{Keywords:}~ \StrSubstitute[0]{\keywords}{,}{, }. @@ -2632,6 +2642,9 @@ \notbeforenufive{Changes specific to the \NUFive upgrade following \Canopy are highlighted in \nufive{\nufivecolorname}.} +\notbeforenusix{Changes specific to the proposed \NUSix upgrade following \NUFive +are highlighted in \nusix{\nusixcolorname}.} + All of these are also changes from \Zerocash. The name \Sprout is used for the \Zcash protocol prior to \Sapling (both before and after \Overwinter), and in particular its shielded protocol. @@ -12428,10 +12441,15 @@ \cite{ZIP-212}, \cite{ZIP-213}, and \cite{ZIP-221}. Additional information and rationale is given in \cite{Zcash-Orchard} and \cite{Zcash-halo2}.} +\nusix{ +This draft specification describes the set of changes proposed for the \NUSix \networkUpgrade +(for which a \Mainnet activation height has not yet been set). +} %nusix + \introlist \vspace{1ex} This section summarizes the strategy for upgrading from \Sprout to subsequent versions -of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, and \NUFive), +of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, \NUFive, and \NUSix), and for future upgrades. \defining{The \networkUpgrade mechanism is described in \cite{ZIP-200}.} @@ -14811,7 +14829,7 @@ \intropart \lsection{Change History}{changehistory} -\historyentry{Unreleased}{2024-04-14} +\historyentry{2024.5.0}{2024-08-28} \begin{itemize} \item Add the hyphen in \nh{Daira-Emma} Hopwood. @@ -14819,6 +14837,7 @@ \item Prevent incorrect line-breaking on hyphens. \item In \crossref{concretesinsemillahash}, declare use of $\LEBStoIP{}$ instead of $\LEOStoIP{}$. \item Add an acknowledgement to Conrado Gouvea for discussions on the Zcash protocol. + \item Add boilerplate support for \NUSix. \end{itemize} diff --git a/rendered/draft-noamchom67-manufacturing-consent.html b/rendered/draft-noamchom67-manufacturing-consent.html index e5bdf1b9c..8a4bf2958 100644 --- a/rendered/draft-noamchom67-manufacturing-consent.html +++ b/rendered/draft-noamchom67-manufacturing-consent.html @@ -10,7 +10,7 @@ Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub Owner: Noam Chom <noamchom1967@gmail.com> Credits: The ZIP-1014 Authors -Status: Active +Status: Withdrawn Category: Consensus Process Created: 2024-06-25 License: MIT diff --git a/rendered/draft-nuttycom-funding-allocation.html b/rendered/draft-nuttycom-funding-allocation.html index 873d30463..1f1c1a17b 100644 --- a/rendered/draft-nuttycom-funding-allocation.html +++ b/rendered/draft-nuttycom-funding-allocation.html @@ -14,7 +14,7 @@ Credits: Daira-Emma Hopwood Jack Grigg @Peacemonger (Zcash Forum) -Status: Draft +Status: Withdrawn Category: Consensus Created: 2024-07-03 License: MIT diff --git a/rendered/draft-zf-community-dev-fund-2-proposal.html b/rendered/draft-zf-community-dev-fund-2-proposal.html index 4fdd60eab..13c5b253e 100644 --- a/rendered/draft-zf-community-dev-fund-2-proposal.html +++ b/rendered/draft-zf-community-dev-fund-2-proposal.html @@ -10,7 +10,7 @@ Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve Owners: Jack Gavigan <jack@zfnd.org> Credits: The ZIP 1014 Authors -Status: Draft +Status: Withdrawn Category: Consensus Process Created: 2024-07-01 License: MIT diff --git a/rendered/index.html b/rendered/index.html index 8ee5e0a9c..4837413ba 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -47,7 +47,7 @@ 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 221 FlyClient - Consensus-Layer Changes Final @@ -59,6 +59,7 @@ 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Final 252 Deployment of the NU5 Network Upgrade Final + 253 Deployment of the NU6 Network Upgrade Proposed 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 308 Sprout to Sapling Migration Final @@ -68,6 +69,8 @@ 321 Payment Request URIs Proposed 401 Addressing Mempool Denial-of-Service Active 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed

Draft ZIPs

These are works-in-progress that have been assigned ZIP numbers. These will eventually become either Proposed (and thus Released), or one of Withdrawn, Rejected, or Obsolete.

@@ -89,9 +92,10 @@ 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Decouple Memos from Transaction Outputs Reserved + 233 Establish the Zcash Sustainability Fund on the Protocol Level Draft + 234 Smooth Out The Block Subsidy Issuance Draft 236 Blocks should balance exactly Draft 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft - 253 Deployment of the NU6 Network Upgrade Draft 302 Standardized Memo Field Format Draft 303 Sprout Payment Disclosure Reserved 304 Sapling Address Signatures Draft @@ -115,7 +119,6 @@ 402 New Wallet Database Format Reserved 403 Verification Behaviour of zcashd Reserved 416 Support for Unified Addresses in zcashd Reserved - 2001 Lockbox Funding Streams Draft guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft
@@ -178,7 +181,7 @@ 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 217 Aggregate Signatures Reserved @@ -193,6 +196,8 @@ 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Decouple Memos from Transaction Outputs Reserved + 233 Establish the Zcash Sustainability Fund on the Protocol Level Draft + 234 Smooth Out The Block Subsidy Issuance Draft 236 Blocks should balance exactly Draft 239 Relay of Version 5 Transactions Final 243 Transaction Signature Validation for Sapling Final @@ -201,7 +206,7 @@ 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Final 252 Deployment of the NU5 Network Upgrade Final - 253 Deployment of the NU6 Network Upgrade Draft + 253 Deployment of the NU6 Network Upgrade Proposed 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 302 Standardized Memo Field Format Draft @@ -248,7 +253,8 @@ 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 2001 Lockbox Funding Streams Draft + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft diff --git a/rendered/protocol/blossom.pdf b/rendered/protocol/blossom.pdf index 6ebbbe543..e8a948e4e 100644 Binary files a/rendered/protocol/blossom.pdf and b/rendered/protocol/blossom.pdf differ diff --git a/rendered/protocol/canopy.pdf b/rendered/protocol/canopy.pdf index bd1cb8897..e8a9667ab 100644 Binary files a/rendered/protocol/canopy.pdf and b/rendered/protocol/canopy.pdf differ diff --git a/rendered/protocol/heartwood.pdf b/rendered/protocol/heartwood.pdf index ba7423ba5..9faa3e3dc 100644 Binary files a/rendered/protocol/heartwood.pdf and b/rendered/protocol/heartwood.pdf differ diff --git a/rendered/protocol/nu5.pdf b/rendered/protocol/nu5.pdf index 6091c70e2..94332100c 100644 Binary files a/rendered/protocol/nu5.pdf and b/rendered/protocol/nu5.pdf differ diff --git a/rendered/protocol/protocol.pdf b/rendered/protocol/protocol.pdf index 6091c70e2..94332100c 100644 Binary files a/rendered/protocol/protocol.pdf and b/rendered/protocol/protocol.pdf differ diff --git a/rendered/protocol/sapling.pdf b/rendered/protocol/sapling.pdf index 8304c988d..ebed3fa37 100644 Binary files a/rendered/protocol/sapling.pdf and b/rendered/protocol/sapling.pdf differ diff --git a/rendered/zip-0000.html b/rendered/zip-0000.html index 83e34a33f..a0be30265 100644 --- a/rendered/zip-0000.html +++ b/rendered/zip-0000.html @@ -11,6 +11,7 @@ Owners: Jack Grigg <str4d@electriccoin.co> Conrado Gouvêa <conrado@zfnd.org> Arya <arya@zfnd.org> + Kris Nuttycombe <kris@nutty.land> Original-Authors: Daira-Emma Hopwood Josh Cincinnati George Tankersley @@ -60,7 +61,7 @@

ZIP Editors

The current ZIP Editors are:

All can be reached at zips@z.cash. The current design of the ZIP Process dictates that there are always at least two ZIP Editors: at least one from the Electric Coin Company and at least one from the Zcash Foundation.

diff --git a/rendered/zip-0214.html b/rendered/zip-0214.html index 1e49cae61..be8647c76 100644 --- a/rendered/zip-0214.html +++ b/rendered/zip-0214.html @@ -9,44 +9,135 @@ 
ZIP: 214
 Title: Consensus rules for a Zcash Development Fund
 Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
-Status: Final
+        Kris Nuttycombe <kris@nutty.land>
+Status: Revision 0: Final, Revision 1: Draft
 Category: Consensus
 Created: 2020-02-28
 License: MIT
 Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>

Terminology

The key words "MUST", "SHALL", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

-

The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (6 or successor agreement).

+

The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (6 or successor agreement) while that agreement is in effect. On termination of that agreement, the term "Zcash" will refer to the continuations of the same Mainnet and Testnet block chains as determined by social consensus.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200 8 and the Zcash Trademark Donation and License Agreement (6 or successor agreement).

The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification 3.

The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification 5.

-

The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 12.

-

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 4.

+

The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 13.

+

The terms "Zcash Community Grants (or "ZCG") and "Financial Privacy Foundation" (or "FPF") in this document are to be interpreted as described in ZIP 1015 14.

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 4.

"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.

+

"NU6" is the code-name for the seventh Zcash network upgrade, also known as Network Upgrade 6.

Abstract

-

This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

+

Revision 0 of this ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

+

Revision 1 of this ZIP describes consensus rule changes related to funding of Zcash development via block rewards, to be enacted at Network Upgrade 6 and lasting for 1 year.

Applicability

This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.

Motivation

-

Motivation for the Zcash Development Fund itself is considered in ZIP 1014 12, which gives a high-level description of the intended structure of the fund.

-

An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.

+

Motivation for the Zcash Development Fund itself is considered in ZIPs 1014 13 and 1015 14, which give high-level descriptions of the intended structure of the funds.

+

An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIPs 1014 and 1015, which have already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIPs 1014 and 1015.

Requirements

-

The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIP 1014.

+

The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIPs 1014 and 1015.

The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and activation height for Testnet, in order to allow testing and auditing of the design and implementation within sufficient lead time before activation on Mainnet.

Non-requirements

-

This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.

+

This ZIP is not required to enforce provisions of ZIP 1014 or ZIP 1015 that fall outside what is implementable by Zcash consensus rules.

Specification

-

The Blossom network upgrade changed the height of the first halving to block height 1046400 10, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

-

Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.

-

ZIP 207 9 SHALL be activated in Canopy.

-

The following funding streams are defined for Mainnet:

-
+

Revisions

+
    +
  • Revision 0: The initial version of this specification, as agreed upon by the Zcash community in ZIP 1014 13.
    • +
+
    +
  • Revision 1: Funding streams defined to start at Zcash's second halving, and last for one year, as agreed upon in ZIP 1015 14.
    • +
+
+

Activation

+

The Blossom network upgrade changed the height of the first halving to block height 1046400 10, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

+

Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.

+

Revision 0 of ZIP 207 9 SHALL be activated in Canopy.

+

Since ZIP 1015 specifies that the specified funding streams start at the second halving, the activation height of NU6 on Mainnet therefore SHALL be 2726400.

+

Revision 1 of ZIP 207 9 SHALL be activated in NU6.

+

As specified in 9, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.

+
+

Funding Streams

+

As of Revision 0, the following funding streams are defined for Mainnet:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_ZIP214_BP710010464002726400
FS_ZIP214_ZF510010464002726400
FS_ZIP214_MG810010464002726400
+
+

As of Revision 0, the following funding streams are defined for Testnet:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_ZIP214_BP710010285002796000
FS_ZIP214_ZF510010285002796000
FS_ZIP214_MG810010285002796000
+
+

As of Revision 1, the following additional streams are defined for Mainnet:

@@ -59,32 +150,22 @@ - - - - - - - - - + + - + - + - +
FS_ZIP214_BP710010464002726400
FS_ZIP214_ZF5FS_DEFERRED12 1001046400 27264003146400
FS_ZIP214_MGFS_FPF_ZCG 8 1001046400 27264003146400
-
-

As specified in 9, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.

-

The following funding streams are defined for Testnet:

-
+

As of Revision 1, the following additional streams are defined for Testnet:

@@ -97,50 +178,47 @@ - - + + - - + + - - - - - - - - + - - + +
FS_ZIP214_BP7FS_DEFERRED12 1001028500279600029760003396000
FS_ZIP214_ZF510010285002796000
FS_ZIP214_MGFS_FPF_ZCG 8 1001028500279600029760003396000
-
-

Notes:

- -

Dev Fund Recipient Addresses

+

Notes for Revision 0:

+
    +
  • The block heights of halvings are different between Testnet and Mainnet, as a result of different activation heights for the Blossom network upgrade (which changed the block target spacing). The end height of these funding streams corresponds to the second halving on each network.
    • +
  • On Testnet, the activation height of Canopy will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1116000) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1116000 (inclusive) to 2796000 (exclusive).
    • +
+

Notes for Revision 1:

+
    +
  • The new funding streams begin at the second halving for Mainnet, but the second halving on Testnet occurred prior to the introduction of the new funding streams. For both new funding streams on each network, the associated duration corresponds to approximately one year's worth of blocks.
    • +
+
+
+

Dev Fund Recipient Addresses for Revision 0

For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC on behalf of BP; and ZF) SHALL generate sequences of recipient addresses to be used for each stream in each funding period:

  • ECC SHALL generate the addresses for the FS_ZIP214_BP funding stream, which on Mainnet corresponds to the BP slice;
  • ZF SHALL generate the addresses for the FS_ZIP214_ZF and FS_ZIP214_MG funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.

Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.

-

Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 12.

+

Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 13.

No requirements are imposed on the use of funds sent to Testnet funding streams.

Direct-grant option

-

ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 12

-

The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total value of funding streams assigned to direct grantees MUST be subtracted from the value of the funding stream for the remaining MG slice (or, if all Major Grants are direct, replace the funding stream for the MG slice).

-

For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP SHOULD be published specifying those modifications.

+

ZIP 1014 specified a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 13 However, this option was never taken up.

-

Mainnet Recipient Addresses

+
+

Mainnet Recipient Addresses for Revision 0

FS_ZIP214_BP.AddressList[0..47] = [
   "t3LmX1cxWPPPqL4TZHx42HU3U5ghbFjRiif",
   "t3Toxk1vJQ6UjWQ42tUJz2rV2feUWkpbTDs",
@@ -197,7 +275,12 @@
 FS_ZIP214_MG.AddressList[0..47] = ["t3XyYW8yBFRuMnfvm5KLGFbEVz25kckZXym"] * 48

(i.e. FS_ZIP214_ZF.AddressList and FS_ZIP214_MG.AddressList for Mainnet each consist of 48 repetitions of the same address).

-

Testnet Recipient Addresses

+
+

Mainnet Recipient Addresses for Revision 1

+

<TBD>

+
+
+

Testnet Recipient Addresses for Revision 0

FS_ZIP214_BP.AddressList[0..50] = [
   "t26ovBdKAJLtrvBsE2QGF4nqBkEuptuPFZz",
   "t26ovBdKAJLtrvBsE2QGF4nqBkEuptuPFZz",
@@ -257,14 +340,21 @@
 FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51

(i.e. FS_ZIP214_ZF.AddressList and FS_ZIP214_MG.AddressList for Testnet each consist of 51 repetitions of the same address).

+
+

Testnet Recipient Addresses for Revision 1

+
+

FS_FPF_ZCG.AddressList[0..12] = ["t2HifwjUj9uyxr9bknR8LFuQbc98c3vkXtu"] * 13

+
+
-

Rationale

-

The rationale for ZF generating the addresses for the FS_ZIP214_MG funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 12

+
+

Rationale for Revision 0

+

The rationale for ZF generating the addresses for the FS_ZIP214_MG funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 13

Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.

It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.

Deployment

-

This proposal is intended to be deployed with Canopy. 11

+

Revision 0 of this proposal was deployed with Canopy. 11 Revision 1 of this proposal is intended to be deployed with NU6. 12

References

@@ -279,7 +369,7 @@ - +
2Zcash Protocol Specification, Version 2021.2.16 or laterZcash Protocol Specification, Version 2023.4.0 or later
@@ -287,7 +377,7 @@ 3 - Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward + Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward @@ -295,7 +385,7 @@ 4 - Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet + Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.12: Mainnet and Testnet @@ -303,7 +393,7 @@ 5 - Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward + Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward @@ -355,14 +445,30 @@ - +
+ + + +
12ZIP 253: Deployment of the NU6 Network Upgrade
+ + + +
13 ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
+ + + + + + + +
14ZIP 1015: Block Reward Allocation for Non-Direct Development Funding
diff --git a/rendered/zip-0233.html b/rendered/zip-0233.html new file mode 100644 index 000000000..e9c1b5254 --- /dev/null +++ b/rendered/zip-0233.html @@ -0,0 +1,243 @@ + + + + ZIP 233: Establish the Zcash Sustainability Fund on the Protocol Level + + + + + +
ZIP: 233
+Title: Establish the Zcash Sustainability Fund on the Protocol Level
+Owners: Jason McGee <jason@shieldedlabs.com>
+        Mark Henderson <mark@equilibrium.co>
+        Tomek Piotrowski <tomek@eiger.co>
+        Mariusz Pilarek <mariusz@eiger.co>
+Original-Authors: Nathan Wilcox
+Credits:
+Status: Draft
+Category: Consensus / Ecosystem
+Created: 2023-08-16
+License: BSD-2-Clause
+

Terminology

+

The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, +“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as +described in RFC 2119. [1]

+

The term “network upgrade” in this document is to be interpreted as +described in ZIP 200. [2]

+

“Block Subsidy” - the algorithmic issuance of ZEC on block creation – +part of the consensus rules. Split between the miner and the Dev Fund. +Also known as Block Reward.

+

“Issuance” - The method by which unmined or unissued ZEC is converted +to ZEC available to users of the network

+

“We” - the ZIP authors, owners listed in the above front matter

+

“MAX_MONEY” is the ZEC supply cap. For simplicity, this +ZIP defines it to be 21,000,000 ZEC, although this is +slightly larger than the actual supply cap of the original ZEC issuance +mechanism.

+

Abstract

+

This ZIP describes the motivation, the necessary changes for, and the +implementation specifications for the Zcash Sustainability Fund (ZSF). +The ZSF is a proposed alteration to the block rewards system and +accounting of unmined ZEC that allows for other sources of funding +besides unissued ZEC. This new mechanism for deposits – that new +applications or protocol designs can use to strengthen the long-term +sustainability of the network – will likely be an important step for +future economic upgrades, such as a transition to Proof of Stake or +Zcash Shielded Assets, and other potential protocol fees and user +applications.

+

The changes in this ZIP are ultimately minimal, only requiring for +the node to track state in the form of a ZSF_BALANCE, and +for a new transaction field to be added, called +ZSF_DEPOSIT. While wallet developer would be encouraged to +add the ZSF_DEPOSIT field to their UIs, no changes or new +behavior are absolutely required for developers or ZEC holders.

+

This ZIP does not change the current ZEC block subsidy issuance +schedule. Any additional amounts paid into the sustainability fund are +reserved for use in future ZIPs.

+

Motivation

+

The Zcash network’s operation and development relies fundamentally on +the block reward system inherited from Bitcoin. This system currently +looks like this:

+
    +
  • At Every New Block: +
      +
    • Miner and funding streams are rewarded a constant amount via +unissued ZEC (this constant amount halves at specified heights)
      • +
    • Miner is rewarded via Transaction fees +(inputs - outputs)
      • +
    • +
+

The Zcash Sustainability Fund is a proposed replacement to that +payout mechanism, with the relevant parts in bold below:

+
    +
  • Unmined ZEC is now accounted for as +ZSF_BALANCE
    • +
  • Transaction includes optional contributions to ZSF via a +ZSF_DEPOSIT field
    • +
  • Thus, at Every New Block: +
      +
    • Miner and funding streams rewarded the same constant amount, +but from ZSF_BALANCE (this constant amount +still halves at specified heights)
      • +
    • Miner is rewarded via Transaction fees +(inputs - outputs), where outputs +includes the ZSF_DEPOSIT amount
      • +
    • +
+

For example, an end-user wallet application could have an option to +contribute a portion of a transaction to the ZSF, which would be +included in a ZSF_DEPOSIT field in the transaction, to be +taken into account by the Zcash nodes.

+

This quite simple alteration has – in our opinion – a multitude of +benefits:

+
    +
  1. Long Term Consensus Sustainability: This mechanism +supports long-term consensus sustainability by addressing concerns about +the sustainability of the network design shared by Bitcoin-like systems +through the establishment of deposits into the Sustainability Fund to +augment block rewards, ensuring long-term sustainability as the issuance +rate of Zcash drops and newly issued ZEC decreases over time.
    2. +
  2. Benefits to ZEC Holders: Deposits to the ZSF slow +down the payout of ZEC, temporarily reducing its available supply, +benefiting current holders of unencumbered active ZEC in proportion to +their holdings without requiring them to opt into any scheme, +introducing extra risk, active oversight, or accounting complexity.
    3. +
  3. Recovery of “Soft-Burned” Funds: In some instances, +such as miners not claiming all available rewards, some ZEC goes +unaccounted for, though not formally burned. This proposal would recover +it through the ZSF_BALANCE mechanism described below.
    4. +
+

Specification

+

In practice, The Zcash Sustainability Fund is a single global balance +maintained by the node state and contributed to via a single transaction +field. This provides the economic and security support described in the +motivation section, while also importantly keeping the fund payouts +extremely simple to describe and implement.

+

The two modifications are: 1. The re-accounting of unmined ZEC as a +node state field called ZSF_BALANCE 2. The addition of a +transaction field called ZSF_DEPOSIT

+

ZSF_BALANCE

+

The ZEC issuance mechanism is re-defined to remove funds from +ZSF_BALANCE, which is initially set to +MAX_MONEY at the genesis block.

+

Consensus nodes are then required to track new per-block state:

+
    +
  • ZSF_BALANCE[height] : u64 [zatoshi]
    • +
+

The state is a single 64 bit integer (representing units of +zatoshi) at any given block height, height, representing the Sustainability Fund +balance at that height. The ZSF_BALANCE can be calculated +using the following formula:

+

$\mathsf{ZsfBalanceAfter}(\mathsf{height}) += \mathsf{MAX\_MONEY} + \sum_{h = 0}^{\mathsf{height}} +(\mathsf{ZsfDeposit}(h) + \mathsf{Unclaimed}(h) - +\mathsf{BlockSubsidy}(h))$

+

where Unclaimed(height) is the +portion of the block subsidy and miner fees that are unclaimed for the +block at the given height.

+

The block at height height commits +to ZsfBalanceAfter(height) as part of a +new block commitment in the block header, at the end of the +hashBlockCommitments chain in ZIP-244.

+

TODO ZIP editors: consider introducing a chain state commitment hash +tree. (When we get closer to the network upgrade, we will have a better +idea what commitments that network upgrade needs.)

+

Deposits into the +Sustainability Fund

+

Sustainability fund deposits can be made via the new +zsfDeposit field. This can be done by: - ZEC fund holders, +in non-coinbase transactions; - Zcash miners, in coinbase +transactions.

+

In transaction versions without this new field: - unclaimed miner +fees and rewards in coinbase transactions are +re-defined as deposits into the sustainability fund, and - there are no +sustainability fund deposits from non-coinbase transactions.

+

Note: older transaction versions can continue to be supported after a +network upgrade. For example, NU5 supports both v4 and v5 transaction +formats, for both coinbase and non-coinbase transactions.

+

zsfDeposit +fields in transactions

+

Each transaction can dedicate some of its excess funds to the ZSF, +and the remainder becomes the miner fee, with any excess miner +fee/reward going to the ZSF

+

This is achieved by adding a new field to the common transaction +fields [#zip-0225-transaction-format]:

+
    +
  • zsfDeposit : u64 [zatoshi]
    • +
+

The ZSF_BALANCE[H] for a block at height H +can be calculated given a value of ZSF_BALANCE[H-1] and the +set of transactions contained in that block. First, the +ZSF_DEPOSIT[H] is calculated based solely on +ZSF_BALANCE[H-1]. This is subtracted from the previous +block’s balance to be distributed as part of the block reward. Second, +the sum of all the ZSF_DEPOSIT fields of all transactions +in the block is added to the balance.

+

Non-Coinbase Transactions

+

If the ZSF_DEPOSIT field is not present in an older +transaction version, it is defined to be zero for non-coinbase +transactions.

+

Consensus Rule Changes

+
    +
  • Transparent inputs to a transaction insert value into a transparent +transaction value pool associated with the transaction. Transparent +outputs and sustainability fund deposits remove value +from this pool.
    • +
+

Coinbase Transactions

+

Any excess miner fee/reward is sent to the ZSF.

+

In new blocks, this deposit is tracked via the +ZSF_DEPOSIT field in coinbase transactions.

+

If the ZSF_DEPOSIT field is not present in a coinbase +transaction with an older transaction version, it is defined as the +value of any unspent miner fee and miner reward. This re-defines these +previously unspendable funds as ZSF deposits.

+

Consensus Rule Changes

+
    +
  • The remaining value in the transparent transaction value pool of a +coinbase transaction is deposited in the sustainability +fund.
    • +
+

ZSF_DEPOSIT +Requirements

+
    +
  • ZIP 230 [3] must be updated to include +ZSF_DEPOSIT.
    • +
  • ZIP 244 [4] must be updated as well to include +ZSF_DEPOSIT.
    • +
+

Rationale

+

All technical decisions in this ZIP are balanced between the +necessary robustness of the ZSF mechanics, and simplicity of +implementation.

+

ZSF_BALANCE as node +state

+

Tracking the ZSF_BALANCE value as a node state using the +above formula is very simple in terms of implementation, and should work +correctly given that the node implementations calculate the value +according to the specifications.

+

ZSF_DEPOSIT +as explicit transaction field

+

An explicit value distinguishes the ZEC destined to Sustainability +Fund deposits from the implicit transaction fee. Explicitness also +ensures any arithmetic flaws in any implementations are more likely to +be observed and caught immediately.

+

Deployment

+

This ZIP is proposed to activate with Network Upgrade (TODO ZIP +editors).

+

References

+

[1]: Key words for use in +RFCs to Indicate Requirement Levels

+

[2]: ZIP 200: Network +Upgrade Mechanism

+

[3]: ZIP +230: v6 transactions, including ZSAs

+

[4]: ZIP 244: +Transaction Identifier Non-Malleability

+ + diff --git a/rendered/zip-0234.html b/rendered/zip-0234.html new file mode 100644 index 000000000..5da8eb546 --- /dev/null +++ b/rendered/zip-0234.html @@ -0,0 +1,193 @@ + + + + ZIP 234: Smooth Out The Block Subsidy Issuance + + + + + +
ZIP: 234
+Title: Smooth Out The Block Subsidy Issuance
+Owners: Jason McGee <jason@shieldedlabs.com>
+        Mark Henderson <mark@equilibrium.co>
+        Tomek Piotrowski <tomek@eiger.co>
+        Mariusz Pilarek <mariusz@eiger.co>
+Original-Authors: Nathan Wilcox
+Credits:
+Status: Draft
+Category: Consensus
+Created: 2023-08-23
+License: BSD-2-Clause
+

Terminology

+

The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, +“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as +described in RFC 2119. [1]

+

“Network upgrade” - to be interpreted as described in ZIP 200. +[2]

+

“Block Subsidy” - to be interpreted as described in the Zcash +Protocol Specification (TODO ZIP Editors: link from comment).

+

“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: +work out if this definition is correct or can be removed).

+

“ZsfBalanceAfter(h)” is the total ZEC available in the +Zcash Sustainability Fund (ZSF) after the transactions in block +h, described in ZIP draft-zsf.md. In this ZIP, the +Sustainability Fund is used to pay out Block Subsidies from unmined ZEC, +and other fund deposits.

+

Let PostBlossomHalvingInterval be as defined in +[#protocol-diffadjustment]_.

+

Abstract

+

This ZIP proposes a change to how nodes calculate the block +subsidy.

+

Instead of following a step function around the 4-year halving +intervals inherited from Bitcoin, we propose a slow exponential +“smoothing” of the curve. The new issuance scheme would approximate the +current issuance over 4-year intervals.

+

This ZIP depends on the ZIP introducing the Zcash Sustainability Fund +(ZIP-XXX).

+

Motivation

+

The current Zcash economic model, inherited from Bitcoin, includes a +halving mechanism which dictates the issuance of new coins. While this +has been foundational, halvings can lead to abrupt changes in the rate +of new coins being introduced to the market. Such sudden shifts can +potentially disrupt the network’s economic model, potentially impacting +its security and stability. Furthermore, the halvings schedule is fixed +and does not provide any way to “recycle” funds into future +issuance.

+

To address this, we propose issuing a fixed portion of the pending +funds-to-be-issued in each block. This has the effect of smoothing out +the issuance curve of ZEC, ensuring a more consistent and predictable +rate of coin issuance, while still preserving the overall supply cap of +21,000,000 coins. This mechanism by itself (without other anticipated +changes) seeks to preserve the core aspects of Zcash’s issuance policy +and aims to enhance predictability and avoid sudden changes. By making +this shift, the average block subsidy over time will remain predictable +with very gradual changes.

+

However, we anticipate schemes proposed in [#draft-zsf]_ where the +amount of funds-to-be-issued may increase. In that scenario, this +issuance mechanism would distribute that increase starting in the +immediately following block and subsequent blocks. Because this +distribution mechanism has an exponential decay, such increases will be +spread out in miniscule amounts to future blocks over a long time +period. This issuance mechanism thus provides a way for potential +increases or decreases of issuance while constraining those changes to +be small on a short time scale to avoid unexpected disruptions.

+

Additionally, the current Bitcoin-style issuance does not take into +account the current balance of ZsfBalanceAfter(h). If +[#draft-zsf]_ were to activate without a change to the issuance +mechanism, then some funds would never be disbursed after they are +deposited back into the ZSF.

+

Requirements

+

Smoothing the issuance curve is possible using an exponential decay +formula that satisfies the following requirements:

+

Issuance Requirements

+
    +
  1. The issuance can be summarised into a reasonably simple +explanation
    2. +
  2. Block subsidies approximate a continuous function
    3. +
  3. If there are funds in the ZSF, then the block subsidy must be +non-zero, preventing any final “unmined” zatoshis
    4. +
  4. For any 4 year period, all paid out block subsidies are +approximately equal to half of the ZSF at the beginning of that 4 year +period, if there are no deposits into the ZSF during those 4 years
    5. +
+

TODO daira: add a requirement that makes the initial total issuance +match the previous total issuance

+

Specification

+

Goals

+

We want to decrease the short-term impact of the deployment of this +ZIP on block reward recipients, and minimise the potential reputational +risk to Zcash of changing the block reward amount.

+

Constants

+

Define constants:

+

“BLOCK_SUBSIDY_FRACTION” = 4126 / 10,000,000,000 or +0.0000004126

+

“DEPLOYMENT_BLOCK_HEIGHT” = 2726400

+

Issuance Calculation

+

At the DEPLOYMENT_BLOCK_HEIGHT, nodes should switch from +the current issuance calculation, to the following:

+

Given the block height h define a function +BlockSubsidy(h), such that:

+

BlockSubsidy(h) = Block subsidy for a given +h, that satisfies above requirements.

+

Using an exponential decay function for BlockSubsidy +satisfies requirements R1 and R2 +above:

+

BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)

+

Finally, to satisfy R3 above we always round up to +the next zatoshi.

+

BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))

+

Rationale

+

BLOCK_SUBSIDY_FRACTION

+

Let IntendedZSFFractionRemainingAfterFourYears = +0.5.

+

The value 4126 / 10_000_000_000 satisfies the +approximation within +0.002%:

+

(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears

+

Meaning after a period of 4 years around half of +ZSF_BALANCE will be paid out as block subsidies, thus +satisfying R4.

+

The largest possible amount in the ZSF is MAX_MONEY, in the +theoretically possible case that all issued funds are deposited back +into the ZSF. If this happened, the largest interim sum in the block +subsidy calculation would be MAX_MONEY * 4126 + 10000000000.

+

This uses 62.91 bits, which is just under the 63 bit limit for 64-bit +signed two’s-complement integer amount types.

+

The numerator could be brought closer to the limit by using a larger +denominator, but the difference in the amount issued would be very +small. So we chose a power-of-10 denominator for simplicity.

+

TODO for ZIP owners: How many ZEC per day?

+

DEPLOYMENT_BLOCK_HEIGHT

+

The deployment should happen at the next halving, which is block +2726400.

+

Since there is a planned halving at this point, there will already be +a significant “shock” caused by the drop in issuance caused by the +halving. This reduces surprise and thus increases security. Also, due to +the nature of the smoothed curve having a portion of the curve above the +respective step function line at times, this will maximally +reduce the issuance shock at the +DEPLOYMENT_BLOCK_HEIGHT.

+

Visualization of the +Smoothed Curve

+

The following graph illustrates compares issuance for the current +halving-based step function vs the smoothed curve.

+
+ + +
+

The graph below shows the balance of the ZSF assuming smooth issuance +is implemented.

+
+ + +
+

Deployment

+

The implementation of this ZIP MUST be deployed at the same time or +after the Zcash Sustainability Fund is established (ZIP-XXX).

+

Appendix: Simulation

+

The ZSF +simulator allows us to simulate the effects of this ZIP on the ZSF +balance and the block subsidy, as well as generate plots like the ones +above. Its output:

+
Last block is 47917869 in ~113.88 years
+

indicates that, assuming no ZEC is ever deposited to the ZSF, its +balance will be depleted after 113.88 years, and the block subsidy will +be 0 ZEC after that point.

+

This fragment of the output

+
Halving  1 at block  1680000:
+  ZSF subsidies:    262523884819889 (~ 2625238.848 ZEC,        1.563 ZEC per block)
+  legacy subsidies: 262500000000000 (~ 2625000.000 ZEC,        1.562 ZEC per block)
+  difference:           23884819889 (~         238 ZEC),         ZSF/legacy: 1.0001
+

shows that the difference between the smoothed out and the current +issuance schemes is 238 ZEC after 1680000 blocks (aroound 4 years).

+

References

+

[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119

+

[2] ZIP-200: https://zips.z.cash/zip-0200

+

[3] ZIP-XXX: Placeholder for the ZSF ZIP

+ + diff --git a/rendered/zip-0253.html b/rendered/zip-0253.html index a8764a8de..138230ad8 100644 --- a/rendered/zip-0253.html +++ b/rendered/zip-0253.html @@ -10,72 +10,143 @@ 
ZIP: 253
 Title: Deployment of the NU6 Network Upgrade
 Owners: Arya <arya@zfnd.org>
-Status: Draft
+Status: Proposed
 Category: Consensus / Network
 Created: 2024-07-17
 License: MIT
 Discussions-To: <https://github.com/zcash/zips/issues/806>

Terminology

-

The key word “MUST” in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

-

The term “network upgrade” in this document is to be interpreted as described in ZIP 200 2.

-

The terms “Testnet” and “Mainnet” are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.

+

The key word “MUST” in this document are to be interpreted as +described in BCP 14 1 when, and only when, they appear in +all capitals.

+

The term “network upgrade” in this document is to be interpreted as +described in ZIP 200 2.

+

The terms “Testnet” and “Mainnet” are to be interpreted as described +in section 3.12 of the Zcash Protocol Specification 3.

Abstract

This proposal defines the deployment of the NU6 network upgrade.

Specification

NU6 deployment

- -

The primary sources of information about NU6 consensus protocol changes are:

+

The primary sources of information about NU6 consensus protocol +changes are:

    -
  • The Zcash Protocol Specification 4.
    • -
  • Network Upgrade Mechanism 5.
    • -
  • Lockbox Funding Streams 6.
    • -
  • Block Reward Allocation for Non-Direct Development Funding 7.
    • -
  • Blocks should balance exactly 8.
    • +
  • The Zcash Protocol Specification 4.
    • +
  • ZIP 200: Network Upgrade Mechanism 5.
    • +
  • ZIP 236: Blocks should balance exactly 6.
    • +
  • ZIP 1015: Block Reward Allocation for Non-Direct Development Funding +7.
    • +
  • ZIP 2001: Lockbox Funding Streams 8.
-

The network handshake and peer management mechanisms defined in ZIP 201 9 also apply to this upgrade.

-

The following ZIPs have been updated in varying degrees to take into account NU6:

+

The network handshake and peer management mechanisms defined in ZIP +201 9 also apply to this upgrade.

+

The following ZIPs have been updated in varying degrees to take into +account NU6:

    -
  • ZIP 207: Funding Streams 10.
    • -
  • ZIP 214: Consensus rules for a Zcash Development Fund 11.
    • +
  • ZIP 207: Funding Streams 10.
    • +
  • ZIP 214: Consensus rules for a Zcash Development Fund 11.
-

The following network upgrade constants 12 are defined for the NU6 upgrade:

+

The following network upgrade constants 12 +are defined for the NU6 upgrade:

CONSENSUS_BRANCH_ID
-
0xC8E71055 +
+0xC8E71055
ACTIVATION_HEIGHT (NU6)
-
Testnet: TBD +
+Testnet: 2976000
-
Mainnet: TBD +
+Mainnet: TBD
MIN_NETWORK_PROTOCOL_VERSION (NU6)
-
Testnet: 170110 +
+Testnet: 170110
-
Mainnet: 170120 +
+Mainnet: 170120
-

For each network (Testnet and Mainnet), nodes compatible with NU6 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6) for that activation.

+

For each network (Testnet and Mainnet), nodes compatible with NU6 +activation on that network MUST advertise a network protocol version +that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6) +for that activation.

Backward compatibility

-

Prior to the network upgrade activating on each network, NU6 and pre-NU6 nodes are compatible and can connect to each other. However, NU6 nodes will have a preference for connecting to other NU6 nodes, so pre-NU6 nodes will gradually be disconnected in the run up to activation.

-

Once the network upgrades, even though pre-NU6 nodes can still accept the numerically larger protocol version used by NU6 as being valid, NU6 nodes will always disconnect peers using lower protocol versions.

-

NU6 does not define a new transaction version or impose a new minimum transaction version. NU6 transactions are therefore in the same v4 or v5 formats as NU5 transactions. This does not imply that transactions are valid across the NU6 activation, since signatures MUST use the appropriate consensus branch ID.

+

Prior to the network upgrade activating on each network, NU6 and +pre-NU6 nodes are compatible and can connect to each other. However, NU6 +nodes will have a preference for connecting to other NU6 nodes, so +pre-NU6 nodes will gradually be disconnected in the run up to +activation.

+

Once the network upgrades, even though pre-NU6 nodes can still accept +the numerically larger protocol version used by NU6 as being valid, NU6 +nodes will always disconnect peers using lower protocol versions.

+

NU6 does not define a new transaction version or impose a new minimum +transaction version. NU6 transactions are therefore in the same v4 or v5 +formats as NU5 transactions. This does not imply that transactions are +valid across the NU6 activation, since signatures MUST use the +appropriate consensus branch ID.

References

-
+
+ diff --git a/rendered/zip-1015.html b/rendered/zip-1015.html new file mode 100644 index 000000000..c13e55984 --- /dev/null +++ b/rendered/zip-1015.html @@ -0,0 +1,224 @@ + + + + ZIP 1015: Block Reward Allocation for Non-Direct Development Funding + + + +
+ 
ZIP: 1015
+Title: Block Reward Allocation for Non-Direct Development Funding
+Owners: Jason McGee <aquietinvestor@gmail.com>
+        @Peacemonger (Zcash Forum)
+        Kris Nuttycombe <kris@nutty.land>
+Credits: @GGuy (Zcash Forum)
+         Daira-Emma Hopwood
+         Jack Grigg
+         Skylar Saveland
+Status: Proposed
+Category: Consensus
+Created: 2024-08-26
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/881>
+

Terminology

+

The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

+

"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of community members assembled by the Zcash Foundation and described at 5.

+

"Zcash Community Grants", also called "ZCG", refers to the committee selected by the Zcash Community Advisory Panel or a successor process (e.g. as established by FPF) to decide on the funding of grants intended to fund the Zcash ecosystem.

+

"Financial Privacy Foundation", also called "FPF", refers to the Cayman Islands-incorporated non-profit foundation company limited by guarantee of that name.

+

"Autonomous Entities" refers to committees, DAOs, teams or other groups to which FPF provides operations, administrative, and financial management support.

+
+

Abstract

+

This ZIP proposes the allocation of a percentage of the Zcash block subsidy, post-November 2024 halving, split between Zcash Community Grants (ZCG) and an in-protocol "lockbox." The "lockbox" is a separate pool of issued funds tracked by the protocol, as described in ZIP 2001: Lockbox Funding Streams 4. No disbursement mechanism is currently defined for this "lockbox"; the Zcash community will need to decide upon and specify a suitable decentralized mechanism for permitting withdrawals from this lockbox in a future ZIP in order to make these funds available for funding grants to ecosystem participants.

+

The proposed lockbox addresses significant issues observed with ZIP 1014 3, such as regulatory risks, inefficiencies due to funding of organizations instead of projects, and centralization. While the exact disbursement mechanism for the lockbox funds is yet to be determined and will be addressed in a future ZIP, the goal is to employ a decentralized mechanism that ensures community involvement and efficient, project-specific funding. This approach is intended to potentially improve regulatory compliance, reduce inefficiencies, and enhance the decentralization of Zcash's funding structure.

+
+

Motivation

+

Starting at Zcash's second halving in November 2024, under pre-existing consensus rules 100% of the block subsidies would be allocated to miners, and no further funds would be automatically allocated to any other entities. Consequently, unless the community takes action to approve new block-reward-based funding, existing teams dedicated to development or outreach or furthering charitable, educational, or scientific purposes would likely need to seek other sources of funding; failure to obtain such funding would likely impair their ability to continue serving the Zcash ecosystem. Setting aside a portion of the block subsidy to fund development will help ensure that both existing teams and new contributors can obtain funding in the future.

+

It is important to balance the incentives for securing the consensus protocol through mining with funding crucial charitable, educational, and scientific activities like research, development, and outreach. Additionally, there is a need to continue to promote decentralization and the growth of independent development teams.

+

For these reasons, the Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development funds. The alternatives presented here are intended to address the following:

+
    +
  1. Regulatory Risks: The current model involves direct funding of US-based organizations, which can potentially attract regulatory scrutiny from entities such as the SEC, posing legal risks to the Zcash ecosystem.
    2. +
  2. Funding Inefficiencies: The current model directly funds organizations rather than specific projects, leading to a potential mismatch between those organizations' development priorities and the priorities of the community. Furthermore, if organizations are guaranteed funds regardless of performance, there is little incentive to achieve key performance indicators (KPIs) or align with community sentiment. A future system that allocates resources directly to projects rather than organizations may help reduce inefficiencies and better align development efforts with community priorities.
    3. +
  3. Centralization Concerns: The current model centralizes decision-making power within a few organizations, contradicting the decentralized ethos of blockchain technology. Traditional organizational structures with boards and executives introduce single points of failure and limit community involvement in funding decisions.
    4. +
  4. Community Involvement: The current system provides minimal formal input from the community regarding what projects should be funded, leading to a misalignment between funded projects and community priorities.
    5. +
  5. Moving Towards a Non-Direct Funding Model: There is strong community support for a non-direct Dev Fund funding model. Allocating funds to a Deferred Dev Fund Lockbox incentivizes the development of a decentralized mechanism for the disbursement of the locked funds.
    6. +
  6. Limited Runway: ZCG does not have the financial runway that ECC/BP and ZF have. As such, allocating ongoing funding to ZCG will help ensure the Zcash ecosystem has an active grants program.
    7. +
  7. Promoting Decentralization: Allocating a portion of the Dev Fund to Zcash Community Grants ensures small teams continue to receive funding to contribute to Zcash. Allowing the Dev Fund to expire, or putting 100% into a lockbox, would disproportionately impact grant recipients. This hybrid approach promotes decentralization and the growth of independent development teams.
    8. +
  8. Mitigating Regulatory Risks: The Financial Privacy Foundation (FPF) is a non-profit organization incorporated and based in the Cayman Islands. By minimizing direct funding of US-based organizations, this proposal helps to reduce potential regulatory scrutiny and legal risks.
    9. +
+

By addressing these issues, this proposal aims to ensure sustainable, efficient, and decentralized funding for essential activities within the Zcash ecosystem.

+
+

Requirements

+
    +
  1. In-Protocol Lockbox: The alternatives presented in this ZIP depend upon the Lockbox Funding Streams proposal 4.
    2. +
  2. Regulatory Considerations: The allocation of funds should minimize regulatory risks by avoiding direct funding of specific organizations. The design should enable and encourage compliance with applicable laws and regulations to support the long-term sustainability of the funding model.
    3. +
+
+

Non-requirements

+

The following considerations are explicitly deferred to future ZIPs and are not covered by this proposal:

+
    +
  1. Disbursement Mechanism: The exact method for disbursing the accumulated funds from the lockbox is not defined in this ZIP. The design, implementation, and governance of the disbursement mechanism will be addressed in a future ZIP. This includes specifics on how funds will be allocated, the voting or decision-making process, and the structure of the decentralized mechanism (such as a DAO).
    2. +
  2. Regulatory Compliance Details: The proposal outlines the potential to reduce regulatory risks by avoiding direct funding of US-based organizations, but it does not detail specific regulatory compliance strategies. Future ZIPs will need to address how the disbursement mechanism complies with applicable laws and regulations.
    3. +
  3. Impact Assessment: The long-term impact of reallocating a portion of the block subsidy to the lockbox on the Zcash ecosystem, including its effect on miners, developers, and the broader community, is not analyzed in this ZIP. Subsequent proposals will need to evaluate the outcomes and make necessary adjustments based on real-world feedback and data.
    4. +
+
+

Specification

+

Development Funding Recipients

+

Lockbox

+

The "lockbox" is a pool of issued funds tracked by the protocol, as described in ZIP 2001: Lockbox Funding Streams 4. No disbursement mechanism is currently defined for this "lockbox"; the Zcash community will need to decide upon and specify a suitable decentralized mechanism for permitting withdrawals from this lockbox in a future ZIP in order to make these funds available for funding grants to ecosystem participants.

+
+

Zcash Community Grants (ZCG)

+

The stream allocated to Zcash Community Grants (ZCG) is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem, to the extent that such teams are available and effective. The ZCG Committee is given the discretion to allocate funds not only to major grants, but also to a diverse range of projects that advance the usability, security, privacy, and adoption of Zcash, including community programs, dedicated resources, and other projects of varying sizes.

+

The funds SHALL be received and administered by the Financial Privacy Foundation (FPF). FPF MUST disburse them for grants and expenses reasonably related to the administration of the ZCG program, but subject to the following additional constraints:

+
    +
  1. These funds MUST be used exclusively for issuing Zcash Community Grants to external parties that are independent of the FPF or to Autonomous Entities operating under the FPF umbrella. Additionally, they MAY be used to cover expenses reasonably related to the administration of Zcash Community Grants. These funds MUST NOT be used by FPF for its internal operations or for any direct expenses unrelated to the administration of Zcash Community Grants.
    2. +
  2. ZCG SHOULD support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration or ongoing without a duration limit. Grants of indefinite duration SHOULD be reviewed periodically (on a schedule that the Zcash Community Grants Committee considers appropriate for the value and complexity of the grant) for continuation of funding.
    3. +
  3. Priority SHOULD be given to major grants that bolster teams with substantial (current or prospective) continual existence, and set them up for long-term success, subject to the usual grant award considerations (impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD be given to major grants that support ecosystem growth, for example through mentorship, coaching, technical resources, creating entrepreneurial opportunities, etc. If one proposal substantially duplicates another’s plans, priority SHOULD be given to the originator of the plans.
    4. +
  4. The ZCG committee SHOULD be restricted to funding projects that further the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general) as permitted by any relevant jurisdictional requirements.
    5. +
  5. ZCG awards are subject to approval by a five-seat ZCG Committee. The ZCG Committee SHALL be selected by the ZF’s Community Advisory Panel or a successor process (e.g. as established by FPF). Elections SHALL be staggered to ensure continuity within the Committee.
    6. +
  6. The ZCG Committee's funding decisions will be final, requiring no approval from the FPF Board, but are subject to veto if FPF judges them to violate Cayman law or the FPF's reporting requirements and other (current or future) obligations under the Cayman Islands' Companies Act (2023 Revision) and Foundation Companies Law, 2017.
    7. +
  7. ZCG Committee members SHALL have a one-year term and MAY sit for reelection. The ZCG Committee is subject to the same conflict of interest policy that governs the FPF Board of Directors (i.e. they MUST recuse themselves when voting on proposals where they have a financial interest). At most one person with association with the BP/ECC, at most one person with association with the ZF, and at most one person with association with FPF are allowed to sit on the ZCG Committee. “Association” here means: having a financial interest, full-time employment, being an officer, being a director, or having an immediate family relationship with any of the above.
    8. +
  8. A portion of the ZCG Slice shall be allocated to a Discretionary Budget, which may be disbursed for expenses reasonably related to the administration of the ZCG program. The amount of funds allocated to the Discretionary Budget SHALL be decided by the ZF’s Community Advisory Panel or successor process. Any disbursement of funds from the Discretionary Budget MUST be approved by the ZCG Committee. Expenses related to the administration of the ZCG program include, without limitation the following: +
      +
    • Paying for operational management and administration services that support the purpose of the Zcash Community Grants program, including administration services provided by FPF.
      • +
    • Paying third party vendors for services related to domain name registration, or the design, website hosting and administration of websites for the ZCG Committee.
      • +
    • Paying independent consultants to develop requests for proposals that align with the ZCG program.
      • +
    • Paying independent consultants for expert review of grant applications.
      • +
    • Paying for sales and marketing services to promote the ZCG program.
      • +
    • Paying third party consultants to undertake activities that support the purpose of the ZCG program.
      • +
    • Reimbursement to members of the ZCG Committee for reasonable travel expenses, including transportation, hotel and meals allowance.
      • +
    +
    9. +
  9. A portion of the Discretionary Budget MAY be allocated to provide reasonable compensation to members of the ZCG Committee. Committee member compensation SHALL be limited to the hours needed to successfully perform their positions and MUST align with the scope and responsibilities of their roles. The allocation and distribution of compensation to committee members SHALL be administered by the FPF. The compensation rate and hours for committee members SHALL be determined by the ZF’s Community Advisory Panel or successor process.
    10. +
  10. The ZCG Committee’s decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the FPF Board, but are subject to veto if the FPF judges them to violate laws or FPF reporting requirements and other (current or future) obligations under Cayman Islands law.
    11. +
+

FPF SHALL be contractually required to recognize the ZCG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its Transparency and Accountability obligations defined below.

+

ZCG SHALL strive to define target metrics and key performance indicators, and the ZCG Committee SHOULD utilize these in its funding decisions.

+
Furthering Decentralization
+

FPF SHALL conduct periodic reviews of the organizational structure, performance, and effectiveness of the ZCG program and committee, taking into consideration the input and recommendations of the ZCG Committee. As part of these periodic reviews, FPF MUST commit to exploring the possibility of transitioning ZCG into an independent organization if it is economically viable and it aligns with the interests of the Zcash ecosystem and prevailing community sentiment.

+

In any transition toward independence, priority SHALL be given to maintaining or enhancing the decentralization of the Zcash ecosystem. The newly formed independent organization MUST ensure that decision-making processes remain community-driven, transparent, and responsive to the evolving needs of the Zcash community and ecosystem. In order to promote geographic decentralization, the new organization SHOULD keep its domicile outside of the United States.

+
+
Transparency and Accountability
+

FPF MUST accept the following obligations in this section on behalf of ZCG:

+
    +
  • Publication of a ZCG Dashboard, providing a snapshot of ZCG’s current financials and any disbursements made to grantees.
    • +
  • Bi-weekly meeting minutes documenting the decisions made by the ZCG committee on grants.
    • +
  • Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).
    • +
  • Annual detailed review of the organization performance and future plans.
    • +
  • Annual financial report (IRS Form 990, or substantially similar information).
    • +
+

BP, ECC, ZF, FPF, ZCG and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).

+

All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative 2), preferably the MIT license.

+
+
Enforcement
+

FPF MUST contractually commit to fulfill these obligations on behalf of ZCG, and the prescribed use of funds, such that substantial violation, not promptly remedied, will result in a modified version of Zcash node software that removes ZCG’s Dev Fund slice and allocates it to the Deferred Dev Fund lockbox.

+
+
+
+

Funding Streams

+
    +
  • 12% of the block subsidy is to be distributed to the lockbox.
    • +
  • 8% of the block subsidy is to be distributed to the Financial Privacy Foundation (FPF), for the express use of the Zcash Community Grants Committee (ZCG) to fund independent teams in the Zcash ecosystem.
    • +
+

As of the activation of this ZIP, the complete set of funding streams for Mainnet will be:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED1210027264003146400
FS_FPF_ZCG810027264003146400
+

The set of funding streams for Testnet will be:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED1210029760003396000
FS_FPF_ZCG810029760003396000
+
+
+

References

+ + + + + + + +
1Information 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"
+ + + + + + + +
2The Open Source Definition
+ + + + + + + +
3ZIP 1014: Dev Fund Proposal and Governance
+ + + + + + + +
4ZIP 2001: Lockbox Funding Streams
+ + + + + + + +
5Zcash Community Advisory Panel
+
+
+ + \ No newline at end of file diff --git a/rendered/zip-2001.html b/rendered/zip-2001.html index 4677832e3..bc2f3d310 100644 --- a/rendered/zip-2001.html +++ b/rendered/zip-2001.html @@ -12,7 +12,7 @@ Owners: Kris Nuttycombe <kris@nutty.land> Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co> Jack Grigg <jack@electriccoin.co> -Status: Draft +Status: Proposed Category: Consensus Created: 2024-07-02 License: MIT @@ -35,12 +35,13 @@

The funding stream mechanism defined in ZIP 207 3 is modified such that a funding stream may deposit funds into the deferred pool.

Specification

-

Deferred Development Fund Chain Value Pool Balance

-

Full node implementations MUST track an additional - \(\mathsf{PoolValue}_{Deferred}\) - chain value pool balance, in addition to the Sprout, Sapling, and Orchard chain value pool balances. This balance is set to zero prior to the activation of Network Upgrade 6.

-

ZIP 207 3 is modified as follows:

-

In the section Funding streams 4, instead of:

+
+

Modifications to ZIP 207 3

+

The following paragraph is added to the section Motivation:

+
+

ZIP TBD 6 directs part of the block reward to a reserve, the distribution of which is to be determined via a future ZIP. ZIP 2001 7 modified this ZIP to augment the funding stream mechanism with a common mechanism to implement this proposal.

+
+

In the section Funding streams 4, instead of:

Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.

@@ -48,15 +49,93 @@

Each funding stream has an associated sequence of recipients, each of which MUST be either a transparent P2SH address, a Sapling address, or the identifier DEFERRED_POOL.

-

In the section Consensus rules 5, the following will be added:

+

After the section Funding streams, a new section is added with the heading "Deferred Development Fund Chain Value Pool Balance" and the following contents:

-

The "prescribed way" to pay to the DEFERRED_POOL is to add - \(\mathsf{FundingStream[FUND].Value}(\mathsf{height})\) - to +

Full node implementations MUST track an additional + \(\mathsf{PoolValue}_{Deferred}\) + chain value pool balance, in addition to the Sprout, Sapling, and Orchard chain value pool balances.

+

Define + \(\mathsf{totalDeferredOutput}(\mathsf{height}) := \sum_{\mathsf{fs} \in \mathsf{DeferredFundingStreams}(\mathsf{height})} \mathsf{fs.Value}(\mathsf{height})\) + where + \(\mathsf{DeferredFundingStreams}(\mathsf{height})\) + is the set of funding streams with a recipient of DEFERRED_POOL in the block at height + \(\mathsf{height}\) + .

+

The + \(\mathsf{PoolValue}_{Deferred}\) + chain value pool balance for a given block chain is the sum of the values of payments to DEFERRED_POOL for transactions in the block chain.

+

Equivalently, \(\mathsf{PoolValue}_{Deferred}\) + for a block chain up to and including height + \(\mathsf{height}\) + is given by + \(\sum_{\mathsf{h} = 0}^{\mathsf{height}} \mathsf{totalDeferredOutput}(\mathsf{h})\) .

+

Note: + \(\mathsf{totalDeferredOutput}(\mathsf{h})\) + is necessarily zero for heights + \(\mathsf{h}\) + prior to NU6 activation.

+
+

In the section Consensus rules 5, instead of:

+
+
    +
  • The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.
    • +
+
+

it will be modified to read:

+
+
    +
  • In each block, for each active funding stream with a recipient other than DEFERRED_POOL at that block's height, the block's coinbase transaction MUST contain at least one output that pays the stream's value in the prescribed way to that recipient.
    • +
+
+

After the list of post-Canopy consensus rules, the following paragraph is added:

+
+

The effect of the definition of + \(\mathsf{PoolValue}_{Deferred}\) + above is that payments to the DEFERRED_POOL cause + \(\mathsf{FundingStream[FUND].Value}(\mathsf{height})\) + to be added to + \(\mathsf{PoolValue}_{Deferred}\) + for the block chain including that block.

+
+
+

Modifications to the protocol specification

+

In section 7.1.2 Transaction Consensus Rules 10, instead of:

+
+

The total value in zatoshi of transparent outputs from a coinbase transaction, minus + \(\mathsf{v^{balanceSapling}}\) + , minus + \(\mathsf{v^{balanceOrchard}}\) + , MUST NOT be greater than the value in zatoshi of the block subsidy plus the transaction fees paid by transactions in this block.

-

The protocol specification is modified to define the "total issued supply" such that the total issued supply as of a given height is given by the function:

+

it will be modified to read:

+
+

For the block at height + \(\mathsf{height}\) + :

+
    +
  • define the "total output value" of its coinbase transaction to be the total value in zatoshi of its transparent outputs, minus + \(\mathsf{v^{balanceSapling}}\) + , minus + \(\mathsf{v^{balanceOrchard}}\) + , plus + \(\mathsf{totalDeferredOutput}(\mathsf{height})\) + ;
    • +
  • define the "total input value" of its coinbase transaction to be the value in zatoshi of the block subsidy, plus the transaction fees paid by transactions in the block.
    • +
+

The total output value of a coinbase transaction MUST NOT be greater than its total input value.

+
+

where + \(\mathsf{totalDeferredOutput}(\mathsf{height})\) + is defined consistently with ZIP 207.

+

Note: this ZIP and ZIP 236 both make changes to the above rule. Their combined effect is that the last paragraph will be replaced by:

+
+

[Pre-NU6] The total output value of a coinbase transaction MUST NOT be greater than its total input value.

+

[NU6 onward] The total output value of a coinbase transaction MUST be equal to its total input value.

+
+

Section 7.10 Payment of Funding Streams 12 contains language and definitions copied from ZIP 207; it should be updated to reflect the changes made above.

+

In section 3.4 Transactions and Treestates 9, a definition of "total issued supply" will be added, such that the total issued supply as of a given height is given by the function:

\(\begin{array}{ll} \mathsf{IssuedSupply}(\mathsf{height}) := &\!\!\!\!\mathsf{PoolValue}_{Transparent}(\mathsf{height}) \\ &+\;\; \mathsf{PoolValue}_{Sprout}(\mathsf{height}) \\ @@ -64,6 +143,7 @@ &+\,\; \mathsf{PoolValue}_{Orchard}(\mathsf{height}) \\ &+\,\; \mathsf{PoolValue}_{Deferred}(\mathsf{height}) \end{array}\)
+

The second paragraph of section 1.2 High-level Overview 8 should also be updated to take into account the deferred chain value pool. Since that section of the specification is entirely non-normative, we do not give the full wording change here.

References

@@ -107,6 +187,62 @@ + + + + + + + +
6Draft ZIP: Block Reward Allocation for Non-Direct Development Funding
+ + + + + + + +
7ZIP 2001: Lockbox Funding Streams
+ + + + + + + +
8Zcash Protocol Specification, Version 2023.4.0. Section 1.2: High-level Overview <protocol/protocol.pdf#overview>
+ + + + + + + +
9Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates <protocol/protocol.pdf#transactions>
+ + + + + + + +
10Zcash Protocol Specification, Version 2023.4.0. Section 7.1.2: Transaction Consensus Rules <protocol/protocol.pdf#txnconsensus>
+ + + + + + + +
11Zcash Protocol Specification, Version 2023.4.0. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders’ Reward <protocol/protocol.pdf#subsidies>
+ + + + + + + +
12Zcash Protocol Specification, Version 2023.4.0. Section 7.10: Payment of Funding Streams <protocol/protocol.pdf#fundingstreams>
diff --git a/rendered/zip-guide-markdown.html b/rendered/zip-guide-markdown.html index b9121a6d1..e1b2b2809 100644 --- a/rendered/zip-guide-markdown.html +++ b/rendered/zip-guide-markdown.html @@ -19,107 +19,236 @@ License: {usually MIT} Pull-Request: <https://github.com/zcash/zips/pull/???>

Don’t Panic

-

If this is your first time writing a ZIP, the structure and format may look intimidating. But really, it’s just meant to reflect common-sense practice and some technical conventions. Feel free to start with a simple initial draft that gets ideas across, even if it doesn’t quite follow this format. The community and ZIP editors will help you figure things out and get it into shape later.

+

If this is your first time writing a ZIP, the structure and format +may look intimidating. But really, it’s just meant to reflect +common-sense practice and some technical conventions. Feel free to start +with a simple initial draft that gets ideas across, even if it doesn’t +quite follow this format. The community and ZIP editors will help you +figure things out and get it into shape later.

{Delete this section.}

Terminology

-

{Edit this to reflect the key words that are actually used.} The key words “MUST”, “REQUIRED”, “MUST NOT”, “SHOULD”, and “MAY” in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

-

{Avoid duplicating definitions from other ZIPs. Instead use wording like this:}

-

The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification 2.

-

The term “full validator” in this document is to be interpreted as defined in the Zcash protocol specification 3.

+

{Edit this to reflect the key words that are actually used.} The key +words “MUST”, “REQUIRED”, “MUST NOT”, “SHOULD”, and “MAY” in this +document are to be interpreted as described in BCP 14 1 +when, and only when, they appear in all capitals.

+

{Avoid duplicating definitions from other ZIPs. Instead use wording +like this:}

+

The terms “Mainnet” and “Testnet” in this document are to be +interpreted as defined in the Zcash protocol specification 2.

+

The term “full validator” in this document is to be interpreted as +defined in the Zcash protocol specification 3.

The terms below are to be interpreted as follows:

{Term to be defined}
-

{Definition.}

+
+

{Definition.}

{Another term}
-

{Definition.}

+
+

{Definition.}

Abstract

{Describe what this proposal does, typically in a few paragraphs.

-

The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.

-

Use links where applicable, e.g. 4 5.}

+

The Abstract should only provide a summary of the ZIP; the ZIP should +remain complete without the Abstract.

+

Use links where applicable, e.g. 4 5.}

Motivation

{Why is this proposal needed?

-

This is one of the most important sections of the ZIP, and should be detailed and comprehensive. It shouldn’t include any of the actual specification – don’t put conformance requirements in this section.

-

Explain the status quo, why the status quo is in need of improvement, and if applicable, the history of how this area has changed. Then describe at a high level why this proposed solution addresses the perceived issues. It is ok if this is somewhat redundant with the abstract, but here you can go into a lot more detail.}

+

This is one of the most important sections of the ZIP, and should be +detailed and comprehensive. It shouldn’t include any of the actual +specification – don’t put conformance requirements in this section.

+

Explain the status quo, why the status quo is in need of improvement, +and if applicable, the history of how this area has changed. Then +describe at a high level why this proposed solution addresses +the perceived issues. It is ok if this is somewhat redundant with the +abstract, but here you can go into a lot more detail.}

Requirements

-

{Describe design constraints on, or goals for the solution – typically one paragraph for each constraint or goal. Again, don’t actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.}

+

{Describe design constraints on, or goals for the solution – +typically one paragraph for each constraint or goal. Again, don’t +actually specify anything here; this section is primarily for use as a +consistency check that what is specified meets the requirements.}

Non-requirements

-

{This section is entirely optional. If it is present, it describes issues that the proposal is not attempting to address, that someone might otherwise think it does or should.}

+

{This section is entirely optional. If it is present, it describes +issues that the proposal is not attempting to address, that +someone might otherwise think it does or should.}

Specification

{Replace this entire section.}

-

The Specification section describes what should change, using precise language and conformance key words. Anything that is required in order to implement the ZIP (or follow its process, in the case of a Process ZIP) should be in this section.

-

Avoid overspecification! Also avoid underspecification. Specification is hard. Don’t be afraid to ask for help.

-

Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls, consensus rules, etc.

-

ZIPs MUST take into account differences between the Zcash Mainnet and Testnet 6 where applicable. A consensus ZIP MUST be able to be deployed on both Mainnet and Testnet.

-

Unless the specification is particularly simple, you will need to organise it under subheadings.

+

The Specification section describes what should change, using precise +language and conformance key words. Anything that is required in +order to implement the ZIP (or follow its process, in the case of a +Process ZIP) should be in this section.

+

Avoid overspecification! Also avoid underspecification. Specification +is hard. Don’t be afraid to ask for help.

+

Feel free to copy from other ZIPs doing similar things, e.g. defining +RPC calls, consensus rules, etc.

+

ZIPs MUST take into account differences between the Zcash Mainnet and +Testnet 6 where applicable. A consensus ZIP +MUST be able to be deployed on both Mainnet and Testnet.

+

Unless the specification is particularly simple, you will need to +organise it under subheadings.

Example subheading

-

At least while the ZIP is in Draft, we encourage writing open questions and TODOs.

+

At least while the ZIP is in Draft, we encourage writing open +questions and TODOs.

Open questions

TODO: define byte encoding for the Jabberwock.

Comparison of ZIPs to RFCs

-

Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process 7.

+

Like RFCs, ZIPs are precise technical documents that SHOULD give +enough implementation information to implement part of a Zcash-related +protocol or follow a Zcash-related process 7.

ZIPs are different from RFCs in the following ways:

Using mathematical notation

-

Embedded LaTeX x + y is allowed and encouraged in ZIPs. The syntax for inline math is “:math:latex code`" in reStructuredText or "latexcode`” in Markdown. The rendered HTML will use KaTeX 8, which only supports a subset of LaTeX, so you will need to double-check that the rendering is as intended.

-

In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don’t worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in review.

+

Embedded LaTeX x + y is allowed and +encouraged in ZIPs. The syntax for inline math is +“:math:latex +code`" in reStructuredText or "latexcode`” +in Markdown. The rendered HTML will use KaTeX 8, +which only supports a subset of LaTeX, so you will need to double-check +that the rendering is as intended.

+

In general the conventions in the Zcash protocol specification SHOULD +be followed. If you find this difficult, don’t worry too much about it +in initial drafts; the ZIP editors will catch any inconsistencies in +review.

Notes and warnings

-

“.. note::” in reStructuredText, or “:::info” (terminated by “:::”) in Markdown, can be used for an aside from the main text.

-

The rendering of notes is colourful and may be distracting, so they should only be used for important points.

+

“.. note::” in reStructuredText, or +“:::info” (terminated by “:::”) in Markdown, +can be used for an aside from the main text.

+

The rendering of notes is colourful and may be distracting, so they +should only be used for important points.

-

“.. warning::” in reStructuredText, or “:::warning” (terminated by “:::”) in Markdown, can be used for warnings.

-

Warnings should be used very sparingly — for example to signal that a entire specification, or part of it, may be inapplicable or could cause significant interoperability or security problems. In most cases, a “MUST” or “SHOULD” conformance requirement is more appropriate.

+

“.. warning::” in reStructuredText, or +“:::warning” (terminated by “:::”) in +Markdown, can be used for warnings.

+

Warnings should be used very sparingly — for example to signal that a +entire specification, or part of it, may be inapplicable or could cause +significant interoperability or security problems. In most cases, a +“MUST” or “SHOULD” conformance requirement is more appropriate.

Valid markup

-

This is optional before publishing a PR, but to check whether a document is valid reStructuredText or Markdown, first install rst2html5 and pandoc. E.g. on Debian-based distros::

+

This is optional before publishing a PR, but to check whether a +document is valid reStructuredText or Markdown, first install +rst2html5 and pandoc. E.g. on Debian-based +distros::

sudo apt install python3-pip pandoc perl sed
 pip3 install docutils==0.19 rst2html5
-

Then, with draft-myzip.rst or draft-myzip.md in the root directory of a clone of this repo, run::

+

Then, with draft-myzip.rst or +draft-myzip.md in the root directory of a clone of this +repo, run::

make draft-myzip.html
-

(or just “make”) and view draft-myzip.html in a web browser.

+

(or just “make”) and view draft-myzip.html +in a web browser.

Citations and references

-

Each reference should be given a short name, e.g. “snark” 9. The syntax to cite that reference is “[#snark]_” in reStructuredText, or “[^snark]” in Markdown.

-

The corresponding entry in the References section should look like this in reStructuredText:

-
.. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+

Each reference should be given a short name, e.g. “snark” 9. The syntax to cite that reference +is “[#snark]_” in reStructuredText, or +“[^snark]” in Markdown.

+

The corresponding entry in the References +section should look like this in reStructuredText:

+
.. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.

or like this in Markdown::

-
[^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
-

Note that each entry must be on a single line regardless of how long that makes the line. In Markdown there must be a blank line between entries.

-

The current rendering of a Markdown ZIP reorders the references according to their first use; the rendering of a reStructuredText ZIP keeps them in the same order as in the References section.

+
[^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+

Note that each entry must be on a single line regardless of how long +that makes the line. In Markdown there must be a blank line between +entries.

+

The current rendering of a Markdown ZIP reorders the references +according to their first use; the rendering of a reStructuredText ZIP +keeps them in the same order as in the References section.

To link to another section of the same ZIP, use

-
`Section title`_
+
`Section title`_

in reStructuredText, or

-
[Section title]
+
[Section title]

in Markdown.

-

Citing the Zcash protocol specification

-

For references to the Zcash protocol specification, prefer to link to a section anchor, and name the reference as [^protocol-<anchor>]. This makes it more likely that the link will remain valid if sections are renumbered or if content is moved. The anchors in the protocol specification can be displayed by clicking on a section heading in most PDF viewers. References to particular sections should be versioned, even though the link will point to the most recent stable version.

-

Do not include the “https://zips.z.cash/” part of URLs to ZIPs or the protocol spec.

+

Citing the Zcash +protocol specification

+

For references to the Zcash protocol specification, prefer to link to +a section anchor, and name the reference as +[^protocol-<anchor>]. This makes it more likely that +the link will remain valid if sections are renumbered or if content is +moved. The anchors in the protocol specification can be displayed by +clicking on a section heading in most PDF viewers. References to +particular sections should be versioned, even though the link will point +to the most recent stable version.

+

Do not include the “https://zips.z.cash/” part of URLs +to ZIPs or the protocol spec.

Reference implementation

-

{This section is entirely optional; if present, it usually gives links to zcashd or zebrad PRs.}

+

{This section is entirely optional; if present, it usually gives +links to zcashd or zebrad PRs.}

References

-
+
+ diff --git a/zips/draft-noamchom67-manufacturing-consent.rst b/zips/draft-noamchom67-manufacturing-consent.rst index 1116732e4..bbbb9e359 100644 --- a/zips/draft-noamchom67-manufacturing-consent.rst +++ b/zips/draft-noamchom67-manufacturing-consent.rst @@ -4,7 +4,7 @@ Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub Owner: Noam Chom Credits: The ZIP-1014 Authors - Status: Active + Status: Withdrawn Category: Consensus Process Created: 2024-06-25 License: MIT diff --git a/zips/draft-nuttycom-funding-allocation.rst b/zips/draft-nuttycom-funding-allocation.rst index 15b2bd51c..81cd398f2 100644 --- a/zips/draft-nuttycom-funding-allocation.rst +++ b/zips/draft-nuttycom-funding-allocation.rst @@ -8,7 +8,7 @@ Credits: Daira-Emma Hopwood Jack Grigg @Peacemonger (Zcash Forum) - Status: Draft + Status: Withdrawn Category: Consensus Created: 2024-07-03 License: MIT diff --git a/zips/draft-zf-community-dev-fund-2-proposal.rst b/zips/draft-zf-community-dev-fund-2-proposal.rst index 30182c7fe..603aa981a 100644 --- a/zips/draft-zf-community-dev-fund-2-proposal.rst +++ b/zips/draft-zf-community-dev-fund-2-proposal.rst @@ -4,7 +4,7 @@ Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve Owners: Jack Gavigan Credits: The ZIP 1014 Authors - Status: Draft + Status: Withdrawn Category: Consensus Process Created: 2024-07-01 License: MIT diff --git a/zips/zip-0000.rst b/zips/zip-0000.rst index b7f9ed50f..b777f9701 100644 --- a/zips/zip-0000.rst +++ b/zips/zip-0000.rst @@ -5,6 +5,7 @@ Owners: Jack Grigg Conrado Gouvêa Arya + Kris Nuttycombe Original-Authors: Daira-Emma Hopwood Josh Cincinnati George Tankersley @@ -170,7 +171,7 @@ ZIP Editors The current ZIP Editors are: -* Jack Grigg, associated with the Electric Coin Company; +* Jack Grigg and Kris Nuttycombe, associated with the Electric Coin Company; * Conrado Gouvêa and Arya, associated with the Zcash Foundation. All can be reached at zips@z.cash. The current design of the ZIP Process diff --git a/zips/zip-0214.rst b/zips/zip-0214.rst index 7efbda2d4..2f153919a 100644 --- a/zips/zip-0214.rst +++ b/zips/zip-0214.rst @@ -3,7 +3,8 @@ ZIP: 214 Title: Consensus rules for a Zcash Development Fund Owners: Daira-Emma Hopwood - Status: Final + Kris Nuttycombe + Status: Revision 0: Final, Revision 1: Draft Category: Consensus Created: 2020-02-28 License: MIT @@ -19,7 +20,9 @@ in all capitals. The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor -agreement). +agreement) while that agreement is in effect. On termination of that agreement, +the term "Zcash" will refer to the continuations of the same Mainnet and Testnet +block chains as determined by social consensus. The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License @@ -36,19 +39,30 @@ The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "MG slice" in this document are to be interpreted as described in ZIP 1014 [#zip-1014]_. +The terms "Zcash Community Grants (or "ZCG") and "Financial Privacy Foundation" +(or "FPF") in this document are to be interpreted as described in ZIP 1015 +[#zip-1015]_. + The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. "Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. +"NU6" is the code-name for the seventh Zcash network upgrade, also known as +Network Upgrade 6. + Abstract ======== -This ZIP describes consensus rule changes interpreting the proposed structure of -the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last -for 4 years. +`Revision 0`_ of this ZIP describes consensus rule changes interpreting the +proposed structure of the Zcash Development Fund, which is to be enacted in +Network Upgrade 4 and last for 4 years. + +`Revision 1`_ of this ZIP describes consensus rule changes related to funding +of Zcash development via block rewards, to be enacted at Network Upgrade 6 and +lasting for 1 year. Applicability @@ -61,21 +75,22 @@ applicable to other block chains using Zcash technology. Motivation ========== -Motivation for the Zcash Development Fund itself is considered in ZIP 1014 -[#zip-1014]_, which gives a high-level description of the intended structure of -the fund. +Motivation for the Zcash Development Fund itself is considered in ZIPs 1014 +[#zip-1014]_ and 1015 [#zip-1015]_, which give high-level descriptions of the +intended structure of the funds. An important motivation for describing the consensus rules in a separate ZIP is -to avoid making unintended changes to ZIP 1014, which has already been agreed -between ECC, ZF, and the Zcash community. This facilitates critically assessing -whether the consensus rule changes accurately reflect the intent of ZIP 1014. +to avoid making unintended changes to ZIPs 1014 and 1015, which have already +been agreed between ECC, ZF, and the Zcash community. This facilitates +critically assessing whether the consensus rule changes accurately reflect the +intent of ZIPs 1014 and 1015. Requirements ============ The primary requirement of this ZIP is to make changes to consensus rules necessary -and sufficient to implement the intent of ZIP 1014. +and sufficient to implement the intent of ZIPs 1014 and 1015. The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and @@ -86,13 +101,29 @@ and implementation within sufficient lead time before activation on Mainnet. Non-requirements ================ -This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what -is implementable by Zcash consensus rules. +This ZIP is not required to enforce provisions of ZIP 1014 or ZIP 1015 that fall +outside what is implementable by Zcash consensus rules. Specification ============= +Revisions +--------- + +.. _`Revision 0`: + +* Revision 0: The initial version of this specification, as agreed upon + by the Zcash community in ZIP 1014 [#zip-1014]_. + +.. _`Revision 1`: + +* Revision 1: Funding streams defined to start at Zcash's second halving, + and last for one year, as agreed upon in ZIP 1015 [#zip-1015]_. + +Activation +---------- + The Blossom network upgrade changed the height of the first halving to block height 1046400 [#zip-0208]_, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds. @@ -100,9 +131,21 @@ The Blossom network upgrade changed the height of the first halving to block hei Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400. -ZIP 207 [#zip-0207]_ SHALL be activated in Canopy. +`Revision 0`_ of ZIP 207 [#zip-0207]_ SHALL be activated in Canopy. + +Since ZIP 1015 specifies that the specified funding streams start at the second +halving, the activation height of NU6 on Mainnet therefore SHALL be 2726400. + +`Revision 1`_ of ZIP 207 [#zip-0207]_ SHALL be activated in NU6. + +As specified in [#zip-0207]_, a funding stream is active for a span of blocks +that includes the block at its start height, but excludes the block at its end +height. + +Funding Streams +--------------- -The following funding streams are defined for Mainnet: +As of `Revision 0`_, the following funding streams are defined for Mainnet: ================= =========== ============= ============== ============ Stream Numerator Denominator Start height End height @@ -112,11 +155,7 @@ The following funding streams are defined for Mainnet: ``FS_ZIP214_MG`` 8 100 1046400 2726400 ================= =========== ============= ============== ============ -As specified in [#zip-0207]_, a funding stream is active for a span of blocks -that includes the block at its start height, but excludes the block at its end -height. - -The following funding streams are defined for Testnet: +As of `Revision 0`_, the following funding streams are defined for Testnet: ================= =========== ============= ============== ============ Stream Numerator Denominator Start height End height @@ -126,7 +165,25 @@ The following funding streams are defined for Testnet: ``FS_ZIP214_MG`` 8 100 1028500 2796000 ================= =========== ============= ============== ============ -Notes: +As of `Revision 1`_, the following additional streams are defined for Mainnet: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2726400 3146400 +``FS_FPF_ZCG`` 8 100 2726400 3146400 +================= =========== ============= ============== ============ + +As of `Revision 1`_, the following additional streams are defined for Testnet: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2976000 3396000 +``FS_FPF_ZCG`` 8 100 2976000 3396000 +================= =========== ============= ============== ============ + +Notes for `Revision 0`_: * The block heights of halvings are different between Testnet and Mainnet, as a result of different activation heights for the Blossom network upgrade (which @@ -139,9 +196,15 @@ Notes: initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1116000 (inclusive) to 2796000 (exclusive). +Notes for `Revision 1`_: -Dev Fund Recipient Addresses ----------------------------- +* The new funding streams begin at the second halving for Mainnet, but the second + halving on Testnet occurred prior to the introduction of the new funding streams. + For both new funding streams on each network, the associated duration + corresponds to approximately one year's worth of blocks. + +Dev Fund Recipient Addresses for `Revision 0`_ +---------------------------------------------- For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC on behalf @@ -163,26 +226,16 @@ the corresponding slice specified in ZIP 1014 [#zip-1014]_. No requirements are imposed on the use of funds sent to Testnet funding streams. - Direct-grant option ''''''''''''''''''' -ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC +ZIP 1014 specified a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the **MG slice** may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. [#zip-1014]_ +However, this option was never taken up. -The funding stream mechanism allows for this option by adding a funding stream -corresponding to each direct grantee, with addresses generated by ZF. In this case -the total value of funding streams assigned to direct grantees MUST be subtracted -from the value of the funding stream for the remaining **MG slice** (or, if all -Major Grants are direct, replace the funding stream for the **MG slice**). - -For each network upgrade after Canopy requiring modifications to the set of direct -grantees, a separate ZIP SHOULD be published specifying those modifications. - - -Mainnet Recipient Addresses ---------------------------- +Mainnet Recipient Addresses for `Revision 0`_ +--------------------------------------------- :: @@ -244,9 +297,13 @@ Mainnet Recipient Addresses (i.e. ``FS_ZIP214_ZF.AddressList`` and ``FS_ZIP214_MG.AddressList`` for Mainnet each consist of 48 repetitions of the same address). +Mainnet Recipient Addresses for `Revision 1`_ +--------------------------------------------- + + -Testnet Recipient Addresses ---------------------------- +Testnet Recipient Addresses for `Revision 0`_ +--------------------------------------------- :: @@ -311,9 +368,14 @@ Testnet Recipient Addresses (i.e. ``FS_ZIP214_ZF.AddressList`` and ``FS_ZIP214_MG.AddressList`` for Testnet each consist of 51 repetitions of the same address). +Testnet Recipient Addresses for `Revision 1`_ +--------------------------------------------- + + FS_FPF_ZCG.AddressList[0..12] = ["t2HifwjUj9uyxr9bknR8LFuQbc98c3vkXtu"] * 13 + -Rationale -========= +Rationale for `Revision 0`_ +=========================== The rationale for ZF generating the addresses for the ``FS_ZIP214_MG`` funding stream is that ZF is the financial recipient of the **MG slice** as specified @@ -331,21 +393,24 @@ other than at network upgrades. Deployment ========== -This proposal is intended to be deployed with Canopy. [#zip-0251]_ +`Revision 0`_ of this proposal was deployed with Canopy. [#zip-0251]_ +`Revision 1`_ of this proposal is intended to be deployed with NU6. [#zip-0253]_ 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" `_ -.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ -.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ -.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward `_ +.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_ +.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward `_ .. [#trademark] `Zcash Trademark Donation and License Agreement `_ .. [#osd] `The Open Source Definition `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0207] `ZIP 207: Funding Streams `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ .. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ +.. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade `_ .. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ +.. [#zip-1015] `ZIP 1015: Block Reward Allocation for Non-Direct Development Funding `_ diff --git a/zips/zip-0233.md b/zips/zip-0233.md new file mode 100644 index 000000000..c68bb8cb4 --- /dev/null +++ b/zips/zip-0233.md @@ -0,0 +1,242 @@ +``` +ZIP: 233 +Title: Establish the Zcash Sustainability Fund on the Protocol Level +Owners: Jason McGee + Mark Henderson + Tomek Piotrowski + Mariusz Pilarek +Original-Authors: Nathan Wilcox +Credits: +Status: Draft +Category: Consensus / Ecosystem +Created: 2023-08-16 +License: BSD-2-Clause +``` + +# Terminology + +The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", +and "REQUIRED" in this document are to be interpreted as described in RFC 2119. +[1] + +The term "network upgrade" in this document is to be interpreted as described +in ZIP 200. [2] + +"Block Subsidy” - the algorithmic issuance of ZEC on block creation – part of +the consensus rules. Split between the miner and the Dev Fund. Also known as +Block Reward. + +"Issuance" - The method by which unmined or unissued ZEC is converted to ZEC +available to users of the network + +"We" - the ZIP authors, owners listed in the above front matter + +"`MAX_MONEY`" is the ZEC supply cap. For simplicity, this ZIP defines it to be +`21,000,000 ZEC`, although this is slightly larger than the actual supply cap +of the original ZEC issuance mechanism. + +# Abstract + +This ZIP describes the motivation, the necessary changes for, and the +implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF +is a proposed alteration to the block rewards system and accounting of unmined +ZEC that allows for other sources of funding besides unissued ZEC. This new +mechanism for deposits -- that new applications or protocol designs can use to +strengthen the long-term sustainability of the network -- will likely be an +important step for future economic upgrades, such as a transition to Proof of +Stake or Zcash Shielded Assets, and other potential protocol fees and user +applications. + +The changes in this ZIP are ultimately minimal, only requiring for the node to +track state in the form of a `ZSF_BALANCE`, and for a new transaction field to +be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to +add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are +absolutely required for developers or ZEC holders. + +This ZIP does not change the current ZEC block subsidy issuance schedule. Any +additional amounts paid into the sustainability fund are reserved for use in +future ZIPs. + +# Motivation + +The Zcash network's operation and development relies fundamentally on the block +reward system inherited from Bitcoin. This system currently looks like this: + +- At Every New Block: + - Miner and funding streams are rewarded a constant amount via unissued ZEC + (this constant amount halves at specified heights) + - Miner is rewarded via Transaction fees `(inputs - outputs)` + +The Zcash Sustainability Fund is a proposed replacement to that payout +mechanism, with the relevant parts in *bold* below: + +- **Unmined ZEC is now accounted for as `ZSF_BALANCE`** +- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field** +- Thus, at Every New Block: + - Miner and funding streams rewarded the same constant amount, **but from + `ZSF_BALANCE`** (this constant amount still halves at specified heights) + - Miner is rewarded via Transaction fees `(inputs - outputs)`, **where + `outputs` includes the `ZSF_DEPOSIT` amount** + +For example, an end-user wallet application could have an option to contribute +a portion of a transaction to the ZSF, which would be included in a +`ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash +nodes. + +This quite simple alteration has -- in our opinion -- a multitude of benefits: + +1. **Long Term Consensus Sustainability:** This mechanism supports long-term + consensus sustainability by addressing concerns about the sustainability of + the network design shared by Bitcoin-like systems through the establishment + of deposits into the Sustainability Fund to augment block rewards, ensuring + long-term sustainability as the issuance rate of Zcash drops and newly + issued ZEC decreases over time. +2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of + ZEC, temporarily reducing its available supply, benefiting current holders + of unencumbered active ZEC in proportion to their holdings without requiring + them to opt into any scheme, introducing extra risk, active oversight, or + accounting complexity. +3. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not + claiming all available rewards, some ZEC goes unaccounted for, though not + formally burned. This proposal would recover it through the `ZSF_BALANCE` + mechanism described below. + +# Specification + +In practice, The Zcash Sustainability Fund is a single global balance +maintained by the node state and contributed to via a single transaction field. +This provides the economic and security support described in the motivation +section, while also importantly keeping the fund payouts extremely simple to +describe and implement. + +The two modifications are: +1. The re-accounting of unmined ZEC as a node state field called `ZSF_BALANCE` +2. The addition of a transaction field called `ZSF_DEPOSIT` + +## `ZSF_BALANCE` + +The ZEC issuance mechanism is re-defined to remove funds from `ZSF_BALANCE`, +which is initially set to `MAX_MONEY` at the genesis block. + +Consensus nodes are then required to track new per-block state: + +- `ZSF_BALANCE[height] : u64 [zatoshi]` + +The state is a single 64 bit integer (representing units of `zatoshi`) at any +given block height, $\mathsf{height}$, representing the Sustainability Fund +balance at that height. The `ZSF_BALANCE` can be calculated using the following +formula: + +$\mathsf{ZsfBalanceAfter}(\mathsf{height}) = \mathsf{MAX\_MONEY} + \sum_{h = 0}^{\mathsf{height}} (\mathsf{ZsfDeposit}(h) + \mathsf{Unclaimed}(h) - \mathsf{BlockSubsidy}(h))$ + +where $\mathsf{Unclaimed}(\mathsf{height})$ is the portion of the block subsidy +and miner fees that are unclaimed for the block at the given height. + +The block at height $\mathsf{height}$ commits to +$\mathsf{ZsfBalanceAfter}(\mathsf{height})$ as part of a new block commitment +in the block header, at the end of the `hashBlockCommitments` chain in +[ZIP-244](https://zips.z.cash/zip-0244#block-header-changes). + +TODO ZIP editors: consider introducing a chain state commitment hash tree. +(When we get closer to the network upgrade, we will have a better idea what +commitments that network upgrade needs.) + +## Deposits into the Sustainability Fund + +Sustainability fund deposits can be made via the new `zsfDeposit` field. This +can be done by: +- ZEC fund holders, in non-coinbase transactions; +- Zcash miners, in coinbase transactions. + +In transaction versions without this new field: +- unclaimed miner fees and rewards in **coinbase transactions** are re-defined + as deposits into the sustainability fund, and +- there are no sustainability fund deposits from non-coinbase transactions. + +Note: older transaction versions can continue to be supported after a network +upgrade. For example, NU5 supports both v4 and v5 transaction formats, for both +coinbase and non-coinbase transactions. + +### `zsfDeposit` fields in transactions + +Each transaction can dedicate some of its excess funds to the ZSF, and the +remainder becomes the miner fee, with any excess miner fee/reward going to the +ZSF + +This is achieved by adding a new field to the common transaction fields +[#zip-0225-transaction-format]: + +- `zsfDeposit : u64 [zatoshi]` + +The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value +of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. +First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. +This is subtracted from the previous block's balance to be distributed as part +of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all +transactions in the block is added to the balance. + + +### Non-Coinbase Transactions + +If the `ZSF_DEPOSIT` field is not present in an older transaction version, it +is defined to be zero for non-coinbase transactions. + +#### Consensus Rule Changes + +- Transparent inputs to a transaction insert value into a transparent + transaction value pool associated with the transaction. Transparent outputs + **and sustainability fund deposits** remove value from this pool. + +### Coinbase Transactions + +Any excess miner fee/reward is sent to the ZSF. + +In new blocks, this deposit is tracked via the `ZSF_DEPOSIT` field in coinbase +transactions. + +If the `ZSF_DEPOSIT` field is not present in a coinbase transaction with an +older transaction version, it is defined as the value of any unspent miner fee +and miner reward. This re-defines these previously unspendable funds as ZSF +deposits. + +#### Consensus Rule Changes + +- The remaining value in the transparent transaction value pool of a coinbase + transaction is **deposited in the sustainability fund**. + +### `ZSF_DEPOSIT` Requirements + +- ZIP 230 [3] must be updated to include `ZSF_DEPOSIT`. +- ZIP 244 [4] must be updated as well to include `ZSF_DEPOSIT`. + +# Rationale + +All technical decisions in this ZIP are balanced between the necessary +robustness of the ZSF mechanics, and simplicity of implementation. + +## `ZSF_BALANCE` as node state + +Tracking the `ZSF_BALANCE` value as a node state using the above formula is +very simple in terms of implementation, and should work correctly given that +the node implementations calculate the value according to the specifications. + +## `ZSF_DEPOSIT` as explicit transaction field + +An explicit value distinguishes the ZEC destined to Sustainability Fund +deposits from the implicit transaction fee. Explicitness also ensures any +arithmetic flaws in any implementations are more likely to be observed and +caught immediately. + +# Deployment + +This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors). + +# References + +**[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)** + +**[2]: [ZIP 200: Network Upgrade Mechanism](https://zips.z.cash/zip-0200)** + +**[3]: [ZIP 230: v6 transactions, including ZSAs](https://github.com/zcash/zips/pull/687)** + +**[4]: [ZIP 244: Transaction Identifier Non-Malleability](https://zips.z.cash/zip-0244)** diff --git a/zips/zip-0234-balance.png b/zips/zip-0234-balance.png new file mode 100644 index 000000000..9f0e8e5a7 Binary files /dev/null and b/zips/zip-0234-balance.png differ diff --git a/zips/zip-0234-block_subsidy.png b/zips/zip-0234-block_subsidy.png new file mode 100644 index 000000000..435d8fcd4 Binary files /dev/null and b/zips/zip-0234-block_subsidy.png differ diff --git a/zips/zip-0234.md b/zips/zip-0234.md new file mode 100644 index 000000000..332baac6d --- /dev/null +++ b/zips/zip-0234.md @@ -0,0 +1,221 @@ +``` +ZIP: 234 +Title: Smooth Out The Block Subsidy Issuance +Owners: Jason McGee + Mark Henderson + Tomek Piotrowski + Mariusz Pilarek +Original-Authors: Nathan Wilcox +Credits: +Status: Draft +Category: Consensus +Created: 2023-08-23 +License: BSD-2-Clause +``` + +# Terminology + +The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, “OPTIONAL”, +and “REQUIRED” in this document are to be interpreted as described in RFC 2119. [1] + +"Network upgrade" - to be interpreted as described in ZIP 200. [2] + +“Block Subsidy” - to be interpreted as described in the Zcash Protocol +Specification (TODO ZIP Editors: link from comment). + +“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out +if this definition is correct or can be removed). + +“`ZsfBalanceAfter(h)`” is the total ZEC available in the Zcash Sustainability +Fund (ZSF) after the transactions in block `h`, described in ZIP draft-zsf.md. +In this ZIP, the Sustainability Fund is used to pay out Block Subsidies from +unmined ZEC, and other fund deposits. + +Let `PostBlossomHalvingInterval` be as defined in [#protocol-diffadjustment]_. + + +# Abstract + +This ZIP proposes a change to how nodes calculate the block subsidy. + +Instead of following a step function around the 4-year halving intervals +inherited from Bitcoin, we propose a slow exponential “smoothing” of the curve. +The new issuance scheme would approximate the current issuance over 4-year +intervals. + +This ZIP depends on the ZIP introducing the Zcash Sustainability Fund +(ZIP-XXX). + +# Motivation + +The current Zcash economic model, inherited from Bitcoin, includes a halving +mechanism which dictates the issuance of new coins. While this has been +foundational, halvings can lead to abrupt changes in the rate of new coins +being introduced to the market. Such sudden shifts can potentially disrupt the +network's economic model, potentially impacting its security and stability. +Furthermore, the halvings schedule is fixed and does not provide any way to +"recycle" funds into future issuance. + +To address this, we propose issuing a fixed portion of the pending +funds-to-be-issued in each block. This has the effect of smoothing out the +issuance curve of ZEC, ensuring a more consistent and predictable rate of coin +issuance, while still preserving the overall supply cap of 21,000,000 coins. +This mechanism by itself (without other anticipated changes) seeks to preserve +the core aspects of Zcash's issuance policy and aims to enhance predictability +and avoid sudden changes. By making this shift, the average block subsidy over +time will remain predictable with very gradual changes. + +However, we anticipate schemes proposed in [#draft-zsf]_ where the amount of +funds-to-be-issued may increase. In that scenario, this issuance mechanism +would distribute that increase starting in the immediately following block and +subsequent blocks. Because this distribution mechanism has an exponential +decay, such increases will be spread out in miniscule amounts to future blocks +over a long time period. This issuance mechanism thus provides a way for +potential increases or decreases of issuance while constraining those changes +to be small on a short time scale to avoid unexpected disruptions. + +Additionally, the current Bitcoin-style issuance does not take into account the +current balance of `ZsfBalanceAfter(h)`. If [#draft-zsf]_ were to activate +without a change to the issuance mechanism, then some funds would never be +disbursed after they are deposited back into the ZSF. + +# Requirements + +Smoothing the issuance curve is possible using an exponential decay formula +that satisfies the following requirements: + +## Issuance Requirements + +1. The issuance can be summarised into a reasonably simple explanation +2. Block subsidies approximate a continuous function +3. If there are funds in the ZSF, then the block subsidy must be non-zero, + preventing any final “unmined” zatoshis +4. For any 4 year period, all paid out block subsidies are approximately equal + to half of the ZSF at the beginning of that 4 year period, if there are no + deposits into the ZSF during those 4 years + +TODO daira: add a requirement that makes the initial total issuance match the previous total issuance + +# Specification + +## Goals + +We want to decrease the short-term impact of the deployment of this ZIP on +block reward recipients, and minimise the potential reputational risk to Zcash +of changing the block reward amount. + +## Constants + +Define constants: + +“`BLOCK_SUBSIDY_FRACTION`” = 4126 / 10,000,000,000 or `0.0000004126` + +"`DEPLOYMENT_BLOCK_HEIGHT`" = 2726400 + +## Issuance Calculation + +At the `DEPLOYMENT_BLOCK_HEIGHT`, nodes should switch from the current issuance +calculation, to the following: + +Given the block height `h` define a function **BlockSubsidy(h)**, such that: + +**BlockSubsidy(h)** = Block subsidy for a given `h`, that satisfies above +requirements. + +Using an exponential decay function for **BlockSubsidy** satisfies requirements +**R1** and **R2** above: + +`BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)` + +Finally, to satisfy **R3** above we always round up to the next zatoshi. + +`BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))` + +# Rationale + +## `BLOCK_SUBSIDY_FRACTION` + +Let `IntendedZSFFractionRemainingAfterFourYears` = 0.5. + +The value `4126 / 10_000_000_000` satisfies the approximation within +0.002%: + +`(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears` + +Meaning after a period of 4 years around half of `ZSF_BALANCE` will be paid out +as block subsidies, thus satisfying **R4**. + +The largest possible amount in the ZSF is MAX_MONEY, in the theoretically +possible case that all issued funds are deposited back into the ZSF. If this +happened, the largest interim sum in the block subsidy calculation would be +MAX_MONEY * 4126 + 10000000000. + +This uses 62.91 bits, which is just under the 63 bit limit for 64-bit signed +two's-complement integer amount types. + +The numerator could be brought closer to the limit by using a larger +denominator, but the difference in the amount issued would be very small. So we +chose a power-of-10 denominator for simplicity. + +TODO for ZIP owners: How many ZEC per day? + +## `DEPLOYMENT_BLOCK_HEIGHT` + +The deployment should happen at the next halving, which is block `2726400`. + +Since there is a planned halving at this point, there will already be a +significant "shock" caused by the drop in issuance caused by the halving. This +reduces surprise and thus increases security. Also, due to the nature of the +smoothed curve having a portion of the curve above the respective step function +line at times, this will maximally _reduce_ the issuance shock at the +`DEPLOYMENT_BLOCK_HEIGHT`. + +## Visualization of the Smoothed Curve + +The following graph illustrates compares issuance for the current halving-based +step function vs the smoothed curve. + +![A graph showing a comparison of the halving-based step function vs the smoothed curve](../rendered/assets/images/zip-0234-block_subsidy.png) + +The graph below shows the balance of the ZSF assuming smooth issuance is +implemented. + +![A graph showing the balance of the ZSF assuming smooth issuance is implemented](../rendered/assets/images/zip-0234-balance.png) + +# Deployment + +The implementation of this ZIP MUST be deployed at the same time or after the +Zcash Sustainability Fund is established (ZIP-XXX). + +# Appendix: Simulation + +The [ZSF simulator](https://github.com/eigerco/zsf-simulator) allows us to +simulate the effects of this ZIP on the ZSF balance and the block subsidy, as +well as generate plots like the ones above. Its output: + +``` +Last block is 47917869 in ~113.88 years +``` + +indicates that, assuming no ZEC is ever deposited to the ZSF, its balance will +be depleted after 113.88 years, and the block subsidy will be 0 ZEC after that +point. + +This fragment of the output + +``` +Halving 1 at block 1680000: + ZSF subsidies: 262523884819889 (~ 2625238.848 ZEC, 1.563 ZEC per block) + legacy subsidies: 262500000000000 (~ 2625000.000 ZEC, 1.562 ZEC per block) + difference: 23884819889 (~ 238 ZEC), ZSF/legacy: 1.0001 +``` + +shows that the difference between the smoothed out and the current issuance +schemes is 238 ZEC after 1680000 blocks (aroound 4 years). + +# References + +[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119 + +[2] ZIP-200: https://zips.z.cash/zip-0200 + +[3] ZIP-XXX: Placeholder for the ZSF ZIP diff --git a/zips/zip-0253.md b/zips/zip-0253.md index b4334c76e..3238dcdfa 100644 --- a/zips/zip-0253.md +++ b/zips/zip-0253.md @@ -2,7 +2,7 @@ ZIP: 253 Title: Deployment of the NU6 Network Upgrade Owners: Arya - Status: Draft + Status: Proposed Category: Consensus / Network Created: 2024-07-17 License: MIT @@ -26,15 +26,13 @@ This proposal defines the deployment of the NU6 network upgrade. ## NU6 deployment - - The primary sources of information about NU6 consensus protocol changes are: * The Zcash Protocol Specification [^protocol]. -* Network Upgrade Mechanism [^zip-0200]. -* Lockbox Funding Streams [^zip-2001]. -* Block Reward Allocation for Non-Direct Development Funding [^draft-nuttycom-funding-allocation]. -* Blocks should balance exactly [^zip-0236]. +* ZIP 200: Network Upgrade Mechanism [^zip-0200]. +* ZIP 236: Blocks should balance exactly [^zip-0236]. +* ZIP 1015: Block Reward Allocation for Non-Direct Development Funding [^zip-1015]. +* ZIP 2001: Lockbox Funding Streams [^zip-2001]. The network handshake and peer management mechanisms defined in ZIP 201 [^zip-0201] also apply to this upgrade. @@ -50,7 +48,7 @@ CONSENSUS_BRANCH_ID : `0xC8E71055` ACTIVATION_HEIGHT (NU6) -: Testnet: TBD +: Testnet: 2976000 : Mainnet: TBD MIN_NETWORK_PROTOCOL_VERSION (NU6) @@ -71,20 +69,20 @@ NU6 does not define a new transaction version or impose a new minimum transactio [^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) -[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) - [^protocol-networks]: [Zcash Protocol Specification, Version v2023.4.0 or later. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) [^protocol]: [Zcash Protocol Specification, Version v2023.4.0 or later](protocol/protocol.pdf) -[^zip-2001]: [ZIP 2001 Lockbox Funding Streams](draft-nuttycom-lockbox-streams.rst) - -[^zip-0236]: [ZIP 236: Blocks should balance exactly](draft-hopwood-coinbase-balance.rst) - -[^draft-nuttycom-funding-allocation]: [ZIP ???: Block Reward Allocation for Non-Direct Development Funding](draft-nuttycom-funding-allocation.rst) +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) [^zip-0201]: [ZIP 201: Network Peer Management for Overwinter](zip-0201.rst) [^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst) [^zip-0214]: [ZIP 214: Consensus rules for a Zcash Development Fund](zip-0214.rst) + +[^zip-0236]: [ZIP 236: Blocks should balance exactly](zip-0236.rst) + +[^zip-1015]: [ZIP 1015: Block Reward Allocation for Non-Direct Development Funding](zip-1015.rst) + +[^zip-2001]: [ZIP 2001: Lockbox Funding Streams](zip-2001.rst) diff --git a/zips/zip-1015.rst b/zips/zip-1015.rst new file mode 100644 index 000000000..1ed4f0a26 --- /dev/null +++ b/zips/zip-1015.rst @@ -0,0 +1,391 @@ +:: + + ZIP: 1015 + Title: Block Reward Allocation for Non-Direct Development Funding + Owners: Jason McGee + @Peacemonger (Zcash Forum) + Kris Nuttycombe + Credits: @GGuy (Zcash Forum) + Daira-Emma Hopwood + Jack Grigg + Skylar Saveland + Status: Proposed + Category: Consensus + Created: 2024-08-26 + License: MIT + Pull-Request: + + +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. + +"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of +community members assembled by the Zcash Foundation and described at [#zcap]_. + +"Zcash Community Grants", also called "ZCG", refers to the committee selected +by the Zcash Community Advisory Panel or a successor process (e.g. as established +by FPF) to decide on the funding of grants intended to fund the Zcash ecosystem. + +"Financial Privacy Foundation", also called "FPF", refers to the Cayman +Islands-incorporated non-profit foundation company limited by guarantee of +that name. + +"Autonomous Entities" refers to committees, DAOs, teams or other groups to +which FPF provides operations, administrative, and financial management +support. + + +Abstract +======== + +This ZIP proposes the allocation of a percentage of the Zcash block subsidy, +post-November 2024 halving, split between Zcash Community Grants (ZCG) and an +in-protocol "lockbox." The "lockbox" is a separate pool of issued funds tracked +by the protocol, as described in ZIP 2001: Lockbox Funding Streams [#zip-2001]_. +No disbursement mechanism is currently defined for this "lockbox"; the Zcash +community will need to decide upon and specify a suitable decentralized +mechanism for permitting withdrawals from this lockbox in a future ZIP in order +to make these funds available for funding grants to ecosystem participants. + +The proposed lockbox addresses significant issues observed with ZIP 1014 +[#zip-1014]_, such as regulatory risks, inefficiencies due to funding of +organizations instead of projects, and centralization. While the exact +disbursement mechanism for the lockbox funds is yet to be determined and will be +addressed in a future ZIP, the goal is to employ a decentralized mechanism that +ensures community involvement and efficient, project-specific funding. This +approach is intended to potentially improve regulatory compliance, reduce +inefficiencies, and enhance the decentralization of Zcash's funding structure. + + +Motivation +========== + +Starting at Zcash's second halving in November 2024, under pre-existing +consensus rules 100% of the block subsidies would be allocated to miners, and no +further funds would be automatically allocated to any other entities. +Consequently, unless the community takes action to approve new +block-reward-based funding, existing teams dedicated to development or outreach +or furthering charitable, educational, or scientific purposes would likely need +to seek other sources of funding; failure to obtain such funding would likely +impair their ability to continue serving the Zcash ecosystem. Setting aside a +portion of the block subsidy to fund development will help ensure that both +existing teams and new contributors can obtain funding in the future. + +It is important to balance the incentives for securing the consensus protocol +through mining with funding crucial charitable, educational, and scientific +activities like research, development, and outreach. Additionally, there is a +need to continue to promote decentralization and the growth of independent +development teams. + +For these reasons, the Zcash Community wishes to establish a new Zcash +Development Fund after the second halving in November 2024, with the intent to +put in place a more decentralized mechanism for allocation of development +funds. The alternatives presented here are intended to address the following: + +1. **Regulatory Risks**: The current model involves direct funding of US-based + organizations, which can potentially attract regulatory scrutiny from + entities such as the SEC, posing legal risks to the Zcash ecosystem. + +2. **Funding Inefficiencies**: The current model directly funds organizations + rather than specific projects, leading to a potential mismatch between those + organizations' development priorities and the priorities of the community. + Furthermore, if organizations are guaranteed funds regardless of + performance, there is little incentive to achieve key performance indicators + (KPIs) or align with community sentiment. A future system that allocates + resources directly to projects rather than organizations may help reduce + inefficiencies and better align development efforts with community + priorities. + +3. **Centralization Concerns**: The current model centralizes decision-making + power within a few organizations, contradicting the decentralized ethos of + blockchain technology. Traditional organizational structures with boards and + executives introduce single points of failure and limit community + involvement in funding decisions. + +4. **Community Involvement**: The current system provides minimal formal input + from the community regarding what projects should be funded, leading to a + misalignment between funded projects and community priorities. + +5. **Moving Towards a Non-Direct Funding Model**: There is strong community + support for a non-direct Dev Fund funding model. Allocating funds to a + Deferred Dev Fund Lockbox incentivizes the development of a decentralized + mechanism for the disbursement of the locked funds. + +6. **Limited Runway**: ZCG does not have the financial runway that ECC/BP and ZF + have. As such, allocating ongoing funding to ZCG will help ensure the Zcash + ecosystem has an active grants program. + +7. **Promoting Decentralization**: Allocating a portion of the Dev Fund to Zcash + Community Grants ensures small teams continue to receive funding to + contribute to Zcash. Allowing the Dev Fund to expire, or putting 100% into a + lockbox, would disproportionately impact grant recipients. This hybrid + approach promotes decentralization and the growth of independent development + teams. + +8. **Mitigating Regulatory Risks**: The Financial Privacy Foundation (FPF) is a + non-profit organization incorporated and based in the Cayman Islands. By + minimizing direct funding of US-based organizations, this proposal helps to + reduce potential regulatory scrutiny and legal risks. + +By addressing these issues, this proposal aims to ensure sustainable, +efficient, and decentralized funding for essential activities within the Zcash +ecosystem. + + +Requirements +============ + +1. **In-Protocol Lockbox**: The alternatives presented in this ZIP depend upon + the Lockbox Funding Streams proposal [#zip-2001]_. + +2. **Regulatory Considerations**: The allocation of funds should minimize + regulatory risks by avoiding direct funding of specific organizations. The + design should enable and encourage compliance with applicable laws and regulations to + support the long-term sustainability of the funding model. + + +Non-requirements +================ + +The following considerations are explicitly deferred to future ZIPs and are not +covered by this proposal: + +1. **Disbursement Mechanism**: The exact method for disbursing the accumulated + funds from the lockbox is not defined in this ZIP. The design, + implementation, and governance of the disbursement mechanism will be + addressed in a future ZIP. This includes specifics on how funds will be + allocated, the voting or decision-making process, and the structure of the + decentralized mechanism (such as a DAO). + +2. **Regulatory Compliance Details**: The proposal outlines the potential to + reduce regulatory risks by avoiding direct funding of US-based + organizations, but it does not detail specific regulatory compliance + strategies. Future ZIPs will need to address how the disbursement mechanism + complies with applicable laws and regulations. + +3. **Impact Assessment**: The long-term impact of reallocating a portion of the + block subsidy to the lockbox on the Zcash ecosystem, including its effect on + miners, developers, and the broader community, is not analyzed in this ZIP. + Subsequent proposals will need to evaluate the outcomes and make necessary + adjustments based on real-world feedback and data. + + +Specification +============= + +Development Funding Recipients +------------------------------ + +Lockbox +''''''' + +The "lockbox" is a pool of issued funds tracked by the protocol, as described in +ZIP 2001: Lockbox Funding Streams [#zip-2001]_. No disbursement mechanism is +currently defined for this "lockbox"; the Zcash community will need to decide +upon and specify a suitable decentralized mechanism for permitting withdrawals +from this lockbox in a future ZIP in order to make these funds available for +funding grants to ecosystem participants. + +Zcash Community Grants (ZCG) +'''''''''''''''''''''''''''' + +The stream allocated to Zcash Community Grants (ZCG) is intended to fund +independent teams entering the Zcash ecosystem, to perform major ongoing +development (or other work) for the public good of the Zcash ecosystem, to the +extent that such teams are available and effective. The ZCG Committee is given +the discretion to allocate funds not only to major grants, but also to a +diverse range of projects that advance the usability, security, privacy, and +adoption of Zcash, including community programs, dedicated resources, and other +projects of varying sizes. + +The funds SHALL be received and administered by the Financial Privacy Foundation +(FPF). FPF MUST disburse them for grants and expenses reasonably related to the +administration of the ZCG program, but subject to the following additional +constraints: + +1. These funds MUST be used exclusively for issuing Zcash Community Grants to + external parties that are independent of the FPF or to Autonomous Entities + operating under the FPF umbrella. Additionally, they MAY be used to cover + expenses reasonably related to the administration of Zcash Community Grants. + These funds MUST NOT be used by FPF for its internal operations or for any + direct expenses unrelated to the administration of Zcash Community Grants. + +2. ZCG SHOULD support well-specified work proposed by the grantee, at + reasonable market-rate costs. They can be of any duration or ongoing without + a duration limit. Grants of indefinite duration SHOULD be reviewed + periodically (on a schedule that the Zcash Community Grants Committee + considers appropriate for the value and complexity of the grant) for + continuation of funding. + +3. Priority SHOULD be given to major grants that bolster teams with substantial + (current or prospective) continual existence, and set them up for long-term + success, subject to the usual grant award considerations (impact, ability, + risks, team, cost-effectiveness, etc.). Priority SHOULD be given to major + grants that support ecosystem growth, for example through mentorship, + coaching, technical resources, creating entrepreneurial opportunities, etc. + If one proposal substantially duplicates another’s plans, priority SHOULD be + given to the originator of the plans. + +4. The ZCG committee SHOULD be restricted to funding projects that further the + Zcash cryptocurrency and its ecosystem (which is more specific than + furthering financial privacy in general) as permitted by + any relevant jurisdictional requirements. + +5. ZCG awards are subject to approval by a five-seat ZCG Committee. The ZCG + Committee SHALL be selected by the ZF’s Community Advisory Panel or a + successor process (e.g. as established by FPF). Elections SHALL be staggered + to ensure continuity within the Committee. + +6. The ZCG Committee's funding decisions will be final, requiring no approval + from the FPF Board, but are subject to veto if FPF judges them to violate + Cayman law or the FPF's reporting requirements and other (current or future) + obligations under the Cayman Islands' Companies Act (2023 Revision) and + Foundation Companies Law, 2017. + +7. ZCG Committee members SHALL have a one-year term and MAY sit for reelection. + The ZCG Committee is subject to the same conflict of interest policy that + governs the FPF Board of Directors (i.e. they MUST recuse themselves when + voting on proposals where they have a financial interest). At most one + person with association with the BP/ECC, at most one person with + association with the ZF, and at most one person with association with FPF + are allowed to sit on the ZCG Committee. + “Association” here means: having a financial interest, full-time employment, + being an officer, being a director, or having an immediate family + relationship with any of the above. + +8. A portion of the ZCG Slice shall be allocated to a Discretionary Budget, + which may be disbursed for expenses reasonably related to the administration + of the ZCG program. The amount of funds allocated to the Discretionary + Budget SHALL be decided by the ZF’s Community Advisory Panel or successor + process. Any disbursement of funds from the Discretionary Budget MUST be + approved by the ZCG Committee. Expenses related to the administration of the + ZCG program include, without limitation the following: + + * Paying for operational management and administration services that + support the purpose of the Zcash Community Grants program, including + administration services provided by FPF. + * Paying third party vendors for services related to domain name + registration, or the design, website hosting and administration of + websites for the ZCG Committee. + * Paying independent consultants to develop requests for proposals that + align with the ZCG program. + * Paying independent consultants for expert review of grant applications. + * Paying for sales and marketing services to promote the ZCG program. + * Paying third party consultants to undertake activities that support the + purpose of the ZCG program. + * Reimbursement to members of the ZCG Committee for reasonable travel + expenses, including transportation, hotel and meals allowance. + +9. A portion of the Discretionary Budget MAY be allocated to provide reasonable + compensation to members of the ZCG Committee. Committee member compensation + SHALL be limited to the hours needed to successfully perform their positions + and MUST align with the scope and responsibilities of their roles. The + allocation and distribution of compensation to committee members SHALL be + administered by the FPF. The compensation rate and hours for committee + members SHALL be determined by the ZF’s Community Advisory Panel or + successor process. + +10. The ZCG Committee’s decisions relating to the allocation and disbursement + of funds from the Discretionary Budget will be final, requiring no approval + from the FPF Board, but are subject to veto if the FPF judges + them to violate laws or FPF reporting requirements and other + (current or future) obligations under Cayman Islands law. + +FPF SHALL be contractually required to recognize the ZCG slice of the Dev Fund +as a Restricted Fund donation under the above constraints (suitably formalized), +and keep separate accounting of its balance and usage under its Transparency and +Accountability obligations defined below. + +ZCG SHALL strive to define target metrics and key performance indicators, +and the ZCG Committee SHOULD utilize these in its funding decisions. + +Furthering Decentralization +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +FPF SHALL conduct periodic reviews of the organizational structure, performance, +and effectiveness of the ZCG program and committee, taking into consideration +the input and recommendations of the ZCG Committee. As part of these periodic +reviews, FPF MUST commit to exploring the possibility of transitioning ZCG into +an independent organization if it is economically viable and it aligns with the +interests of the Zcash ecosystem and prevailing community sentiment. + +In any transition toward independence, priority SHALL be given to maintaining or +enhancing the decentralization of the Zcash ecosystem. The newly formed +independent organization MUST ensure that decision-making processes remain +community-driven, transparent, and responsive to the evolving needs of the Zcash +community and ecosystem. In order to promote geographic decentralization, the +new organization SHOULD keep its domicile outside of the United States. + +Transparency and Accountability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +FPF MUST accept the following obligations in this section on behalf of ZCG: + +* Publication of a ZCG Dashboard, providing a snapshot of ZCG’s current + financials and any disbursements made to grantees. +* Bi-weekly meeting minutes documenting the decisions made by the ZCG committee + on grants. +* Quarterly reports, detailing future plans, execution on previous plans, and + finances (balances, and spending broken down by major categories). +* Annual detailed review of the organization performance and future plans. +* Annual financial report (IRS Form 990, or substantially similar information). + +BP, ECC, ZF, FPF, ZCG and grant recipients MUST promptly disclose any security +or privacy risks that may affect users of Zcash (by responsible disclosure +under confidence to the pertinent developers, where applicable). + +All substantial software whose development was funded by the Dev Fund SHOULD be +released under an Open Source license (as defined by the Open Source Initiative +[#osd]_), preferably the MIT license. + +Enforcement +~~~~~~~~~~~ + +FPF MUST contractually commit to fulfill these obligations on behalf of +ZCG, and the prescribed use of funds, such that substantial violation, not +promptly remedied, will result in a modified version of Zcash node software +that removes ZCG’s Dev Fund slice and allocates it to the Deferred Dev Fund +lockbox. + +Funding Streams +--------------- + +* 12% of the block subsidy is to be distributed to the lockbox. +* 8% of the block subsidy is to be distributed to the Financial Privacy + Foundation (FPF), for the express use of the Zcash Community Grants Committee + (ZCG) to fund independent teams in the Zcash ecosystem. + +As of the activation of this ZIP, the complete set of funding streams for +Mainnet will be: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2726400 3146400 +``FS_FPF_ZCG`` 8 100 2726400 3146400 +================= =========== ============= ============== ============ + +The set of funding streams for Testnet will be: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2976000 3396000 +``FS_FPF_ZCG`` 8 100 2976000 3396000 +================= =========== ============= ============== ============ + + +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" `_ +.. [#osd] `The Open Source Definition `_ +.. [#zip-1014] `ZIP 1014: Dev Fund Proposal and Governance `_ +.. [#zip-2001] `ZIP 2001: Lockbox Funding Streams `_ +.. [#zcap] `Zcash Community Advisory Panel `_ diff --git a/zips/zip-2001.rst b/zips/zip-2001.rst index 9be3855cd..93b227281 100644 --- a/zips/zip-2001.rst +++ b/zips/zip-2001.rst @@ -5,7 +5,7 @@ Owners: Kris Nuttycombe Credits: Daira-Emma Hopwood Jack Grigg - Status: Draft + Status: Proposed Category: Consensus Created: 2024-07-02 License: MIT @@ -63,15 +63,15 @@ that a funding stream may deposit funds into the deferred pool. Specification ============= -Deferred Development Fund Chain Value Pool Balance --------------------------------------------------- +Modifications to ZIP 207 [#zip-0207]_ +------------------------------------- -Full node implementations MUST track an additional -:math:`\mathsf{PoolValue}_{Deferred}` chain value pool balance, in addition to -the Sprout, Sapling, and Orchard chain value pool balances. This balance is -set to zero prior to the activation of Network Upgrade 6. +The following paragraph is added to the section **Motivation**: -ZIP 207 [#zip-0207]_ is modified as follows: + ZIP TBD [#draft-nuttycom-funding-allocation]_ directs part of the block reward + to a reserve, the distribution of which is to be determined via a future ZIP. + ZIP 2001 [#zip-2001]_ modified this ZIP to augment the funding stream mechanism + with a common mechanism to implement this proposal. In the section **Funding streams** [#zip-0207-funding-streams]_, instead of: @@ -84,15 +84,92 @@ it will be modified to read: MUST be either a transparent P2SH address, a Sapling address, or the identifier `DEFERRED_POOL`. -In the section **Consensus rules** [#zip-0207-consensus-rules]_, the following -will be added: +After the section **Funding streams**, a new section is added with the heading +"Deferred Development Fund Chain Value Pool Balance" and the following contents: - The "prescribed way" to pay to the `DEFERRED_POOL` is to add - :math:`\mathsf{FundingStream[FUND].Value}(\mathsf{height})` to - :math:`\mathsf{PoolValue}_{Deferred}`. + Full node implementations MUST track an additional + :math:`\mathsf{PoolValue}_{Deferred}` chain value pool balance, in addition to + the Sprout, Sapling, and Orchard chain value pool balances. -The protocol specification is modified to define the "total issued supply" such -that the total issued supply as of a given height is given by the function: + Define :math:`\mathsf{totalDeferredOutput}(\mathsf{height}) := \sum_{\mathsf{fs} \in \mathsf{DeferredFundingStreams}(\mathsf{height})} \mathsf{fs.Value}(\mathsf{height})` + where :math:`\mathsf{DeferredFundingStreams}(\mathsf{height})` is the set of + funding streams with a recipient of `DEFERRED_POOL` in the block at height + :math:`\mathsf{height}`. + + The :math:`\mathsf{PoolValue}_{Deferred}` chain value pool balance for a given + block chain is the sum of the values of payments to `DEFERRED_POOL` for + transactions in the block chain. + + Equivalently, :math:`\mathsf{PoolValue}_{Deferred}` for a block chain up to + and including height :math:`\mathsf{height}` is given by + :math:`\sum_{\mathsf{h} = 0}^{\mathsf{height}} \mathsf{totalDeferredOutput}(\mathsf{h})`. + + Note: :math:`\mathsf{totalDeferredOutput}(\mathsf{h})` is necessarily + zero for heights :math:`\mathsf{h}` prior to NU6 activation. + +In the section **Consensus rules** [#zip-0207-consensus-rules]_, instead of: + + - The coinbase transaction in each block MUST contain at least one output per + active funding stream that pays the stream's value in the prescribed way to + the stream's recipient address for the block's height. + +it will be modified to read: + + - In each block, for each active funding stream with a recipient other than + `DEFERRED_POOL` at that block's height, the block's coinbase transaction + MUST contain at least one output that pays the stream's value in the + prescribed way to that recipient. + +After the list of post-Canopy consensus rules, the following paragraph is added: + + The effect of the definition of :math:`\mathsf{PoolValue}_{Deferred}` above + is that payments to the `DEFERRED_POOL` cause + :math:`\mathsf{FundingStream[FUND].Value}(\mathsf{height})` to be added to + :math:`\mathsf{PoolValue}_{Deferred}` for the block chain including that block. + + +Modifications to the protocol specification +------------------------------------------- + +In section **7.1.2 Transaction Consensus Rules** [#protocol-txnconsensus]_, instead of: + + The total value in zatoshi of transparent outputs from a coinbase transaction, + minus :math:`\mathsf{v^{balanceSapling}}`, minus :math:`\mathsf{v^{balanceOrchard}}`, + MUST NOT be greater than the value in zatoshi of the block subsidy plus the transaction + fees paid by transactions in this block. + +it will be modified to read: + + For the block at height :math:`\mathsf{height}`: + + - define the "total output value" of its coinbase transaction to be the total value + in zatoshi of its transparent outputs, minus :math:`\mathsf{v^{balanceSapling}}`, + minus :math:`\mathsf{v^{balanceOrchard}}`, plus :math:`\mathsf{totalDeferredOutput}(\mathsf{height})`; + - define the "total input value" of its coinbase transaction to be the value in zatoshi + of the block subsidy, plus the transaction fees paid by transactions in the block. + + The total output value of a coinbase transaction MUST NOT be greater than its + total input value. + +where :math:`\mathsf{totalDeferredOutput}(\mathsf{height})` is defined consistently +with ZIP 207. + +Note: this ZIP and ZIP 236 both make changes to the above rule. Their combined effect +is that the last paragraph will be replaced by: + + [Pre-NU6] The total output value of a coinbase transaction MUST NOT be greater + than its total input value. + + [NU6 onward] The total output value of a coinbase transaction MUST be equal to + its total input value. + +Section **7.10 Payment of Funding Streams** [#protocol-fundingstreams]_ contains +language and definitions copied from ZIP 207; it should be updated to reflect the +changes made above. + +In section **3.4 Transactions and Treestates** [#protocol-transactions]_, a definition +of "total issued supply" will be added, such that the total issued supply as of a given +height is given by the function: .. math:: @@ -104,6 +181,12 @@ that the total issued supply as of a given height is given by the function: &+\,\; \mathsf{PoolValue}_{Deferred}(\mathsf{height}) \end{array} +The second paragraph of section **1.2 High-level Overview** [#protocol-overview]_ +should also be updated to take into account the deferred chain value pool. Since +that section of the specification is entirely non-normative, we do not give the +full wording change here. + + References ========== @@ -114,3 +197,10 @@ References .. [#zip-0207] `ZIP 207: Funding Streams `_ .. [#zip-0207-funding-streams] `ZIP 207: Funding Streams. Section: Funding streams `_ .. [#zip-0207-consensus-rules] `ZIP 207: Funding Streams. Section: Consensus rules `_ +.. [#draft-nuttycom-funding-allocation] `Draft ZIP: Block Reward Allocation for Non-Direct Development Funding `_ +.. [#zip-2001] `ZIP 2001: Lockbox Funding Streams `_ +.. [#protocol-overview] `Zcash Protocol Specification, Version 2023.4.0. Section 1.2: High-level Overview ` +.. [#protocol-transactions] `Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates ` +.. [#protocol-txnconsensus] `Zcash Protocol Specification, Version 2023.4.0. Section 7.1.2: Transaction Consensus Rules ` +.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2023.4.0. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders’ Reward ` +.. [#protocol-fundingstreams] `Zcash Protocol Specification, Version 2023.4.0. Section 7.10: Payment of Funding Streams `