ECC Roadmap for Q2 2024

General
1

Hi Zeeps,

TLDR: we updated our roadmap this week for Q2. You can find it here, but if you want the juice, you’ll really want to read all the significant bits below. :wink:

Zashi Roadmap

image
image2725×872 220 KB

Potential Zcash Roadmap

image
image2725×663 109 KB

As I’ve highlighted elsewhere, ECC has moved to a quarterly planning cycle that includes a reassessment and refactoring of our roadmap. We spent last week working through the current state, market opportunities, and Zashi feedback; and then planning and estimating.

We are listening to you and inviting you in. Our next in-person get-together is in July. If you are working in the ecosystem and want to collaborate, apply!

Fluidity, assumptions, and dependencies

I’m stating the obvious, but our vision is better when the target is closer. We’re confident about this quarter, but it’s fuzzier longer out. For better or worse, we only see with human eyes. That’s why we need to reevaluate and refactor constantly.

There are also assumptions and dependencies here. For example, our work integrating gift cards in Zashi depends on a signed commercial agreement. In some cases, like ZSAs, the bulk of the development right now is being done by an independent team, Qedit, with our support. In other cases, like zcashd deprecation, ECC and ZF are sharing the work, so there are multiple dynamics at play, and good cross-team collaboration will be required up and down this plan.

Roadmap Details

The roadmap is divided into two main sections: Zashi, and the Zcash protocol.

Zashi Roadmap

The release of Zashi 1.0 for Android remains a top priority for this month, and we’ll work to bring the release times for iOS and Android closer together.

Zashi 1.1 (May)

ZIP 320 support: This introduces the new address type requested by Binance, which will only accept funds coming from a transparent address.

Currency conversion: This feature allows the Zashi user to see the current value of their ZEC or ZEC transaction in US Dollars.

User authentication for spends: This adds support for biometric or pin-based authorization for enhanced user protection.

We’ll also release Dark Mode (highly requested) and a few other UX improvements.

Zashi 1.2 (June)

Gift card purchases: We have been working with a third party to allow customers to purchase gift cards from various retailers. While we’re all highly motivated to make this happen, we are still working through contractual details and will update you.

Address rotation: This will allow users to generate new addresses in the wallet.

Spend quick controls: This UX improvement will allow the user to send a % of their funds up to the maximum amount without having to type it in and figure out fees.

Faster spend latency: This is related to how long you have to wait to spend funds. This one is a bit tricky, but we think we can handle a lot of it with changes in how we manage notes. Regardless of the ultimate solution, we are committed to reducing this friction.

Zashi 1.3 is lighter to allow for carryover work if necessary and to account for Q3 planning that month. As of now, it includes the ability to import viewing keys and various performance improvements to make things easier and faster.

Zashi 2.0 and 3.0

We are exploring this quarter, through research and partnership discussions, several possible candidates for Zashi 2.0 and 3.0. The timing of some of these things is based on dependencies. We’ll use that information in our planning with you in July! :wink:

Zcash Roadmap

We’ve broken this roadmap into Hybrid Consensus, NU6, NU7, zcashd deprecation, and additional R&D.

We’ve done our best to map out what we believe is possible. However, this is all subject to change based on community feedback and our development partners across the community. In fact, a number of us are meeting together tomorrow if you’d like to tune in.

Hybrid Consensus: We’re finishing up Design Phase 2 this month and plan to work on the Simulator in May and June. We’ll take a short R&D break from this in July to ensure we have adequate time for necessary NU6 and NU7 support before beginning prototype work in August.

In this section and across the others, we’ve added a concept called “Transient testnets.” We intend to start opening up early and ephemeral public testnets that anyone can use to test against new capabilities added to Zcash. If all goes according to plan, we’d like to start pushing Transient testnets for Hybrid Consensus as early as November.

NU6: We (all of us in the community) need to lock in development priorities for NU6 this month, assuming we intend to update in November. This does not mean we reach a consensus on the dev fund or its particulars. Technically, that one should be simple. However, we need to work through a set of candidate features quickly. Not all of these will likely make it. These options include a new transaction format to account for explicit fees and extending the memo field to support novel features such as ZSAs and liberated payments. Assuming all development is complete by the end of June, we should have enough time to activate in November.

NU7: We are making the assumption that NU7 is focused on ZSAs (Zcash Shielded Assets) and largely driven by Qedit, with support from us. Based on what we know to be true today, we believe they should be ready by April 2025. However, this timeline could be accelerated if they complete all circuit reviews and auditing earlier. If we get Transient testnets, this will allow us all to conduct more testing more quickly.

