@zancas, you’ve done it again! Your insights always get my gears turning. This makes me ponder: Is decentralizing keys the same as decentralizing baskets?
cc: @josh @Dodger @ZecHub @ZcashGrants @skyl @nuttycom @noamchom @FPF @zooko
6 Likes
The primary question of decentralization is ultimately that of how to distribute decision-making power. One option that is available in the future design of lockbox disbursement mechanisms is definitely to divide the lockbox into multiple portions, with distinct sets of keyholders. Under such a mechanism, the 5-member ZCG committee could be one such set of keyholders. This approach is one that the protocol engineers have discussed: it’s the bottom-center option in the table at Notes on deferred dev fund proposals - HackMD
The question at hand is: does the community potentially want to try out several different grant disbursement mechanisms in parallel? One slice of funds could be disbursed by the 5-member ZCG committee, another could be disbursed by @joshs’s proposed Zcash Funding Bloc. The question that arises for me there is: do we have sufficient resources in the ecosystem to run more than one of these? What happens when a grantee applies for grants from multiple slices, and is there a risk that in that situation there’s a “chicken” dynamic where each slice expects the other to fund a grant? One potentially interesting approach would be if there were separate “proactive grant” and “retroactive grant” slices, but I’m a little wary here; I can’t reason through all the incentives in play.
In general, I think that introducing too much complexity into the dev funding disbursement process is something we should be wary of, but it’s good to think through these sorts of possibilities.
7 Likes
From the practical side of this, I’d say decentralized keys that manage a centralized basket is a challenging enough end state to get accomplished in the year(s) ahead.
But in an ideal sense, I’d say there is some sweet spot where both 1. keys are sufficiently decentralized, and 2. many decentralized baskets are being distributed from.
Some keys may only be capable of signing for some baskets, other keys might be capable of signing for all baskets. Certainly there are endless possibilities to consider.
I’ve already raised my practical concerns about going to a lockbox only, because we risk a notable ZEC block subsidies disbursement draught. My proposal for a 4-year lockbox +ZCG hybrid was not especially popular, so it seems pretty obvious that the ecosystem in a majority are not as concerned about risks around a disbursement gap (from either ZCG in practice which is happening already i.m.o. or from the lockbox).
I’ll also note the finances of the lockbox. If it only accrues 12% of block subsidies, it will take quite a few calendar months before the amount of ZEC held becomes great enough to be spent on Major Grants - things like ZebHub, Maya, Qedit, Zcash Media, etc. ($200-800k size grants)
12% will amount to about 6,000 ZEC per month ($200,000 or so at around $30 ZEC). Ideally the market wakes up on this project, and the coin price is up above $100 by the time that disbursements from the lockbox begin to happen.
1 Like
I’ve only spent a couple of hours with this book so far. I plan to read it 2 or 3 times in the coming weeks. I think it would be good for everyone to study it so that we all have the same vocabulary:
https://greenpill.network/pdf/onchain-capital-allocation.pdf (pdf)
A lot of this is new to me. But, there are some awesome possibilities. I see a path to implementing most or all of the mechanisms described in the book. For the lockbox NDFM, I think we should weigh the pros and cons of all the mechanisms and pick 1-3 to implement. If there is 1 mechanism that is a clear winner then we could focus on just that one initially. But, so far in my reading, I’m getting pretty excited about several mechanisms that have different strengths and weaknesses and use cases.
One thing I forgot to mention or emphasize in the call yesterday that I think is important is that the lockbox presents an opportunity to drop the USD accounting that IMO plagues the ecosystem. The block reward is not USD, it’s ZEC. The lockbox will not have USD, it will have ZEC. To make really awesome decentralized allocation mechanism(s), with potential onchain settlement and incorporation of ZSAs, grant proposals should probably be stated in ZEC. Or, we should build up liquidity in other assets onchain.
Anyways, I think we should all read that book 2 or 3 times and start thinking about possible mechanisms. One route might be to do small pilot rounds trying different funding mechanisms without dedicating the entire lockbox to one idea a priori. This way we could experience different mechanisms, learn from the experiences, and probably get funds out faster without having to have one gigantic debate over the fate of the entire lockbox all at once.
3 Likes
There are going to be probably two layers of disbursement mechanism: the social layer, and the consensus layer. There may be some limitations on what is implementable at the consensus layer (with a reasonable amount of effort) and so in the design of the social layer, it will be important to think about what properties will be required of the consensus-layer bits. Some relevant questions, with the assumption that disbursement will be a multi-sig process of some sort:
- How many signers are anticipated? With a threshold multisig, is attribution of a signature to a signer desirable or not? There are tradeoffs here in terms of the cryptography involved: for example, with FROST you do not get signer attribution, but the fact that FROST requires two rounds of participation, a commitment round and then a signing round, means that there’s an attack vector if someone who participates in the commitment round then withholds their signature from the signing round.
- How is key rotation handled?
- If you have a threshold signature, do you want the signing process to be strictly positive, or also to record negative sentiment and abstention? It might be desirable to be able to know whether a particular signer is consistently not participating or has abandoned their role, so that their key can be rotated out. This requires some sort of attribution; abstention can be used if someone wants to recuse themselves from the disbursement process for a particular grant to avoid it being considered that they’ve abandoned us.
These are just examples, but when thinking about mechanisms, think about the properties you need; that’s a good foundation for protocol engineers and cryptographers to work from. Likewise, I expect that the protocol engineers will soon start discussing what kinds of mechanisms might be implementable in a reasonable timeframe (some such discussion has already begun) and at least for the initial iterations of a NDFM, those implementation constraints may have implications for what designs can look like at the social layer.
3 Likes