You should have a read here: https://medium.com/tezos/there-is-no-need-for-hard-forks-86b68165e67d
1 Like
You should read the top highlight of his article.
We wish to avoid hard-forks because, as a mechanism for introducing innovative but contentious changes, they tend to be centralizing. We do not do it out of some weird intrinsic rejection of hard-forks . We value pragmatism.
Although, he also mentions this:
If buggy or malicious protocol upgrade passes through the various defenses of the governance procedure, not letting it permanently cripple the network is a perfectly valid reason to hard fork.
The bug did not pass through the last defense of the governance procedure, which is the promotion period, we still can reject it but people here are too impatient, I still think there is no rush.
1 Like
The question here becomes how do we in an on-chain governance fashion modify the on-chain governance mechanism to allow for midstream patching when bugs are found during the test vote period without violating the rules in the meantime and as we discuss how to move forward on Babylon 2.0.1?
The sticky issue here is that many would take issue with new code being applied to an existing proposal that was not there before. I am not sure how serious of a concern this maybe. I imagine developers, bakers, and teams within the ecosystem will somehow test the patched Babylon 2.0.1 containing the fixes within the promotional period itself before casting a vote. If new bugs are found or any other issues I will advocate to vote against the passage of Babylon 2.0.1 and recommend that Babylon 2.0.1 be reintroduced and that additional proposals be attached that would allow for the patching of code if and when bugs are found during the test vote period midstream as @Bitcom suggested a few days ago.
I am completely behind both Cryptium and Nomadic and have absolute confidence in their abilities to safely achieve what they have proposed with option B. However, I will instruct bakers who I provide assistance and ongoing consultation to not vote until the very near the end of the promotional vote period. This allows us to think longer about the situation and leaves us plenty of wiggle room for voting against Babylon 2.0.1 if the community is made aware of any new or old issues found in the patched code.
2 Likes
Reputation is also affected by A. For example, we have several companies and other devs specifically waiting on Babylon to either release their apps/features or things they need to move forward with development.
3 Likes
In line with what others have mentioned, I’m inclined to support option B, but will ultimately support whatever the community decides.
I do not feel it would harm the image of on-chain governance, as it’s still being decided via the governance process. On the other hand, I actually feel option A does more (short-term) damage to the image of on-chain governance, that we are forced to delay by 3 months over a tiny bug when there are developers and companies waiting on Babylon changes to release their apps or new features. In addition to what Gabriel said above, we are also working with other companies that are waiting on Babylon. And like Adrian said, this incident could repeat with future proposals as well.
Tezos is still a young protocol, and we have time to improve the governance process so that this doesn’t happen in the future, so I disagree that this would somehow prove that on-chain governance is flawed if we patch it. Either way, I agree with improving the process and allowing proposals to be amended during the testing phase or other such improvements already mentioned here.
Happy voting 
4 Likes
I agree wholly with @adrian’s analysis of the technical preferability of the possible outcomes. My position is that because of:
- The clear signalling before the promotion period began, that a vote for Babylon 2.0 is functionally a vote for Babylon 2.0.1
- The nature of the change as an uncontentious bugfix that would clearly be preferred in direct comparison with the original proposal
- The success at which uncontentious bugfix protocol changes have been twice applied in the history of Tezos without the slightest hint of forking the chain, acrimony, or loss of legitimacy of the main chain
- Recalling that externally coordinated hard forks are in fact critical to the continued evolution of Tezos, in the form of amended OCaml bindings for use by the protocol compiler.
That 1-4 constitute grounds for the ‘democratic hard fork’ (my suggested terminology) to be able to be trivially subsumed by an only marginally more expansive definition of the Tezos social contract than the ‘on-chain self-amending literalist’ view.
XTZ Antipodes therefore supports option B for reasons of expediency and ecosystem momentum, and will vote accordingly nearer the end of the period, barring further problems revealed in testing. Parenthetically, I also support exploration of changes to the amendment and testing processes to reduce the incidence of future events like this.
References:
On the Social Contract of Tezos
2 Likes
Based on what has been discussed here and also other information and materials available we will vote yay next week.
3 Likes
We prefer the pragmatic approach. This is software development and there will be a need for fixes. The governance process is to have a consensual agreement on how the chain will evolve.
Adding an extra 3 months just for the sack of “governance integrity” is something we firmly oppose. We need to keep the momentum and integrate further improvements within the chain and keep creating the incentives to encourage developers and companies to come to Tezos.
There was a statement coming from Banque de France that blockchain needs to have privacy features. We believe that currently Tezos is the best available proof-of-stake network. Once we have privacy features integrated within the protocol, we will have the best smart-contract platform.
For the next protocol amendment, we need to amend the governance process to better handle this sort of situation. We need a clear path to patch an upgrade during the voting process. A patch should be allowed as long as the substance of the upgrade is not changed or as ZHZ puts it: the fix does not materially change the meaning or intent or function of the original proposal .
We will vote yay by the end of this week.
5 Likes
we have the governance, and with consensus the hot fix will go ahead, that is all.
4 Likes
I am leaning to voting no. I get that it will delay things by 3m but my primary point is this, if we think the promotion testing etc needs to change then we should inject a proposal to change it. Using the argument that oh it’s just a small change sets a precedent that i feel is more dangerous than, “we will never allow another protocol upgrade, because we will always find a bug”
Tezos needs to last and grow for many many years, 3m is nothing. These are my early thoughts I have not finally made up my mind. but I am leaning towards NO.
2 Likes
For those that keep describing our current situation as a dangerous precedent, I would like to ask you to read more on the material published prior to the fundraise. The goal of Tezos governance is to make good decisions – hard forks are a fully legitimate and expected approach for the types of important (yet easy to fix without altering the intent or structure of the code) bugs found in Babylon.
People are free to disagree with the pragmatic over dogmatic intention of our governance, but please do so with full knowledge that choosing to be dogmatic runs counter to how our governance was originally intended.
Here are two relevant quotes from articles about the design and intent of the Tezos governance:
“However, there will almost certainly be hard-forks in the life of Tezos . Allow me to explain. There are circumstances in which changes to the ledger through the governance model aren’t practical and do not present any advantage over a simple hard-fork. In those scenarios, the desired change is typically uncontroversial and widely desired among the participants.”
and
"Principles
Principles are the moral code that governs the Tezos network. They represent the core beliefs, the foundational concepts, upon which Tezos is built.
Non-dogmatism
We value hard rules and will follow them to their natural conclusion, but not to their absurd conclusion. We believe in being consistent, but not foolishly consistent."
Here are just some of the relevant articles and video:
5 Likes
Good point.
I’ll open my hash commitment next week. For those of you who want to pre-commit to predictions about the content of my commitment, now’s a good time
6 Likes
Can you provide links to the quoted articles so we can do as you asked and read them?
I edited the post to contain links to relevant articles and video.
1 Like
If anyone’s interested, this opens the sha256 commitment:
you can verify by running https://pastebin.com/VWXHNGDN
TL;DR I’d go with A even though B has merit and nothing horrible will happen if B is picked.
I’ve been deliberately avoiding to weigh in on the topic of Babylon 2.0.1 because I think it’s important for the Tezos community to exercise its debating and governance muscles as much as possible. I am however pre-committing now to this short post so that it can be unsealed after a decision has been made.
The issue at hand boils down to a bug found in Babylon 2.0 during the testing period. The standard procedure in Tezos is to simply reject the proposal and, potentially, propose it again in the following phase. This has been dubbed “option A”. In addition, a non-standard approach was suggested, and has been referred to as “option B”. In option B, the Tezos shell is modified (requiring the coordination of all bakers) in a way that applies a hotfix to Babylon 2.0 should it pass the vote.
Before delving into my personal opinion on the matter, let’s get one thing out of the way: neither option spells doom or disaster. One option reinforces the stability of on-chain governance, the other saves valuable time at an important juncture of growing adoption. Reasonable people can weigh these pros and cons differently and reasonably disagree without being stupid or evil.
All things considered, I personally favor option A, despite B’s undeniable appeal.
The Babylon 2.0 proposal contains useful improvements to Michelson which change the way in which smart-contracts are developped. Introducing additional delays and uncertainty in the deployment of those changes can, in the short-run, negatively impact people building projects on Tezos. Option B has the merit of avoiding that delay with minimal disturbance to the on-chain governance process. For Babylon 2.0.1 to be activated under option B, it still requires a vote with an 80% supermajority. If that happens, it’s hard to make a serious argument that it fundamentally runs contrary to the will of the participants.
It is also the case that if the bug warranting Babylon 2.0.1 had been found after the activation of Babylon 2.0, it would have been patched with a shell update without raising any question as to the appropriateness of the procedure. It is a bit strange that catching the bug earlier rather than later can be, in a way, more problematic, but such is life.
So why favor A?
In a nutshell, I see A as a good memetic investment. The obvious short-term cost to A is the delaying of useful functionality, but the benefit is a long term strengthening of on-chain governance. I see the goal of on-chain governance as forming strong cultural norms and Schelling points around a decentralized process as opposed to a protocol set in stone. This adherence can only be demonstrated when adherence is costly when it represents a sacrifice. In the grand scheme of things that haved happened on blockchains, and smart contract platforms, in particular, this is not a particularly expensive sacrifice. There has to be a dose of irrationality in adherence to these norms for them to stick. B is the pragmatic choice, but I think we can get more mileage, in the long run, by picking A.
8 Likes
Pastebin link is dead, more permanently, here’s how to verify the hash:
#!/bin/sh
message=`echo -n "QlpoOTFBWSZTWbbswmsAAWBfgAAQUvdwWLUmnAA////wYAbfbKiX3fe3uOa7mTkGdjtTdsNAQmaj
TQmqep6TQAAZA0DU9BMRCZKeiNA09RoAAAYDQGgAA00GgGgDQM0kEEmAhqIHqA0AA9QMUUA000aZ
MRkNGmhoNGIwlNCaITTU9Uek0yekaGmgDQaGZjdwgZI7jxXNX+oHv8PtB8fGY+XB7pleS96OQr/h
BaDbLUSthq7zdrTEwz5RwoOFQJUZfrLKJVXyRvB7SqjlHrVeLaMNM4yCOPRLKxocJ9JOqmLgPhSm
a5p9moeckfxTY7B3lCFBy0zktDn6q7zxkVYyFTllba+jKbLz5xN0kQvgJR8Y4htKXE13846JSyoS
ONZFlS0X3NHEhpnmXi7s0mw260dBCUojSX35ZvKt3bO5yoniEp3LLUDi5F1i/YFunSVovpSFWz5E
wrqqcr5OCLnxumamZyGbXCxMzoGjRDc6cRz01gOqnlsErvWNuSLxdcTHHczTKpOgo2Rpuph1hEm8
8jzbD7C0lylbys2AnbVV2OjH5YSTml4YdGlhFB9ddKwgVwbIxjXt27x5+XJka/efVStvojx3aPoz
msbNmHpLw7gJsEOVkocbsorqEycPjDvY+21tbb2pROoAZ6nmk80SV2YTxaxIhe2GpBoQCCJI2/O/
kvSzerpP51ZC9bnuTGy67XoO7i6nB+6NYnhGQitppyr3PnPZnlHl+QrWGtR6qUopzsrMftqqpQye
+4mVGEyMzJ0CQlBLV2IzIK9dMheAkC73be2Whrqd50HBCIy6OmBuKA273TOcohAOnZoAgAvvaykE
OFWVEuTH3A8KHb+77q0tjRMkQmIaBLdLHCOTKtTpml6X8FjkGsrTNOlJGgsR+NHq0qDMVMxnS6s/
CMDxqoce/EXXqTc8/Tt4Vnf0xK1F01kGK8sh1VVU1rqLJcwY1iXVdEpSYlUyU9Jm7zSrdd8nDnWz
dE28J0gx/R/l612i2Vxsiac6iQewI6d7BOQzqmoFgKwiwq5mnLryUIlnmzYpYhxIDvtqziHtcJFb
oGtj6Lc27azkSFqQfZRnGd/M1ID54cSjrS7Ct8uvBl7AL9iA+yICkfl1OC2lt4eEcyByWbcTMCmY
HW1ixctDSC77aZF2UIQuNVIhNedJKLjE2DBJAnbsxQ5qJW6OKkKwlZCmMOoQUvtW25yUVPGB0H9Y
ODBykJUFgelQe45458+BpGEjQwB0IGAIjrLiqU4utvkyy2trCS2CIG4QajXCJOxFcXEbrlz7LL2E
ISB+StsVRkXeR9x8eqXQWVbp1XM15rocLbdeW2q5KgDA+kCIDA/FWWeerUPwwICXSojaFqJNjcj3
JbJa2Oy1pDTRqG0ROR2xrLUly0aJfKHO47nZkTbbOHcE0eeQjEVYO5cV28Cd0fGIzKsinKSqqqQp
1VpZWUdECvO9WNqI09WrWwhgrpAJAmCF74VlqjDdCaBA1hipAYFa6dSlaqhdRwULUoayi0wTdp8Q
Gvt5cAyJc7768r4bfj4Lv3v6+NouDe6ewCYuUiXrKQCK464VZXES5fBJvuKFRU/CGYE8eShNS1PM
e1MA+ANxHtAQKcGWBOwV4ai9x1U+gWRtwQmq7Qd6UIdoHJl7GJjLcw72hy3oxKJaYbshAkOWiYbw
TDoqTtQ0UOhDExCyfFZvtXU5ixer6W0cRKoNJjF9KcehF78tNjT1VttEt8qOJDWU9gE7G8zfA6gK
Cj3+RFcvNJFxz7X3MZZfb01xO620+SwGhQHpKqWTK4VDmIZjOb8QuTK52GEBQaBQtIciYoos4YQY
p8Du2pkaEYIRndE7KbOOSnJNrmiM3aCVRKMKgE9VKhma6qvMQ64IS5dppFNUp045cnJ0iUP1uuM6
6lVcIYGN3mZHTBBnOi0yQqtOc+cZQOYSfVlVi4w6A2qU4CAuYkXHNr8zFYEreOuIf99bnCUuy2Vk
e2Bd/VIkUWdBXYoMxMS1kM2Ixquo5kh8JNAZCKjzYkMFJgSZkIZK9FMc0cC60yzsWtxiIJIrt7zb
ZL/xdyRThQkLbswmsA==" | base64 -d | bunzip2`
echo "$message"
echo "$message" | sha256sum
3 Likes
My message above contains its content
1 Like
