UDAs/ZSAs and burning funds for fees

Technology
1

Zcash should build user defined assets (UDAs). UDAs let us offer private stable coins, let other developers build on zcash and become engaged (e.g offering say privacy wrapped ERC20s), and bring us more users, cover traffic, and privacy. Imagine how useful a privacy wrapped version of tether would be? But a question keeps coming up about UDAs: how do we charge fees for UDAs? The basic answer, which is more than good enough for V1, is just like we do for shielded zec: you pay a public zec denominated fee per transaction. Remember, we have effectively fixed fees for shielded transactions and no real fee market. But can we do better. Not now, not when we ship UDAs version 1, but in the future?

I want to stop here and make something explicit: UDAs don’t need extra fees to ship a first version 1 of UDAs. We’ve seen a number of blatantly flawed arguments against UDAs. Many tangentially touching on fees and making false emotional appeals to “fairness”. You can read more here. Lets not unintentionally carry out the CIA’s simple sabotage manual’s tactic of “refer[ing] all matters to committees for “further study and consideration”" and killl UDAs or delay their launch. A long discussion about fees needing “further study” would do exactly that.

It’s important that the UDA fees discussion doesn’t hinder rolling out a basic version of UDAs. I’ve been thinking about UDA fees and discussing it since shorty after I realized UDAs were important nearly 2 years ago. The discussions has been on a back burner because UDAs should ship first and then we can iterate on UDAs just like we are still iterating on zec’s normal fees. (remember, shielded transactions now pay a default and largely symbolic tiny fee.)

Ok, back to fees:
The problem with UDA fees it’s a trivial tweak to Zcash’s snarks to make any UDA TX pay out a higher fee, even one thats a function of the asset type and amount. But, paying out different fees based on asset type or value is a privacy violation. If all UDAs have the same fee, this may be acceptable. But if we want more complex fees that depend on asset type or value , this is a major problem.

The solution is to this problem is instead of paying fees, burn them. burn the UDA specific portion of the fee, this preserves privacy since nothing is revealed. And by burning ZEC for a UDA, we increase the value of ZEC for anyone who holds it. Now we can burn an arbitrary fee as function of the amount of the UDA transferred even.

But things get more complicated when we want fees to depend on the amount of an asset transferred. Sure, we can make you burn 0.001 ZEC for each unit of a UDA you transact, but this will just cause someone to make, e.g., wrapped btc (zbttc) where 1 BTC = .000000000001 zbtc. So you end up burning almost nothing because all UDA transactions are notionally tiny. We could make you burn the asset itself as a percentage fee, which avoids this, but that wouldn’t pay miners or anyone else (unlike burning zec), so it doesn’t do anything.

This leaves us with a few options for fees by burning that meaningfully relate the burned amount to the value transferred:

  1. Build price oracles that can be referenced on chain and in snarks to set fees. (seems complicated and probably requires trusted parties built into the core protocol for fee determination.)

  2. only allow UDAs to be issued from AMMs . Zcash would need to build the AMM to ensure 1 to 1 correspondence between the asset and the UDA. And that still wouldn’t cause fees to very as the price fluctuates. But at least it would help

  3. we could burn a fixed percentage of the asset value itself in a transaction, this would leave some of the asset sitting in the reserve pool Maybe for AAMs or other wrapped setups, its possible to capture this leftover money and pay it out to miners/ the chain. But I see a number of incentive problems, like making people cash out frequently and costing them privacy.

  4. maybe we can have some gas mechanic. Possibly with typed gas per asset which you must burn to transact the asset. To buy gas you swap the wrapped asset for gas and then miners get to take a blended mix of assets out of the gas pool based on how many blocks they mined . This seems both complicated, has major incentive issues, and a usability pain (now you have to have different kinds of gas).

Maybe theres a better way to use burning for fees. Or maybe we can do solve the problems with the above ideas.

9 Likes
2

Thanks for starting this discussion systematically, @secparam! I agree it’s not a blocker, and also that it’s good to try start figuring it out nonetheless.

