Suggestion:

1. Rename spacesuit::transaction::fill_cs() into spacesuit::cloak()
2. Rename spacesuit::<gadget>::fill_cs() into spacesuit::<gadget>().
3. Keep the module organization as-is, though, just not expose it to the user.
4. Expose only the spacesuit::cloak() and spacesuit::rangeproof() and Value/AllocatedValue types. The rest keep private to the crate.

Problem

Currently we have value defined as three-item tuple (q,a,t), quantity, issuer, tag. This is a relic from the original ring-signature-based design in Sept 2017, where the tag could've been used as a private key by an issuer to enable "confidential issuance".

In Bulletproofs, the prover must know all the secrets to compute per-proof values [*], which makes use of confidential "tag" impossible.

Proposal

Given the narrow role of the tag in the first place, we can completely get rid of it and simplify the implementation as a result.

1. Get rid of tag and issuer.
2. Change flavor from a tuple (issuer, tag) into a single scalar f.
3. Simplify all gadget definitions accordingly.

[*] Strictly speaking, the prover can cooperate with the issuer to construct necessary pieces of the CS commitments and polynomials with the use of the secret tag, but it must be done per-transaction, and this way leaks the fact that the transaction involves that issuer's assets.

Each value is a triplet of amount, tag, issuer.

• amount: represent a secret amount
• tag: represents a customization part of the asset flavor
• issuer: represent an issuer of the asset flavor

In transfers, all values are secret. In plain issuance, tag and issuer are not secret. In confidential issuance case, issuer is non-secret generic program (which implements confidential issuance), while tag is secret.

We have two options to represent the values:

1. Simple: as Bulletproofs require, each secret may have its own single-point commitment. Therefore, each value is committed in 3 group elements. That's 96 bytes per output. So in a 16-output transaction, the size of commitments is 1.5Kb which is more or equal to the aggregated proof size. For larger transactions commitments begin to dominate the bandwidth.
2. Compact: we may do a vector pedersen commitment to compress the representation in 1 group element: V = amount*A + tag*B + issuer*C + blinding*D. That's 32 bytes per output. In a 16-output transaction the size of commitments is less than the proof size (0.5Kb vs 1.5Kb).

The problem is: we don't know how to adapt BP to work with such compressed commitment. It may turn out that to support it we'd need additional intermediate commitments, destroying the gains from the compression in the first place.

Potentially also get performance comparisons against other confidential assets protocols.

What's the difference between the main and master branch?

This is prompted by the discussion in ZkVM interstellar/zkvm#28.

In ZkVM spec we use borrow instruction that returns a WideValue which may have negative qty, but with absolute value still in u64 range. We are not exposing WideValues to the higher-level protocols, but we still need to represent the negative-but-in-range quantity in ZkVM and Cloak.

Cloak protocol must be updated to explicitly allow negative, but in-range input values. Outputs are still explicitly checked to be non-negative, and since inputs are in narrow range, overflow mod |G| cannot happen, and therefore negative quantities have to be compensated by the corresponding positive quantities in the Mix gadgets.

• Update the spec to allow negative in-range quantities in the inputs to the cloak instruction.
• Replace qty:u64 in AllocatedValue with enum SignedInteger { Positive(u64), Negative(u64) }.

WDYT @cathieyun @vickiniu ?

PR here: #15