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.quantity
andrcv
are scalarsr.kind()
andblindBase
are EC pointsrcv
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 thatrcv
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
andbsk
,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
- 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: