Babylon 2.0.1 (PsBabyM1)

8b96d03e7bfe3f21875a8515699d5d6a1cbcfdb395ab6a8fc0de85960a4aca4b

5 Likes

How about hotfixing Babylon and, if it passes the Promotion Period, reinjecting and putting to vote the old (Athens) protocol once more? That way, if Athens is rejected, Babylon in its 2.0.1 form is democratically confirmed, albeit with a delay.

1 Like

There’s value in this kind of approach when there’s an emergency bug patch: act when needed, correct in the next vote if need be.

It’s not really the situation here though. This isn’t so much about whether or not people want to activate Babylon 2.0.1 since that’s implicit in the vote but rather over the relative importance of a strict, principled, adherence to the rules of on-chain governance vs. pragmatic expediency (or a pig-headed literalist interpretation of the rules vs. an unconstitutional shortcut)

5 Likes

Outside of an emergency patch there isn’t a need to violate the rules or develop shortcuts when we can change them. This sets a precedent that will be referenced in the future.

3 Likes

Hm, then how about downvoting whatever Babylon version is about to enter the Promotion Phase and instead applying the whole Babylon 2.0.1 as a “hotfix” as soon as the current voting cycle ends? It can be democratically legitimized/confirmed by reinjecting and putting to vote the Athens protocol in a following voting cycle. But then hotfixes are supposed to be for emergencies only, so probably not the best way to do it. And as Bernd says: there is no rush.

Here are my 2-cents.

As a developer of LIGO, I am in contact with multiple app developers, tool developers. Those people have mostly been waiting to use at least entry-points and are explicitly waiting for Babylon to start thinking of deploying stuff, using sandboxes until then. I believe people saying there is not a lot of demand for Babylon are simply lacking information.

However, I believe devs will shift to Zeronet (and feel frustrated in the process). I haven’t had much experience, but as long as Zeronet is reasonably supported and there is confidence that we’ll have the updates in the next round, it should be ok.

I personally think comparing Option B to a network split is misguided, given we can easily check if there is an hyper-majority agreement (>95% for instance) of the stake, and then do the vote with modified shell in case there is. In general, I believe off-chain votes of the bakers (or surveys, depending on the point of view) should be used much more often, and that this is not the right moment to start with this.

11 Likes

Crypto is a very competitive scene, we have already lost enough time with several past dramas. We need to be more agile if we intend to survive.
We are for option B, this hard fork is not contested, I would say lets upgrade the protocol by hard fork and social coordination this time and fix the testing phase and let it restart for patches in next governance vote.

1 Like

Right now, I’m for option A, even though I haven’t given it too much thought. I don’t think the Tezos project is in a rush, but I might be wrong.

There is no rush, In any case we are giving the Tezos Devs 3 more months to decide about what things are priority, if midstream patching or the other stuff.

How do you hold that view when you can see in this very thread that both options have supporters?

What you seem to be saying is that anyone who disagrees with you either doesn’t matter or doesn’t exist.

Bearing in minds all potential risks Bake’n’Rolls are still supporting the B option!

Both issues are minor and could be fixed by changing two lines of code. No need to postpone Babylon for another 3 months.

2 Likes

I’m going to outline the pros and cons for each of the proposed options (A, B, C) and close with my personal opinion and how and why I arrived at it.

Option A
This path suggests to vote Nay in the current promotion phase and reinject Babylon2.0.1 without any further changes in the next proposal phase.

This option is the principalled approach to the current governance mechanism. It says that “code is law” and that governance should adhere to the letter to the code. It’s a decent option that tries to preserve the purity of the Tezos governance process.
However this option has two large caveats:
First it postpones everything by 3 months, including amendments to the governance process. Some people suggested to inject Babylon2.0.1 + “some more fixes” and I am strongly against this. If option A is choosen, Babylon2.0.1 should be injected as is and without any further changes. Every further change introduces more code which results in greater chances for bugs. It’s important to remember that no code is ever bug free. We can do our best to reduce the chances for bugs to appear, but we can never eliminate that possibility.
Second it opens up a can of worms with regards to being too principalled with governance. Imagine that option A is choosen, and that in December during the testing phase we find another minor bug. Are we going to postpone everything by another 3 months and reinject Babylon2.0.2 in December? Given that software is never going to be bug free (there are probably bugs in the existing protocol that we just don’t know yet) it is dangerous to be too principalled, since it could result in never passing an upgrade.

Option B
This path suggest to vote Yay in the current promotion phase and include a hotfix in the shell to switch to the fixed protocol instead.

