Please bear with as I provide some background to motivate this.
Nomadic is planning on introducing shielded transactions through a contract that will compute zk-SNARKs from Merkle trees. The major weakness of this approach is that transactions can be analyzed based on values and timing coming in and out of this contract. There are two issues here. One places the onus on individual users to have good operational security, i.e. using delays and splitting the values of outputs similar to when using mixes in Bitcoin. This seems okay to me.
The second issue is that the anonymity set in the shielded contract is only as strong as how many users choose to store value in it. If few users do so, then it becomes easy for an entity to own the anonymity set and create a false sense of privacy. This is a huge problem, among others, in Monero. Itās also arguably a problem with Zcash due its anonymity set being so small, although to my knowledge no one has so far provided an analysis of this.
However, the major difference between this contract and Zcashās division of transparent and shielded addresses is that in Tezos weād be financially disincentivizing users from storing value in this contract through inflation. My idea to solve this involves another use of zero knowledge proofs thatās been proposed for Tezos: anonymous delegation. The entire pool of tez stored in the shielded transaction contract could be delegated anonymously, thus killing two birds with one stone as far as features. In addition to the benefits of anonymous delegation, users would now actually be incentivized to increase the anonymity set for shielded transactions even if they themselves donāt want to use them.
So who would be the delegates for the shielded pool? Ideally they would be determined by a market. Bakers could set bids for a certain number of tez that would be automatically fulfilled in order of highest rewards.
This also incentivizes users to leave tez in the shielded pool for longer periods in order to prevent large delegates from being able to analyze the output based on the reward value and determine who was delegated to them, although large blocks may end up being split between multiple delegates.
Another possibility to increase anonymity is to provide the option of locking up the shielded tez for longer intervals with longer maturities commanding a premium in rewards payouts. Something like anonymous T-bills.
Thoughts? Criticism? Has anything similar been floated in other contexts?
Hey @sophia interesting questions youāve raised, and Iām glad you brought up the topic. I think another implementation that could resolve some of these concerns could be through bakepools, have you looked into it? Itās a not-for-profit ecosystem project that Iāve been working on.
For one thing delegates can delegate to a bakepool instead of to an individual baker. The bakers who bake on the pool can be whatever criteria, respectively, that the bakepool manager for that pool sees fit.
Perhaps some bakepools focus on marketing to delegates want to have full KYC/AML/(whatever-else)ācompliant data on each bake in the pool to which they are delegating. (and would probably charge their delegates the higher-end of fees because of the cost of that service, as well as pay their bakers the most)
Perhaps other bakepools target-markets delegates who are okay with not having info on each baker, and such a bakepool competes on their own reputability and their delegate market honors that (and would probably charge mid-range fees, and pay bakers well, but less than if their data were fully disclosed )
Perhaps some other bakepools are fully anonymous for themselves and their bakers, and although this would be arguably more risky, that in exchange for that higher risk incurred by the delegate, that bakepool charges the lowest feesā that being the tradeoff. likewise, those bakers would earn the least in exchange for full anonymity thatās tiered not only by a shield but a bakepool as well.
Also keep in mind bakepools would differentiate themselves in other ways as well. This is an example of just one dimension of tradeoffs that the bakepool mechanism will enable, with respect to the topic youāre raising
Thanks for bringing this to my attention. These ideas do seem naturally related.
I just tried looking into bakepools, but canāt find anything more specific about how theyād actually work. Do you have anything you can link me to? Iām specifically wondering whether they can be implemented, at least for the time being, without programmatic staking? The big implementation problem with what I suggested above is that the shielded transaction contract canāt split its delegation rights.
Wrt KYC, I view the lack of it here as a feature. By giving an advantage to small independent delegates we increase censorship resistance. Itās great that Tezos is attracting institutional bakers because they offset the political risk of having fully anonymous transactions. However, itās easy to imagine a future in which custodians like Coinbase dominate delegation, making the network more centralized. The advantage of an anonymous pool is that institutional bakers could not participate. So in addition to allowing unpopular token holders to avoid censorship in delegation, the competitive fees resulting from a more liquid and efficient delegation market (whether through a matching engine or a syndicalist approach) would both give small independent bakers access to a large pool of delegated funds and prevent price fixing by their institutional counterparts.
Finally, @cwgoes pointed out a major flaw in the design I laid out above: bakers could set fees to zero in order to essentially purchase voting rights. I have no problem with buying votes, but they need to be fairly priced. It doesnāt make sense that someone who owns 8.25% of the shielded pool should be able to capture all its voting rights simply by offering free baking for a short time. Ideally, pricing of fees would be decoupled from pricing of voting rights. Again, not sure about your implementation, but I would think a bakepool might be able to accomplish this.
Hi Sophia! Yes, this can all be done without any protocol upgrades. Weāve confirmed this. You are correct in that the interactive āfeelā of how youāll be operating with a bakepool is something that should be explained a bit more. Iāll be pumping out some articles on this over time.
Bakepools will help prevent large bakers from dominating delegation. Right now baking delegation services are dominated by a few large fiefdoms that retain dominance through slotting mechanisms (being pre-loaded selections in wallets) and other anti-competitive norms weāve fallen into. Bakepools will tier the supply chain so that the marketers can focus on marketing and bakers can focus on baking, etc.
Even if you are a big organization like Coinbase, it would probably even be better for you to go with a Bakepool. Bakepools donāt just make things more fair, they also diversify risk ipso facto by diversifying vendors. Itās perhaps even more critical for an insured and regulated organization with many institutional investors and many institutional, clients consider using an external bakepool instead of doing it in-house. Or at the very least, to operate a bakepool in-house.
Within a bakepool delegation is distributed equitably to a standardized rate for all bakers in that pool. The bakepool manager sets the rate. The individual baker canNot get a larger share by expressing willingness to take a smaller fee.
Bakepools will compete with each other based on how they tinker with their own variables like degree of KYC vetting (or no vetting), and amount % in fees given.
Anyone can be a bakepool manager (BPM) and curate a network of bakers and client delegates. They can range from open-to-exclusive on either end of the market. The BPM sets reward distribution rates as distributed to the different parties participating in the bakepool.
The keys that originate the smart-contract of a ābakepoolā are that of the BPM. Even with multi-sig elements, the BPM is the āownerā with the ultimate authority.
Thatās the plain mechanics of it. But the real ācolorā to this process will come via the entrepreneurial efforts to be made as people start their own bakepools or convert their current bakers into bakepools.
@sophia Actually, there will be a formal process for their management Iāve been writing a 3-part series that will explain Bakepool in full. The details on method of implementation which I think will interest you will be next up in Part 2. Hereās Part 1 in the meantime.
@sophia I think there are no great solutions to this problem, but a simple auction is probably the best approach. Have the ābakerā of the pool for the next k cycles be put up for auction , whoever pays most gets to be the baker for next k cycles, etc. Itās simple to implement, it means the pool wonāt lose out.
The downside is that the pool becomes, in some sense, automatically bribe-able, it will give its delegation to the baker that pays the most, without exercising any judgement. I donāt think itās possible to do much better at the moment, and I donāt think itās bound to be a problem unless the pool grows very large, which would be a good problem to have anyway. If it starts to, that bridge can be crossedā¦
It might help if the protocol allowed delegation to not carry voting rights, thatās an easy change that could make it into Proto7.
The tez could be kept in separate contracts, so that multiple bakers can be used. When a withdrawal is made, it would be drawn from the pool with the highest balance. Anyone could later submit a ārequest to re-balanceā by specifying t pools with a different amount of tez. Why t instead of just looking at all the pools? Because of the gas limit, letting the ārequest-to-rebalanceā limit itself to a subset of the pools allow for the equalisation of many pools over several blocks if there are too many for this to happen in one transaction.
@sophia Have you thought about how rewards (paid by the bakers) would be distributed to users with notes in the shielded pool? Matching the transparent reward distribution mechanism seems tricky - the pool can accumulate a balance, but how would you calculate what a user is owed when they withdraw (or somehow elect to collect rewards)?
Even assuming a specially crafted zero-knowledge proof, the notes in the Sapling circuit state donāt cleanly correspond to accounts, as a user could have had many notes over time prior to withdrawing - I suppose proving that certain notes with certain values were created at certain block heights and not spent before certain later heights is possible in principle (then this would give a sort of ābalance * timeā) - but it seems like it would be rather intricate & likely inefficient.
You prorate by keeping track of two āsupplyā numbers.
Letās call the balances kept into the Sapling commit tree āztezā, you keep track of the number of āztezā and the number of ātezā.
If the contract holds n_z ztez and n_t tez and you deposit d_t tez, you receive d_z = d_t / n_t ztez. If you withdraw w_z ztez, you get w_t = w_z / n_z tez.
This might create an incentive to deposit before a baker bids for the pool and withdraw right after, but itās enough to arrange for the bakerās bid to only accrue slowly to the pool by reflecting it in n_t over time. Alternatively, even a tiny 0.05% withdrawal fee would make this unprofitable.
Ah, I see. I think that works with simple lock-up (no variable-maturity/payout T-bills), although it will mean that the exchange rate between ztez in the shielded pool and tez varies over time (and also per-pool, if there are multiple) as baking rewards are paid out, which will require clear explanation to avoid confusing UX.
I think delegation should be separated from voting. Question is: would one still be able to delegate votes, i.e. republicanism? This is more complicated, but I think necessary because otherwise participation would be too low. Maybe should be discussed in another thread.
@murbard can you go into more detail about how tez would be allocated to separate contracts? Iām trying to think how this would interact with the contract storing the Sapling state. Ideally it would generate traffic indistinguishable from shielded transactions in order to mitigate timing attacks, although Iām having trouble sketching that out. Also worth mentioning this is presumably a stop-gap until programmable staking (@cwgoes is this on your roadmap?).
I strongly think rewards should accrue to the pool. This incentivizes a larger anonymity set. I didnāt work out how variable-maturity rewards would be structured. It seems questionable that the shortest maturity reward would be low enough for this to work yet competitive with institutional delegates.
Could be, but right now bakers have to have bonds, if votes are delegated separately, they need to be delegated to people who put up actual stake. In the meantime, a simple tweak would be to allow contracts to delegate without granting any voting rights (no one gets them).
Having tez in separate pools leaks nothing about the traffic, this is just a way to have multiple bakers. Literally, the main contract just splits its tez into multiple contracts which have their own bakers and bid for it, nothing more.
I think you are confused about what Iām describing, Iām not suggesting it shouldnāt.
Iām trying to think about whether the traffic involved in this can prevent timing attacks on withdrawals by serving as decoys. Unclear how much that should be a goal vs. just limiting the need to withdraw at all. If the shielded pool is sizable and mostly inflation-proof thatās probably enough. More generally, Iām wondering how ādepositsā and withdrawals would work. If itās just by priority, with older tez allocated to higher rewards bids, then thatās somewhat like variable maturity by design.
Not confused, just siding with accrual over a withdrawal fee.
When Iām talking about depositing and withdrawing right before and after a baker bids for baking, that has nothing to do with concerns about timing attack to attack privacy. Iāve outlined how deposits and withdrawals can work, itās pretty simple I donāt see whatās complicated hereā¦
I think it is complicated in how it plays out. As I understand your description of it: you have a set number of pools, withdrawals come out of the largest pool, presumably deposits come into the smallest, bakers can rebalance subsets of pools, bakers bid on each pool separately (presumably?).
Questions that come to mind:
How does one avoid bad faith rebalancing, e.g. I make one pool exactly the right size for me to bake and others too large or small for my competitors? Presumably rebalancing requests require bids attached to each pool and are fulfilled in order of bids? Does this mean some amount likely ends up undelegated?
How are pools rebalanced, e.g. are we tracking age of funds to assure tokens that are in the longest remain in the largest pool?
Would rewards accrue over the cycles between bids? So I can withdraw in between and receive a fraction of the total rewards, but the benefit of benefit of staying in for multiple bidding periods is likelihood of being matched with a higher bidder?
The pools target equal sizes, you can only rebalance by making the balance between two pools equal.
There is no concept of āhow longā the tokens stay in a given pool nor is there a need for one.
You are overcomplicating this, the only accrual that takes place is that the accepted bid accrues lineary to n_t , for each pool, until the next bid is accepted.
Iāve been writing a 3-part series that will explain Bakepool in full. The details on method of implementation which I think will interest you will be next up in Part 2. Hereās 
