Authors: Ian Miers (@secparam)
ZK assets (sometimes called user defined assets or ZSAs) allow anyone to make their own private currency on Zcash. These can range from stable coins like Gemini-USD, to wrapped assets issued by things like Ren and TBTC, to algorithmic stable coins like Dai. Transactions of zk-assets are fully private, indistinguishable from both other zk-asset transactions and shielded ZEC transactions. This document lays out the design of zk-assets for Zcash and open problems.
On a technical level, zk-assets require:
We note, that the use of zk-assets is not limited to currencies. The exact same change also supports privately transferable non-fungible tokens that can be used for access control, counterfeiting prevention, and for art. We leave full support of NFTs to future versions of zk-assets, but hope this document will support the trival case: issue a zk-asset with only one instance.
This describes the core technical prototype for development and beta testing.
The circuit changes are analogous to the ones proposed for sapling by Jack Griggs in his draft ZIP. What remains is to port the changes to the plonk constraint system used by the Halo2 proof system in Orchard and implement a very clever (but thankfully simple) optimization by Daira Hopwood that removes the need for an expensive hash operation
See https://github.com/zcash/zcash/issues/830
The fees paid for moving a zk-asset (as opposed to issuing it), are paid in zec by the same mechanism as shielded zec transactions. The fees must be the same to preserve privacy.
At a reduction in privacy, all zk-asset transactions could have a higher minimum fee that must be output. This does not seem worth the privacy lost.
See this for more in depth discussion
Assets are issued, either once, or repeatedly, by posting a signed message to the Zcash chain.
We associate the public key with the asset (e.g. the asset ID is the public key). Creating x amount of the asset requires posting to the blockchain a public message signed by that address requesting x amount be printed. This immediately allows stable coins like Gemini-USD where a trusted party already exists to hold backing assets and already holds signing keys to issue assets on other platforms. It also supports cross chain issuance via mechanism like Ren, tBTC, etc which can hold keys.
Asset issuance is intentionally public. A stable coin where you do not know how many coins are issued is problematic.
Issuance should be supported for multiple types of public keys including from Bitcoin, Ethereum, and the zcash shielded pool. This is crucial to integrate with existing custody mechanisms and on chain schemes. It is also CRUCIAL that we support multisig.
To allow assets that can be issued only once, we can allow the asset_id to be set to, instead of the public key, the key combined with the last Merkle tree root. This ensures, without adding complicated state keeping, that attempts to issue fixed supply assets multiple times don't produce the same asset.
Ideally, we should allow zk-asset issuing keys to be rotated. This is likely a hard requirment for major stable coins.
Issuance key rotation should be realizable in the TZE model without adding global statekeeping. TZEs are, in essence, extensible version of script pubkey and script sig from Bitcoin. A TZE_output can be used to define the mapping from random asset_id to issuing key. Issuance is handled by a transaction spending that TZE_output with a corresponding satisfying TZE_input which specifies the amount to mint and a signature. The TZE output of this second transaction is allowed to reuse the asset_id and map it to a new public_key.
Issuance would be via a TZE. Exact wire format needs to be worked out by protocol engineers.
We may also need a simple TZE to allow destorying a zk-asset. In the case of a stable coin or wrapped token, this would allow withdraw of the backing coin.
Version 1 extends the core technical protocol to address economic considerations. We consider it separately from version 0, as version 0 is the MVP: It transfers zk-assets privately and pays fees as in existing Zcash transactions.
Version one considers possible economic enhancements.
Two persistant economic complaints for zk-asssets are:
Zk-assets like a wrapped version of Bitcoin (zbtc) are probably not a direct competitor for zcash, nor are stable coins. The (semi) trusted issuance mechanisms make them risky: the asset backing wrapped Bitcoin or shielded Gemini USD may vainish in a way zec itself cannot. The core case for Zec is "sound money" that needs to be private, just like Bitcoin has a value story even given wrapped BTC and stablecoin. Zk-assets and zec are probably complimentary and certainly benefit from a shared anonymity set.
Moreover, we note that credible plans for zk-assets on other chains(e.g. Tezos, cosmos,and Ethereum) make the concern moot. If the existence of zk-assets will undermine zcash, then this will happen when they exist on other chains. We are better off if zk-assets are on Zcash's chain,pay transaction fees in zec, and contribute to anonymity.
As to fairness: Zk-asset traffic could increase the anonymity set considerably and zk-assets pay zec fees same as any other use of the blockchain. And zcash benefits from increased usage, visibility, and exchange support for shielded transactions that could come from zk-asset support.
The economic concern that remains for zk-assets is one that has existed for Ethereum since its inception and applies to any chain that carries assets such as Cosmos, Avalanche, or Tezos: that a blockchain where the value of a block in other assets greatly exceeds the value of the native asset and block reward, is in a risky position. This is sometimes refered to as "topheavyness"
The concern is valid, albeit distant. Blockchain economics are in their infancy and we don't have good models for security. Empirically, we know Ethereum, Cosmos, etc have fared just fine so far. We have time before those chains have problems, and even more time–- and warning–-before Zcash does.
The goal for V1 of zk-assets is to provide a basic means of addressing econimic concerns and a mechanism for future improvement. We should take a similar approach to Ethereum: they shipped a minimum viable approach and have progressively addressed economic issues e.g., with EIP1559. As of yet, they have not had major economic security problems.
As a starting point, we examine fees for issuing zk-assets.
Any fee mechanism that distributes some amount of the issued assets to miners/bidders (e.g.2,4,5 above), has some downsides that should be weighed against the magnitude of the economic risks posed by zk-assets and the emprical effects seen in other blockchains like Ethereium,
Operational concerns. Custodial stable coins may wish to avoid the KYC/OFAC risks of issuing an asset where part of it ends up going to unkown parties they don't control.
Incompatibility with NFTs. You can't sell a fraction of a Picasso. Similarly, we can’t issue tokens for access control to e.g., members of a maker space, if anyone can bid for the token or (in the case of first refusal) force the issuer to pay an arbitrary amount to retain the the token. This removes a number of privacy preserving applications.
Privacy and efficiency concerns. Issuance mechnisms that fairly value the asset may cause people to only issue initial batches of valueless tokens and then, after the auction is complete, make them useful. This may fragment assets by resulting in batches of, e.g., wrapped BTC, actually being different and therefor neither fully fungible or fully private.
It is possible to support fees for destroying or burning zk-assets as well. It is unclear if doing so will encourage hidden destruction mechanisms (e.g. paying to the null key in a shielded transaction). The same choices for issuance fees apply.
Once these versions have shipped and after a few more iterations, we should consider implementing a native automated market maker on Zcash to support various assets. ZK-assets v0 are just the beginning.
If zk-asset transactions and zec transactions must look the same for privacy, then seemingly the only way to have differential fee's is via burning the fee (as in EIP 1559), since this can be done privately. In principle, it's possible to make the burned fee depend on the asset amount and type, but without pricing oracles its unclear how we fairly value the asset. One possibility is to have asset specific gas. Some pricing mechanism for the gas could be done, in the clear, the gas purchased with zec, and then the asset specific gas burned to transaction.
This poses three challenges:
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe