spec: update proof statements

docs/protocol/src/protocol/action_descriptions/delegator_vote.md

@@ -8,7 +8,7 @@ The delegator vote proof demonstrates the properties enumerated below for the fo
 
 * Note amount $v$ (interpreted as an $\mathbb F_q$) and asset `ID` $\isin \mathbb G$
 * Note blinding factor $rcm \isin \mathbb F_q$ used to blind the note commitment
-* Address associated with the note being spent, consisting of diversified basepoint $B_d \isin \mathbb G$, 
+* Address associated with the note being spent, consisting of diversified basepoint $B_d \isin \mathbb G$,
 transmission key $pk_d \isin \mathbb G$, and clue key $\mathsf{ck_d} \isin \mathbb F_q$
 * Note commitment $cm \isin \mathbb F_q$
 * Spend authorization randomizer used for generating the randomized spend authorization key $\alpha \isin \mathbb F_r$
@@ -30,7 +30,7 @@ The zk-SNARK certifies that the position of the staked note `pos` is less than t
 
 `pos < start_pos`
 
-This demonstrates that the staked note used in voting existed prior to the proposal. 
+This demonstrates that the staked note used in voting existed prior to the proposal.
 
 The zk-SNARK also certifies that the commitment index of the start position is zero.
 
@@ -50,7 +50,7 @@ The zk-SNARK certifies that the public input balance commitment $cv$ was derived
 
 $cv = [v] G_v + [\widetilde{v}] G_{\widetilde{v}}$
 
-where $G_{\widetilde{v}}$ is a constant generator and $G_v$ is an asset-specific generator point derived as described in [Value Commitments](../../protocol/value_commitments.md). For delegator votes, $[\widetilde{v}] = 0$.
+where $G_{\widetilde{v}}$ is a constant generator and $G_v$ is an asset-specific generator point derived in-circuit as described in [Value Commitments](../../protocol/value_commitments.md). For delegator votes, $[\widetilde{v}] = 0$.
 
 ### Nullifier Integrity
 

docs/protocol/src/protocol/action_descriptions/outputs.md

@@ -38,7 +38,7 @@ The zk-SNARK certifies that the public input balance commitment $cv$ was derived
 
 $cv = [v] G_v + [\widetilde{v}] G_{\widetilde{v}}$
 
-where $G_{\widetilde{v}}$ is a constant generator and $G_v$ is an asset-specific generator point derived as described in [Value Commitments](../../protocol/value_commitments.md).
+where $G_{\widetilde{v}}$ is a constant generator and $G_v$ is an asset-specific generator point derived in-circuit as described in [Value Commitments](../../protocol/value_commitments.md).
 
 ### Diversified Base is not Identity
 

docs/protocol/src/protocol/action_descriptions/spend.md

@@ -8,7 +8,7 @@ The spend proof demonstrates the properties enumerated below for the following p
 
 * Note amount $v$ (interpreted as an $\mathbb F_q$) and asset `ID` $\isin \mathbb G$
 * Note blinding factor $rcm \isin \mathbb F_q$ used to blind the note commitment
-* Address associated with the note being spent, consisting of diversified basepoint $B_d \isin \mathbb G$, 
+* Address associated with the note being spent, consisting of diversified basepoint $B_d \isin \mathbb G$,
 transmission key $pk_d \isin \mathbb G$, and clue key $\mathsf{ck_d} \isin \mathbb F_q$
 * Note commitment $cm \isin \mathbb F_q$
 * Blinding factor $\tilde v \isin \mathbb F_r$ used to blind the balance commitment
@@ -24,13 +24,9 @@ And the corresponding public inputs:
 * Nullifier $nf$ of the note to be spent
 * Randomized verification key $rk \isin \mathbb G$
 
-### Dummy spend
-
-We require each one of the following integrity properties to hold only for notes with non-zero values $v \ne 0$. This is to allow for dummy spends to pass stateless verification. Dummy spends may be added for metadata resistance (e.g. to ensure there are two spends and two outputs in each transaction).
-
 ### Note Commitment Integrity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the note commitment $cm$ was derived as:
