mirror of https://github.com/zcash/zips.git
216 lines
18 KiB
HTML
216 lines
18 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>Draft ecc-onchain-accountable-voting: On-chain Accountable Voting</title>
|
|
<meta charset="utf-8" />
|
|
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.11/dist/katex.min.css" integrity="sha384-nB0miv6/jRmo5UMMR1wu3Gz6NLsoTkbqJghGIsx//Rlm+ZU03BU6SQNC66uf4l5+" crossorigin="anonymous">
|
|
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.11/dist/katex.min.js" integrity="sha384-7zkQWkzuo3B5mTepMUcHkMB5jZaolc2xDwL6VFqjFALcbeS9Ggm/Yr2r3Dy4lfFg" crossorigin="anonymous"></script>
|
|
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.11/dist/contrib/auto-render.min.js" integrity="sha384-43gviWU0YVjaDtb/GhzOouOXtZMP/7XUzwPTstBeZFe/+rCMvRwr4yROQP43s0Xk" crossorigin="anonymous" onload="renderMathInElement(document.body);"></script>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css">
|
|
</head>
|
|
<body>
|
|
<pre><code>ZIP: XXX
|
|
Title: On-chain Accountable Voting
|
|
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
|
Status: Draft
|
|
Credits: Josh Swihart
|
|
Kris Nuttycombe
|
|
Jack Grigg
|
|
Category: Consensus / Process
|
|
Created: 2025-02-21
|
|
License: MIT
|
|
Pull-Request: <<a href="https://github.com/zcash/zips/pull/???">https://github.com/zcash/zips/pull/???</a>>
|
|
</code></pre>
|
|
|
|
<h1 id="terminology"><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>The key words “MUST”, “REQUIRED”, “MUST NOT”, “SHOULD”, and “MAY” in this document are to be interpreted as described in BCP 14 <a href="#fn:1" id="fnref:1" title="see footnote" class="footnote"><sup>1</sup></a> when, and only when, they appear in all capitals.</p>
|
|
|
|
<p>The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification <a href="#fn:2" id="fnref:2" title="see footnote" class="footnote"><sup>2</sup></a>.</p>
|
|
|
|
<p>TODO: Consider defining “Proposal”, “Decision”, “Approval”, “Rejection”, etc.</p>
|
|
|
|
<h1 id="abstract"><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>This proposal specifies a mechanism for on-chain accountable voting that is available for use by Zcash governance and funding proposals.</p>
|
|
|
|
<h1 id="motivation"><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>Several proposals that have been made for the future of Zcash governance, including the Zcash Governance Bloc <a href="#fn:3" id="fnref:3" title="see footnote" class="footnote"><sup>3</sup></a> and Loan-Directed Retroactive Grants <a href="#fn:4" id="fnref:4" title="see footnote" class="footnote"><sup>4</sup></a>, require similar mechanisms. In particular they require some form of on-chain accountable voting.</p>
|
|
|
|
<p>The details of these mechanisms matter for security and robust oversight. Separating the concerns of governance and funding policy on the one hand, and the mechanisms used to enact this policy on the other, frees initial policy proposals (and proposers) from having to specify unnecessary detail, while ensuring that implementability and security concerns are nonetheless thoroughly considered.</p>
|
|
|
|
<p>Using a shared vocabulary and repertoire of implementation mechanisms can also facilitate comparison of governance and funding proposals, by focussing attention on their higher-level differences.</p>
|
|
|
|
<p>It is possible that these mechanisms may also have wider usefulness in the Zcash ecosystem beyond governance and development funding.</p>
|
|
|
|
<h1 id="requirements"><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<ul>
|
|
<li>This specification should avoid, as far as possible, over-constraining how decisions about governance and funding are made, if and when they use this mechanism.</li>
|
|
<li>The mechanism is resistant to compromise of some of the parties' keys, up to a given threshold.</li>
|
|
<li>No single party’s non-cooperation or loss of keys is able to cause further decisions to be blocked indefinitely.</li>
|
|
</ul>
|
|
|
|
<h1 id="non-requirements"><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>The on-chain accountable voting mechanism does not need to directly support coinholder voting. If that is required, it should be performed via a separate protocol. The results of that protocol might then feed into votes cast in on-chain accountable voting, as suggested by the Zcash Governance Bloc <a href="#fn:3" title="see footnote" class="footnote"><sup>3</sup></a> proposal, for example.</p>
|
|
|
|
<h1 id="specification"><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>A Proposal to be decided using On-chain Accountable Voting is represented as a Proposal Transaction, which references a human-readable Description of what is to happen on its Approval. The Proposal Transaction MAY also lock up funds that are to be granted on Approval [TODO].</p>
|
|
|
|
<p>The scope of possible Proposals is left to be specified by the high-level policy that uses this mechanism.</p>
|
|
|
|
<p>A Decision is represented by spending the Approval Output or Rejection Output of the Proposal, as described in <a href="#decisions">Decisions</a>. This can signal either an Approval, recording the fact that the Approval Threshold has been met, or a Rejection, recording the fact that sufficient voting units have been cast against the Proposal that its Approval Threshold <em>cannot</em> be met.</p>
|
|
|
|
<p>More concretely, if there are <span class="math">\(V\)</span> voting units overall and <span class="math">\(A = \mathsf{ceiling}(V \cdot \mathsf{threshold})\)</span> of them are required for approval, then <span class="math">\(V - A + 1\)</span> voting units suffice for Rejection.</p>
|
|
|
|
<p>A Proposal also has a Deadline Height. It is Implicitly Rejected if no Approval or Rejection occurs on the consensus chain <em>at or before</em> the Deadline Height (that is, the Deadline Height is inclusive).</p>
|
|
|
|
<p>Honestly constructed Proposals SHOULD take into account any planned change in the block target spacing when setting the Deadline Height (see <a href="#blocktargetspacingchanges">Block Target Spacing changes</a>).</p>
|
|
|
|
<h2 id="proposaltransactions"><span class="section-heading">Proposal Transactions</span><span class="section-anchor"> <a rel="bookmark" href="#proposaltransactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
|
|
<p>A transaction is considered to be a Proposal Transaction if and only if it includes exactly one Specification Output, exactly one Approval Output, and exactly one Rejection Output, as specified below.</p>
|
|
|
|
<h3 id="descriptionoutput"><span class="section-heading">Description Output</span><span class="section-anchor"> <a rel="bookmark" href="#descriptionoutput"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
|
|
<p>A Proposal Transaction MUST reference a human-readable Description of what is being voted on. This is represented by a Description Output encrypted to the zero <span class="math">\(\mathsf{ovk}\)</span>, in the same way as for shielded coinbase transactions <a href="#fn:5" id="fnref:5" title="see footnote" class="footnote"><sup>5</sup></a>. The plaintext memo of the Description Output MUST use the following format:</p>
|
|
|
|
<ul>
|
|
<li>the string <span class="math">\(\texttt{“b2-256:”}\)</span></li>
|
|
<li>a hex-encoded BLAKE2b-256 hash of the contents of the file specifying the proposal</li>
|
|
<li>the string <span class="math">\(\texttt{“:”}\)</span></li>
|
|
<li>a stable URL to the contents of that file.</li>
|
|
</ul>
|
|
|
|
<p>The URL MUST be encoded as US-ASCII, but MAY use %-encoding to specify UTF-8 characters as described in <a href="#fn:6" id="fnref:6" title="see footnote" class="footnote"><sup>6</sup></a>.</p>
|
|
|
|
<p>For example, to refer to the contents of ZIP 1015 at time of writing:</p>
|
|
|
|
<pre><code>"b2-256:bacb0d5430968e4ce77246523d0e6f29c442f8fce0f3656462fdf5a5c4b8c656:" ||
|
|
"https://raw.githubusercontent.com/zcash/zips/38e4501a2c3bf90f6057872db497295a0a76eb35/zips/zip-1015.rst"
|
|
</code></pre>
|
|
|
|
<p>Since a memo field can be a maximum of 512 bytes, this currently allows a maximum of 440 bytes for the URL, which should be enough. If and when memo bundles <a href="#fn:7" id="fnref:7" title="see footnote" class="footnote"><sup>7</sup></a> are supported, this will increase the allowed size, and potentially allow the text of the proposal to be encoded directly in the memo.</p>
|
|
|
|
<p>The contents of the file at the given URL MUST NOT be automatically downloaded unless that is requested by an explicit user action.</p>
|
|
|
|
<h2 id="approvalandrejectionoutputs"><span class="section-heading">Approval and Rejection Outputs</span><span class="section-anchor"> <a rel="bookmark" href="#approvalandrejectionoutputs"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
|
|
<p>Let DeadlineHeight be the last block height at which a Decision can be made for this Proposal.</p>
|
|
|
|
<p>An Approval Output is a P2SH output with a script of the following form:</p>
|
|
|
|
<ul>
|
|
<li>TBD</li>
|
|
</ul>
|
|
|
|
<p>A Rejection Output is a P2SH output with a script of the following form:</p>
|
|
|
|
<ul>
|
|
<li>TBD</li>
|
|
</ul>
|
|
|
|
<h2 id="decisions"><span class="section-heading">Decisions</span><span class="section-anchor"> <a rel="bookmark" href="#decisions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
|
|
<p>Approval of a Proposal Transaction is signalled by spending its Approval Output in a transaction mined at or before the Deadline Height.</p>
|
|
|
|
<p>Rejection of a Proposal Transaction is signalled by spending its Rejection Output in a transaction mined at or before the Deadline Height.</p>
|
|
|
|
<p>A spend of an Approval or Rejection Output that occurs in a transaction mined strictly after the Proposal’s Deadline Height has no effect.</p>
|
|
|
|
<p>A spend of an Approval or Rejection Output is performative <a href="#fn:8" id="fnref:8" title="see footnote" class="footnote"><sup>8</sup></a> in the sense that, even if it does not directly transfer funds, it records that the decision has been made.</p>
|
|
|
|
<p>A holder of voting units SHOULD NOT sign transactions that spend both the Approval Output and the Rejection Output of a given Proposal Transaction. However, if this does occur, then it is interpreted as follows:</p>
|
|
|
|
<ul>
|
|
<li>If Approval and Rejection occur in the same transaction, then the proposal is rejected.</li>
|
|
<li>Otherwise, the outcome is determined by which of the Approval and Rejection outputs is spent first (i.e. in the earlier transaction).</li>
|
|
</ul>
|
|
|
|
<p>As stated earlier, a Proposal is Implicitly Rejected if no Approval or Rejection occurs on the consensus chain at or before the Deadline Height.</p>
|
|
|
|
<h3 id="finalityofdecisions"><span class="section-heading">Finality of Decisions</span><span class="section-anchor"> <a rel="bookmark" href="#finalityofdecisions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
|
|
<p>Zcash’s current consensus layer provides only eventual consistency. A Decision SHOULD be considered “final” when it has 100 confirmations. (In the case where the Decision transaction also directly transfers funds to a recipient, this does not constrain the recipient’s ability to spend the funds.)</p>
|
|
|
|
<p>An Implicit Rejection SHOULD be considered final if a transaction in a block at the Deadline Height would have 100 confirmations.</p>
|
|
|
|
<p>If and when a mechanism for “assured finality” <a href="#fn:9" id="fnref:9" title="see footnote" class="footnote"><sup>9</sup></a> of transactions is adopted by the Zcash network, it is expected to be possible to redefine “finality” of Decisions accordingly.</p>
|
|
|
|
<h2 id="testnet-specificconsiderations"><span class="section-heading">Testnet-specific considerations</span><span class="section-anchor"> <a rel="bookmark" href="#testnet-specificconsiderations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
|
|
<p>Proposal Transactions on Testnet MUST only be used to test this mechanism, and have no significance for Zcash governance.</p>
|
|
|
|
<h1 id="rationale"><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<h2 id="blocktargetspacingchanges"><span class="section-heading">Block Target Spacing changes</span><span class="section-anchor"> <a rel="bookmark" href="#blocktargetspacingchanges"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
|
|
<p>The block target spacing of the Zcash network is currently 75 seconds, but is not necessarily fixed. For example, the current value was established at activation of the Blossom network upgrade, halving the previous value of 150 seconds. This potentially has implications for the use of block heights to specify deadlines, but in practice we believe that block heights will suffice:</p>
|
|
|
|
<ul>
|
|
<li>If the block target spacing decreases, then this can only bring a deadline closer. This is not a problem because the Proposal can always be resubmitted if it expires sooner than intended.</li>
|
|
<li>Changes that increase the block target spacing are usually signalled well in advance. It is therefore very unlikely that a deadline will unintentionally be extended. In any case, it is always possible to explicitly Reject any proposal for which the deadline is unintentionally extended.</li>
|
|
</ul>
|
|
|
|
<h1 id="referenceimplementation"><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#referenceimplementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>TBD</p>
|
|
|
|
<h1 id="acknowledgements"><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<p>Thank you to Josh Swihart and Kris Nuttycombe for discussions about <a href="#fn:3" title="see footnote" class="footnote"><sup>3</sup></a> and <a href="#fn:10" id="fnref:10" title="see footnote" class="footnote"><sup>10</sup></a> that led to the idea for this ZIP.</p>
|
|
|
|
<h1 id="references"><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h1>
|
|
|
|
<div class="footnotes">
|
|
<hr />
|
|
<ol>
|
|
|
|
<li id="fn:1">
|
|
<p><a href="https://www.rfc-editor.org/info/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”</a> <a href="#fnref:1" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:2">
|
|
<p><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet</a> <a href="#fnref:2" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:3">
|
|
<p><a href="draft-ecc-zbloc">draft-ecc-zbloc: Zcash Governance Bloc</a> <a href="#fnref:3" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:4">
|
|
<p><a href="https://forum.zcashcommunity.com/t/loan-directed-retroactive-grants/48230">Zcash forum: Loan-Directed Retroactive Grants</a> <a href="#fnref:4" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:5">
|
|
<p><a href="zip-0213">ZIP 213: Shielded Coinbase</a> <a href="#fnref:5" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:6">
|
|
<p><a href="https://www.rfc-editor.org/rfc/rfc3986.html#section-2.5">RFC 3986: Uniform Resource Identifier (URI). Section 2.5: Identifying Data</a> <a href="#fnref:6" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:7">
|
|
<p><a href="zip-0231">ZIP 231: Memo Bundles</a> <a href="#fnref:7" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:8">
|
|
<p><a href="https://en.wikipedia.org/wiki/Performative_utterance">Wikipedia: Performative utterance</a> <a href="#fnref:8" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:9">
|
|
<p><a href="https://electric-coin-company.github.io/tfl-book/terminology.html#definition-assured-finality">Zcash Trailing Finality Layer. Section 2: Terminology — Assured Finality</a> <a href="#fnref:9" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
<li id="fn:10">
|
|
<p><a href="draft-ecc-community-and-coinholder">draft-ecc-community-and-coinholder: Community and Coinholder Funding Model</a> <a href="#fnref:10" title="return to body" class="reversefootnote"> ↩︎</a></p>
|
|
</li>
|
|
|
|
</ol>
|
|
</div>
|
|
</body>
|
|
</html>
|