Announcing Zcash Blossom and proposed feature goals

General
1

Now that Sapling has activated and active work on ecosystem adoption is underway, we’ve begun early planning for our next protocol upgrade, codenamed Zcash Blossom.

Upgrade Development Process

A lot of my personal effort in planning for this upgrade has been initially focused on the process itself with several important process design goals: improving quality/safety, avoiding rushing or cramming, aiming to enable the Foundation to “hook in” the ZIP process, providing synchronization points to allow multiple dev teams to contribute to upgrades, and so forth. I intend to write more about the process itself in the future. But now let’s talk about Blossom:

We plan to have Zcash Blossom activate approximately around October 28th, 2019 (one year after Sapling activation). The new development process we are following begins with a set of potential goals for an upgrade, and the first milestone is a set of feature requirements. Over the next few weeks, we’re going to be gathering feedback on these goals and vetting these goals with a product-focused mindset (ie: to ensure they help real users and advance our overall strategy).

Potential Blossom Upgrade Goals

Here’s the current set of feature goals we’re looking into for Blossom. Keep in mind that these goals and actual design details that go into these goals are likely to shift as we do our initial R&D into them.

Note: The actual goals for Blossom will evolve with during our research and product validation work. The current list of goals live at the Blossom Goal github label.

Harmony Mining

  • Github: zcash #3672
  • What is it? A dual-proof-of-work scheme, where one algorithm is backwards compatible with current mining equipment, and another is designed to work well with GPUs on a temporary time scale.
  • Who does this affect? miners
  • Why is this a goal? By attracting distinct mining userbases (ASIC & GPU owners) we aim to make the Zcash ecosystem more resilient by spreading issuance and political influence among distinct kinds of stakeholders.

Split Founders’ Reward

  • Github: zcash #3673
  • What is it? Alter the consensus rules so that there are distinct FR addresses for the Zcash Foundation, Zcash Company Strategic Reserve, and the remainder.
  • Who does this affect? FR Recipients and Governance/Transparency focused public
  • Why is this a goal? This decouples these three funding streams organizationally, legally, and operationally. It further reinforces transparency as to the structure of the Founders’ Reward.

Transaction Confirmation Usability and Security Improvements

  • Github: zcash #3674
  • What is it? Improve usability and security of fees and confirmations while accounting for growing transaction volume, demand spikes, and transaction-based DOS scenarios.
  • Who does this affect? Transaction senders and receivers.
  • Why is this a goal? We cannot prevent demand shocks or growth approaching scalability limits, but we can and should help users understand what is happening and help them protect themselves.

Light Client Protocol Dovetailing

  • Github: zcash #3675
  • What is it? Alter the base consensus protocol to reinforce light client support.
  • Who does this affect? (Future potential) Zcash light client end users.
  • Why is this a goal? We anticipate more light client users than full node users in the future (all other things being equal), so any streamlining of this use case in the base consensus protocol is potentially valuable.

BOLT Support

  • Github: zcash #3676
  • What is it? Base consensus support for the BOLT second-layer protocol (see our introductory blog post).
  • Who does this affect? (Future potential) Users of BOLT-enabled light wallets.
  • Why is this a goal? Second-layer channel-based protocols may enable use cases that allow substantially more transactions with minimized capacity impact on the base consensus protocol. A direct BOLT integration with Zcash would have stronger privacy protections than existing second layer systems, which may be especially important if service providers centralize.

Retire Sprout Addresses

  • Github: zcash #3677
  • What is it? Turn off all support for Sprout addresses and funds stored at those addresses except the ability to transfer funds out of those addresses.
  • Who does this affect? Sprout users.
  • Why is this a goal? This removes technical debt and simplifies the ecosystem moving forward. Additionally it prompts usage of the Sprout→Sapling turnstile.

Rollback Protection and Hardening

  • Github: zcash #3678
  • What is it? Add protections against rollbacks larger than some predetermined length.
  • Who does this affect? All transactors, especially multi-user service providers.
  • Why is this a goal? All users would reject a large enough rollback. Some users would reject a smaller rollback. By codifying a well-known standard for the maximum acceptable rollback depth, we reduce economic uncertainty across the ecosystem. Other consensus features as well as external products and services can begin relying on this design decision. (Nuance: this does not answer the question of what people should or will do in the event of such a rollback. It simply ensures that no one will naively or accidentally proceed in a business-as-usual manner in this event thus protecting them from harm.)

Custodian Reinforcement

  • Github: zcash #3679
  • What is it? This includes a variety of potential features that can potentially protect typical end-users as well as specialized custodians. This may include recipient address verification, “vault functionality”, “I Got Burgled Button”, transaction cancellation, or transfer rate limiting functionality.
  • Who does this affect? All users.
  • Why is this a goal? A substantial weakness of cryptocurrencies is how difficult self-custody is for wide user bases. By introducing protocol features that can help users protect themselves against theft or loss and/or enable custodian providers to reduce their operational risk, we aim to make Zcash safer for a larger user base.

What’s Next?

I’m going to be making “feature requirements” github tickets for these goals, and then we will move the feature requirements gathering and feature selection processes into github.

After that, I’ll be working with Zcash developers (both inside and outside the Zcash Company) to work on feature requirements for specific goals, while we also begin a new “product validation” process. Additionally, I’ll be seeking out feedback from a variety of sources.