+The zk-SNARK certifies that the note commitment $cm$ was derived as:
 
 $cm = hash_6(ds, (rcm, v, ID, B_d, pk_d, ck_d))$.
 
@@ -40,29 +36,27 @@ using the above witnessed values and where `ds` is a constant domain separator:
 
 ### Balance Commitment Integrity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the public input balance commitment $cv$ was derived from the witnessed values as:
+The zk-SNARK certifies that the public input balance commitment $cv$ was derived from the witnessed values as:
 
 $cv = [v] G_v + [\widetilde{v}] G_{\widetilde{v}}$
 
-where $G_{\widetilde{v}}$ is a constant generator and $G_v$ is an asset-specific generator point derived as described in [Value Commitments](../../protocol/value_commitments.md).
+where $G_{\widetilde{v}}$ is a constant generator and $G_v$ is an asset-specific generator point derived in-circuit as described in [Value Commitments](../../protocol/value_commitments.md).
 
 ### Nullifier Integrity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the
-revealed nullifier $nf$ was derived as:
+The zk-SNARK certifies that the revealed nullifier $nf$ was derived as:
 
 $nf = hash_3(ds, (nk, cm, pos))$
 
 using the witnessed values above and where `ds` is a constant domain separator:
 
-`ds = from_le_bytes(BLAKE2b-512(b"penumbra.nullifier")) mod q
-`
+`ds = from_le_bytes(BLAKE2b-512(b"penumbra.nullifier")) mod q`
 
 as described in [Nullifiers](../notes/nullifiers.md).
 
 ### Diversified address Integrity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the diversified address $pk_d$ associated with the note being spent was derived as:
+The zk-SNARK certifies that the diversified address $pk_d$ associated with the note being spent was derived as:
 
 $pk_d ​= [ivk] B_d$
 
@@ -74,22 +68,22 @@ as described in [Viewing Keys](../addresses_keys/viewing_keys.md).
 
 ### Randomized verification key Integrity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the randomized verification key $rk$ was derived using the witnessed $ak$ and spend auth randomizer $\alpha$ as:
+The zk-SNARK certifies that the randomized verification key $rk$ was derived using the witnessed $ak$ and spend auth randomizer $\alpha$ as:
 
 $rk = ak + [\alpha]B_{SpendAuth}$
 
 where $B_{SpendAuth}$ is the conventional `decaf377` basepoint as described in [The Decaf377 Group](../../crypto/decaf377.md).
 
 ### Merkle auth path verification
 
-The zk-SNARK certifies that for non-zero values[^1] $v \ne 0$, the witnessed Merkle authentication path is a valid Merkle path to the provided public anchor.
+The zk-SNARK certifies that for non-zero values[^1] $v \ne 0$, the witnessed Merkle authentication path is a valid Merkle path to the provided public anchor. Only for notes with non-zero values $v \ne 0$, the note is unrooted from the state commitment tree to allow for these "dummy" spends to pass stateless verification. Dummy spends may be added for metadata resistance (e.g. to ensure there are two spends and two outputs in each transaction).
 
 ### Diversified Base is not Identity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the diversified basepoint $B_d$ associated with the address on the note is not identity.
+The zk-SNARK certifies that the diversified basepoint $B_d$ associated with the address on the note is not identity.
 
 ### The spend authorization key is not Identity
 
