TLDR; should the ECC/ZF/ECC/Community embrace the idea that Zcash could innovate on more then 1 chain? As a concrete example should ZF implement compute in the Zcash chain or a new/forked chain?
After watching the @zooko’s discussion with uponlytv it got me thinking about the feedback loops and specifically what feedback loops the dev fund creates and if those feedback loops provide the best opportunity for the success of Zcash.
So I don’t remember exactly what the public statement/goals of ECC/ZF/ZCG are but there appears to be an implicit rule that dev funds should be used to benefit Zcash. This almost certainly includes the value of ZEC. On the surface I wholeheartedly agree with this, but it got me thinking about how these economic incentives affect engineering decisions.
So let’s imagine a smart engineer outside the Zcash ecosystem wants to hire a team to create a private compute chain. They already have funding so aren’t influenced by personal economic incentives. They conclude that zk-proofs are one of the essential pieces they want and they decide there are a few ways they could implement this new feature.
- Work on the Zcash chain and eventually submit a pull request to add support to mainnet
- Fork/borrow technology/code from other chains (e.g. Zcash, Ethereum, etc)
- Build from the ground up
I find it really hard to imagine the engineer would decide to add this feature to Zcash directly. Not only hasn’t Zcash been built for compute which adds some technological and risk challenges but it also would likely take a lot political effort to get it approved. On the other hand halo2 is pretty wicked, why wouldn’t an engineer want to borrow that tech? Building from the ground up is also a possibility but you’d want to have a super OP team that has a proven track record with zk-proofs to design/implement it.
So if 2 and 3 are the most valid options and you could hire a team to implement it who should we hire? Maybe a team that is comprised of experts in halo2 and have a track record of building zk-proofs chains.
So from an engineering perspective having engineers/connections that live inside the Zcash system seems like a massive OP advantage but that doesn’t necessitate the need to bake “Zcompute” into the Zcash mainnet chain. At least not as it exists today. So the engineer might decide to implement a new blockchain that specifically solves the compute problem.
This scenario of creating a smart compute chain is similar to some of the objectives of Zcash Foundation.
Of the 3 explicit strategic objectives the Zcash Foundation have one is to make Zcash smarter. I assume, and haven’t seen any discussions to indicate otherwise, that by “make Zcash smarter” they are referring to Zcash mainnet as we call it today. And that makes sense because I imagine they want to adhere to the implicit rule of providing a net benefit to ZEC. But, would it be the best engineering decisions to add extra risk and maintenance to the Zcash chain (mainnet)?
As far as I can tell from both @zooko and @Dodger’s statements they appear to have opposing views on the topic of the Zcash Dev fund investing in making Zcash “smarter”. I want to be clear that it’s my understanding @zooko has no explicit issues with using ZEC in smart ways but I believe he thinks that can be achieved by composability with other blockchains/services. I assume that means composability with other chains developed outside the Zcash ecosystem. Does ZF think “we” can do it better by implementing a smart blockchain? And from a purely engineering standpoint is it really better to put that feature into Zcash mainnet? Or can compute exist on some other a completely seperate chain? And if it can exist on another chain should we be the ones to implement/fund the development of that chain?
I guess if we are going to discuss if we want Zcash to be smart we have to actually define what Zcash is. When I describe Zcash what I’m often describing is ZEC. That’s likely to change when ZSAs are release. After ZSAs as released I will describe Zcash as a blockchain that keeps ZEC and other transactions private? But wait, in the future, does Zcash have to be defined in terms of a single chain? What if the true definition of Zcash is “verifiable private actions as a service” (e.g. transaction and compute)? And what if that service existed on multiple chains? And what if the Zcash API/RPC allowed you to interact seemlessly on either the asset or compute chain? If from an engineering perspective it’s better to have more then one chain should we simply accept it and have more then one chain be defined as Zcash?
This seems to be the core issue. People have invested their hard earned money into ZEC. What value can we provide these investors? Does ZEC need to reflect the “value” of this new version of Zcash? Could “Zcompute” have a seperate ZCO token? If we have both ZEC and ZCO tokens should we float the value of ZCO or should we PEG the price at some ratio? Do Zcash holders accumulate the value of this new chain organically over time through ZEC adoption or upfront in the form of an airdrop?
I don’t know the answers but wonder if a ZEC only approach might hamper innovation and the ability to work on these grand ideas like “Zcompute”.