That seems to be the full extent of information published by ECC on this… And the referenced presentation is short on details (and not a great medium for reference material). So…
@joshs, @nathan, @mhluongo, @prestwich: can you tell us more about what “wrapped ZEC” means, why it’s important, what are its privacy/security/economy implications, and what work (by ECC and by others) it would take?
can you tell us more about what “wrapped ZEC” means
A token on some other chain that can be redeemed for ZEC on the Zcash chain on-demand.
This post assumes a peg styled after tBTC/XClaim, although I think Rollout is really compelling for this usecase. By common usage wZEC implies a central custodian, while tZEC implies an economic system on the remote chain.
what are its privacy/security/economy implications
privacy: While you could add privacy layers to the remote chain, it is unlikely that remote wrapped ZEC could effectively share the anonymity set of Zcash. Plus, it would be extremely difficult to wrap shielded ZEC, so the wrapping/unwrapping process is likely to have very little privacy
security/economy
very little impact. in worst-case scenarios (miner cabal entirely controls Zcash chain) this could be used to monetize double-spends or reorgs, although most likely the cabal would be able to extract very little value
what work (by ECC and by others) it would take?
Ethereum Istanbul hard fork is the only strict requirement for implementing this on Ethereum. On the Zcash side, no changes are (strictly speaking) required. ZIP-221 helps, but the ideal is a change to Zcash’s PoW to make its (extremely large) headers smaller.
For reference, we’ve revived EIP-152 on Ethereum for Istanbul to make this possible.
I’m also interested in a broader two-way system where Zcash can also support non-native assets in-circuit, but the simplest implementation today would be tBTC with ZEC as collateral, against t-addresses. @prestwich and I discussed some of this at Zcon1
ECC is contributing work in support of wrapped ZEC in three ways:
looping in other developers like Matt and James to help see the Flyclient-style MMR deployed as a Zcash upgrade,
coordinating work between developers so that the resulting integration works coherently, and
probably doing integration and testing work for the MMR feature in zcashd.
Notice that ECC is not planning to contribute to any wrapped ZEC product at this point. Instead we see MMR as a building block for others to build valuable stuff atop Zcash, and so we want to enable them to do their thing.
Also note that ideally the first bullet wouldn’t be necessary in my opinion. In other words, ECC shouldn’t be a bottleneck/gatekeeper for other developers to propose and develop Zcash improvements, so that’s something we intend to improve in the future.
We’ll be publishing a blog and doing a livestream describing how this fits into our strategy and what our rationale is next week.