I’ve always been dubious about the “constant market cap” hypothesis, which assets that if units of a cryptocurrency are burned/minted then (all other things being equal) the price will increase/decrease to keep the market cap unchanged. This hypothesis is elegant, but do we have empirical evidence that it’s true, or any models that imply it for an asset whose value is not clearly grounded in fundamental underlying value?

I’m doubly dubious that this holds when the supply change is not known! How would the value of ZEC increase in response to a shielded transaction burning some ZEC, if no one (but the transaction’s sender and recipient) even knows that the ZEC was burnt?! Arguably there would be some long term effects in rejiggering supply and demand, but how can we predict it’s magnitude and why would we think it will exactly correspond to the secretly burnt amount, so as to preserve constant market cap?

Put otherwise: if you had 1% of TSLA, and today you withdrew it as paper certificates, and burned them, but didn’t tell anyone — do you think the TSLA price would increase, and moreover by exactly 1% and within a reasonable timeframe?

Let alone for something for which “revenues” and “book value” can’t even be defined.

we could burn a fixed percentage of the asset value itself in a transaction, this would leave some of the asset sitting in the reserve pool Maybe for AAMs or other wrappepd setups, its possible to capture this leftover money and pay it out to miners/ the chain.

Cool direction, but i don’t quite follow: if we don’t publicly know how much of the asset value was burnt (which somehow affects the AMM liquidity pool for the asset?), then we can’t compute how much excess there is in the liquidity pool that can be disbursed.

1 Like
3

This is a very good point.

If we went with the gas mechanic, we’d have an explicit mechanism for avoiding this. You use some of your asset to buy asset specific gas. You burn asset specific gas, miners get generic gas for each TXs (at a fixed rate/ or some EIP 1559 style thing) with which they can take assets out of the gas pool.

The only idea I had was you’d need a sweep and clear mechanism where everyone periodically claims everything they can. Whatever is left goes to the house. But this has so many problems.

4

I just trying to understand UDA. If we can have a stablecoin linked to the USD. How does the user convert to their local currency and get it into their local bank? We probably have a 10 -20 year transition period where you need to work with local banks don’t you?
Eg
Let say I’m on the USA and I hire a developer from India or any country. We use the US dollar as the coin with an agreed price in USD equivalent. How does the vendor get the money?

If you can create the SDK to start linking your wallet to local banks, you will hit a home run. Make it easy to transact with a z stable coin, save your money in zcash, and then monetize it to get money out in a local currency, you will get massive traction in the marketplace for local to local and local to fX transactions

5

UDAs do more than stable coins. They let you build wrapped BTC that’s private. Imagine how much attention that would get.
But for stable coins there two types

  • Algorithmic ones ran by a smart contract. These are stable, but just like any crypt currency.
  • Dollar/Euro/Etc backed coins. Here the idea is someone wants that currency but doesn’t have access to the banking system and cash is inconvenient. It’s been a year - 5 days since I traveled internationally :upside_down_face: , but usually you find people who want dollars or can convert things to them.

So that mostly exists for US dollars. Someone will always take them and convert them. So all we need to do is build a bridge between Zcash user defined assets and something like tether or USDC. Which is easy once we have UDAs. Ren already supports it and works with zcash’s chain.

1 Like
6

The problem seems to be the time. The cryto coins are great. It’s instant. But people want to spend the money in the local currency instantly too. So how can to make it instant to spend the money when most places only accept visa/MasterCard/local credit/debit etc or physical currency. Can you transact in zcash or uda and actually spend the money instantly? It seems like you need a bridge to visa or equivalent?

7

Micro combustion seems to me acceptable, or the equivalent of gas, in general, zec combustion is not very good, because deflationary mechanisms are also detrimental to the economy at a distance, and I think that this should not affect the price in general, but the reduction of coins in circulation in general undesirable in my opinion. Can we get an answer from ECC why in this update (spring 2021) they did not deploy the UDA but left it to a later date? If the UDA interfered with plans for some grandiose innovation and, for example, concluding a contract that would change zcash and give such necessary success, and it was necessary to abandon a promising technology in order to get great success now, then this should be discussed?

