Posting here for visibility
1 Like
Interesting stuff here as well:
1 Like
That seems weird. I wonder if they are computing the fees correctly.
1 Like
@dismad You were just working on this, does your data match?
1 Like
Between block 3137557 and 3145621 here is what I calculated:
Total Fees 92.46838518
Max Fee 2.29065513
Median Fee 0.00365
Average Fee 0.011465391838809671
So at a price of $500 per ZEC that equals $46,234.19259 for the week, which is MUCH lower. Would love for others to verify 
3 Likes
I think they’re (incorrectly) measuring block rewards as well as transaction fees.
3 Likes
Introducing the Zcash Dynamic Fee Lab
To kick off the larger conversation, we put together an experimental “Zcash Dynamic Fees Lab” which is infused with live mainnet data. It walks through:
- The history of Zcash fee mechanisms
- The current (uncongested) state of the network
- Prior art explorations (like EIP-1559)
- Goals and Principles
- The simplest design we could think of that meets all of the goals
The Initial Design
Our proposal builds upon ZIP-317’s action-based accounting, but introduces a median-based fee based on “comparables” from previous blocks. When there is competition for block space, we open a “fast lane” for users to prioritize transactions. This simple design has many benefits: fees are low when the network activity is light, and raise quickly when the network is busy.
We also use powers-of-10 bucketing to greatly reduce fee entropy, which reduces information leakage and linkability.
Finally, this design can be rolled out first as policy-only, like ZIP-317, and later hardened in a network upgrade by very simple consensus rules.
This is not a finalized proposal or a commitment to any specific design. The goal is to get feedback on something concrete, gathering data and perspectives, and then iterate on the design as a community.
Please visit the lab, tell us what you think, and help us shape what a better Zcash fee mechanism that can last far into the future.
More discussion on X:
7 Likes
I am generally in favour of this proposal, as Zcash becomes more used, the current fee model will become too expensive for some. Also I really like the bucketing of fees to reduce information leakage.
I am interested how this will work in tandem with the NSM, AFAIK fees will be at least partially “burned” rather than rewarded to the miners, so they will be more inclined to be transaction agnostic rather than pick tx with a higher fee attached
2 Likes
Good question - this will respect ZIP-235’s burning of 60% of transaction fees. That still leaves 40% of the fee for the miners to sort but it’s a good thought that it could make them at least more agnostic.
3 Likes
Thank you for sharing this interesting and exciting initiative.
In the context of the proposed design, what aspects do you believe would most effectively reduce transaction friction during congestion, enabling a ‘shield once, spend privately forever’ experience while preserving the utmost seamless experience for users?
Additionally, aside from reducing friction, are there other aspects in your initiative you believe would facilitate broader real-world private adoption?
I’d greatly value your insights as valuable input for ecosystem priorities.
During congestion (which I’m not confident we’ve ever seen outside of sandblasting) we need a way to ensure that users can prioritize transactions if they decide to, with the expectation that miners will act in their own self interest by including high-fee transactions before others. That aspect of our design would be the so-called “fast lane.”
It’s worth noting that shielded transactions do incur a cost on every wallet in the form of the trial decryption. A block full of legitimate shielded transactions could take a very long time to sync, even if all of the transaction is legitimate.
@nuttycom and I have started to spend more time thinking about how we can more directly tie the transaction fee to this cost, and are still in the early stages of this. The Network Sustainability Mechanism is the closest thing we have to a working solution, though that choice is limited to only “pay miners now” or “pay miners (and/or stakers and/or oblivious syncing server operators) later”.
Fees are one of the many things in blockchain tech (like Proof-of-Work itself) where one mechanism serves many, sometimes conflicting purposes:
- They are a spam reduction measure
- They incentivize inclusion in blocks
- Allocate scarce block space under congestion
- VERY Indirectly deal with externalities like syncing compute, storage etc
So once again we find ourselves in a delicate trade-off space where sometimes higher fees are better, and sometimes lower fees are better.
Eliminating fees altogether might help here We could just replace them with a captcha or PoW anti-spam measure and call it a day, but then we lose the NSM, and we lose the usefulness in the other capacities listed above.
In the design itself, I think generally lowering the fees would be popular. Also, the power-of-10 bucketing and median based calculation arguably make fees easier to reason about.
At the end of the day there’s only so many levers we can pull in the context of fees.
3 Likes
Also, yay for cross-org collaboration 
5 Likes
This is a very good proposal. If implemented this way, would it burn more Zcash? It should further drive up the price of Zcash.
1 Like
Thanks!
We would not burn any ZEC as part of this specific proposal, but if the Network Sustainability Mechanism is activated, 60% of transaction fees would be returned to issuance as per ZIP-235
3 Likes
Is the cost-to-wallets in scope for this problem statement?
I thought that the problem was (potential) bottle-necking on confirmations? I.E. “mempool-bloat”
Isn’t wallet-trial-decryption orders of magnitude faster than block confirmation?
(post deleted by author)
This is some interesting work pointing out some issues with 1559.
1 Like
A slight tangent but a new thesis paper from MIT on game theory around fees on PoW mining and reorg attacks. Something to have in the back of the mind if dynamic fees are implemented and block rewards get smaller the risk of miner reorganization is plausible. If the PoS hybrid model being looked at just another data point to consider