Dear Zcash community,
We are super excited to share with you the first DRAFT versions of the two ZIPs that cover the ZSA protocol, which @naure @PabloK @shahafn @vivek and myself worked on for the past months with the help of @daira @str4d and @tromer:
These ZIPs have been in the works for the past two months and we have interacted with the community, the ECC and the ZF developers to ensure the compatibility, usability, privacy & security and elegancy of the protocol.
You can find here the three different calls that we had discussing these ZIPs
- Arborist call (24/02/22): https://youtu.be/jXY01qGyd_I?t=1774
- Arborist call (24/03/22): https://youtu.be/-r06Dm41DS0?t=2325
- Independent call (25/04/22): https://us02web.zoom.us/rec/share/ZbXfGFtOZKsYuRc46TWWhmXBqAR-FGJKTJvKVFuMsiWXuTSd_GvEhM9VTQZIkGnF.cyi1zUFZMxEVIIeo
A short description
Issuance
As our MVP, the issuance mechanism is transparent, and enables several interesting applications of issuance on Zcash. We have designed a protocol that enables batch issuance for finite or infinite supply of assets. It allows for NFT-style issuance, and is off-chain extensible to allow for bridges to be built. In terms of security, we provide the ability for the chain to track the total supply of any token, as well as for individuals to revoke the issuance of an asset id in case of compromise.
Transfer
In terms of the transfer mechanism, we have designed a circuit that ensures that old-style ZEC Orchard notes can be used as-is within the ZSA protocol, making the transactions totally indistinguishable from the Orchard transactions. This means that we have backward-compatibility and in terms of upgrade, we will not have to create a turnstile.
The transfer has been reviewed to be secure, albeit lacking of an actual security proof, which we hope to at least sketch.
Burn
In order to properly support an end-to-end ZSA protocol, we designed a very elegant burning mechanism. We will use the inherited format of the shielding/unshielding of ZEC in the Orchard protocol (that uses the transparent ValueBalance) in order to confirm that some amount of a given asset has been burnt and is unspendable. We define purely the protocol for burning, but we do not provide a specific implementation of how a bridge should be built, as there could be several ways to accomplish the bridge (the main question is how to transfer data to the bridge operator).
Discussion points
- We have included a paragraph on how we believe the fees for the issuance mechanism should be designed, but we would love the community input. We will review in the coming weeks the study done by George Mason University and the ECC (https://electriccoin.co/wp-content/uploads/2022/05/A-Study-of-Decentralized-Markets-on-the-Zcash-Blockchain.pdf)
- We are looking for feedback on the burn protocol from issuers and bridge operators to understand exactly if this protocol covers the needs of a semi-trustless and secure bridge.
- others?
Comments
These ZIPs are in DRAFT mode and will definitely see some changes in the months to come, both as we receive feedback from the community and core developers, as well as changes that arise in the implementation process. We have started working on a prototype of these designs in order to have initial tests.
We welcome any comments and questions!
We will be hosting a live twitter spaces in a couple of weeks to discuss this, stay on the look out for more info!