Babylon 2.0.1 (PsBabyM1)

Proposals
1

Includes Emmy+, delegatable tz1 addresses, Michelson upgrades to improve compilation from high-level languages, hardened governance mechanisms, and more. Fixes a bug affecting big maps in smart contracts and a minor regression affecting the trace_code RPC.

Features

During the testing phase of Babylon 2.0 (PsBABY5H), two issues were identified (more details here). The tezos-node in Nomadic Labs’ Mainnet September 2019 release contains a corrected version of Babylon, Babylon 2.0.1 (PsBabyM1), that will be activated in place of Babylon 2.0 (PsBABY5H) if the promotion vote is successful.

Otherwise, Babylon 2.0.1’s changes to Tezos match Babylon 2.0, including:

  • A new variant of our consensus algorithm, Emmy+, that is both more robust and simpler to analyze
  • New Michelson features which assist Tezos smart contract developers and designers of higher-level languages (e.g. SmartPy, LIGO, Lorentz)
    • The changes made to Michelson in this proposal intend to simplify smart contract development by making the code of complex contracts simpler and cleaner.
  • An account rehaul that establishes a clear distinction between accounts (tz1, tz2, and tz3) and smart contracts (KT1)
    • Makes implicit accounts (i.e. tz1, tz2, and tz3 accounts) able to delegate and KT1s are for contracts
    • Replaces KT1 accounts with formally verified KT1 script (with same semantic)
  • Refinements to the quorum formula and a new 5% proposal quorum
    • A Proposal will require 5% support in the Proposal Period to proceed to the Exploration Vote Period
    • The Quorum floor will be set to 20% and a Quorum cap set to 70%

Explanation Posts

Migration Resources

Invoice

500 ꜩ to a multisig at KT1DUfaMfTRZZkvZAYQT5b3byXnvqoAykc43

Proposal archive

10 Likes
2

See also the conversation at Babylon 2.0

2 Likes
3

Option B discussed in the Cryptium’s On Babylon 2.0.1 post is the least attractive. It short-circuits the legitimacy of the on-chain governance process. It would be more useful to show restraint and respect for the process by either letting the proposal succeed as is and deploying P005 now and then submitting P005.01; or letting P005 fail in the promotion vote and then submitting P005.01.

It is a shame to some extent that this issue has come up. Cryptonomic is done updating the dev tools for P005 and we’re nearly complete with the product side of things (Galleon, etc). At the same time, it shows competence that this issue was discovered before deployment. It would further lend credence to the platform if we collectively show that we respect the governance process.

If it turns out later that the current governance setup is not ideal, the community can propose changes and then vote on them.

3 Likes
4

The Medium article goes to great lengths describing the issue and potential solutions which is appreciated. What was not discussed is potential adjustments to the governance model in order to allow for patching midstream, without the introduction of new features. My initial reaction is to recommend not attempting to override our current governance system. Open to hearing out others in favor of the update.

2 Likes
5

B is a no for me. I can see all the media news TEZOS HARDFORKS! IS not like i’m an irrational on-chain governance anti-fork maximalist but i’d like to keep on the same incorruptible trend (which appears to give the sense of “security” and “investors confidence”). Option C will also create some FUD because of the broken smart contracts. We also cannot fail developers like that, we can’t break their contracts just to take shortcut C.

A is the slow but steady responsible approach.

If we choose A… For example, in the next voting period can we inject the fixed babylon code upgrade plus whatever new features we consider to add like zk-SNARKs? IN the same proposal?

6

I’m consciously not weighing in on this debate, though I will post a precomitment hash to a few paragraphs on the topic.

Regarding the broader point that @Bitcom is making, here are two simple ideas to mitigate the impact of discovering issues during the testing phase:

  1. Allow the testing phase to be called off and for a proposal phase to restart right away. This could be achieved by having the initial proposer pull the proposal, and / or some threshold amount of participants approve ending the test. This could cut the time by 25% to 50%.

  2. Shorten the exploration vote period, lengthen the testing period.

10 Likes
7

1 is interesting.

8

In addition to #1 and #2 is it viable to allow a proposer to submit a hotfix during testing? Idea being it would merge with the existing proposal code. This would allow bakers to vote whether to restart the testing period with the hotfix code under testing or start a new voting cycle. It could minimize time lost due to a faulty proposal.

6 Likes
9

I will vote for option A with 12 rolls! I believe is the BEST option for the long term success of Tezos. Let’s make things right guys, do not take any shortcut. A is voting nay for Babylon.

2 Likes
10

An important step in determining the best course of action is to properly understand and describe the system we currently have.

Your use of all caps “hard forks” suggests you are failing to realize that we have already forked in this manner before and that we will again. It is how we apply important fixes.

The 3 month governance is not intended to be the only mechanism for modifying the software. Once we all understand this important point, we are better able to view the pros/cons of A vs B. But this idea that we should be worried that the media will complain about our hot fixes is misplaced.