-The zk-SNARK certifies that for non-zero values $v \ne 0$, the spend authorization key $ak$ is not identity.
+The zk-SNARK certifies that the spend authorization key $ak$ is not identity.
 
 [^1]: Note that [issue 2135](https://github.com/penumbra-zone/penumbra/issues/2135) tracks a bug where dummy spends fail to verify due to the merkle paths.

docs/protocol/src/protocol/action_descriptions/swap.md

@@ -42,13 +42,12 @@ The zk-SNARK certifies that the public input fee commitment $cv_f$ was derived f
 
 $cv_f = [-v_f] G_{v_f} + [\widetilde{v_f}] G_{\widetilde{v}}$
 
-where $G_{\widetilde{v}}$ is a constant generator and $G_{v_f}$ is an asset-specific generator point derived as described in [Value Commitments](../../protocol/value_commitments.md).
+where $G_{\widetilde{v}}$ is a constant generator and $G_{v_f}$ is an asset-specific generator point derived in-circuit as described in [Value Commitments](../../protocol/value_commitments.md).
 
 ### Balance Commitment Integrity
 
 The zk-SNARK certifies that the total public input balance commitment $cv$ was derived from the witnessed values as:
 
 $cv = [-v_1] G_1 + [-v_2] G_2 + cv_f$
 
-where the first two terms are from the input amounts and assets, and $cv_f$ is the
-fee commitment.
+where the first two terms are from the input amounts and assets, with the corresponding asset-specific generates derived in-circuit as described in [Value Commitments](../../protocol/value_commitments.md), and $cv_f$ is the fee commitment.

docs/protocol/src/protocol/action_descriptions/undelegate_claim.md

@@ -1,19 +1,22 @@
 # Undelegate Claim Descriptions
 
-Each undelegate claim contains a UndelegateClaimBody and a zk-SNARK undelegate claim proof.
+Each undelegate claim contains a UndelegateClaimBody and a zk-SNARK undelegate claim proof. The undelegate claim proof is implemented as an instance of a generic convert circuit which converts a private amount of one input asset into a target asset, given a public conversion rate.
 
-## Undelegate Claim zk-SNARK Statements
+First we describe the convert circuit, and then the undelegate claim proof.
 
-The undelegate claim proof demonstrates the properties enumerated below for the private witnesses known by the prover:
+## Convert zk-SNARK Statements
 
-* Unbonding amount $v_u$ interpreted as an $\mathbb F_q$
+The convert circuit demonstrates the properties enumerated below for the private witnesses known by the prover:
+
+* Input amount $v_i$ interpreted as an $\mathbb F_q$
 * Balance blinding factor $\widetilde{v} \isin \mathbb F_r$ used to blind the balance commitment
 
 And the corresponding public inputs:
 
 * Balance commitment $cv \isin G$ to the value balance
-* Penalty $p$ interpreted as an $\mathbb F_q$
-* Unbonding asset ID $G_u \isin \mathbb G$
+* Rate $p$, a 128-bit fixed point value, represented in circuit as four 64-bit (Boolean constraint) limbs
+* Asset ID $ID_i \isin \mathbb G$ of the input (source) amount
+* Asset ID $ID_t \isin \mathbb G$ of the target amount
 
 ### Balance Commitment Integrity
 
@@ -23,14 +26,20 @@ $cv = v_e + [\widetilde{v}] G_{\widetilde{v}}$
 
 where $G_{\widetilde{v}}$ is a constant generator.
 
-$v_e$ is the expected balance computed from the penalty $p$, the unbonding
-amount $v_u$ and the unbonding asset ID $G_u$:
+$v_e$ is the expected balance computed from the public conversion rate $p$ and the input
+amount $v_i$:
+
+$v_e = [-v_i] G_{v_i} + [p * v_i] G_{v_t}$
+
+where $G_{v_i}$ is the asset-specific generator corresponding to the input
+token with asset ID $ID_i$ and $G_{v_t}$ is the asset-specific generator corresponding to the
+target token with asset ID $ID_t$. Both these asset-specific bases are derived in-circuit as described in [Value Commitments](../../protocol/value_commitments.md).
 
-$v_e = [-v_u] G_{v_u} + v_p G_{v_s}$
+## Undelegate Claim
 
-where $G_{v_u}$ is the asset-specific generator corresponding to the unbonding
-token and $G_{v_s}$ is the asset-specific generator corresponding to the
-staking token. $v_u$ is the unbonding amount, and $v_p$ is the penalized amount,
-computed by applying the penalty $p$ to the unbonding amount:
+The undelegate claim proof uses the convert circuit statements above where:
 
-$v_p = v_u * (100,000,000 - p) / 100,000,000$
+* The input amount $v_i$ is set to the unbonding amount
+* The rate is set to the Penalty $p$
+* Asset `ID` $G_i$ is the unbonding token asset ID
+* Asset `ID` $G_t$ is the staking token asset ID