zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 224: Additional rationale 

This is in addition to the design rationale included by reference.
This commit is contained in:
Jack Grigg 2021-02-28 00:18:39 +00:00 committed by Daira Hopwood
parent 6631754e19
commit 2961726557
2 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
zip-0224.html
View File

@ -137,7 +137,9 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</section>
</section>
<section id="additional-rationale"><h2><span class="section-heading">Additional Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#additional-rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBD</p>
<p>The primary motivator for proposing a new shielded protocol and pool is the need to migrate spend authority to a recursion-friendly curve. Spend authority in the Sapling shielded pool is rooted in the Jubjub curve, but there is no known way to construct an efficient curve cycle (or path to one) from either Jubjub or BLS12-381.</p>
<p>Despite having recursion-friendliness as a design goal, we do not propose a recursive protocol in this ZIP. Deploying an entire scaling solution in a single upgrade would be a risky endeavour with a lot of moving parts. By focusing just on the components that enable a recursive protocol (namely the curve cycle and the proving system), we can start the migration of value to a scalable protocol before actually deploying the scalable protocol itself.</p>
<p>The remainder of the changes we make relative to Sapling are motivated by simplifying the Sapling protocol (and fixing deficiencies), and using protocol primitives that are more efficient in the UltraPLONK arithmetization.</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an Orchard-specific

16
zip-0224.rst
View File

@ -165,7 +165,21 @@ in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).
Additional Rationale
====================
TBD
The primary motivator for proposing a new shielded protocol and pool is the need to
migrate spend authority to a recursion-friendly curve. Spend authority in the Sapling
shielded pool is rooted in the Jubjub curve, but there is no known way to construct an
efficient curve cycle (or path to one) from either Jubjub or BLS12-381.
Despite having recursion-friendliness as a design goal, we do not propose a recursive
protocol in this ZIP. Deploying an entire scaling solution in a single upgrade would be a
risky endeavour with a lot of moving parts. By focusing just on the components that enable
a recursive protocol (namely the curve cycle and the proving system), we can start the
migration of value to a scalable protocol before actually deploying the scalable protocol
itself.
The remainder of the changes we make relative to Sapling are motivated by simplifying the
Sapling protocol (and fixing deficiencies), and using protocol primitives that are more
efficient in the UltraPLONK arithmetization.
Security and Privacy Considerations