[ZIP 220] Zcash Shielded Assets (previously UDA or UIT)

[daira]

Several block chain platforms allow supporting multiple asset types in a single system — for example ERC 20 tokens in Ethereum. Each of these assets satisfy balance individually. For Zcash, they could all share the same note anonymity set. We rejected this from 1.0 on grounds of complexity, but it deserves an issue ticket to be able to refer to the idea.

[Edit: when I originally wrote this I thought that "Coloured coins" in Bitcoin were an example, but they actually do not represent separate assets.]

[jackgavigan]

In recent months, we have using the term "user-defined assets" (UDA) to refer to this concept.

To my mind, the goal should be to allow users to issue "native" assets - i.e. the new assets are effectively identical to ZEC in terms of functionality (including the ability to shield and unshield), they'll just have a different identifier. Note that this approach is very different to coloured coins, which effectively allows a user to "paint" a pre-existing, native coin instead of creating a new asset. This would allow anyone to create and transact new assets on the Zcash platform. Transaction fees would continue to be denominated in ZEC.

Questions to be explored include:

• How to identify/differentiate user-defined assets? (e.g. an asset identifier based on a public key)
• How to control issuance? (e.g. with the corresponding private key?)
• What issuance models should be supported? Supply defined and fixed at the time of creation? Ongoing issuance - either unlimited or with a maximum supply set at the time of creation?
• Should it be possible to issue assets privately or should all issuance happen transparently?
• Should it be possible to redeem/withdraw assets from circulation (thereby formally reducing the total supply)?
• Should there be multisig-style support for issuance?
• Should it be possible to define an asset whose issuance is triggered from another blockchain (e.g. by depositing the other blockchain's asset into an escrow address/contract), and which can be redeemed/withdrawn back to the other blockchain? (This would effectively allow the Zcash network to be used as a payment channel).
• Should there be a fee for creating a new asset type? (e.g. Payable to the Zcash Foundation?)

Once support for UDA is in place, the logical next step is to add support for what I'm dubbing "intra-chain atomic trades" (ICAT) - i.e. the ability to atomically swap different assets on the same blockchain. I've created a separate issue for that feature: #2053

[nathan-at-least]

Here are some design constraints in the form of 'features we wish to avoid precluding':

• Various simple UIT-based voting protocols. See ZIP:publicly verifiable anonymous voting on the Zcash blockchain (with minimal protocol changes) zips#102 and the related but different voting-protocols work in Voting based on proof-of-stake #1112.
• ICAT: indistinguishable multi-party-opt-in asset trades (see Intra-Chain Atomic Trades (ICAT) #2053).

[nathan-at-least]

BTW- we've renamed this feature from "User-Defined Assets" to "User Issued Tokens".

[Pratyush]

Our paper has some ideas on how such an updated interface might look:

https://eprint.iacr.org/2016/1033

It uses terminology from ZeroCash, but that shouldn't be too difficult to work around.

[daira]

^ more precisely, I marked #2424 as a duplicate of this. (Grr, Github.)

[daira]

There's a proposal for one way to do UIT at #2277 (comment) .

[gojomo]

To extend @jackgavigan's questions:

• Could an issuer have an option as to whether the total initial issuance is public to any blockchain observer, or semi-private where they can create a private proof that exactly N have been issued? (Both seem useful even if holders' addresses & holders' balances are totally private.)
• Can UIT holder prove their exclusive holdings as of a certain block, for example to qualify (in some external offchain system) to collect some benefit that is intended for holders-at-certain-levels? (For example: "everyone with at least 1 zNOM at block Y gets a commemorative t-shirt".)
• Can the issuer 'airdrop" an on-chain amount (of ZEC or other UIT) to all UIT holders in proportion to their ownership – without in fact knowing the holder addresses/amounts, or forcing those to be revealed when the airdrop is collected? (If so, can another entity beside the issuer also do the same?) (If a precise proportionate allocation is impractical, might a probabilistic allocation, where holders' expected value matches their proportionate holdings, work?)

[tromer]

@gojomo Yes, our zkSNARK-based approach is flexible enough for supporting everything you described (with straightforward protocol extensions). We'll need to decide what to actually support, to keep complexity at bay, so can you suggest motivating use cases?

[gojomo]

I like Kickstarter-like projects as a model, but with added censorship-resistance & anonymity. So a blended use-case, here contrived but hopefully representative of possibilities, might be:

A team wants to execute some bit of art with a controversial political edge. (Maybe it's a monumental sculpture, maybe it's a documentary, maybe it's a computer game.) It might eventually generate recurring revenue, or be salable as a unit, when completed. They need help covering initial costs of $X00,000, and would like to offer patron's tokens with downstream benefits to those who can help supply the funds.

They'd want the system to help them irrevocably commit to some issuance plan (fixed or a range/schedule), then atomically exchange tokens for bona fide ZEC payments. The team will want to be able to prove the total number of tokens in existence, and perhaps reveal for some or all of the initial transfers how much ZEC were received. Some buyers will want to be able to prove their participation & at what cost, while others will want to remain anonymous.

To make the tokens attractive, a number of Kickstarter-like rewards would be offered. Say there's an opportunity for the work to include some messaging (such as a plaque of 'dedications' or list of credits/patron's-statements), to be determined not at initial-offering but some later date just before launch, available to any patron with more than X tokens. There'll be a launch party or other showings to which patrons with more than Y tokens get a free ticket. Some limited-edition branded-memento of the full work will be available after completion to all patrons with more Z tokens. Collecting these off-chain benefits would require a token-holder to prove their unique holding proportion, as of certain varying deadlines, together with a signed-request-for-delivery-of-the-benefit.

The completed work might generate recurring revenues, for example exhibition fees or licensed use in other commercial venues. The team may pledge that J% of such revenues are converted to ZEC and distributed to token-holders proportionately. Ideally receiving and then spending these ZEC would require no loss of privacy by token-holders. (That is, unlike claiming offline rewards above, there'd be no necessary interaction with other unshielded value-delivery systems.) Further, receiving such benefits should not consume the underlying tokens.

The completed work might have some terminal liquidation value, for example upon sale to a collector/distributor/exhibitor, of which the team has pledged that K% of such value be proportionately distributed to token-holders. This could be effected like the other distribution above – non-consumptive of the tokens – even though the intent of the team is that there be no further value to the tokens. Or it could be offered in a fashion that consumes the tokens: claiming a proportionate amount of this terminal value, in other ZEC/token-balances, necessarily retires (or sells) the corresponding tokens. (Even short of liquidation, this sort of standing 'open tender' might have interesting uses, if it could live on the blockchain for either a fixed-period, indefinitely, or until-cancelled. Perhaps hard to do in a shielded non-interactive fashion, though.)

In terms of priorities, a publicly-observable/enforced cap on issuance and ICAT #2053 seem foundational. An externalizable-proof-of-exclusive-holdings-as-of-date would enable allocating off-chain (and thus perhaps privacy-compromising) benefit-delivery. Proportionate on-chain airdrops of shielded value to holders would enable perpetual shielded revenue/profit-sharing.

[daira]

@jackgavigan wrote:

To my mind, the goal should be to allow users to issue "native" assets - i.e. the new assets are effectively identical to ZEC in terms of functionality (including the ability to shield and unshield), they'll just have a different identifier.

I had been assuming that UITs would be shielded-only. Assuming we have full selective disclosure and the performance improvements from Sapling, is there any compelling use case for unshielded UITs?

[jackgavigan]

If it's shielded-only, how would a publicly-observable/enforced cap on issuance work?

Also, there may be use cases where transparency is desirable (e.g. public voting, distributing funds for aid or grants).

[RiganoESQ]

will coloured coins be supported on sapling? will sapling support smart contracts?

[daira]

@archmaester: no and no. Sapling is already a very ambitious upgrade without either of those features.

There is however a proposal for how to do UITs building on Sapling: #2277 (comment)

[nathan-at-least]

While having conversations about Blossom and subsequent upgrades, one theme that has popped up is the potential value for "stablecoins". Stable coins need strong privacy and can ideally mitigate volatility concerns that MoE users would have with cryptocurrencies.

I believe they are a specific use case for a "User Issued Tokens" feature, and we should revisit the product market fit for this feature with this use case in mind in 2019.

[daira]

The earlier technical proposal that I came up with during the Sapling design process, has the disadvantage that each asset requires a different base, and therefore it's necessary to hash from the asset ID to an elliptic curve point in the circuit. This is possible but expensive, and complicated.

I invented the following simplification during the design of Orchard, but hadn't written it up until now.

Suppose that per transaction we have a limit L on the number of distinct non-ZEC assets that can be transacted (so L+1 including ZEC). I.e. we can have arbitrarily many assets, as long as only L of them (plus ZEC) are used in each transaction.

Define A₀ to be the asset ID for ZEC, and let A_1..L be the asset IDs of assets 1..L in a given transaction. The idea is that we only need value commitments over L+1 fixed bases, in order to check that each asset balances. Call these bases B_0..L where B₀ is the existing \mathcal{V}^Orchard base for ZEC. It does not matter whether or not the same base is used for the same asset across transactions, since the checking of value commitment balance is local to a transaction. It also does not matter whether A contains duplicate asset IDs.

In more detail:

• Add a per-transaction field, assets, which is a hiding commitment to A_1..L.
• Add assets as a public input common to each proof.
• Add A_1..L, Slot_old∈{0..L}, and Slot_new∈{0..L} as private inputs to each proof.
• Add an asset ID to each note and note plaintext, such that the asset ID of the old and new notes in the Action circuit are A_old and A_new.
  • We can easily make this compatible with and share the note anonymity set with the existing protocol, as long as the note commitments of ZEC-denominated notes use the existing input format.
• In the Action circuit,
  • check that A_1..L is an opening of assets;
  • check that A_old = A_Slotold and A_new = A_Slotnew;
  • calculate the old value commitment using base B_Slotold, and the new value commitment using base B_Slotnew.
• To mint new value in a given token, we use an Action in which everything is revealed, and v^balance is adjusted to account for the new value.
• The rest of value balance and binding signature checking is as before.

The additional circuit cost of this design is:

• the cost of opening a Sinsemilla commitment to A_1..L;
• the additional cost of including an asset ID in the commitments to the old and new notes;
• the difference in cost between fixed-base and variable-base (more precisely, one of L+1 bases) scalar multiplication of the value (which is only 64 bits) in old and new value commitments;
• the (trivial, for small L) cost of checking that the correct base is used for each note.

The resulting Orchard circuit should easily still fit within 2¹¹ rows, without any increase in advice columns.

[hdevalence]

In this proposal, the action circuit has to check that the asset IDs A_{1..L} are an opening of the Sinsemilla commitment assets. But if the goal is to avoid a hash-to-group operation by not computing the value bases directly by hashing the asset IDs, doesn't opening a Sinsemilla commitment inside the circuit also require a hash-to-group operation?

[ghost]

In this proposal, the action circuit has to check that the asset IDs A_{1..L} are an opening of the Sinsemilla commitment assets. But if the goal is to avoid a hash-to-group operation by not computing the value bases directly by hashing the asset IDs, doesn't opening a Sinsemilla commitment inside the circuit also require a hash-to-group operation?

I think the primary difference is that in the prior proposal, the hash-to-group must be a PRF, whereas opening the commitment only requires a CRF.

[str4d]

@hdevalence there is no hash-to-group operation in the circuit (in the traditional PRF sense), because we don't need to ensure that we can derive independent bases from the asset IDs. The trick here is in recognising that you don't need to use a specific base for a specific asset; any base will do, as long as each asset type within the transaction uses an independent base. So what we actually have is the cost of opening a Sinsemilla commitment (which is just a Sinsemilla invocation, same as we already do for opening NoteCommit or the Merkle path), and then a deterministic map (based on the slot order) from asset types to fixed known-independent bases (for which we could reuse e.g. the 2¹⁰ independent Sinsemilla bases, giving us an effectively unlimited number of asset types an individual transaction can operate on).

[daira]

for which we could reuse e.g. the 2¹⁰ independent Sinsemilla bases, giving us an effectively unlimited number of asset types an individual transaction can operate on.

We could, but note that opening assets is linear in L. Concretely the cost that varies with L is only about 15L rows, assuming that asset IDs are Pallas field elements. (26 rows × 5 advice columns + estimated 2 rows overhead, where we have 10 advice columns in the Orchard circuit.)

[ghost]

There's an interesting side effect, where a prover now needs to know assets before generating any proofs (without any other dependence on transaction-level data).

For example, to execute a 3 party swap where Alice swaps asset X for asset Y, Bob swaps asset Y for asset Z, and Charlie swaps asset Z for asset X, Alice must know that asset Z is present in the transaction even if she neither spends or receives any asset Z.

In this case, building the transaction seems to require an extra round of interaction to agree on assets before generating proofs. A unique value base would allow Alice to prove her Action descriptions and then go offline (ignoring, for now, how multi-party transaction signatures might work)