Scope

What about other upgrades, other potential goals, or non-consensus features? These are all out of scope for this early Blossom planning. That doesn’t mean they aren’t important!

We’re aiming to start longer ranging R&D for future upgrades in early 2019. As feedback and ideas flow in around Blossom goals, we might incorporate those into Blossom or later ugprades.

Additionally, there are key feature areas outside of consensus rules we plan to put on our roadmap, such as improvements to the networking layer.

Thanks and carry on with encrypting things,
Nathan

Edit 2018-11-14: Crosslinked to github tickets and the Blossom Goal github label.

27 Likes
2

How about deprecating transparent addresses?

Giving a year’s notice is plenty of time to prepare everybody.

6 Likes
3

Everything sounds great. I hope it all can be implemented in a year. I am wondering if Coda is going to be funded/integrated? Since ZCashCo is aiming towards light wallets it isn’t required as much I suppose, but maybe in the next upgrade cycle it can be included. Are there any other techniques where zk-SNARKS can be used for scaling on the main chain or is the best choice for scaling doing most transactions off-chain and making them private? I am wondering since I saw that Ethereum may use them for their scaling issues.

3 Likes
4
3 Likes
5

We’re not ready for that. The missing pieces include lack of shielded support for some common uses of scripts (especially multisig and hash time-locked contracts), and the dependence of coinbase transactions on t-addresses.

That said, we could include some preparations in this upgrade, for example enabling payment of mining fees, block rewards, and maybe FR directly into Sapling addresses. There is also a possible method of supporting shielded multisig without a further consensus change, taking advantage of the fact that RedJubjub is a Schnorr-based signature scheme. Shielded HTLC support is more difficult because I think it requires a circuit change, but it probably wouldn’t be a blocker on its own for deprecating t-addresses.

If all goes well, I would expect that the next upgrade after Blossom, in 2020, would be a good candidate for disabling sending to t-addresses (but you could still send from them). This is purely my personal view; it is not something we’re committing to, and I haven’t discussed it with other Zcash engineers.

13 Likes
6

Coda-style succinct blockchains are something I’m very enthusiastic about and I’m actively researching how to integrate that in Zcash, but they’re way out of scope for Blossom.

13 Likes
7

By the way, there are “Blossom wishlist” and “NU3 wishlist” tags on GitHub that may give an idea of what is and is not feasible. (NU3 is the temporary name of the upgrade after Blossom.) They haven’t been updated to reflect the feature goals Nathan outlined, but we’ll be doing that soon.

4 Likes
8

LOVE Zcash!!!

5 Likes
9

I have my doubts that harmony mining will be a success or even work out, at least not for the average joe asic/gpu miner. October 2019, about 1 year from now, my prediction is that personal private POW mining won’t excist anymore …

2 Likes
10

Why dont do some research on POS to eliminate 51% attack. This is something to concern as zcash is also in the list : Calvin Ayre and Craig Wright Allegedly Plan to Attack BTC, ETH, All Cryptos – Trustnodes

2 Likes
11

@labus Zcash uses a completely different algorithm than BTC or BCH so getting enough hashrate to 51% attack Zcash isn’t easily done.

That said, I think the idea of dual PoW is cool if it can be done safely.

And I’m :100::100: excited to see BOLT integration, has J. Ayo Akinyele seen this plan? He just got the Grant from the Zcash Foundation to work on it, I hope the core team will be working with him on this.

8 Likes
12

What on earth is wrong with (some) BCH people? Their ABC/SV fork is not even about technical issues worth fighting over.

2 Likes
13

Lol, Im just a laymen person and dont really understand technical so we believe what is published news.

14

[Moderation edit by @daira: restored more context to the quotation.]

We haven’t committed to a timeline or the requirements for deprecating t-addrs within the company. OTOH, we have agreed to deprecate t-addrs someday. So that’s a good first step in that direction.

6 Likes
15

I sort of think of the approach Coda takes as if it’s “making all light wallets into full nodes” and erasing the need for a distinction. That is truly awesome!

We’re definitely interested in that potential and learning about it. However, it would require more time to do something like that well for Zcash than the Blossom timeline. Remember, this post doesn’t cover our plans past Blossom. Hopefully in early next year we’ll have longer term R&D efforts underway and we can share them at that time.

5 Likes
16

What details contribute to your doubt?

1 Like
17

“If you build it, they will come.”

1 Like
18

Starting to look like a cult to me. It’s about the people and not the coin/design goals/adoption. Just because “Satoshi” designed it doesn’t mean it can’t be improved upon.

19

My prediction is that as soon as ETH goes POS, i guess it will be latest in 1 year as well, private POW gpu mining comes to it’s end, there are no coins and algos that can take all this hashrate.
For the POW asics, we (me included) will maybe able to mine some months more until new and more batches are released and than we come to the point where mining makes no more sense after hardware will never ROI. Have in mind that Batch 3 allready won’t ROI. This said, as many times in other posts, i don’t think private POW mining will survice until 2020 … hence i doubt the double ALGO Harmony change will favour us private miners, but only very low electricity facilities, both, gpu and asics…

We will see if my prediction is right…

2 Likes
20

It seems to me that Harmony Mining is just as a challenge as Succint Blockchains? Is there anything in particular that the team is worried about the concept that you don’t think it’s resolvable in a one year time frame?

1 Like