8

Engineering time is a limitation, but in my opinion the more significant limiting factor is simply the risks that would be associated with further increasing the scope of the changes in the next network upgrade. Deploying Halo2 and Orchard is a major engineering effort, but the fact that it will permit future circuit changes (such as those needed to deploy UDAs) without a new parameter generation ceremony or a new shielded pool will make it possible for Zcash to evolve more rapidly in the future.

Deploying a new circuit and proving system is frankly a large change to begin with; deploying UDAs would be another large change. By making those changes in separate network upgrades, it helps to limit the overall risk and reduces the scope that needs to be reviewed by third-party auditors. I think that a lot of members of the community may not fully appreciate the amount of scrutiny that is applied to every change to the consensus rules.

The core protocol team at ECC has 5 members, two of whom (including myself) have been working on Zcash for less than a year. But even if the team were larger, I personally think that deploying both UDAs and Halo2 in the same network upgrade would represent an unreasonable amount of risk.

Right now, and in this thread, is a perfect time and fashion to begin discussing design tradeoffs as @secparam has done. If it could result in a ZIP authored by the interested parties for consideration by the community (and hopefully for analysis by independent economists) for inclusion in a future network upgrade, that would be an ideal outcome.

3 Likes
9

Finally, we received the answer that everyone suspected, I suppose who chose that HALO2 is more important than UDA? This is what many people here are planting as some say a toxic swamp, I don’t understand these priorities and that Halo is more important than UDA right now,
I never heard the rationale or didn’t understand, but the fact remains, there was no discussion on this issue in advance, before the choice network development strategies that seem to be directed by the community, that’s where it’s really toxic, I don’t like when there are behind-the-scenes games in politics and then pass it off as democracy. It’s sad. I believe the 120K grand from EF made HALO a priority, despite community funding for the main development of zcash, and now when it’s too late to propose to discuss the UDA, I believe that deploying the UDA in the first update and discussing HALO (which is still not ready) for the next is more appropriate with a risk perspective.
Or Halo2 will change something radically, which was not reported, which I personally doubt because everything that this update gives in my opinion will not qualitatively improve zcash, but quantitatively and ordinary users will not benefit from it in any way, but the fact that so much noise around Halo says about the fact that there is nothing else, so the UDA is economically more profitable in my opinion.

1 Like
10

I agree, UDAs shouldn’t make it into NU5 in what is it, June? Anyway, the point is first to decide to do UDAs and then figure out timing. Right now we’re stuck on not deciding. And this isn’t even a thread about deciding, it’s about what we do with the next version of UDAs and fees:) But glad to have you onboard.

Funnily most of the change has already been done … twice now. @str4d did a draft zip and circuit for sapling (which is now going to be included in Tezos), and @daira got it to work with Halo/Orchard with a really insanely clever but retrospectively dead simple modification to Str4ds code. The only things that need to happen are 1) adding transparent mint and burn operations (this looks like vin/vout) and putting those bits somewhere in the tx format. and 2) review.

Which, I agree isn’t happening by June. Mainly because of review and rushing things being bad.
Anyway, let’s figure out that we want to do UDAs, then sequencing can come later. Nice thing is we don’t have to do a whole new ceremony because halo removes trusted setup.

Then we can figure out how to make fees better in the next version of UDAs. Which is again, easier to iterate on because circuit changes become simpler.

6 Likes
11

Eagerly looking at the thread …

12

BNB is regularly burned which seems to have appreciated the price. Article also talks about increased demand for BNB.

good primer on EIP-1559: What is EIP 1559 and How it will Lower Ethereum Gas Fees and Make ETH More Scarce? | CoinCodex

Whoever comes up with an equivalent that works for Zcash & UDAs — they’re genius.

13