I applaud Nomadic and Cryptium for identifying these issues and bringing them to the attention of the community. Now we can decide if the fixes described are really “patches” or in some way fundamentally alter the proposal such that the prior votes are effectively invalidated. But our current software upgrade process involves both hot fixes and amending through governance and we shouldn’t shy away from using both as needed.

1 Like
11

I agree. It’s probably best to re-propose Babylon 2.0.1 with an additional adjustment to the governance model to allow midstream patching as Bitcom has suggested.

3 Likes
12

The problem I see is that the potential damage for smart contract developers everybody is talking about is very abstract to most part of the community. In order to make this conversation constructive, we should probably ask those developers who will be affected in any way by this bug is it really a blocker for them. If it is, let them express their concerns and let the community decide if the cumulative value these dapps may bring to the ecosystem worth the hotfix.

As a side result, we get a slice of the current state of dapp development, which would be good news by itself :thinking:

Now a bit of numbers. Of course, I couldn’t look into individual sandboxes, but I was able to check the mainnet and alphanet for contracts that are using big maps and was active during the past week (last 7 days).

In the mainnet there is only ONE such contract, it’s our atomic swap implementation :sweat_smile:
In the alphanet there are 16 contracts (I’ve filtered different versions of the same contracts), these are mostly token implementations (by Morley team and others), b9lab test assignment, our swap again, and several more with unclear purposes.

Right now I’m aware of only four apps that are going to be launched in the mainnet in the following three months: Bakers registry, Сortez spending limit, Dexter, and our swaps. There are definitely more, please show yourself :slight_smile:

3 Likes
13

When and where should those who are interested expect to find your precommitment hash?

14

This makes perfect sense to me. The testing period should be modified to handle this predicament of a newly discovered bug. As I see it that should be one of the functions of the testing period.
Bakers should then vote to give the community’s permission to add the patch. The community must have the power to decline. If a consensus is reached a new testing period should begin to test the proposal with the patch included.
Seeing that this situation happened after only two amendments we will likely see it happening repeatedly in many future amendments as well and we should be prepared.

3 Likes
15

If in the normal course of using our chain we had discovered two bugs that needed to be fixed urgently, it would likely be uncontroversial to fix by hard forking the code by social coordination ASAP (“out of band,” meaning outside the formal governance process). It seems what makes people deeply uncomfortable is that these two bugs have happened “in-band,” and it appears to subvert a constitutional process. It would be something like if the US House of Representative passed a bill making 29th Feb “each year” OCaml Coder’s Day, a technical fault is committed which no one sees (stupid example, but run with it to the end of the argument). It gets to the US Senate. The Senate flags the error, and amends the bill to 28th Feb “each year.” In the normal course of constitutional process this bill can not be simply changed in the Senate and passed and somehow it becomes law. A new bill has to be introduced, passed in the Senate, and resent to the House to pass as written. Something similar has happend in our governance where in Option B we fix the error, the Senate passes the bill, and it becomes code law. From a clear, sound, strict construction, constitutional perspective, this is a violation of process and it sets a disturbing precedence, because while something can be done for ad-hoc expedience, at some later time, that same expedience can be abused and lead to unintended consequences. The reason I support B, fix the flaw in-band, and let the voters pass or reject in the “promotion” phase, is that we all agree that there is such a thing as a hot fix outside of governance (something in US law like an emergency declaration by President Lincoln to suspend Habeas Corpus; a kind of exigent act that in the normal course of law would be illegal). So I support B: 1) because we recognize hot fix; it just happens that the hot fix is happening in-band; 2) and here is the more important thing, the fix does not materially change the meaning or intent or function of the original proposal. For instance, if some economic constant were suggested to be tweaked for “efficiency” in the hot fix, I would in dire straights be dead against such an in-band “fix.” I would consider it manipulative, illegal, unconstitutional and subversive, because it is a material breach. I can appreciate how we want to not mess constitutional process, to do things cleanly and with respect for established, prior, social commitment, to chase chaste and pure as a couplet of ideological talisman. But we live in a world of ambiguity thrown full of yet unhandled exceptions. There will come a time, if not now, a soonish later, where we will again face a sharp subtlety that will test our commitment to purity; this never ends. Asymptotically, in governance, you will reach the point where you “betray your revolution,” or exchange one charismatic asshole for an ever more charismatic asshole, because, why not? Even Spaghetti Monsters are eventually found to be incompetent and at a surfeit of flaws. There is not a system that will not eventually prove your hypocrisy, using informal methods. So, I urge flexibility, practicality, a measure of reasonableness in approach to problems. For these reasons, I support that we hot-fix in-band and pass Babylon 2.0.1, as hash-amended without material change. If however, we wish to respect our constitution in strict construction and respect of process, in a rarefied purity among the lesser angels of heaven, and refuse the in-band hot-fix and restart the process, I’m OK with that. I only remind you that there will eventually come a time when exigent is so profitable that you will willingly let the angels fall for profit.

6 Likes
17

I just don’t think we should proceed with B. We should only use forks if they are truly necessary. This is not the case, as the solution to the bug is only 1 line of code.

I rather wait 3 months to fix the bug, implement midstream patching and if possible any other new features that were suppose to come after Babylon.

1 Like
18

Honestly I don’t have a position on the hotfix question, but I would make it a priority to implement a way of restarting the testing phase with a patched version as mentioned in previous posts.

======

A proposal gets promoted to testing period:

Bug is found by issuer or someone else, issuer can submit patch request, then:

:point_right:Patch request is voted:

If yay, testing period restarts with the patched proposal.

If nay, testing phase continues normally and then it can be promoted without modification or rejected.

4 Likes
19

I’m for passing Babylon with implied hotfix.

While not ideal, I’m not seeing any underlying principle being broken in requiring an out of band patch because governance is still used to reach consensus.

I like Bitcom’s and Murbard’s comments on possible future adjustments.

20

I apologize for the length of this. If you just want a TL;DR, please see the final two paragraphs.

Honestly I’m of two minds on the subject. I think both options are reasonable and justifiably valid ways to move forward in this specific instance. That said, there are a number of things about option B that make me uncomfortable. Meanwhile, the only reason I can think of against option A is my impatience for the new features I feel are (or were) on the verge of being activated on the chain.

Let’s all remember that we’re discussing a patch to Babylon 2.0.0. The 2.0.0 implies that there was a 1.0.0. Indeed, just a few weeks ago there was seemingly unanimous support for Babylon 1.0.0. Then they decided to add more to it and submitted Babylon 2.0.0 during the proposal phase. Did these bugs exist in Babylon 1.0.0? Based on the information I can find, I think it seems likely that they did. Nevertheless, there was a fair amount of confusion in the community about what exactly changed between Babylon 1.0.0 and 2.0.0. Nomadic Labs updated their blog post, but didn’t detail the changes. They just said the instructions in the post (on how to verify the hash and vote for the proposal) were updated. IMO, things should have been more clearly communicated.

In other words, this amendment period has been handled somewhat poorly from the start. We’ve gone from 1.0.0 to 2.0.0 to 2.0.1 in a single amendment period. And with just a few days left in the testing phase before we’re supposed to vote for or against it, how can we be sure that even this patched code doesn’t have other hidden bugs that haven’t been discovered? Rapid/Agile development has its place, but I don’t believe that the Tezos protocol is the right place for it.

Perhaps it would be prudent to go with option A and vote nay during the promotion phase in order to drive home the message even further to Cryptium and Nomadic, as well as anyone else who may submit proposals in the future, to slow down and make sure that the proposed changes are thoroughly vetted and clearly explained/documented before proposing them.

It seems as though patching the proposal in the middle of the amendment process can set a nasty precedent and send the message that there’s no need to worry about code quality since it can always be patched later if something comes up.

Yes, emergency patches have been done in the past, and will likely be done again in the future. These are perfectly valid and desirable ways to improve the protocol. However, this is not an emergency. This is the testing phase doing what it was designed to do: test to make sure the new code works as intended and doesn’t break anything. The result was that we found out that the new code does not work as intended, and it does break things.

This event has brought up many wonderful ideas of how the amendment process itself can be amended in the future so that a similar situation doesn’t delay progress on the chain as much as this one will if we go with option A. That’s all well and good, and I am in favor of some of the changes that have been suggested in that regard.

But as things are now, with the amendment process designed the way it is currently designed, it seems the most correct thing to do is to vote nay for code that doesn’t pass muster during the testing phase.

In two or three years, a three month delay now will be long forgotten. On the other hand, I think it’s plausible that going for option B could irreparably damage some people’s trust in the amendment process as well as damage the reputation of Tezos for many years to come. If people feel the rules have been subverted, it could drive people away from Tezos and onto a Tezos fork (such as Dune). I can’t help but see some parallels to Ethereum’s “The DAO” hack and its resulting schism. Option B could result in there being a Tezos and a “Tezos Classic” in the very near future.

In short: I am not aware of any argument which sounds reasonable to me in which option A can be considered “illegal” (i.e., subverting Tezos governance), immoral, or unethical. But I do think that some people would reasonably find option B to be “illegal,” immoral, or unethical, even if I personally find it to be justifiable in this specific instance.

For these reasons, and probably many others I won’t mention because this is long enough already, I am inclined to err on the side of caution and support option A over option B, and vote nay during the promotion phase. While I fully respect and feel I understand those who choose to support option B, I think it would do us all well to temper our impatience for the much desired features upcoming in Babylon. Let’s make sure that Babylon works correctly and that it gets passed through the amendment process in a way that does right by all citizens of this commonwealth.

2 Likes
21

First of all, the bakers decide, so I have no vote on this.

But in my opinion bakers should vote “Nay” in the promotion vote. The testing phase caught two issues, so the system worked accordingly. Just inject the Babylon 2.0.1 proposal during the next proposal phase. I don’t believe there is any rush!

2 Likes