Unit 410 is voting yay in support of the Babylon 2.0.1 Tezos amendment with the Conditional Hotfixes. As one of the largest Bakers powering the Tezos blockchain, we’re committed to responsibly upgrading Tezos into a more powerful, usable and resilient blockchain. After much community discussion we believe this to be in the best interest of the network.

Upgrading with Fork Resistance

It’s helpful to start with why on-chain governance exists in the first place.

As a network that’s only recently turned one, we believe continuing to scale Tezos responsibly is necessary for the project to remain relevant to both end-users and developers. Successfully upgrading such a network can be thought of as an optimization maximizing both usability through upgrades and fork resistance.

Attempts to scale by older networks with off-chain governance or strictly through social coordination have been notoriously plagued by in-fighting resulting in project stasis or high-profile forks when two opposing views on what to upgrade results in two teams splitting into two separate networks.

As the Self-Amending ledger, Tezos was built with an on-chain governance process that’s codified in the protocol. Every 3 months new ballots can be proposed through the Tezos protocol, followed by a voting process designed to result in a single upgrade or no-upgrade decision. This on-chain governance cycle was in part designed to optimize this combination of usability and fork resistance. Which leads us to Babylon 2.0.1.

Babylon 2.0.1 and Conditional Hotfixes

Babylon succeeds Athens as the second on-chain upgrade proposal. Where Athens was a trivial change of constants that successfully activated in May, Babylon is anything but trivial: our first real test of maximizing usability through an on-chain upgrade.

Roughly 2 months into the 3 month voting process for Babylon a small and obscure bug was detected in contract execution of big maps, resulting in a severe performance degradation for new contracts and breaking functionality in existing contracts.

Upgrading to this unusable state breaks what we’re trying to accomplish with governance and is clearly not a good option to vote for as-is. While we could then vote Babylon in 4 months later in the next upgrade process, delaying 4 months would be a long enough delay to encourage our developer community to explore new projects. Not good.

The proposal’s authors including Cryptium Labs, Nomadic Labs and other developers responded by proposing an alternative option to stay on course while fixing these bugs: Vote in Babylon 2.0.1 but as soon as the upgrade passes, automatically patch (i.e. change) the protocol’s code to fix this bug. The “Conditional Hotfix”

On/Off-Chain Coordination

It’s our position that coordinating critical bug and security fixes off-chain, so long as they match on-chain sentiment and align with our intent to maximize upgradability while minimizing the likelihood of a fork are perfectly compatible with the goals of Tezos. On-chain coordination is just much cleaner.

In this case, the “Conditional Hotfix” was proposed with ample time for the community to evaluate and doesn’t change any of the intended functionality that has been front and center throughout this upgrade process. Furthermore, contract usage on Tezos is still quite small, and we expect it to remain small until the features in Babylon are passed.

Community Reception

We believe Babylon’s new functionality is significant step forward for the Tezos project, particularly the improvements to Michelson functionality that make smart contract execution more powerful.

We also believe that outreach, debate and off-chain coordination over the past several weeks has established that the majority of network participants will support (or not oppose) an upgrade to Babylon 2.0.1 with the Conditional Hotfix. We’ve been in good touch with many community members, exchanges and large holders over the past month and as of the writing of this post:

  • 73% of the network is participating in the vote
  • 91% of voting power is in favor
  • Only 3 of the top 50 bakers are voting nay
  • If all of the remaining top-50 bakers stood against Babylon, 77% of the voting stake would still be in support of the amendment

Also interestingly 8 of the top 50 voters don’t appear to be participating at all in this upgrade process. We encourage all network holders, particularly such large holders to actively participate!

Our Vote

Because this proposal meaningfully improves the capability of Tezos, minimizes the likelihood of a fork and has been well tested by several engineering teams including ours, we have therefore cast our vote in favor of Babylon 2.0.1 with Conditional Hotfixes and are eager to see the final results

Babylon is scheduled to be promoted, or vetoed on October 15th and we encourage Bakers who have yet to vote to carefully consider their options and vote towards what they believe is in the best interest of the network. Below we’ll expand on our voting rationale.