Binding signature in RM terms

Binding signature from Sapling is a clever approach that allows verifying the balance of the transaction without seeing the explicit values. We adopted this approach for our shielded RM design for now. This post aims to describe binding signature in the RM terms for those who are not familiar with Zcash.

Binding signature <> RM

In the RM world, binding signature is an instantiation of delta proving system. The expectedBalance value is always 0. Binding signature operates over compliance unit deltas, so let’s take a look how they work in details.

Compliance unit delta computation

In the current shielded RM design, each compliance unit takes one input and one output resource, the compliance unit delta is computed as: complianceDelta = inputResource.delta() - outputResource.delta(). Resource delta is computed as r.delta() = PedersenCommit(r.quantity, r.kind(), rcv) = r.quantity * r.kind() + rcv * blindBase
where:

  • * is a scalar multiplication EC operation
  • r.quantity and rcv are scalars
  • r.kind() and blindBase are EC points
  • rcv is random, blindBase is fixed

Note that computing compliance delta from resource deltas is equivalent to computing compliance delta from resource object components directly (i.e., skipping the individual resource delta computation), so in practice we do it as:
complianceDelta = inputResource.quantity * inputResource.kind() - outputResource.quantity * outputResource.kind() + rcv * blindBase

Binding signature

Let’s assume that we only have resources of the same kind for now.

  • Binding signature signing key is computed by adding commitment randomness rcv from all compliance units in the transaction: bsk = \sum{rcv}. Note that rcv are secret values.
  • Verifying key is computed by adding compliance unit deltas together bvk = \sum{cu.delta()}. Note that cu.delta() are public values - anyone can compute binding signature verifying key.
  • From the above it follows that for correctly computed bvk and bsk, bvk = bsk * blindBase since individual balances add to 0, which proves that:
    • the signer knows rcv used to compute compliance deltas
    • the transaction balances to 0 - otherwise, bvk = bsk * blindBase wouldn’t be true and the signature wouldn’t verify
  • Note that it doesn’t matter much what the signed message is because the properties described in this post are provided by how the keys are derived, not what is signed. In practice the signed message is the transaction (details omitted)

Multikind binding signature

Because of how elliptic curves work (kind distinctness holds), having multiple kinds in the same binding signature is equivalent to having multiple binding signatures per each kind, but having one binding signature is just simpler and more efficient. Note that it is all possible because we expect everything balance to 0.

Resources:

1 Like