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 operationr.quantityandrcvare scalarsr.kind()andblindBaseare EC pointsrcvis random,blindBaseis 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
rcvfrom all compliance units in the transaction: bsk = \sum{rcv}. Note thatrcvare 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
bvkandbsk,bvk = bsk * blindBasesince individual balances add to 0, which proves that:- the signer knows
rcvused to compute compliance deltas - the transaction balances to 0 - otherwise,
bvk = bsk * blindBasewouldn’t be true and the signature wouldn’t verify
- the signer knows
- 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: