What are your plans or better to say vision for improvements scalability of ZCash ? Is something on the roadmap re sharding or alternative techs ?
2 Likes
It is recommended to pause sending transactions about an hour before the network upgrade. Here’s a FAQ about that very topic!
6 Likes
This question will have obvious overtones to a well-known coin’s scaling debate.
Could you indicate your position(s) on the ‘natural state’ of Zcash’s blocks given increased demand and usage?
Absent new scaling techniques and irrespective of the existence of an L2, what is the purpose of Zcash’s maximum block size and will it be increased to avoid an artificial ‘fee market’?
Thanks.
5 Likes
That depends a lot on the capabilities of the device. Sapling is primarily designed to support isolation of spend authority in very small devices (in theory a few hundred bytes of RAM, and very little computational power, is sufficient). As the spec says, in that case privacy is lost to whatever party/device is doing the zk-SNARK proving. However, the proving itself is much more efficient in both time and memory for Sapling – so, it’s entirely plausible that a mobile phone or other small/dedicated device can do the whole spending process without loss of privacy to any other party. For that the device wouldn’t necessarily need to be a full node.
We don’t know yet what the timescale will be for support of shielded transactions on mobile.
4 Likes
While someone from the Zcash Foundation is free to answer and may do so, they are a separate entity from the Company and aren’t officially part of this AMA.
2 Likes
The team is heads down on Sapling right now but have plans to update our roadmap post-Sapling once we’ve had more time for deliberations and planning. Stay tuned!
4 Likes
We’re focused on Zcash as a mechanism for Internet money and have not expanded the scope to include smart contracts or Ethereum-like functionality. It would be interesting to see more RnD on this, though. We previously stated an interest in “user issued token” support but have since refocused on improving shielded address functionality and more fundamental usability.
Maybe someone else is interested in doing this to move it along!
3 Likes
Sean Bowe came up with an extremely cool way to do zk-smart contracts called pay to verification key. It’s not gonna be in Sapling and there are no concrete plans on when it will be incorporated. Pay-to-verification-key payments · Issue #2425 · zcash/zcash · GitHub
4 Likes
There are many possible approaches we’re looking at:
- Succinct blockchains, and similar work by StarkWare
- Block DAG protocols such as SPECTRE and PHANTOM
- Ethereum-style sharding
- I’ve been working in my spare time on an idea that separates the consensus protocol into two layers – a “transaction feed” protocol and a “block consensus” protocol. It’s primarily designed to improve security against 51% attacks but may also help scalability if it works out, and it’s complementary to the succinct blockchain idea.
10 Likes
Initially sprout transactions will be allowed, and my understanding is that there are no concrete plans on how the phasing out will happen.
2 Likes
When can we expect to have official Zcash windows wallet with supportof z-addresses ?
1 Like
That’s interesting. Will z_sendmany do the magic behind the scenes or will there be separate RPC calls for Sprout/Sapling sending?
2 Likes
We are working toward adding Windows as a supported platform for zcashd, meaning the same level of testing as our other currently supported platforms. Like the other supported platforms, this would run as a command line program.
As for when to expect it, it’s not a top priority (sapling is) and we don’t have an official release date, but I am currently working on it 
4 Likes
z_sendmany will do the right thing behind the scenes. [Edit by @daira: z_sendmany will not do direct transfers between Sprout and Sapling, though.] There may be other interfaces for doing things like migrating funds from Sprout to Sapling, but we haven’t specified those yet. My understanding is that z_getnewaddress will default with a new Sapling address.
4 Likes
Assuming I understand correctly if I am sending to a Sapling address from a current Sprout one the amount will be revealed (by design). So, I guess it’s going to be really important people are proactively moving funds between Sprout/Sapling in a way to maximise privacy (cue your other interfaces) before using them in normal payments.
2 Likes
Indeed Hopefully this issue will not result in the same level of political acrimony as for that other coin and its forks.
In my opinion the primary purpose of a maximum block size is to mitigate denial of service attacks. Zcash has considerations around fee selection that don’t apply to transparent coins, since user-chosen fees may leak information about which user created a transaction. The core Zcash devs also seem to have quite different intuitions about the effects of fees on usability and adoption than, e.g., the Bitcoin Core devs. So our strong preference is not to allow a laissez-faire fee market (see #398, #2942, and #2863). I think we’re pretty determined not to let fees get too high, and if that requires increasing block size then I don’t imagine we’d have much trouble deciding on that. (Note that this is not a commitment to do so, and we don’t have concrete plans to increase block size at the moment, because fees and transaction mining latency are currently fairly low. Also, Zcash started with 8 times the transaction bandwidth limit of pre-Segwit Bitcoin.)
I know you said “absent new scaling techniques”, but we’re also likely to pretty aggressively pursue such techniques (see my previous answer), and we have talked about this being the main focus of the NU2 upgrade after Sapling.
8 Likes
What do you mean by “cue your other interfaces”?
I was just eluding to the @ebfull post above:
There may be other interfaces for doing things like migrating funds from Sprout to Sapling, but we haven’t specified those yet
As in these are going to be important to give users an intuitive way to migrate between Sprout/Sapling. The t/z stuff is already confusing to many newcomers so adding in Sprout vs Sapling addresses and the potential privacy issues of moving between the two probably is going to need a bit of explaining!
4 Likes
Initially there will be no restrictions on continuing to use Sprout shielded addresses when Sapling activates. (Note that those transactions will change to use the more efficient Groth16 proving system for JoinSplits - #3071.)
We’ve talked about that but haven’t made any decisions about timescale. Personally I would like to see Sprout transactions disabled in around a year (see #2718), but that hasn’t been agreed on and is somewhat contentious. Your input on that ticket is welcome. It’s likely that sending to Sprout addresses will be disabled before sending from such addresses.
4 Likes
This is the most “ZcashCo Team Member” participation I have ever seen in a thread!!!
3 Likes