Protocol hash PsmarYW3qFVZUNYwJaYvPEYG96N3awx5SpYs3PxiAWmCzRBAhY8
Given the current discussion around liquidity baking I would like to present a version of granada with LB disabled by setting the sunset block to zero:
this has been tested in a sandbox and I encourage you to test it too, instructions can be found here:
This idea was first proposed by @keefertaylor, I am not associated with him or any core developer.
I have read this code and I believe it to be correct and achieve the desired outcomes. I believe, to the best of my knowledge, that this is a legitimate proposal.
I do not, however, know this person and I encourage the community to validate the code on their own, rather than trusting my opinion.
It is now up to a baker to decide if they wish to inject this protocol. Perhaps if @Mariella is feeling generous, they can provide the exact steps for less technical but interested parties.
- You should vanity the hash so that it starts with G to keep things consistent. PsGmarY for example
I’ll leave this to the proposal author, but it is just a vanity hash.
- Why even leave the LB code in? Wouldn’t it be best to completely remove that code rather than keeping the code in?
I cannot speak to the author’s intents, but I would generally think:
This proposal is a no for me considering there is an escape hatch feature and sunset period for LB. This proposal is useless and a waste of time.
Onwards to Liquidity, faster blocks, and cheaper gas. Tezos will be a monster after Granada.
It is my understanding that this proposal has been injected in Operation oo1SPm..TB7b on tzkt.io. This proposal was injected by baker TezosRus and written by an anonymous protocol developer, based on ideas I have presented.
As I’ve stated before, I think it’s important that bakers have the final say in what features they want to uptake this proposal period. I would like to see an additional asset presented for liquidity baking consideration as well (and have outlined that here). I am open to helping interested developers put forth a proposal.
On a personal level I’m proud of the community for rallying to give ourselves choice and I now think it is up the bakers of Tezos to decide the upgrade path. Competing ideologies and options truly produce a digital commonwealth.
Importantly, as an individual, I have advocated for options around liquidity baking. I will remain neutral on whether I think this proposal, the previously injected Granada, or protocols injected in the future are a good option for the foreseeable future as I am advocating for process, not politics.
I’m going to attach a brief description of how I see the proposal here, as I do not know, but do not suspect we will hear from the protocol author again. I know others will have opinions too - please feel free to respectfully weight in.
Fundamentally, this proposal represents and upgrade path to Granada for users who wish to uptake common sense improvements (Emmy* and gas improvements) while removing the liquidity baking functionality. Essentially, non-controversial and controversial features are decoupled and able to be accepted a la carte.
To accomplish this, the protocol code makes a simple change to a global constant. Liquidity Baking has a built in block height where it will turn off defined as a constant. This proposal removes liquidity baking by setting this height to 0, meaning that liquidity baking will technically be in the protocol, but off by default. While not the most elegant, the author of this protocol seemed to value simplicity, safety and review-ability. The author helpfully included options to spin up a sandbox to prove the protocol worked.
There have been many discussions on liquidity baking (mostly here). Some concerns that have been raised:
I agree with some of these concerns and disagree with others. I am sure I am also poorly summarizing some of the multitude of opinions presented, and invite discussion.
A vote for this proposal does not necessarily mean that a baker does not support Liquidity Baking. It could also represent an objection to the processes used for asset selection or protocol formation. It could also represent a vote to slow the pace of Liquidity Baking and re-examine asset selection, economics and to re-propose this feature in protocol H. It will fall to bakers to liaise with their delegates about the best path forward, and for delegates to align themselves with bakers who represent their views.
Most importantly, this proposal elevates bakers from rubber stamps to being having options for new protocols and makes them the true stewards of the network, rather than relying on decisions from core developer teams or RFCs with poor participation [1]. In that role, Bakers will have to weight the tradeoffs, precedents set, and risks they are willing to accept for the benefit of the network.
[1] I think there is both a visibility problem and participation problem we need to discuss here as a community, but at current time it is obvious that there was a fair amount of the community who did not participate in the RFC/TZIP process and who have feelings.
(Edit 1: Fix missing link, baker name and grammar)
(Edit 2: Clarify Bitcoin Suisse is part of a consortium)
I did put some thought into the name, I wanted it to start with P*mari, but I had limited time and could only write a very simple bash script as vanitygen that called the tezos-protocol-compiler -hash-only ... and performed extremely bad even on GCPs largest instances, I assume the existence of an optimized vanitygen that core-developers use otherwise things like PtGRANAD seem impossible. I think protocols by core developers can follow a naming scheme, future proposals that have been modified or created by community members should stand out, when core-devs come to the M proposal, they can still differentiate with uppercase M. That being said the change I made was minimal. I do not want to take much credit, I also think the first proposal however small by a non-TF-funded entity deserves at least some differentiation? Not at all an obvious decision.
Regarding keeping the LB code in, @keefertaylor’s assumptions are correct that was also my thinking, I want to emphasize I very much like the fact that LB is still in the code, with it it becomes obvious how future (small?) projects can use inflation funding if they want to stay completely anonymous or decentralized and don’t want to apply for TF funding for whatever reasons.
Regarding a better explanation for less technical folk, I plan to do that within a day or so.
This is entirely suspect to vote for a proposal by an anonymous developer with no information except “trust us”. This proposal is valuable as the other meme proposals.
Anyways vote with your rolls and choose the one that benefits the Tezos ecosystem as a whole and the ones that have actually helped Tezos in good faith.
This is a four line change. Only one of those lines is a change in a variable’s value. It changes one variable’s value to 2_032_928l to 0l. The other lines are the hash of the protocol, and a comment that is inert.
Helpfully, the protocol author included both testing instructions and example code that also proves the correctness of their code. Generally, this is a sign of an experienced and careful engineer.
The nice thing about a multi phase governance proposal process is that there is both a testing and exploration phase for exactly this purpose.
In my opinion, this take represents FUD from a one day old, anonymous account. I understand that @Tezla has strong opinions, but I wish they’d be presented with slightly more care.
A protocol with liquidity baking feature completely removed from the code (and a vanity hash 
) has been injected. Its hash is PtGRENLBgC4kALRCjYwBAgDNSvK9ZDCst7cRQ1aNP9Ke1cZDwnY.
You can get it on my fork on gitlab but you should also be able to ask your node to fetch both the protocol with and without liquidity baking by tezos-admin-client fetch protocol PtGRENLBgC4kALRCjYwBAgDNSvK9ZDCst7cRQ1aNP9Ke1cZDwnY, tezos-admin-client fetch protocol PtGRANADsDU8R9daYKAgWnQYAJ64omN1o3KMGVCykShA97vQbvV and compare.
Remember, if liquidity baking is NOT important for you, vote for both protocols with and without it! This way, the choice that truly have the biggest part of the community supporting it will go in the next phase and we maximize the probability to have the super cool improved michelson interpreter as soon as possible.
I guess that you are referring to this code base: Commits · GRENLB · ki rimoch / tezos · GitLab
Well done. I will build and test.
Is there a testnet up already?
Guess i’ll be voting for this proposal
Given the fact that LB has a switch in the original proposal, I dont understand why a second proposal is required.
I am not sure if LB on tzBTC would be beneficial for tezos or not, but still I would like to go with the experiment, if we didnt like it, we can all vote to turn it off anytime that we want.
Look into the signaling process to turn off the LB experiment. The effort to do so is imo harder than passing this LB to begin with. It will take a lot more than us not liking it to turn it off. It will take some kind of active or well known theoretical exploit to turn it off.