zcashd Deprecation: To move beyond the legacy Bitcoin codebase in zcashd, the community needs a stack of software that includes consensus nodes, parity with current RPC interfaces, and wallet support. The Zcash Foundation has built zebrad for consensus, but much work remains on the rest. We are proposing an RPC wrapper around a CLI wallet and will work with the foundation and others to move this along as quickly as possible. As ZSAs will not be supported in zcashd, this is a prerequisite for their deployment on Zcash.

Other: The ECC core team has a full plate, so for this quarter, we’ve limited additional R&D to Liberated Payments. This would allow Zcashers to send ZEC to others through secure messaging systems rather than using a specific address and might unlock some other cool capabilities we’ll revisit later.

As always, we welcome your feedback!

Onward.

12 Likes
2

Do you have a plan to alter the zec issuance schedule vis a vis the halving schedule? I would amend the JGx7 proposal to eliminate funding to any organization that seeks to change the ZEC supply issuance schedule such that ZEC issuance becomes greater than under the existing halving schedule. I hope your issuance smoothing on the roadmap doesn’t relate to increasing the issuance of tokens (at any point in time) relative to the existing halving schedule. This would be a value destructive idea (all else equal). On the other hand, if you are acknowledging ZEC inflation is too high and intend to reduce issuance (at every point in time) relative to the existing halving schedule :clap:. we have a major zec issuance and spending problem (otherwise know as tax and spend).

3

Good question. It’s the smoothing schedule proposed as part of the sustainability fund. It doesn’t change total issuance. It smooths out the halvenings.

The sustainability fund is something that Shielded Labs is working on, not us.

It’s a candidate for NU6 consideration, but my opinion is that the issuance schedule is something that requires a lot more thought and debate in the community.

2 Likes
4

it increases issuance at time 0 as proposed. its a terrible idea as proposed. now if they start at a point in time that results in lower issuance, it could be beneficial . But it’s clear to me at least, the goal is not to smooth out issuance, it’s to “pull forward” issuance. A zec positive smoothing would push back issuance while at the same time smoothing. I’m happy to help you smooth in a zec positive manner.

5

Cool. Look forward to reading your thoughts.

6

ZSA support in July… isn’t this mainly the concept of POS?

7

there is not much more to say. you either want to

a) get more issuance up front and lower issuance on the backend,

b) get less issuance up front and more issuance on the backend.

c) keep existing halving,

I personally think it should be removed from the roadmap because we don’t have zec holder voting and no org should be putting up a plan to benefit themselves by increasing more zec supply than uner the existing halving. I also think the org that puts forth the plan to increase supply at any point in time (next 4 years) vis a via the halving schedule should be de funded.

we have one or more people in the community setting forth org warfare proposals:

  1. increase near term zec issuance to dilute zec holders and give the extra money to ECC/ZCG
  2. take funding from the foundation and give it to ZCG/ECC
  3. take funding from miners and give it to ZCG/ECC

The theme seems pretty clear.

1 Like
8

Flexa integration still in the cards?

2 Likes
9

Yes! Good friends.

2 Likes
10

Hi and welcome. They are different things. ZSAs will allow you to shield other assets.

1 Like
11

I really appreciate the frequent updates and the granular, short-term roadmap that evolves with feedback. I think these are essential to build great software. Here are my opinions on priorities in brief.

Protocol

  1. Going all in on the Rust stack and improving the health of the codebase :+1:
  2. Consensus needs to be reformed. I don’t think this challenge is adequately represented in the roadmap. Proof-of-Stake, Hybrid consensus, adjusting/changing/revolutionizing the PoW. The distribution of the block reward needs to be reformed. I think there are huge improvements to be made but they will take a lot of thought and work. This should be invested in.
  3. General improvements, testnet improvements, zcashd deprecation :+1:

Health of the codebase, slashing of tech debt, general improvements, testnet, … I think preparing for NU6 without having too ambitious a scope is in order. But, I would put consensus reformation towards the top of the list otherwise - whether this is PoS or any other ideas. The guiding light for reforming consensus should be maintaining or improving security while vastly increasing the distribution and participation. This would be ambitious enough without much more.

Zashi

Focus should be on usability with pure ZEC and security.

  1. Security
  2. Performance
  3. Hardware support :+1:
  4. Recovery, usability of special features like viewing keys
  5. Staking, ZSA(s)
  6. Cross-chain, DEX, vault, mixnet, …

