OpenZeppelin/openzeppelin-labs

Vouching dynamics discussion

Closed this issue · 3 comments

spalladino commented

This is an issue for discussing vouching-related matters

1- How do we feel toward someone vouching for their own version? Is it expected to happen, something we want to incentivise...?

2- Given a user that is locked on a version that "just works" for him, what are his incentives to move his vouching onto a new, better version, so development moves forward and is promoted?

3- Is there any chance for a malicious player to propose different versions in a progressive manner, making people stake their ZEP in different ones to “divide and conquer”, allowing this player to send a final version and stake his now-majority of tokens?

teempai commented

1-I don't think this is a problem per se. I would just assume that anyone with confidence in their proposal will stake their own.

2-Security I think is the primary incentive, but it may be wise to assume that not many are qualified to assess security. Could you maybe delegate your stake to someone else? I.e. I could initially delegate my stake to Zeppelin as I trust them to ensure the system works properly. A "subscription" also solves this to a degree I think.

3-This could be an issue, but it does assume that a) they have managed to lock up a majority of tokens and b) no one moves their stake to this new proposal. In general, how are you guys thinking about the time delay from staking? Even if a was true, over time tokens would probably move to the newest proposal, so when is a proposal actually "accepted"?

  • 👍2
wendyxs commented

  1. A malicious actor might be incentivized to do that in a bad version if they've found a vulnerability in the OS that they can exploit where the collective value of the vulnerability of all the things built on top is worth much more than the amount required to stake (could be the entire supply of ZEP theoretically if the OS becomes big enough such that many ecosystems are built on top). This problem needs to be solved, but I agree with Teemu above given typically the collective should move things along much faster.

  2. I think you might actually have the opposite free rider problem where most people prefer to delegate their stake to a more knowledgeable authority so it's not decentralized, because there is a cost to making a judgement on which version is better, and if you delegate your vote, you get to minimize your cost while still piggybacking off of the benefits. An interesting mechanism might be to charge someone to delegate their vote rather than letting them do it for free, that might also have negative impacts on adoption of staking in general, so maybe it's something you do tied to a certain condition.

  3. People should be able to see how much that person has staked proportionate to all these different versions no?

fzeoli commented

  1. I think this is okay and expectable. It happens in open-source.

  2. I don't think this is a scenario that will happen. A user whose only interest is in using the platform and not taking part in the governance process won't be vouching for the version he's using in the first place, given that it can be used for free. I don't think artificially incetivizing users to take part in governance when they wouldn't do so organically would yield high quality decision making.

  3. I think the amount of capital required to achieve this in the master branch would be significant enough that this won't be an issue. Smaller forks won't do as well though.