Whatever fee mechanism we decide on for UDAs, I think that the fee market for ZEC should be separate from the UDA fee market. Having two separate fee markets would help ZEC maintain a privileged position relative to any UDA asset.

Also, it is probably better to give UDA tx fees to miners rather than burn them, since the increased chain security is more important/significant than the small increased value of ZEC from burning.

3 Likes
14

So if you do something like the gas mechanic this is possible, all be it indirectly. Fees go to miners.

It’s also possible doing it directly by having UDA TXs just pay a clear text fee, but the problem there is it violates user privacy, either by a maybe acceptable amount for a fixed higher UDA fee and by way worse amounts if you do some complex fee mechanism that is dependent on asset type or worse amount.

The idea for burning was exactly that it lets you play with complicated fee designs that might make it into miners pockets without exposing privacy.

15

Would it be possible to set a default fee for UDA related transactions independent of the typical transaction fee?

This could help with anonymity by grouping all “those kinds” of transactions into one, albeit different than “regular” network fees. Plus it could help with the free rider problem by setting that default fee to something higher, say 0.01 ZEC or similar.

16

Yes. Thats possible and IMHO, within the threshold of acceptable privacy trade offs.
Also would make it clear where Zcash’s increased usage comes from if we deploy UDAs:)

2 Likes
17

What about using ZEC as gas and having a sealed-bid auction? UDA txs indicate the maximum zec they will pay in a zk way, and then a computation is done in zk so that every tx fee in a block is the same, and equal to lowest bid that made it into that block?

This solves the privacy issue of unequal fees and while also sending zec to miners instead of burning it. How hard would it be to create this type of sealed bid auction for the miners to compute in zk?

18

Hrm. So auctions for blocksapce are a good idea and under explored I think. What would be UDA specific about the auction? Why would UDA bids be any different, or the price they pay. As a mechanism this seems promising to explore.

The exact cryptographic idea you have will be challenging to do in practice, some trusted third party, either real or simulated using MPC, would need to computer over the sealed bids to compute the clearing price. And the miners aren’t even known in advance. But these are small details.

Luckily, i think the effect can be had without that particular cryptographic construction, so lets focus on figuring out how that mechanism works and then go from there.

1 Like
19

Nothing necessarily. The same auction mechanism could be applied to the ZEC tx fee market. I think that the big economic benefit is that we separate out the ZEC tx fees from the UDA tx fees, so UDAs are not taking away tx throughput from ZEC users and bidding up the tx fees of ZEC users. The combined effect of 1) separate tx fees and block space for UDAs and 2) an auction mechanism, is that the economics and throughput of UDAs becomes decoupled from the tx fees and block space for ZEC. We could set a higher minimum tx fee for UDA txs, for example, to create some incentive to transfer value with ZEC vs UDAs. Conversely, if ZEC tx fees became much higher than UDA tx fees, the existence of UDAs would benefit ZEC holders by incentivizing some users to use UDAs instead of ZEC, and bring the ZEC fees back down.

I think that this should address some of the economic issues brought up by @zooko ? There are still questions about ‘top heaviness’ that may require more thought, but I think this could at least be a step forward.

Glad you think so! Here is a simple modification that obviates the need for anything zk. How about we only allow three possible bids in the tx fee auction? You can bid the same fee that was paid by all txs in the previous block, or you can bid +/- 5% of the fee that was paid by all txs in the previous block. This can be implemented easily by just broadcasting one -5% tx if you only agree to pay that much, or broadcasting both a -5% and ‘stay the same’ tx, etc. Then let miners fill the blocks with whichever txs they want, subject to a consensus rule that all tx fees must be the same. This way all tx fees are the same in a given block, and the only info leak is a 1 of 3 choice that miners know about, and I think that is acceptable.

20

Interesting, what happens to user’s txn when they bid low tx fee? Does it mean users will broadcast upto 3 transactions then rest of them will be rejected?

If we are brainstorming this auction route then we could pick median fee as the base fee for next block (if Zcash doesn’t enforce all txns in same block to have same fees — regd. your point about miners including txns that bid lower).