The Zcash Developer Alliance held its second meeting on Monday, September 14th. To promote transparency and collaboration, Electric Coin Company will post a short summary after each quarterly ZDA meeting. This is the summary from the discussion.
In attendance
Company
Names
Agoric
Dean Tribble, Vanessa Pestritto, Brian Warner
ConsenSys
Robert Drost, Joseph Chow
Electric Coin
Nathan Wilcox, Steven Smith, Daira Hopwood, Chris Nuttycombe, Andre Serrano, Elena Giralt, Jack Grigg, Kim Wolf
Iqlusion
Zaki Manian
Thesis
Matt Luongo, Carolyn Reckhow
Bolt Labs
Ayo Akinyele
Absent Loi Luu, Kyber
Discussion
Welcome, Introductions, and Agenda Review: The agenda for the meeting covered Zcash/ ECC Updates and ZDA Member Updates.
Zcash & ECC Updates: Steven updated the group on MGRC, elections for the five person committee will conclude on September 18th. MGRC will issue grants to 3rd party developers to work on top of Zcash. Canopy (NU4) mainnet activation will be 2020.11.18 which coincides with the first Zcash halvening and the launch of the new development fund.
Since the initial ZDA meeting in May, ECC has activated the Heartwood network upgrade, Luxor mined the first shielded coinbase, ECC released testnet-in-a-box and ECC released the source code for Halo 2. Zcash Foundation is working on launching zebrad consensus node as well as R&D work on network privacy.
Cosmos Pegzone: is another project that the Zcash Foundation is working on. Zaki elaborated on the Pegzone project and the possibility of a decentralized shielded pool pegzone on zebrad.
FROST: FROST was submitted for academic review in early August.
Other updates: Nathan highlighted the work of several community projects including Nighthawk Wallet, Zbay, Zboard, ZecPages and an upcoming Zcash focused Gitcoin Grants campaign.
Member Updates
Agoric: Dean Tribble gave the update. Agoric is exploring DeFi, “it is extremely exciting but very dangerous.” Kate Sills, software engineering at Agoric recording a Code with us demo to show how to make composable defi contracts with Cosmos.
Bolt Labs: Ayo Akinyele shared his update in slack. At Bolt Labs, we’ve been working to deploy zkChannels on top of Zcash (amongst a few other blockchains). zkChannels is a second layer protocol for scalable and usable private off-chain transactions. Over the last few months, we have been working with the testnet-in-a-box project and getting closer to our goal with the Transparent Zcash Extension (TZE) design & implementation. Regarding our zkChannels protocol design, we have generalized our ZK protocol beyond Zcash so that it supports Tezos (an account-based blockchain) in addition to Zcash.
Consensys: Robert Drost gave the update. Ethereum 2.0 is getting close to mainnet.
Thesis: Matt Luongo gave the update. Matt discussed the lessons learned from tBTC.
Next steps: ZDA will publish a round up of the launches related to member projects.
Transparent Zcash Extensions are a framework for adding new transaction functionality in future upgrades aimed at making it easier to deploy new modular functionality.
Any specific extension may or may not use shielded functionality, I believe. (This means the name of “Transparent” a bit confusing, so I’ll double check on my understanding here.)
Our plan is to ensure over time all such extensions have direct shielded support. The reason we don’t require shielded support for the initial launch is for two reasons:
First, for a given feature it may be easier to launch a transparent version quickly, and we prefer to make it as easy as possible to launch new features.
Second, if we have several transparent features, we may be able to introduce some amount of programmable shielded support that can support all of those features at once. This can ensure we develop programmable shielded functionality that actually supports known working use cases.
Finally, just to repeat nothing precludes a specific feature from having good shielded support, it’s just that it’s not required.
“Transparent” refers specifically to the fact that the on-chain value associated with a TZE-encumbered output is public, in the same way that the value in a coin sent to a t-address (which is a P2PKH or P2SH Bitcoin script encumbrance) is public.
There is nothing that prevents a specific extension from being implemented internally using ZKPs - Bolt, for example, uses ZKPs to provide privacy for its off-chain aspects. There is also nothing that prevents an extension from making assertions about existing Zcash shielded pools, including proofs that reference mined shielded notes via the commitment tree, or requiring that a transaction containing a specific TZE output also contain a shielded output with some properties. All of this can be implemented by interacting with the Zcash chain through an extension-defined Context (as long as it’s reasonably efficient for a full node to provide the necessary context).
You could even implement an entirely new shielded pool as a TZE, by having the public value encumbered by the TZE correspond to the total value inside the new shielded pool. This amounts to running a shielded pool in a sidechain, where you lock up / release main-chain ZEC in the TZE output, and mint / burn corresponding side-chain ZEC. On-chain updates to the new shielded pool’s state would be implemented as spends from one TZE output to another; these updates would be created by the entities that control the sidechain (either a single controller, or a group of them creating the necessary state update proofs via an MPC). If you squint a bit, a Bolt state channel is basically this, where the only two entities using a particular “shielded pool” are the merchant and customer.
However, there are things that you can’t do with TZEs, due to their base-layer use of transparent value. For example:
You can’t create a new shielded pool that can be used globally with no user coordination (beyond agreeing on what the Zcash chain is). The side-chain example above requires users to coordinate on the side-chain, and to trust the entities making the side-chain state updates.
You can’t send funds between different TZEs (or from an existing global shielded value pool like Sapling into a TZE) without revealing the value being sent between them.
TZEs that have internal anonymity sets can’t share those anonymity sets with each other (it’s always obvious on-chain which TZE is being used in a given transaction).
These use cases require some form of shielded programmability, where there is a base “execution framework” with shielded values, upon which almost-arbitrary shielded encumbrances could be built. This is what a future Shielded Zcash Extensions framework would provide. I believe that the pathway from TZEs to SZEs should be relatively straightforward (though no small amount of engineering effort), once we have an understanding of the kinds of protocols users want to deploy, and how flexible the shielded programmability model would need to be.
?