mirror of https://github.com/zcash/zips.git
ZIP 224: Additional rationale
This is in addition to the design rationale included by reference.
This commit is contained in:
parent
6631754e19
commit
2961726557
|
@ -137,7 +137,9 @@ Discussions-To: <<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
16
zip-0224.rst
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue