Meanwhile at Cryptium Labs #1 Part V
If you haven’t read them yet, here are links to Part I, Part II, Part III, and Part IV. In Part V, another feature we are working on is described: a spam prevention feature on the Tezos on-chain governance mechanism, by adding a 5% minimum upvotes required for the proposal phase.
- As this is a change to the governance mechanism, I recommend reading Part II on quorum caps as well.
This article starts with a recap of the Tezos on-chain governance process, followed by a brief motivations section and ending with the description of the feature with a link to its implementation on GitLab.
Recap of Tezos On-chain Governance & Proposal Period
Tezos on-chain governance is a mechanism that enables the process, through which not only the protocol can be amended (adding, removing, improving features), but also the governance system in itself.
As described in this blogpost, the existing on-chain governance process has four phases: proposal, exploration, testing, and promotion. The proposal period, the most relevant one for the purpose of this article, is when delegates or bakers submit proposals. This period lasts 8 cycles (about ~24 natural days), during which bakers can upvote their preferred proposal(s). However, only one proposal, the one with the highest amount of votes, will proceed to the next phase, the exploration period.
Motivations
One of the limitations that the current mechanism presents is the lack of minimum upvote requirements in the proposal period. As mentioned above, any baker is able to inject up to 20 proposals in every proposal period. This means that any baker can submit anything, as long as the codebase compiles with the change. For example:
- Anyone who wishes to submit a text proposal, would be able to do so by simply adding comments to the Tezos codebase that link to an external markdown file.
This, in combination with the lack of minimum upvotes, constitutes a latent spam vector, where any proposal, regardless of its chances of succeeding through the entire governance process, can proceed to the exploration phase, resulting in an additional 8 cycles of waiting time until the process is reset (back to the proposal period).
5% Minimum of Upvotes for the Proposal Period
Description
One way of preventing this latent spam vector in the Tezos on-chain governance process is by adding a minimum % of upvotes for every injected proposal in the proposal period. This would result in the requirement that for any proposal to be considered valid, it must have at least 5% upvotes. For illustration:
- Scenario 1: Given a proposal period with proposals A, B, C, with 1%, 2%, 3% of upvotes respectively, as none of them have reached the minimum 5% of upvotes, none of them will proceed to the exploration period and the process will be reset to a new proposal period.
- Scenario 2: Given a proposal period with proposals A, B, C, with 3%, 4%, 5% upvotes respectively, only proposal C is valid and will proceed to the exploration period.
- Scenario 3: Given a proposal period with proposals A, B, C, with 3%, 10%, 15% upvotes respectively, both proposal B and C are valid but only C will proceed to the exploration period, since it has gained the most upvotes.
*Note that this does not introduce other changes to the proposal system, the other rules remain the same, for instance:
- Given proposals A, B, C, with 5%, 5%, 5% upvotes respectively, although all 3 satisfy the minimum % of upvotes required, they will draw and the the process will be reset to a new proposal period.
The Code
This feature is open-source and can be reviewed here: https://gitlab.com/nomadic-labs/tezos/merge_requests/71
Final Remarks
In Part V, we describe another feature we are working on, which aims to prevent a potential spam vector in the Tezos on-chain governance process, by adding a minimum of 5% of upvotes for any proposal to be considered valid in the proposal period.
This feature, just like all other features, will be proposed in the upcoming proposal period. Nevertheless, it must be voted by the community to be adopted.