That list is a lot! What scope could be cut to get traction on all of that? In my opinion any 3rd-party fiat integrations, KYC services, gift-cards, Flexa, etc can be deprioritized. I don’t personally have use for any of these. I think people are doing a great job being able to sell their ZEC for fiat to buy Chipotle. Third-party processors could perhaps do the work if they want to provide an easy way for people to sell their ZEC. I don’t have anything against these integrations, if they are low-hanging fruit or the 3rd parties will do the work. But, there is enough work to do with the above list without going out of the way to integrate KYC’d gift cards only available in certain countries into the wallet.

I know that reforming the consensus and distribution is a hairy topic. But, I think it’s worth investing in it and making a change in NU6 or NU7.

Number priority is all-hands-on-deck to build the unified Rust codebase that hums, is super-convenient, amazing to work on with testnet stuff, and whatnot - that’s really enough to think about. If there is bandwidth left, next up is reforming consensus. Other features can get descoped for now, if needed IMO.

12

Gift cards have zero impact on the protocol, and my understanding is that they will not require any work in the core libraries either. They are just something you can buy with ZEC, with some Zashi frontend work to make it easier.

3 Likes
13

Note that no organisation currently funded by the dev fund is proposing this. It was proposed by Shielded Labs. Personally I don’t think it is disqualifying simply to propose it, and that it would set a bad precedent in general if mere proposal of controversial protocol changes were disqualifying for funding (presumably including grants etc.)

This is not making any comment on their smoothing proposal itself in my role as ECC’s R&D manager. It is on the shortlist because it has been proposed and is within the scope of what is technically possible (within complexity and engineering capacity constraints) to include in NU6, perhaps with parameter changes.

Speaking for myself (not ECC), I think that Shielded Labs has not made a sufficient case for it in the current draft.

2 Likes
14

I understand that the gift card stuff would be in Zashi and not in the protocol. But, my opinion stands that there are plenty of things to attend to with usability, security, performance, hardware wallets, viewing keys, etc and that focus on these 3rd party integrations would be the first to get cut from the scope. Again, if they are LHF and don’t distract from the other work that I consider more important then fine. But, Zashi’s simplicity is one of the strongest things going for it. Perhaps “less is more” - 3rd party integrations (especially centralized, KYC, not available to anyone in the world, etc…) would make me less likely to use a wallet.

1 Like
15

First, thanks for all the feedback! It’s helpful.

There are a few reasons things are prioritized, including dependencies and lead times, and the division of labor across front-end, back-end, and protocol. In the case of gift card purchases, it’s based on user research, feedback from the community at Zeboot, experience, and opportunism, and on the willingness of a potential partner to move forward quickly. It’s a relatively low lift technically, all front end, and will be an option that a Zashi user can turn on. It’s pretty cool and something I’ll use. :wink:

7 Likes
16

Do you mean made the technical case, to get their smoothening implementation into NU6? Or made the ideological case about why the smoothening is desirable at all; in NU6, or any other point in the future?

Based on the estimated issuance chart here, I’d advocate that smoothening is considered no earlier than ~November 2026. By that point, the existing halving issuance rate and the smoothening rate would be comparable near 4.5% and in the years that follow, the differences between how fast coins are issued would only have maximum divergences of about 1.5% at any given point (~4.5% halving compared to ~3% smoothening, for example near Oct-Nov 2028)

On the other hand, if the smoothening gets into NU6 it would have an immediate impact on ZEC issuance (annualized) in late 2024 through 2025 where the rate would be about 2-2.5% higher than what we all anticipate today if the halving is retained. (I’m estimating ~4.5% post halving issuance compared to ~6 - 7% issuance via the smoothening during late 2024 through most of 2025)

Excuse the poor markup:

image
image953×432 29.4 KB

3 Likes
17

Hi, everyone. The ECC roadmap has been updated. We’ll continue to tweak as we learn more and will release another update in Q3.

7 Likes
18

This update suggests that NU6 is on track, does that imply that the lockbox implementation will be complete by then (and ZEC would begin flowing in after NU6 activation)?

Is the lockbox work a joint effort (ZF & ECC) or will it be an ECC only item?

2 Likes
19

Yes, both ECC and ZF have the lockbox implementation more or less complete in open PRs. We are awaiting the results of the final poll in order to configure what streams (direct funding and lockbox) will be released, but at this point it’s essentially just configuration (modulo PR review & testing.)

The ECC and ZF engineering teams have been collaborating on this effort.

15 Likes