This option is the practical approach. It says that governance has a large toolset at it’s disposal and this option proves that it is willing to use those tools.
It’s important to understand that this option does not circumvent nor change the Tezos governance process. The hotfix only gets activated if 80% vote in favour and ~74.7% participate in the vote. Furthermore it does allow for obvious bugs to be fixed quickly which is especially important, since almost all large codebases will have some bugs.

Option C
This path wants to activate the buggy protocol.

This option is bad, since it will result in existing smart contracts breaking. A blockchain should be tremendously careful to break existing smart contracts, specifically it shouldn’t do so by accident. It is most likely acceptable to break something, if it was discussed and precautions were taken, but breaking by accident should be avoided in almost all cases.

Conclusion
My personal opinion is to go with option B. It is the practical approach, which is what is needed early on during the life of a network. It allows us to upgrade to a much needed feature set without having to wait an extra 3 months.
The second best alternative is option A. However here it should be clear that we should only inject Babylon2.0.1 and not attach any other changes to it. In my opinion this option will delay everything by 3 months for little benefit.
The worst alternative is option C. It breaks existing contracts which violates a fundamental tenent of decentralised blockchains.

Suggestion
If we were to go with option A right now I am worried that we may never pass another protocol upgrade, because of small bugs that are found towards the end of the testing/promotion period. Due to this I am suggesting that amend the governance process in the protocol upgrade after Babylon2.0.1.
The first option is to add a Fix_vote during the promotion phase. Anyone can submit a fix vote with a new protocol hash in that phase and if it gets accepted, then the protocol returns to the testing phase with the “fixed” protocol.
The second option is to remove the exploration phase in order to have the testing phase happen much sooner in the governance cycle.

The two suggestions are first ideas and can be iterated on over time.

11 Likes

I am pragmatic about this, I also support option B.

Also am in favor of the hotfix mechanism as described by Bitcom.

3 Likes

I think I would go with A (If I was a baker). As a hotfix would be a hotfix and I think we should refrain from it. For smart contract developers who want the proposed changes to be included asap, I think it would be better to wait and let the protocol govern in a way it is supposed to.
As mentioned by fellow members, to shorten the time during such situations, changes should be proposed in upcoming amendments.

I’m also against patching, even if it is a minute change of only one variable. But as others have also stressed here, it will set precedence and also sends a strong signal that the on-chain governance process can be easily bypassed.

Tezos represents itself as a secure platform for security tokens and already attracted some large actors planning to tokenise more than 1 billion USD on this chain. I believe, the reason these actors have chosen Tezos, is because they trust in its security model. We are not in a hurry and we should not violate this trust for short-term gains.

This incidence has also underlined why I’m against bundling of unrelated features in Tezos proposals, such as in Babylon. I had previously thought that these features would be injected as several proposals, including variances of these features on which bakers could vote on, similar to the method that was employed in Athens. I still find it disturbing that only one proposal was injected that includes all these features so that bakers do not have the choice to reject some unwanted features, but can only accept or reject all features.

In this incidence, bundling has proven to be insecure as including many features also allowed that a bug slipped the attention of developers. This could have possibly been avoided by only focussing on one single feature, similar to the BIPs in Bitcoin. The developers have publicly admitted that they have been in a hurry to push as many features as possible in this proposal. This is not how I wish future proposals will be handled and I think such attitude will do more harm than good to Tezos in the long-term. I have no problem with a slow development of consensus relevant features when this insures a stable and secure chain, in which everyone can trust for the years to come.

2 Likes

I’m a delegator so can’t vote, but i would choose for B. What if after 3 months another bug is found? Then we wait 3 months and somehow another bug is found, then a bug that can be solved with 1 line of code has delayed the project for 6 months! I believe the governance system should be more flexible and that’s why i choose for B

3 Likes

Do a twitter search with the keywords: Tezos Forkless

Several people have mentioned the word forkless next to Tezos, my self included. Should we dishonor that for 1 line of code?

Or should we promote fork based tezos updates now?

Yes, we should promote forks for bug fixes. it is stupid to use 3 months governance votes for bug fixes or performance improvements.
Hard forks are good when they are not contested.

2 Likes

It is not contested means that no one will choose to run the old chain if we hard fork. It is just stupid to run a buggy or outdated chain because you just want to upgrade 3 months later ! no one will support that.
We have no disagreements about the core protocol, it is just a disagreement about the upgrade procedure. All bakers will support the upgraded and more advanced chain.
Bug fixes should never need a governance vote, I say we should hard fork even more often for bug fixes or performance improvements.
Governance voting should be used for core protocol upgrades.

2 Likes

I would also agree that option B seems to be the best way to move forward, specially given that we’re in the very early stages of the network.

2 Likes