Skip to content

Commit

Permalink
replace usage of value commitment term with balance commitment
Browse files Browse the repository at this point in the history
this is in all non-proto files, i.e. code comments and spec
  • Loading branch information
redshiftzero committed Apr 5, 2024
1 parent a333327 commit 362da0a
Show file tree
Hide file tree
Showing 15 changed files with 21 additions and 21 deletions.
2 changes: 1 addition & 1 deletion crates/core/asset/src/asset/id.rs
Original file line number Diff line number Diff line change
Expand Up @@ -132,7 +132,7 @@ pub static VALUE_GENERATOR_DOMAIN_SEP: Lazy<Fq> = Lazy::new(|| {
});

impl Id {
/// Compute the value commitment generator for this asset.
/// Compute the value generator for this asset, used for computing balance commitments.
pub fn value_generator(&self) -> decaf377::Element {
decaf377::Element::encode_to_curve(&poseidon377::hash_1(
&VALUE_GENERATOR_DOMAIN_SEP,
Expand Down
2 changes: 1 addition & 1 deletion crates/core/asset/src/balance.rs
Original file line number Diff line number Diff line change
Expand Up @@ -537,7 +537,7 @@ mod test {

proptest! {
/// Checks to make sure that any possible expression made of negation, addition, and
/// subtraction is a homomorphism with regard to the resultant value commitment, which
/// subtraction is a homomorphism with regard to the resultant balance commitment, which
/// should provide assurance that these operations are implemented correctly on the balance
/// type itself.
#[test]
Expand Down
2 changes: 1 addition & 1 deletion crates/core/asset/src/value.rs
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,7 @@ impl TryFrom<pb::Value> for Value {
.try_into()?,
asset_id: value
.asset_id
.ok_or_else(|| anyhow::anyhow!("missing value commitment"))?
.ok_or_else(|| anyhow::anyhow!("missing balance commitment"))?
.try_into()?,
})
}
Expand Down
2 changes: 1 addition & 1 deletion crates/core/component/dex/src/lp/nft.rs
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ use super::position::{Id, State};
/// be recorded in a programmatic on-chain account (in the future, e.g., to
/// support interchain accounts). This also means that LP-related actions don't
/// require any cryptographic implementation (proofs, signatures, etc), other
/// than hooking into the value commitment mechanism used for transaction
/// than hooking into the balance commitment mechanism used for transaction
/// balances.
#[derive(Debug, Clone)]
pub struct LpNft {
Expand Down
4 changes: 2 additions & 2 deletions crates/core/component/governance/src/delegator_vote/proof.rs
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ use tap::Tap;
pub struct DelegatorVoteProofPublic {
/// the merkle root of the state commitment tree.
pub anchor: tct::Root,
/// value commitment of the note to be spent.
/// balance commitment of the note to be spent.
pub balance_commitment: balance::Commitment,
/// nullifier of the note to be spent.
pub nullifier: Nullifier,
Expand All @@ -55,7 +55,7 @@ pub struct DelegatorVoteProofPrivate {
pub state_commitment_proof: tct::Proof,
/// The note being spent.
pub note: Note,
/// The blinding factor used for generating the value commitment.
/// The blinding factor used for generating the balance commitment.
pub v_blinding: Fr,
/// The randomizer used for generating the randomized spend auth key.
pub spend_auth_randomizer: Fr,
Expand Down
2 changes: 1 addition & 1 deletion crates/core/component/shielded-pool/src/output/action.rs
Original file line number Diff line number Diff line change
Expand Up @@ -108,7 +108,7 @@ impl TryFrom<pb::OutputBody> for Body {

let balance_commitment = proto
.balance_commitment
.ok_or_else(|| anyhow::anyhow!("missing value commitment"))?
.ok_or_else(|| anyhow::anyhow!("missing balance commitment"))?
.try_into()
.context("malformed balance commitment")?;

Expand Down
2 changes: 1 addition & 1 deletion crates/core/component/shielded-pool/src/output/proof.rs
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,7 @@ fn check_circuit_satisfaction(
}

/// Public:
/// * vcm (value commitment)
/// * vcm (balance commitment)
/// * ncm (note commitment)
///
/// Witnesses:
Expand Down
2 changes: 1 addition & 1 deletion crates/core/component/shielded-pool/src/spend/action.rs
Original file line number Diff line number Diff line change
Expand Up @@ -101,7 +101,7 @@ impl TryFrom<pb::SpendBody> for Body {
fn try_from(proto: pb::SpendBody) -> anyhow::Result<Self, Self::Error> {
let balance_commitment: balance::Commitment = proto
.balance_commitment
.ok_or_else(|| anyhow::anyhow!("missing value commitment"))?
.ok_or_else(|| anyhow::anyhow!("missing balance commitment"))?
.try_into()
.context("malformed balance commitment")?;

Expand Down
4 changes: 2 additions & 2 deletions crates/core/component/shielded-pool/src/spend/proof.rs
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ use tap::Tap;
pub struct SpendProofPublic {
/// the merkle root of the state commitment tree.
pub anchor: tct::Root,
/// value commitment of the note to be spent.
/// balance commitment of the note to be spent.
pub balance_commitment: balance::Commitment,
/// nullifier of the note to be spent.
pub nullifier: Nullifier,
Expand All @@ -58,7 +58,7 @@ pub struct SpendProofPrivate {
pub state_commitment_proof: tct::Proof,
/// The note being spent.
pub note: Note,
/// The blinding factor used for generating the value commitment.
/// The blinding factor used for generating the balance commitment.
pub v_blinding: Fr,
/// The randomizer used for generating the randomized spend auth key.
pub spend_auth_randomizer: Fr,
Expand Down
2 changes: 1 addition & 1 deletion crates/core/keys/src/symmetric.rs
Original file line number Diff line number Diff line change
Expand Up @@ -222,7 +222,7 @@ impl OutgoingCipherKey {
// Note: Here we use the same nonce as note encryption, however the keys are different.
// For note encryption we derive the `PayloadKey` symmetric key from the shared secret and epk.
// However, for the outgoing cipher key, we derive a symmetric key from the
// sender's OVK, value commitment, note commitment, and the epk. Since the keys are
// sender's OVK, balance commitment, note commitment, and the epk. Since the keys are
// different, it is safe to use the same nonce.
//
// References:
Expand Down
2 changes: 1 addition & 1 deletion docs/protocol/src/addresses_keys/transaction_crypto.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ should be able to decrypt the per-transaction memo.
### Outgoing Cipher Key

The symmetric outgoing cipher key is a 32-byte key derived from the sender's outgoing viewing key
$ovk$, the value commitment $cv$, the note commitment $cm$, the ephemeral
$ovk$, the balance commitment $cv$, the note commitment $cm$, the ephemeral
public key $epk$, and personalization string "Penumbra_OutCiph":

```
Expand Down
6 changes: 3 additions & 3 deletions docs/protocol/src/assets.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ context.

## Asset types and asset IDs

To be precise, we define:
To be precise, we define:

- an *amount* to be an untyped `u128` quantity of some asset;
- an *asset ID* to be an $\mathbb F_q$ element;
Expand Down Expand Up @@ -58,7 +58,7 @@ rate-1 Poseidon hashing with domain separator
`from_le_bytes(b"penumbra.value.generator")` and then the `decaf377` CDH
map-to-group method.

## Homomorphic Value Commitments
## Homomorphic Balance Commitments

We use the value generator associated to an asset ID to construct homomorphic
commitments to (typed) value. To do this, we first define the *blinding
Expand All @@ -77,7 +77,7 @@ These commitments are homomorphic, even for different asset types, say values
$(x, \mathsf a)$ and $(y, \mathsf b)$:
$$
([x]V_{\mathsf a} + [\widetilde{x}]\widetilde{V}) + ([y] V_{\mathsf b} + [\widetilde{y}]\widetilde{V})
=
=
[x]V_{\mathsf a} + [y] V_{\mathsf b} + [\widetilde{x} + \widetilde{y}]\widetilde{V}.
$$
Alternatively, this can be thought of as a commitment to a (sparse) vector
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ scheme described here.

For our threshold encryption scheme, we require three important properties:

* Homomorphism: we must be able to operate over ciphertexts, by combining value commitments from many participants into a batched value.
* Homomorphism: we must be able to operate over ciphertexts, by combining balance commitments from many participants into a batched value.
* Verifiability: we must be able to verify that a given value $v_i$ was encrypted correctly to a given ciphertext $c_i$
* Robustness: up to $n-t$ validators must be permitted to either fail to provide a decryption share or provide in invalid decryption share.

Expand Down
2 changes: 1 addition & 1 deletion docs/protocol/src/dex/action/swap.md
Original file line number Diff line number Diff line change
Expand Up @@ -123,4 +123,4 @@ The zk-SNARK certifies that the total public input balance commitment $cv$ was d

$cv = [-v_1] G_1 + [-v_2] G_2 + cv_f$

where the first two terms are from the input amounts and assets, with the corresponding asset-specific generators $G_1, G_2$ derived in-circuit as described in [Value Commitments](../../assets.md), and $cv_f$ is the fee commitment.
where the first two terms are from the input amounts and assets, with the corresponding asset-specific generators $G_1, G_2$ derived in-circuit as described in [Balance Commitments](../../assets.md), and $cv_f$ is the fee commitment.
6 changes: 3 additions & 3 deletions docs/protocol/src/transactions.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,17 +28,17 @@ The chain requires that transactions do not create or destroy value. To
accomplish conservation of value, the _binding signature_ proves that the
transaction's value balance, summed up over all actions, is zero. This
construction works as follows. We'd like to be able to prove that a certain
value commitment $C$ is a commitment to $0$. One way to do this would be to
balance commitment $C$ is a commitment to $0$. One way to do this would be to
prove knowledge of an opening to the commitment, i.e., producing $\widetilde{v}$
such that $$C = [\widetilde{v}] \widetilde{V} = \operatorname{Commit}(0,
\widetilde{v}).$$ But this is exactly what it means to create a Schnorr
signature for the verification key $C$, because a Schnorr signature is a proof
of knowledge of the signing key in the context of the message.

Therefore, we can prove that a value commitment is a commitment to $0$ by
Therefore, we can prove that a balance commitment is a commitment to $0$ by
treating it as a `decaf377-rdsa` verification key and using the corresponding
signing key (the blinding factor) to sign a message. This also gives a way to
bind value commitments to a particular context (e.g., a transaction), by using a
bind balance commitments to a particular context (e.g., a transaction), by using a
hash of the transaction as the message to be signed, ensuring that actions
cannot be replayed across transactions without knowledge of their contents.

Expand Down

0 comments on commit 362da0a

Please sign in to comment.