At the time of writing, the current voting phase for the Ithaca amendment should end very soon. As there is a possibility that the amendment will not pass the current Exploration period, the next voting period may be a Proposal period.
We would like to take this opportunity to present a revised version of Ithaca that addresses technical matters around the performance of metadata RPCs and which fixes potentially buggy error messages in those RPCs.
This proposal will be made available very shortly, and we invite people who would like to inject variants of Ithaca to rebase their patch on this updated version.
We heard interesting proposals to improve the liquidity baking escape hatch mechanism, and we are keen to explore them for a future proposal, but these take time and consideration to implement safely.
As the Exploration period comes near its end, we thank the many bakers voicing support for this proposal.
The escape mechanism should take into account the quorum, thatâs like 50% of voters. If you require 33% of votes for an escape hatch, then that should be 15% of all bakers in reality.
So long as it provides a better measure of what bakers want, as opposed to complicating things further. Would it be possible to allow bakers signal in support of LB thus negating an equivalent amount of the escape hatch vote?
Would you be open to sharing ideas about other signaling methods besides the escape hatch that you have explored? Also what kind of timelines we would be looking at to implement those methods(approximately of course). I understand reinventing the escape hatch is not simple, but communicating ideas would help people understand your end game and possibly spawn new ideas.
33% does seem rather high. How many hours of work does it take to inject various proposals at 25% and 22.5%? Then let people vote on which one they want?
I donât agree that we need to reduce the escape hatch. As a means for bakers to cancel LB, 33 percent is not reasonable
But as a contingency/emergency escape hatch (which was how it was originally conceived), 33 percent is reasonable.
We already have 16 percent voting against LB. Just adding DLS and other big baker like everstake and we are almost at 33%. I am confident these 2 entities will vote to cancel LB if there are critical bugs.
Thank you @NomadicLabs. We will follow this directive accordingly. Our upcoming proposal injection (Ipanema Amendment) will reflect this updated version of Ithaca.
@NomadicLabs Why is it so difficult to offer several proposals? Clearly the contentious issue with Ithaca is LB. If you want Tenderbake, then provide a second option that disables LB and use the âescape hatchâ in inverse (bakers signal they want to resume LB).
You guys have so much power yet offer so little choice. If youâre supposed to be impartial, then give us impartial choices.
Thanks to the feedback we got in the Ithaca debate we see a drawback in the escape hatch mechanism as a tool for signaling a will to continue or stop the subsidy: it does not distinguish the bakers promoting liquidity baking from the ones relying on the default behavior. This comes mainly from the lack of symmetry between the options and the lack of a âpassâ option.
Here is a summary of the changes I am implementing:
Rename the two available options to âonâ and âoffâ to avoid confusion.
Add a third âpassâ option. Pass votes are ignored in the computation of the exponential moving average.
Make this LB vote mandatory; thatâs in fact not a protocol change. It is a change in the baker daemon that makes it refuse to start if no vote option is provided
Make the whole mechanism symmetric by resetting the escape threshold to 50% and making subsidy deactivation non-permanent.
Also what kind of timelines we would be looking at to implement those methods(approximately of course).
It is probably a matter of weeks.
I understand reinventing the escape hatch is not simple, but communicating ideas would help people understand your end game and possibly spawn new ideas.
Thank you for opening this communication channel! I am very happy to get feedback on this. I shall soon write a TZIP draft to have this discussed a bit more formally.
I was about to say what posdog just said
We asked NL to submit a no-LB proposal which is a minor change but not to spend your precious time to rework the hatch if itâs enough for âonâ to be activated by the supermajority during voting
unless you see other benefits ofc (more bakers involvement?)
Sure an escape hatch should remain for emergencies, but that doesnât mean you canât also govern the feature using a similar signaling mechanism. The lack of reliance on such mechanisms is a common and valid criticism of Tezosâ governance system. Iâve talked repeatedly over the years of the importance of using fast signaling mechanisms to set economic parameters within safe range in the protocol, I invite you to hear those arguments.
When the escape hatch was implemented, it was built generically, on purpose, so that more signaling mechanisms could be grafted onto it to cover many more scenarios, such as gas instruction pricing for instance, cache size, etc. I have issues with the way this is implemented in Ethereum (yes, Ethereum has signaling-based governance of protocol constants) but this is primarily a matter of using better metrics, not an issue with the approach per se.
The original Tezos papers detail how the initial governance process is a kernel meant to give rise to a rich governance process. One of the main weakness of the current process is that it couples many things. It might seem, to you that making several proposals is enough, but this is because you only see two relevant options are LB or no LB. That is, however, not the case. There are dozens of economic changes and ideas embedded in Tenderbake for instance. A dozen different choices doesnât mean a dozen different proposals, it means 2^12 = 4096 potential different proposals. To avoid the combinatorial explosion, we need concurrent, independent, processes.
Itâs very hard to have concurrent governance processes for features in the protocol because code patches generally do not commute, but it is possible to have concurrent governance process for constants. This decoupling should be used whenever possible, and signaling mechanisms are probably the best way to achieve it.
The amount of inflation from LB to date is a bit less than 0.15%. You are right that, all else equal, inflation reduces the purchasing power of a currency, but you seem to be missing that, all else equal, 0.15% inflation reduces the purchasing power by 0.15%.
When I put {âliquidity_baking_escape_voteâ: false} in the voting file instead of âtrueâ I got the message âWill vote to continue Liquidity Bakingâ upon running the baker. Not sure how itâs counted though.
Can anyone post the math that proves that the new escape hatch mechanism will also have the 80% super majority rule? To be trusted, it should have the same 80% super majority rule. Thatâs what we all sign up for, and it needs to be 80% specially for economics decisionsâŚ
No, you signed up for a network where protocol upgrades are decided by the governance rules of the current protocol.
For a self-proclaimed objectivist you seem to be a big fan of using the word âweâ to speak for other people. So, in Ayn Randâs words:
âIt is the word by which the depraved steal the virtue of the good, by which the weak steal the might of the strong, by which the fools steal the wisdom of the sages.â
Indeed your depravity is patent to anyone whoâs observed your behavior and character over these past weeks. Try intellectual honesty for a change, you might like it.
Since now pass vote will exist with the escape hatch and pass votes wonât even be counted, there is no excuse to not set up the threshold like we have it now with the on-chain governance at 20% to veto stuff or even for an emergency. 50% is just crazy.
Fact 1, the quorum will be guaranteed 100%, because it is forced to vote in order to run baker, perfect good change.
Fact 2, pass votes wonât be counted for the nay/yay threshold, which is perfect too, like with the original 80% voting rule.
Fact 3, dispute vote between nay and yay voters have a threshold of 50%, thatâs the problem.
Another rigged voting system that wonât respect the 80% supermajority ruleâŚ
