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
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 diff --git a/zip-0224.rst b/zip-0224.rst index b39b6d08..aa50b32b 100644 --- a/zip-0224.rst +++ b/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