It moving in the right direction. Now we just need to take the centralization out. its a little bit of a land grab. One more gatekeeper. We need the money to go directly to the developers. And as far as I can see there are 4 important groups today; but there could be more in future as more assets come online.
Creator of the transaction via a mobile wallet or otherwise. Market forces should determine the fee structure for the use case. There will probably be many based on volume, security, etc et. The developers should fund their own ideas and expect to get a large % of the gas. EG apple gives the developers 70%. I dont know if this is the right number. But its a placeholder.
The Foundation. They get a % for the blockchain upgrades and improvements and maintenace etc.
ECC - if ZEC is used in the transaction they get a fee. But if there was a stablecoin, they would not. ECC only gets paid on ZEC transactions. There might be other new organizations who create new assets. And when there are transactions in their respective coins, they get a cut.
Miners/Stakers - they get a cut. So if ZEC was staked, ZEC holders get income for staking and this relates to all future L2s on the blockchain. I think ECC could get a cut of the income here as well as I dont expect ZEC to be a high transaction volume coin.
We all know Visa charges around 3%. So anything higher than this probably wont work. But maybe 2% works to sustain the ecosystem? Someone would just need to do the math based on the costs and volume. All I know is that block rewards doesnât seem to align incentives and it creates more beaurocracy. So the main solution so far is to just create more beurocratic agencies rather than fully decentralize development. Am I missing something?
I think this is a necessary and intriguing concept. I noticed that some people are confusing the ZSF with the Dev fund - we need to make sure the whole community is completely up to speed re. these things being two completely separate concepts and mechanisms.
As i understand it the current block reward system that exists in Bitcoin and blockchains forked from Bitcoin has a finite lifespan as a self sustaining network in terms of the ability to secure the network via miners receiving consideration by way of block rewards in exchange for the work/energy they expend processing transactions/adding blocks to the chain.
It sounds like the ZSF is an innovative proposal for how zcash can develop a mechanism to enable the blockchain to secure the network/incentivise participants to continue securing the network in perpetuity, long after the last ZEC or BTC are currently set to have been mined in their respective blockchains. Unlike the somewhat divisive issue of the dev fund, ensuring a mechanism for the long term viability of the zcash network is not something that should really become a âpartisanâ issue- all network participants need the community to find consensus on how to ensure that the project is viable long after the 21millionth ZEC has been mined into existence. Currently there is no plan in place to ensure either Bitcoin or Zcash could continue to function after that point of the final block issuance and while the ZSF is not to be confused with the dev fund, nevertheless we should note the fact that we in the zcash community now have been handed what seems to be a workable, eminently credible proposal for how to prepare for the future; and we have the dev fund and the dev fund recipients to thank for this - whereas Bitcoin, with no devfund, has not even begun to grapple with its own identical existential threat.
So whilst the ZSF is something quite distinct and not to be confused with the dev fund, i would urge the community to consider the fact that these kind of proposals and necessary network upgrades and the lateral, outside the box thinking of zcash community members and teams funded by the dev fund are the reason why we need the dev fund itself as this kind of proactive forward thinking vision is exactly what will enable zcash to remain at the forefront of the arms race of technological innovation in what is still an embyronic industry, whilst also becoming increasing decentralised as a global project.
I also really like the fact that this proposal seems to offer mechanisms to dove tail with the work being done to bring ZSAs to the world and in general this sounds very forward thinking and in keeping with the long term road map that Zcash has set out.
I defer to other peopleâs infintely deeper understanding of the technicals re. how this will all work, but the principles seem sound and the need for a workable solution is clear and unambiguous.
I do like the idea of stopping the block rewards as the funding source. We certainly agree on this point. And, I also cant see why there is a major issue with an option to pay into the PF. Except, its a little bit of a slippery slope because to give fair access to charitable groups, then Iâm sure other funds will want equal access so people can choose which charitable cause they will support. Does the PF get a monopoly on access to donations? The fairest and most direct way to move forward after block rewards funding ends is gas. If people who most like and need ZEC as private money are not willing to pay gas, its highly unlikely they will choose to pay and optional donation. And if the majority of people donât choose pay, it just puts a heavier burden on the people that do choose. Itâs too heavy a burden and needs to be spread out and pushed down to the actual users via gas fees. So, I will keep pounding the table that the best way forward for a long term solution is a sustainable ecosystem built around gas. We need a âSUSTAINABLE ECOSYSTEM PROPOSALâ where the source of funding is gas and not dilution that is designed for decentralized development. My preference would be to keep the existing structures we have a) The foundation-focused on the blockchain and b) ECC-focused on ZEC. But improve governance. Once governance is improved via a voting mechanism for ZEC holders, real change can happen fairly quickly. It wont be an ad hoc, he said she said. And then to get elected, people should have to present their vision and plan; and stick to it. If people want to go in your direction; just vote to change course. If we have yet another organization; it just makes governance that much more difficult. So, before we hear any proposals about anything, we should first have a an objective reliable, and verifiable voting system in place so ZEC holders decide.
Below is the first draft of our second ZIP to smooth out the block subsidy issuance curve. We invite you to review it and provide your thoughts, feedback, and suggestions. Please post your comments to this thread or DM me if youâd prefer to provide feedback in private.
There will also be a third ZIP that establishes a fee structure that can be used to fund the ZSF. Weâre currently researching a couple different options and hope to post the ZIP early next week.
Zcash Improvement Proposal (ZIP)
Title: Smooth Out the Block Subsidy Issuance
Owners: Jason McGee, Mark Henderson, Tomek Piotrowski, Mariusz Pilarek
Credits: Nathan Wilcox
Status: Draft
Category: Consensus
Created: August 2023
License: BSD-2-Clause
Terminology
The key words âMUSTâ, âSHOULDâ, âSHOULD NOTâ, âMAYâ, âRECOMMENDEDâ, âOPTIONALâ, and âREQUIREDâ in this document are to be interpreted as described in RFC 2119. [1]
âNetwork upgradeâ - to be interpreted as described in ZIP 200. [2]
âBlock Subsidyâ - the algorithmic issuance of ZEC on block creation â part of the consensus rules. Split between the miner and the Dev Fund. Also known as Block Reward.
âIssuanceâ - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network.
âWeâ - the ZIP authors, owners listed in the above front matter.
âAVAILABLE_SUBSIDIES(h)â is the total ZEC available to pay out Block Subsidies from at block height h, ie. ânot yet mined ZEC at hâ.
âBLOCK_SUBSIDY_FRACTIONâ = 41 / 100,000,000 or 0.00000041
Abstract
This ZIP proposes a change to how nodes calculate the block subsidy.
Instead of following a step function around the four-year halving cycle inherited from Bitcoin, we propose a slow exponential âsmoothingâ of the curve. The new issuance scheme would approximate the current 4 year cycle, and results in the last zatoshi being spent in around 113 years.
Motivation
Zcashâs economic model is inherited from Bitcoin and includes the concept of a halving mechanism to regulate the issuance of new coins. This approach, though foundational, invites a reevaluation amid Zcashâs ongoing evolution. As the network matures, the need to address potential future challenges and ensure a sustained and stable economic ecosystem becomes apparent. The transition to a smoothed emissions curve offers an opportunity to adjust the networkâs issuance dynamics while maintaining the supply cap of 21,000,000 coins. By doing so, Zcash endeavors to optimize its economic framework, accommodating changing circumstances while maintaining predictability and stability in rewards distribution.
This proposal outlines a solution to address challenges associated with the existing block subsidy issuance mechanism in the Zcash network. The primary goal of this proposal is to introduce a more predictable and stable issuance of ZEC by smoothing out the issuance curve while preserving the supply cap. Itâs important to note that this proposal does not seek to alter the fundamental aspects of Zcashâs issuance policy. The average block subsidy size over time will remain the same and the funds for block subsidies will last a similar amount of time. Instead, it focuses solely on enhancing the predictability and consistency of the block subsidy issuance process.
Smoothing the emissions curve helps ensure that the network remains economically viable and stable as it transitions from a traditional issuance mechanism to one that maintains a sustainable and predictable issuance of rewards over time. It prevents abrupt changes in the rate of newly issued coins, which could lead to disruptions in the networkâs economic model and potentially impact its security and sustainability. A smoother emissions curve allows for a more gradual and controlled transition, providing ZEC stakeholders and participants with a clear understanding of how rewards will be distributed over time.
Specification
Smoothing the issuance curve is possible using an exponential decay formula that satisfies the following requirements:
Requirements
R1: Block subsidies MUST be weakly decreasing.
R2: Block subsidies SHOULD approximate a continuous function.
R3: When AVAILABLE_SUBSIDIES(h) > 0 then block subsidies for block h MUST always be > 0, preventing a final âunminedâ zatoshi.
R4: For any 4 year period, all paid out block subsidies MUST equal approximately half of AVAILABLE_SUBSIDIES at the beginning of that 4 year period.
R5: This functionality MUST be introduced as part of a network upgrade.
The above requirements assume no deflationary action, i.e. that no ZEC is added to AVAILABLE_SUBSIDIES.
Solution
Given the block height h define a function S, such that:
S(h) = Block subsidy for a given h, that satisfies above requirements.
Please note that:
AVAILABLE_SUBSIDIES(h+1) = AVAILABLE_SUBSIDIES(h) - S(h) assuming no deflationary action.
An exponential decay function S satisfies R1 and R2 above:
Meaning after a period of 4 years around half of AVAILABLE_SUBSIDIES will be paid out as block subsidies, thus satisfying R4.
Other Notes
The suggested implementation avoids using float numbers. Rust and C++ will both round the result of the final division up, satisfying R3 above.
Appendix: Simulation
We encourage readers to run the following Rust code, which simulates block subsidies. According to this simulation, assuming no deflationary action, block subsidies would last for approximately 113 years:
Rust Code
fn main() { // approximate available subsidies in August of 2023 let mut available_subsidies: i64 = 4671731 * 100_000_000; let mut block: u32 = 0;
while available_subsidies > 0 {
let block_subsidy = (available_subsidies * 41 + 99_999_999) / 100_000_000;
available_subsidies -= block_subsidy;
println!(
"{} ({} years): {}({} ZEC) {}({} ZEC)",
block, // current block
block / 420_768, // ~ current year
block_subsidy, // block subsidy in zatoshis
block_subsidy / 100_000_000, // block subsidy in ZEC
available_subsidies, // available subsidies in zatoshis
available_subsidies / 100_000_000 // available subsidies in ZEC
);
block += 1;
} }
Last line of output of the above program is:
47699804 (113 years): 1(0 ZEC) 0(0 ZEC)
Note the addition of 99,999,999 before division to force rounding up of non-zero values.
Thank you for submitting this ZIP for the ZIP editors to review.
The ZIP editors finished their initial content review of the first sustainability fund ZIP today. This ZIP focuses on deposits to the fund, and accounting for the fund balance.
Here are some key points from the review:
Most of our comments are about how ZIPs usually specify changes, or making the specification more precise. Please donât be concerned by the number of comments!
We found some parts of the ZIP motivation that might be more relevant to the issuance ZIP.
We noticed a missing specification for the ZSF deposit field in coinbase transactions, and suggested some changes that would be compatible with the goals of the ZIP.
We agree that there should be some kind of consensus commitment to the sustainability fund balance in the node state, but weâd like to delay deciding on the final details until we know which ZIPs will be included in the same upgrade as this ZIP. The ZIP editors are happy to draft this change at that time.
The ZIP editors are also responsible for updating the detailed specification of the consensus rules, so itâs ok to just have a summary in the ZIP.
There are a few minor suggestions that are still pending, but they shouldnât impact your work. Please feel free to make revisions, and let us know when youâre done in the #zips channel on Discord.
Weâll have a few editors look at the ZIP in detail after youâre done with the content changes. Usually we tweak the precise terminology and wording, section order, formatting, typos, and other minor fixes. (We tried to cover all the substantial changes in the initial review.)
Thank you again for working on Zcash protocol changes!
Under this assumption that âhalfâ per four year cycle, from Bitcoin, is a perfect magic rate, we can assume that practically speaking all ZEC will be emitted around year 2135-2140.
Should we debate that perhaps only âone quarterâ (or even âone eighthâ) could be more preferable? That would allow for ZEC to be emitted for an additional ~110-115 years (or 225-240), meaning the last Zatoshi arrives in 2245-2250 (or 2350-2360).
I donât plan on being around long enough to witness the Last Zatoshi, but I do tend to wonder if the current ~110 year emission duration is enough? I will assume here that humankind will be hoping to be surviving and thriving (and enjoying privacy) for many more than just 100 or 200 years. In that case, do we really want all ZEC to have been emitted so quickly?
Below is the first draft of our third ZIP, which directs a portion of transaction fees to the Zcash Sustainability Fund. We invite you to review it and provide your thoughts, feedback, and suggestions. Please post your comments to this thread or DM me if youâd prefer to provide feedback in private.
Please note that the transaction fee split is not final and may change based on feedback from the community and ZIP Editors.
Zcash Improvement Proposal (ZIP)
Title: Deposit 50% 60% of Transaction Fees to the ZSF
Owners: Jason McGee, Mark Henderson, Tomek Piotrowski, Mariusz Pilarek
Credits: Nathan Wilcox
Status: Draft
Category: Ecosystem
Created: September 2023
License: BSD-2-Clause
Terminology
The key words âMUSTâ, âSHOULDâ, âSHOULD NOTâ, âMAYâ, âRECOMMENDEDâ, âOPTIONALâ, and âREQUIREDâ in this document are to be interpreted as described in RFC 2119. [1]
The term ânetwork upgradeâ in this document is to be interpreted as described in ZIP 200. [2]
The term âBlock Rewardsâ refers to the algorithmic issuance of ZEC to every blockâs creator â part of the consensus rules.
âIssuanceâ - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network
âWeâ - the ZIP authors, owners listed in the above front matter
âZSF_BALANCEâ is balance of the Zcash Sustainability Fund as defined in ZIP
Abstract
This ZIP proposes a modification to transaction fees, diverting 50% 60% of transaction fees back into the ZSF_BALANCE, while the destination of the remaining 50% 40% is unchanged and goes to the block miner. This proposal effectively âunmintsâ a portion of transaction fees, contributing to a deflationary effect and offering long-term support for the Zcash network.
This ZIP attempts to establish a symbiotic relationship between miner incentives and sustained network growth. It achieves this by splitting transaction fees: 50% 40% goes directly to miners, incentivizing them to include transactions, while the remaining 50% 60% is deposited into the ZSF_BALANCE. This approach mitigates a âbootstrapping problemâ, a problem that arises when 100% of transaction fees go to the ZSF and miners are not incentivized to include transactions in block. This ZIP navigates this problem by ensuring miners continue to receive direct rewards for including transactions, while still contributing to the ZSF.
Implementing this change allows the ZSF to accrue value earlier. By ensuring a consistent source of funding, the ZSF contributes to bolstering the Zcash networkâs long-term security and sustainability.
Motivation
While ZIP-XXX (Establishing the Zcash Sustainability Fund) describes a method by which funds can be added to the Zcash Sustainability Fund by a voluntary ZSF_DEPOSIT transaction field. The default value of this field is zero and it is left up to the app and wallet implementers to make use of it.
This ZIP takes a much more explicit and non-optional approach, mandating at the protocol level that 50% 60% of transaction fees be deposited into the ZSF As noted above, implementing this change allows the ZSF to accrue value earlier and contribute to future network sustainability.
This system currently looks something like this:
At Every New Block:
ZSF_DEPOSIT amount is deposited into the ZSF_BALANCE
Miner rewards come from ZSF_BALANCE
Transaction fees (inputs - outputs) paid to miner
After the features described in this ZIP are activated (changed parts in bold):
At Every New Block:
ZSF_DEPOSIT amount is deposited into the ZSF_BALANCE
Miner rewarded from ZSF_BALANCE
50% 40% of transaction fees (inputs - outputs) paid to miner
50% 60% of transaction fees deposited into ZSF_BALANCE
This has a multitude of benefits:
Network Sustainability: This mechanism involves temporarily reducing the supply of ZEC similar to asset burning in Ethereumâs EIP-1559, but with potential long-term sustainability benefits as the redistribution of deposits contributes to issuance rewards and network development, making it an attractive option for current and future Zcash users.
Ecosystem Benefits of Longer Time Horizons: A reliable and long-term functioning Zcash blockchain allows users to make secure long-term plans, leading to a sustainable and virtuous adoption cycle, rather than being influenced by short-term trends.
Incentivizing Transaction Inclusion: By providing a 50% 40% share of transaction fees to miners, this ZIP maintains incentives for miners to prioritize including transactions in their blocks. This helps ensure the efficient processing of transactions and supports a robust and responsive network.
Future-Proofing the Network: Diverting transaction fees into the ZSF_BALANCE is a forward-looking approach that prepares the Zcash network for future challenges and opportunities. It establishes a financial buffer that can be instrumental in addressing unforeseen issues and seizing strategic advantages as the Zcash ecosystem evolves.
Specification
This ZIP only proposes a single modification to the transaction fees:
Keep the current destination of 50% 40% of the fees untouched, but route 50% 60% of the fees back to ZSF_BALANCE
Please note that a network upgrade is required for this work to be fully implemented.
Transaction fee routing requirements
For each transaction, 50% 60% of the total fee MUST be paid to the ZSF_BALANCE.
The minimum of the 50% 60% fee MUST equal 1 zatoshi or more.
Rationale
We believe that is ultimately a very minor change to the protocol, and quite simple in terms of implementation overhead. Additionally â and at the time of this writing â transaction fees are so small that 50% will likely not have a major impact.
If transaction fees were to increase, future ZIPs can be written to change the 50%/50% 60%/40% split. Finding the optimal fee split may require an iterative approach involving adjustments based on real-world data and network dynamics.
In the future, other ZIPs may be written to fund the ZSF in various ways, including but not limited to:
ZSA fees
dApp-specific fees and donations
âStorage feesâ for any future data availability
Can you explain why you settled on the 50/50 split? (If you already mentioned why please help me find those notes )
Using ECCâs 30-year vision as a basis, and to create less shock to miners, what about starting like this:
current year 29 28 27 26 30-k
---------------- : --, --, --, -- , ... , ---- where k is â N
30 year goal 30 30 30 30 30
This decreasing sequence yields a percentage each year, or in terms of two sets, a ratio between miners and the PF.
We start off with k=1, 29/30 ~ 0.967 . This percent is the amount of FEEâs going to the miners. This means 1 - 0.967 = 0.033 will go to the PF in year 1. With k=2, we are in year 2 and thus decrease what the miners are getting. The math works out to 28/30 ~ 0.933. This means 1 - 0.933 = 0.067 will go to the PF in year 2. Eventually we will get to k=30, in the year 2053, and thus the miners would get 0, symbolic of hopefully moving to POS by that point.
The idea is to move the needle slowly over time in a clever way to prevent rapid change. The ratios can change depending on goals / needs / concerns.
Correct me if I misunderstood. But it seems that we are talking about 50% of all commissions, not issuance. That is about 4000 transactions per day multiplied by 0.0001 zatoshi ~ 0,4 ZEC per day. Are we sure weâre going to shock the miners with this?
Correct, the ZIP relates to transaction fees or commissions and not issuance. As @artkor points out, transaction fees are so small that diverting 50% to the ZSF should not shock miners. We originally wanted to propose a 90% to ZSF / 10% to miners split (as Nate discusses here); however, we felt that optically it might be misinterpreted as a harsh tax on miners. Again, since transaction fees are so small, even 90% going to the ZSF would very likely not shock miners.
A 50/50 split seemed like a fair and neutral way to split transaction fees. Weâre open to increasing the percentage that goes to the ZSF, but wanted to hear feedback from the community and ZIP Editors first. Basically, our objective here is to develop a modest version of the ZSF, and leave decisions about meaningful changes to deposits or disbursements for the community to decide at a later point in time after the ZSF is up and running.
My point is that thinking ahead, if we manage to scale the network with those recursions I read about in 2020 and manage to capture the market for shielded transactions with ZSA tokens, we will win the necessary volume by quantity, not by increasing the size of the commission. We need to get a lot of things planted in zcash for that to be enough. Will there be a source from the block reward?
why do we need a Posterity Fund? it seems like ECC/Foundation/EGC and then work to fully decentralize development with market based transaction fee structure would eliminate the need for another organization like the Posterity Fund.
why do we need it? transaction fees go directly to developers of L2 assets. they fund themselves. it zcash offers a transparent fee structure and even letâs them charge their own fees and we charge gas for L1. posterity fund is not needed
get rid of the middle men. fully decentralize development as much as possible.
I would like to see future funding and development decentralized where:
The Foundation is responsible for the L1 Blockchain
ECC is reponsible for the ZEC L2 asset (there might be some overlap with Foundation/ECC that gets worked out over time.
Open architecture that incentivizes third parties to build on the L1 blockchain at their own expense. All they have to do is pay the L1 gas (which includes miner costs, POS rewards, and other costs). But ultimately the gas is a function of market forces.
Here is a link to a very rough draft gas/TXN fee structure that would seek to decentralize funding and development while at the same time maintaining the Foundation/ECC roles. With proper governance we donât need anything more than the Foundation/ECC and with open architecture it could fully decentralize development beyond what any fund or organization can do. If third parties can understand the L1 fees they would have to pay, they can better gauge the risk of funding their own projects.
Isnt this how Ethereurm is structured? Am I missing something?
Isnt the solution to leverage the Zcash blockchain with more L2s (like stablecoins) where all L2s pay gas to the zcash L1 blockchain? Ethereum is dominating because they have decentralized the most, and scaled the use of the blockchain the best. A highly scaled blockchain results in lower costs. I think the answer is development, customer products, and decentralization. Not in diverting transaction fees to a âblank checkâ fund. Now the transaction fees are effectively $0 now. But if they ever become something, I think we want to just have them go directly to the people developing without a gatekeeper or middle man. Maybe I dont understand the posterity fund. But to me it looks like just another managerial layer as opposed to something tangible that I can see as a customer product that could potentially generate more transaction fees.
Nothing to do with governance, it just gives us a way to keep the 21 million limit idea alive. If we have enough transaction fees on PoS to sufficiently motivate validators and block producers - great. But right now we donât know for sure if it will be enough or not. That said, we have a large reward for block (emission) that looks reasonable with PoW, but in the case of switching to PoS, itâs excessive because in the absence of such operating security costs (PoW requires expensive hardware and a many of electricity) turns into pure inflation, which kills the price with excessive market supply. Weâll never be able to change the damn chart if demand is consistently below supply. Letâs low it and pen some of the current issuance for far periods when it will probably be catastrophically insufficient to motivate interest in steaking.
Why not call it a âblockchain special purpose stability fundâ if its purpose is only to ensure 21m cap is not breached and where it has no development, governance, or other purpose? Better define its goal is to not be to hold assets or otherwise capture any excess transaction fees that otherwise should be used by Foundation/ECC/ZGC for development purposes or future staking rewards .
)
