I had some ideas for changing the Tezos amendment process and would be curious to hear what people think about this. These are just some thoughts that came to me as I was reflecting on the process, in light of some recent small controversy e.g. around liquidity baking / the Ithaca vote. I may be wrong about some things or other people may see things differently, so I’m really hoping to get a bit of a discussion going. On-chain governance is a key competitive advantage of Tezos, and while it has worked very well so far, I don’t think we should take that for granted and it does not mean it will always work well in the future.
- Supermajority requirement.
The exploration and promotion steps currently require an 80% supermajority for proposals to move ahead. By comparison, if the current Ithaca proposal is adopted (which seems likely), the Tezos consensus algorithm will switch to Tenderbake, which will require at least 2/3 honest participation in block creation to create consensus. I understand that consensus algorithms have a lot of math and game theory behind them, and that you cannot really compare this 2/3 threshold to the 80% supermajority requirement.
Essentially though, Tenderbake makes it so that you could attack the Tezos blockchain by acquiring 33% of the supply (slightly less, as not all XTZ participates in baking). Yet if you acquire “only” 20%, you can effectively also attack Tezos by fully blocking all network upgrades. In fact, you would need considerably less, because the quorum tends to hover around 50-60% (versus around 80% of XTZ participating in baking, last I checked), and most of those votes tend to be pass votes. The highest roll count in favour of previous proposals was 37 144 rolls in favour of Babylon (we are closer to 20 000 rolls for more recent proposals). You would have needed 9287 rolls against, or 74.3 million XTZ (8.45% of the circulating supply) to block this proposal.
Of course, if a bad actor acquiring such an amount of XTZ decided to start blocking proposals, you would expect a reaction from other participants, and the quorum would likely increase, or the foundation e.g. would start voting in favour rather than passing. However, the general point stands, and it is that we require a smaller majority for passing consensus than we do for passing protocol amendments (or other proposals).
Why do we not align these majorities? Generally, we can also note that a 2/3 majority is still a very high bar to clear and that this is by far the most common threshold required for amending constitutions throughout the world.
- Rules in the proposal stage.
To pass the proposal stage a proposal must meet a 5% quorum requirement and have more upvotes than any other proposal. I believe this simple methodology can create sub-optimal outcomes, either deliberately or accidentally. A good example comes from liquidity baking, where there was controversy both around the concept itself and the choice of asset to support. Imagine three possibilities: no liquidity baking, liquidity baking with tzBTC as the supported asset, and liquidity baking with USDtz as the supported asset, and further assume that the baking preferences are as follows:
35% LB tzBTC > LB USDtz > No LB
25% LB USDtz > LB tzBTC > No LB
30% No LB > LB tzBTC > LB USDtz
10% No LB > LB USDtz > LB tzBTC
A clear majority of 60% is in favour of some form of liquidity baking, but if all three proposals are inserted from the start, then the no liquidity baking proposal will win, simply as a consequence of the rules of the voting process. There are plenty of analogues in real world election systems, whereby a multitude of choices lead to sub-optimal outcomes or disproportionate impact of more extreme candidates.
The solution is simple: keep the 5% quorum requirement for proposals in this stage, but fork the proposal stage to either (i) go to the exploration stage if the most upvoted proposal has more than 50% of the voted rolls in its favour (i.e. no change compared to the current process in this case); or (ii) go to a “run-off” proposal stage where the 2 most upvoted proposals are pitted against one another. In the above example “no LB”, rather than advancing to the exploration stage, would first be pitted against LB tzBTC, and LB tzBTC would win, leading to an objectively superior outcome (in terms of how the majority preferences are taken into account). Run-off requirements are typical for electoral voting systems, such as the upcoming French Presidential election.
- Rules in the promotion stage.
Rather than more or less repeating the rules of the exploration stage, perhaps this stage could somehow be used to incorporate possible bug fixes. I’m on far less solid ground here, so hopefully people have some better ideas. But an option could be for the initial project proposer only to be able to insert a second proposal in this round, with bakers voting for one of the two and the supermajority requirements + quorum requirements applying as normal. In other words, to be adopted one of the proposals would have to meet the supermajority + quorum requirements, and a vote in favour of proposal A would effectively count as a vote against proposal B in terms of meeting the supermajority requirement.
Curious to hear your thoughts!
Swarles
