We’d be glad to coordinate with you on that.
1 Like
1 Like
Is reviewing other new consensus features part of the contract with Eiger?
You’ve got it backwards. Nobody has built a bridge to bring other assets to Zcash because Zcash doesn’t have the functionality to handle other assets. It would be a bridge to nowhere. ZSA adds that functionality.
I don’t think that’s a compelling story. Back when I was at ECC, I met with a huge bank who wanted us to build them a blockchain for stablecoins with Zcash-style privacy. Their principle concerns were scalability, low fees and reasonable speed.
I agree that minimizing the frequency of transaction format changes is desirable.
1 Like
I disagree. This is simply a question of priorities, being responsible w.r.t complexity risk, and avoiding another situation like NU5 (which was delayed by 10 months, if my memory serves me correctly).
ZSAs are being mentioned because both ZSAs and the NSM are non-trivial changes, and trying to do them in the same network upgrade is riskier than doing them separately. If it goes wrong, the network could halt (i.e. no blocks being mined, no transactions could be sent, no deposits into or withdrawals from exchanges) until a fix is implemented, tested, deployed, and the network is restarted, which could take days, maybe weeks. Zcash’s reputation has already been negatively impacted by the sandblasting attack.
This is about trade-offs and priorities. Move fast and maybe break Zcash vs. move a bit slower to minimize the risk of catastrophe. There’s no right answer, only the benefit of hindsight after the fact.
4 Likes
Why isn’t the DEPLOYMENT_BLOCK_HEIGHT specified in ZIP 234? The ZIP specifies it “to be the lowest height after the second halving at which the NSM issuance would be less than the current BTC-style issuance neglecting any burnt ZEC (i.e. assuming the amount of ZEC burnt is exactly 0).”
Shouldn’t it be possible to calculate that now? Or am I missing something?
My primary concern is minimizing the risk of further delays to ZSA deployment, so I’m (personally) not in favour of deploying both ZIP 233 and ZIP 234 in NU7.
In my ideal world, NU7 would ZSAs only but I grok the need to bundle transaction format changes together, and I also see the benefit of sending issuance fees into the NSM (although I’d also be fine with sending them to a lockbox and decide later). Progress over perfection.
I would like to know more about this 
before deciding whether to commit to deploying ZIP 234 in NU8:
How much does it pull forward the issuance curve?
There seems to be conflicting opinions here:
I’d like to see some graphs showing how the issuance schedule is impacted by activating issuance smoothing at different points throughout the halving cycle.
For the record, here’s my (personal) assessment of the ZIPs that are proposed for NU7, based on the information available to me at this point in time:
Jason, what do you mean by (paraphrasing) “open to compromise”? What would need to happen for you to withdraw ZIPs 234 and 235 from consideration for NU7?
3 Likes
Great point!
1 Like
Thank you. I completely forgot about this due to Thanksgiving. Hope more watch it.
Good leadership @Dodger !
Good questions , keep your focus on the top priority.
Blockchain Confidence
1 Like
Eiger is contracted to handle the integration of the NSM into a network upgrade. The contract covers both zcashd and zebrad implementations. Since only zebra is relevant, we should be able to reallocate resources to review other new consensus features and help lighten the load for ZF and ECC engineers.
Looks like the block height didn’t make it into the ZIP. That’s my oversight. The relevant deployment block height for ZIP 234 is 3,518,072. That block height is the crossover height between the second (block 2,726,400) and third (block 4,406,400) halving.
See calculation from @shielded-nate:
We’ve developed a simulator that allows you to visualize the impact of smoothing the issuance curve. We can provide graphs that show how the issuance curve is affected when smoothing is activated at various points in time.
This is currently under discussion. I will address your question in a separate post later today.
Thanks.
3 Likes
I gave it a shot. What if:
- Don’t bundle the NSM with the regular unissued funds; track the balance of the deposited funds separately
- Each block after NSM activates, issue 0.0000004126 (as in ZIP-234) of the current NSM balance in addition to the regular (non-smoothed-out) issuance.
This gives us NSM issuance without smoothing out overall issuance. (Unless I’m missing something.)
1 Like
The graph you’re asking for is literally in the ZIP
1 Like
That plots the issuance curve assuming it’s activated at a network upgrade. I guess the way the math works out, the curve stays the same regardless of when exactly it’s activated, but I don’t think that has been strictly shown.
Hi all.
@aquietinvestor and I spoke at length about the ZIPs and the specifics about why I expressed concern. We talked about different options that I then raised with the ECC core team just ahead of the regular ZIP Editors meeting. They asked me to join them in that meeting along with Arya.
After some discussion about the pros, cons and implications of the ZIPs and their interrelation to ZSAs, we landed on three options to propose back to Shielded Labs.
Option 1 (“As is”): Keep all the NSM ZIPs in but delay the NU7 ZIP finalization date to allow for further conversations on issuance smoothing and burning (ZIPs 234 and 235).
Option 2 (“Withdraw”): Withdraw ZIPs 234 and 235 from NU7 now.
Option 3 (“Continue but Confirm”): Keep all the ZIPs, do not delay NU7 finalization, Shielded Labs would continue development on these ZIPs with the code for ZIP 234 and ZIP 235 behind feature flags. ZIP 233 will be included regardless. Shielded Labs would have until Testnet activation (currently scheduled for the beginning of March) to demonstrate clear community consensus that ZIPs 234 and 235 are desired. If there is no clear consensus, the features would not be activated on Testnet or in NU7. At that point, we should also have a more clear understanding if this would also have any impact on the NU7 activation date.
Jason, how do you intend to proceed?
10 Likes
For community members unfamiliar with the concept, a feature flag is a mechanism that allows specific features to be turned on or off under certain conditions. In the context of NU7, this means that features related to ZIP 234 (smoothing the issuance curve) and ZIP 235 (burning 60% of transaction fees) would remain turned off for both testnet and mainnet until Shielded Labs can demonstrate clear community consensus in support of these protocol-level changes.
We have decided to develop ZIP 234 and ZIP 235 behind two separate feature flags. For ZIP 234, our goal is to demonstrate clear community consensus for its inclusion in NU7 by the testnet activation date, currently scheduled for March 1, 2025. ZIP 235 will be developed behind a separate feature flag to allow testing of a precursor to a consensus-level change, where the node software defaults to burning 60% of transaction fees. If, after mainnet activation and a period of testing the node update, the community decides to support a consensus rule change for ZIP 235, the feature flag can then be activated.
Shielded Labs will take the lead on implementing the feature flags, performing the integration and testing work for the NSM, and resolving any merge conflicts that occur when other features, such as ZSAs, are merged with the NSM.
12 Likes
I’d like to start a discussion on ZIP 234, which introduces a mechanism to systematically issue ZEC into future block rewards, along with the alternative proposal put forward by @conradoplg. My goal is to evaluate the benefits and drawbacks of both approaches and ultimately recommend ZIP 234 as the simpler and straightforward method.
The primary objective of the NSM is to create an automated system that allows users to contribute to the long-term sustainability of the Zcash network. As part of this process, ZEC is burned through ZIP 233, and new ZEC is issued into future block rewards based on the amount burned. ZIP 234 smooths the issuance curve, enabling ZEC to be introduced into circulation in a predictable and straightforward manner. The issuance follows a simple rule: for each block, compare the current supply to the 21 million cap, and issue a small proportion of that difference. The design approximates a four-year half-life, similar to the current halving cycles, ensuring a gradual allocation of coins over time.
The alternative proposal contends that instead of smoothing out the issuance curve by distributing new ZEC over time, we could track the NSM balance separately from the unissued funds. Under this proposal, each block after the NSM is activated would issue a small fraction of the current NSM balance in addition to the regular, non-smoothed issuance. This would allow for NSM issuance while preserving the regular halving schedule and avoiding the smoothing effect.
On the December 12th Arborist Call, Conrado stated that the main benefit of this approach is that it prevents unexpected changes to the issuance process that could confuse users. For example, it helps avoid discrepancies in the reported current supply on platforms like CoinMarketCap and CoinGecko, while still allowing the NSM to function. Both ZIP 234 and the alternative proposal introduce changes to the issuance process that could create confusion. The solution to this issue is to educate exchanges and platforms like CoinMarketCap and CoinGecko on how to accurately report the current supply of ZEC, specifically by using “valuePools” in the getblockchaininfo RPC for zcashd (or the Zebra equivalent) to properly reflect the circulating supply.
Another drawback of the alternative proposal is that, while it preserves halvings, it adds complexity by maintaining two separate categories of unissued ZEC. In contrast, ZIP 234 simplifies the process by treating unissued ZEC as a single category, helping reduce potential confusion. As I mentioned in a recent Forum post, there is no direct connection between burned ZEC and new coins issued in future block rewards. Since ZEC is fungible, burned coins are not “reissued”. However, under the alternative proposal, burned ZEC is tracked separately from unissued supply, conflating the distinct processes of burning and issuance. Rather, coins burned through ZIP 233 or other methods reduce the circulating supply, and ZIP 234 allows new ZEC to be issued in a systematic manner that approaches, but never exceeds, a total supply of 21 million.
Zcash’s issuance schedule was inherited from Bitcoin, and halvings represent a legacy feature that has carried over from the past. In some sense, halvings are valuable as a tradition and ceremonial event. For Bitcoin, halvings have become significant milestones, where the reduction in supply is often accompanied by increased market attention and price growth, signaling the next leg of a bull run. These events are celebrated within the Bitcoin community as symbols of progress and scarcity. However, the bull market sentiment and price increases that are commonly associated with Bitcoin halvings have not been as prominent for Zcash.
In my opinion, what truly matters for Zcash is not the halving cycles themselves, but the 21 million coin cap, which is sacred and non-negotiable. ZIP 234 is designed to maintain the integrity of the network’s supply and ensure that the issuance of ZEC never exceeds 21 million coins. It offers a straightforward solution by approximating the current four-year half-life that exists in halving cycles. This design provides a simple and predictable issuance model without the complexities introduced by the alternative proposal. My personal belief is that ZIP 234 is the better option for the NSM. I encourage the community to share their thoughts and feedback on ZIP 234, as well as their perspective on the importance of halvings for Zcash.
3 Likes
I support moving to any smoothing mechanism and moving away from standard halving for one simple applied reason. Historically, halving Zcash closes the list of halving the most popular old-school coins for which 95% of all ASICs are currently issued: Litecoin, Bitcoin, and Zcash.
By the time the Litecoin and Bitcoin halvings have taken place, the Zcash halvings are still to come. Private miners (individuals and companies) prefer not to take risks and order equipment with a clear payback period. And they give preference to ASICs for Litecoin and Bitcoin. Halving always introduces a big risk for miners. Moreover, Zcash has miners getting 80% and there is a PoS transition planned ahead, which was announced in 2021, but no exact timeframe was mentioned and that’s why miners wait for it every year. All of these things mattered. Compare the hashrate graphs of the three coins and everything will be obvious. And it’s the intangible little things that make up the successes and failures.
This issue is much more fundamental (it can’t be resolved without a smoothing curve) than what CoinMarketCap publishes (it can be resolved by giving them an official tool). By the way CMC has been publishing (since Blossom was activated) misleading information for 6 years in a row.
We need to make coin issue more economically predictable for miners. And make Equihash ASICs more attractive for miner purchase decisions.
We should not neglect this issue. I am still convinced that the involvement of more participants in mining has a positive effect on the popularity of the coin.
5 Likes
Agreed. Halving is disruptive as it suddenly halves potential income for miners. Also, based on the 1st and 2nd halving, we can assume that halving did not have any significant positive impact to the market price of ZEC (miners income).
2 Likes
I believe that’s not true. Nodes already don’t need to keep track of unissued ZEC (they issue a fraction of the maximum block subsidy, which doesn’t require keeping track of the total unissued ZEC). In my proposal they would need to keep track of deposits into NSM; in the original they would need to keep track of all unissued + deposits. In both cases they would need to keep track of a single thing.
(As explained by Paul Dann in the latest Arborist Call, the current design of the NSM doesn’t need to keep track of “deposits” into the NSM because they handle “deposits” into the NSM as regular spends without outputs if I understood correctly. So it’s true that in my proposal it would be required to keep track of something else. Regardless I need to review the latest changes to the NSM ZIPs)
3 Likes