You would be giving spending authority as well. You could reduce the risk somewhat with multisig.
3 Likes
without proof of age, this would not be interesting for projects like namada that are doing an airdrop for ZEC holders or other projects that are planning to do something similar.
all the projects that i have seen doing airdrops, take a snapshot at a certain block or date.
2 Likes
My understanding is “freeze height” is the block height which is used by voting clients to prove a balance. I imagine Namada would pick some arbitrary block in the past (not too far) as the freeze height and if you were lucky enough to hold ZEC at that time you can claim the airdrop.
1 Like
There is a snapshot.
But the age of a coin does not have an impact. For ex: 1 ZEC = 1 NAM as long as it is in possession before the snapshot (freeze height).
5 Likes
@str4d and I have previously done some work on sketching out a protocol for airdrops, proof-of-balance, or stake-weighted polling: Draft ZIP: Airdrops and Stake-weighted Polling - HackMD
19 Likes
Thanks for the link. It looks close to the same idea and supports weighted polling. It uses a new circuit and only works with Orchard.
1 Like
It’s not really specific to Orchard; an almost identical protocol works for Sapling. It’s just stated for Orchard in that draft.
If it were applied to Sapling you would either need another phase-2 Groth16 trusted setup, or you can run Halo 2 on BLS12-381 or any suitable curve that has Jubjub as an embedded curve. (This does not need to be pairing-friendly or in a cycle, for example you can use Bröker and Stevenhagen’s method to construct one.) Sapling uses BLAKE2s-256 to derive its nullifiers and that hash function can be easily domain-separated, so defining \mathsf{DeriveAlternateNullifier} for Sapling is straightforward.
On the other hand, I don’t think it’s unreasonable to just require moving funds to Orchard in order to vote / prove balance using them.
The reason why the protocol Str4d and I drafted uses a new circuit, is that without that you have to reveal the nullifiers of the notes being proven. Those are the same between every instance of the voting / proof-of-balance protocol, and when the notes are eventually spent. Therefore, votes in different polls / proofs-of-balance that rely on the same note can be linked with each other and with the transaction that spends that note. That’s quite a serious privacy problem, I think: you could argue that the linkage with spends could be mitigated by renewing those notes using a fully shielded transaction sending to self, but that cannot mitigate linkage between votes/proofs that run concurrently.
The protocol in our draft does not have this problem, because nullifiers in different domains cannot be linked. In fact I think it is one of the simplest designs that can address this problem while still being able to run concurrent polls / proofs-of-balance, and without requiring actual spends as part of the protocol.
13 Likes
Oh, I just meant that there would be a need for a new trusted setup with Sapling.
That’s great. I didn’t think of that.
The linkage between votes is an interesting problem but as you said, it is a problem with concurrent polls, isn’t it? Otherwise, we can reshield the funds and get fresh nullifiers.
3 Likes
To clarify the idea of reshielding. Would this mean an extra transaction would have to occur or could this spend occur as part of the receipt?
1 Like
It could be done as part of a step in the protocol.
2 Likes
Absolutely!! This would be a great incentive for people to keep their tokens in the latest pool. 100% with this.
8 Likes
If the anchor heights required for the proofs for multiple polls are all at some (different) times in the past, you wouldn’t be able to do that, and I think that for most purposes announcing a past anchor height will be desirable, to avoid the flash loan poll exploit.
In fact, for fairness in polling, I think that the anchor height for each separate poll should be determined by an algorithm like:
- The poll is announced, specifying a block height in the future (
POLL_GOVERNING_HEIGHT), and the current block height (POLL_ANNOUNCEMENT_HEIGHT) is recorded. - Once the chain tip is at or greater than
POLL_GOVERNING_HEIGHT + 100, the hash of the block atPOLL_GOVERNING_HEIGHTis used to seed a deterministic PRNG. That PRNG is used to uniformly choose a number in the range 1…=100000 (POLL_HEIGHT_OFFSET). - Voters in the poll must use the anchor at height
POLL_ANNOUNCEMENT_HEIGHT - POLL_HEIGHT_OFFSETto make their votes.
This guarantees that the result of the poll will be decided by the holders as of a random block some time in the ~3 months prior to when the poll was announced. This cannot be manipulated via a flash loan, and encourages users who want to be involved in governance to consistently keep their funds in the Orchard pool for long periods of time.
4 Likes
I think it would be unfair to people who actively trade ZEC. IMO the flash loan exploit can be avoided by a randomized height as suggested earlier (Coin Voting / Shielded Airdrop / Proof of Balance - #11 by hanh)
3 Likes
Would this system allow for an allocation of the block reward to be paid out to users with funds held in orchard pool, say once a month?
If 10% of the block reward was set aside for this, then it would be a good incentive to not only migrate funds to orchard pool, but also for miners to hold onto mined ZEC
1 Like
It’d be like a monthly airdrop so this should work too. However, the claimer must resubmit a proof every month.
4 Likes
@hanh at the most recent meeting, the @ZcashGrants Committee voted to approve Milestone 1 of this proposal, for a total of $40,000 and has requested that you provide monthly updates via the forum in this thread. Please amend the grant to reflect this on the Submittable platform.
14 Likes
(Speaking just for myself and not for ECC or as a ZIP Editor.)
This is only a thought exercise on how this functionality could be achieved, not whether we should do it.
It’s not necessary to require proofs of balance (which have potential privacy weaknesses when used for this purpose) in order to claim interest for holding funds in the Orchard pool. To do that, we could alter the protocol as follows:
Define the “compounded value” of an Orchard note at a given block height to be 1 at the activation height of this protocol change, and to be multiplied at each block by (1 + the per-block interest rate).
The per-block interest rate can vary; at each block, we subtract \mathsf{ceiling}(\mathsf{perBlockInterestRate} \cdot \mathsf{orchardChainValuePoolBalance}) from the block subsidy and add it to \mathsf{orchardChainValuePoolBalance}, in order to account for the increase in value of Orchard notes relative to other ZEC notes/UTXOs.
(Due to rounding both here and in the circuit below, the Orchard chain value pool balance becomes a slight overestimate of the actual sum of values of Orchard notes, but since a zatoshi is very small in practical value, that might be acceptable.)
Define the “anchor height” of a note output in a transaction with a given anchor, to be the height of the block with final treestate referenced by that anchor.
The relation between compounded values and note positions is public. Find a way to check this relation in zk, for example:
- recompute the note commitment tree so that it commits to both note commitments and compounded values; or
- include the compounded value in each new note commitment input and validate it on the output side of the circuit.
Change the Orchard Action circuit so that in each Action, the net value balance input to \mathsf{ValueCommit^{Orchard}_{rcv}} becomes \mathsf{floor}\!\left(\frac{\mathsf{compoundedValue^{new}}}{\mathsf{compoundedValue^{old}}}\right) \cdot \mathsf{v^{old}} - \mathsf{v^{new}}.
The idea here is that the value of each Orchard note relative to other ZEC notes/UTXOs is multiplied by 1 + \mathsf{blockInterestRate} each block, but this is only claimed when the note is spent. It’s equivalent to splitting ZEC into two currencies that are pegged to each other, with the peg being deflationary on the Orchard side. (I make no comment on the economic consequences of that, which could be quite substantial.)
Notice that this could easily be generalized to keep track of arbitrary exchange rates between pairs of ZSAs or other subsets of notes, as long as there is some way to agree on them as part of consensus.
9 Likes
If I’m understanding correctly, would this effectively double the number of orchard transactions? I.e. everytime you transaction there is a redemption transaction on interest earned? Could be problematic down the road, maybe
No; the user experience of this would just be their balance increasing over time in proportion to their holdings; if you receive X ZEC at time 1, then you have X + interest ZEC available to spend at time 2. It would effectively just redirect part of the issuance to the holders by decreasing the block reward; the interest would essentially be “newly issued” (as a fraction of the accumulated value of the decrease in the block reward) at the moment that it is spent.
5 Likes
Thanks for clarity on that
2 Likes