ECC has previously stated that they believe layer 1 horizontal scalability should be a priority, and a logical next step would be to deploy recursive proofs in NU6 or a subsequent network upgrade.
The Zcash Foundation is strongly in favour of enhancing the Zcash protocol to support user-defined assets (UDAs; also dubbed zk-assets, custom assets, Zcash shielded assets, etc.), as a means of improving user adoption.
We’d love to hear what the Zcash Community thinks, particularly what other ideas you think we should be considering. In mid-August, we will compile a list of options that we think are practicable and enjoy a sufficient level of support amongst the Zcash Community, and present them as a ZCAP poll.
(The following is my personal perspective and does not represent the view of ZOMG as a whole).
I believe that in the long run the two things that will help Zcash gain adoption and strength is a transition proof-of-stake and the inclusion on programmability at some layer. I believe that ZSAs are a great step in the right direction and should be put as a high priority for the 6th fork.
There have been some questions and discussions around the economics of ZSAs. My general view on this is that:
The benefits of ZSAs and the proliferation of use cases it will bring outweigh the economic risks.
Inclusion of ZSAs in NU6 can happen in parallel with PoS research that will take longer than the R&D of ZSAs (much of which appears to be complete). Future forks that include proof-of-stake upgrades are opportunities to tweak ZSA economics and features. Other blockchains tweak their protocol economics when they find out what things work and what things don’t.
I want a future where we see hundreds of sub-communities formed around Zapps and ZSAs. Hackthons where we can meet at awesome locations around the world and share what we’ve created on Zcash beyond pure money movement.
PoS and Zk-assets don’t conflict. Indeed, they can help eachother. PoS requires months (at least) of planning just to figure out how we do the transition, plus the whole problem of picking a PoS algorithm. All of that is good and should happen. But as @daira said on the Twitter space discussion, we can deploy simple zk-assets while doing the ground work for PoS in parallel. And as @Souptacular pointed out, we can use the economic changes an eventual PoS transition has to an opportunity to deal with any problems that might pop up with the first deployment of custom assets.
It’s like you bought a house and want to both add a hot tub and build an extension on the side of the house. One doesn’t have to wait on the other: It’s going to take you a year to design the extension, find the contractor, and build it. You can enjoy having popular parties with the hottub in the meantime.
I think doing PoS is well established among at least the parts of the community I am in. And Zcash should do it. As to why the rush for zk-assets/ZSAs? I don’t think there’s a rush, zk-assets (then called UDAs) were a thing considered for sapling in 2016. Protocol wise , we’re just updating a sapling design to Orchard and fleshing out some details.
But, why now? Well, once Orchard ships, the question is whats the next thing Zcash’s core protocol adds. Options I’ve heard so far are PoS, Sharding, and Zk-assets. Zk-assets have this nice property that we can deploy them in parallel to doing the design work for PoS (or sharding). On the other hand, if we sequence it the other way around, then we have to wait 1.5 years or more for zk-assets. And the problem is, there will be credible chains with zksnark based multi asset private transactions by then. (See, e.g., Tezos, cosmos,and Ethereum, and Mina). And those chains will get all the developers who want to build private stabecoins, private defi, and funky private preserving access control protocols.
If you believe in Zooko’s whale problem, then the ZEC whale will dump their coins and go for private wrapped BTC on one of those chains in a year if we don’t build zk-assets soon. ( I actually don’t worry about this Whale, Balaji made a good point that wrapped assets are risky and different from a native private coin. So private BTC and ZEC are complimentary, not competitive.)
So why now? Because its the opportunity we have to do it. If Zcash goes and does longer term things first (rather than in parallel with doing zk-assets), then all of this will be moot. And again, we don’t have to chose between PoS and zk-assets. We can do them both at the same time, just zk-assets will ship first because its simpler and a lot less work.
It’s important for Zcash to move away from proof of work, for a bunch of different reasons:
significant electricity usage contributes to extreme climate events
reputational and regulatory risks of contributing to climate damage
economic impact of linking Zcash to electricity and hardware prices
remove incentives for miner attacks on the protocol
I’d also like to see us reduce protocol complexity:
take specific steps in NU6 to continue deprecating Sprout,
come up with a general plan for the deprecation of legacy pools (and legacy features), and
require all new features to come with a deprecation plan.
Protocol complexity is an ongoing barrier to entry into the ecosystem, and an ongoing security risk for node and wallet implementations.
I’d also like us to do some work on better network anonymity for Zcash users. For example, node or network protocol changes for Tor v3 onion addresses. And distributing node and wallet implementations with network anonymity by default.
Currently, most Zcash blocks are almost empty. So we might want to wait until we have more users, then work on scalability. For example, we could wait until blocks or CPUs are 10% full, averaged over a month.
I’m pretty neutral on most other stuff right now, but happy to be convinced.
I definitely think ZSAs should be the main focus of NU6 since it adds the most utility for end users and there is a rapidly closing window of first movers advantage. Beyond that I think some form of programmability similar to Mina would be the most useful feature. Although I have no idea how difficult that is to implement so maybe that’s a much more long term kind of thing.
I believe in minimum viable feature experimentation and iteration to gauge market sentiment. Opening the door to ZSA support quickly, without over engineering, would be amazing. I would love to see potential issuers step forward to commit and participate in the discussion sooner than later. Maybe Thesis? I’d hate to unlock the capability and then wait for someone to show up.
I am a huge fan of exploring PoS or a hybrid PoS/PoW model. ASICs had a significant negative impact to ZEC distribution and the health of the community. There are many reasons to believe this move will promote significant growth and increase the value of ZEC, many of which are in Zooko’s blog.
I also personally like the idea of exploring programmability as advocated by @Dodger and @Souptacular and others. I have bias for app composability via interop with something like Agoric or Ethereum. While ECC isn’t focused here right now, I’d love to see others others dig into it.
We’re shifting how we approach our priorities at ECC. I’m hoping to get a blog out on that in the next week or so. Right now, our focus is primarily on Halo Arc and NU5. We are also prioritizing R&D on PoS and ZSAs (driven by UX, supported by scale) but are flexible to shift if the community pushes us in another direction. At a protocol level, we also have some interest in fee models, network level privacy, interop and a few other things.
Crypto is a dynamic area with many opportunities for profit. Why would anyone build bridges for defi on zcash via zk-assets without the base features either existing or in the pipeline in Zcash? Why would we expect that?
Actually, it’s worse than that. Remember, we need a small core change to Zcash to make that possible, its a change to the totally new Orchard circuit for which ECCs engineers are the worlds experts and, realistically, the only people who can make the change. Why would anyone step up to do all the design work and everything else for say an Ethereum to Zcash bridge for wrapped private Eth,BTC, and Tether when, in the face of both ECCs engineers enthusiasm and the community’s, ECC’s Senior Vice President for Growth is going “You know what, we will wait to see if there’s a growth opportunity” Why would they build a bridge to no where?
Huh? I think you are misunderstanding. I did not say anything like that. I said I’d like to see them out there quickly. I said we are prioritizing our work on ZSAs. I said it’d be great if someone planning to use them joined in the conversation. Please reread my post.
Hrm, well, the problem for getting anyone else to do concrete work still applies. Until its clear Zcash is going to ship zk-assets/ZSAs, its pretty hard to get any one onboard for real. But we can probably get requirements to make it really easy for existing players to plug in and use it. Especially since things like Ren already know how to deal with the zcash blockchain in general. I’m asking around.
Saying this as an independent mining operation, literally 1 man for my entire farm.
I would like to explore the idea of a hybrid POS/POW algo as well.
I had the idea of the system being governed on the variable of network difficulty/block height.
Perhaps we have a predefined variable, representing a network difficulty increase that corresponds with the shift from PoW to PoS.
Simply put, when network difficulty increased by X% then switch to PoS for Y.
So it would be dynamic in the sense that the PoS time frame would be directly responsive to large increases in network hashrate. Probably directly as a disruption to the “we will make a private ASIC within 4 months” argument on the ASIC manufacturer’s behalf. If they drive the network difficulty up to fast, they would bottleneck their own earnings, and initiate some of the longest PoS time frames base on network difficulty increases.
Where? I’m missing it. All I see is ECC saying they will investigate usability challenges and the like. Unclear if thats adding a prerequisite that must be done before to starting ZSA/zk-aset core protocol engineering or committing to doing that core engineering and doing usability work after/in parallel.
our priorities are Zcash Shielded Assets (ZSAs) and Proof of Stake (PoS).
I could be wrong, but I think this is significant info since it’s signaling a shift away from ECCs previous engineering focus on scaling and moving to ZSAs and PoS.
As you mentioned before, Zcash in it’s current form has plenty of room for user growth (tx capacity) so scaling is not an issue and not enough “cool things to do with Zcash” to utilize that space. I think ZSAs are a good first step to make the community excited to build more things on Zcash.
ZSA R&D is the priority (beyond what’s already been done), largely after we get NU5 activated on testnet and a block height set, though Nate has done work on fee models. We are looking at scalability through a ZSA lens. GMU should be wrapped up before the end of this month. We have also started looking into possible issuers, beyond but including Thesis, and will begin UX work as soon as feasible after NU5/Halo Arc related work.
Scaling the block chain via recursive proofs can be done either with either PoW or PoS, or a hybrid. Zcash’s current proof of work algorithm isn’t ideal for efficient verification in a circuit (it needs many BLAKE2b hashes), but even that’s much more efficient in Halo 2 than it would have been for Groth16, due to Halo 2’s support for lookups. In any case you can get most of the scaling benefit without needing to check the PoW in a circuit.
From my perspective, it’s not that we think scaling is any less important, but rather that with NU5, we’ve done the necessary work to prepare for it. Previously, we were in the situation that if a sudden increase in network usage had occurred, we would have been very short on time to deploy a scaling solution in response, at least not without incurring significant network congestion in the mean time. Now that Halo 2 is being deployed in NU5, we know that we would be able to deploy scaling using recursion on a timescale that would likely avoid any major disruption, and that would not exceed the complexity budget for a single upgrade. (See Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub for a fairly detailed straw design.)
This a great move from the team and the timing feels correct. What is the expected timeline for ZSAs? I do think we have to be quite aggressive with our evangelism. Once the features are working, there should be hackathons and community building with significant prizes to build out the space. It has been interesting watching Solana and their strategy - overall, they’ve done well.
The cross-chain piece would also be a game changer. Cosmos ecosystem seems to be the best avenue. I have been looking at Sifchain quite a bit recently and I know there were discussions with Thorchain earlier in the year.