Unit 410 is voting yay in support of the Tezos Carthage 2.0 amendment. As one of the largest Bakers powering the Tezos network, we’re committed to responsibly upgrading Tezos into a more powerful, usable, and resilient blockchain. After evaluating the Carthage upgrade and discussing with other network participants, we believe voting yay to be in the best interest of the network.

Babylon 2.0.1 in Hindsight

The Babylon upgrade was far from the smooth process that we first went through with Athens. Babylon had many changes but lacked an adequate testing or release process. The originally submitted Babylon proposal needed to be quickly replaced by Babylon 2.0 in the initial proposal period. While this is not a red flag by default (to some degree, bugs are unavoidable), it is clear in retrospect that adequate testing infrastructure, community, and networks were not in place, resulting in these proposals not being tested as thoroughly as they could have been. Following Babylon 2.0, two months into the currently lengthy amendment process, a new bug was discovered that would have caused unacceptable breaking changes had Babylon 2.0 been promoted. Several options were proposed for how to proceed; bakers ultimately coordinated off-chain to approve Babylon “2.0.1 with Conditional Hotfix” to successfully promote the proposal.

During activation of the Babylon 2.0.1 protocol, many nodes held Athens transactions in their mempools, causing nodes to halt and a slowdown of the entire network. An emergency fix was quickly issued to resolve this situation—again, requiring rapid off-chain coordination to steady the network. As Babylon proceeded in operation, a number of other, non-threatening bugs were uncovered—most notably of which was an integer division bug that caused a miscalculation of baking rewards.

Though the Babylon upgrade had its shortcomings, it’s important to note that the security of the protocol was never at risk, and the response from the Nomadic and Cryptium teams was both swift and practical. Keep in mind, Babylon was the first-ever fully on-chain protocol overhaul of a public blockchain—it’s understandable that it wasn’t flawless. This experience has taught the Tezos community a number of lessons that Carthage is building upon to raise the bar.

On to Carthage 2.0

Tezos is now in the final promition period voting on whether or not to adopt the Carthage 2.0 protocol upgrade. We view Carthage largely as an extension of the Babylon upgrade, rather than an entirely new protocol in of itself.

The Carthage 2.0 upgrade is mostly non-controversial code fixes and optimizations. In particular, it contains bug fixes for Babylon, including support for the COMPARE instruction to compare pairs in sets and maps (Babylon was supposed to allow for this), optimization of dead code that will reduce the gas cost of using the UNPAIR function (which was incorrectly implemented in Babylon), and the addition of an error message for a missing case when using the EMPTY_BIG_MAP instruction. Carthage also includes updates to Michelson, efficiency improvements to the CONTRACT instruction, and fixes to how the MAP instruction is interpreted at runtime.

In addition, Carthage contains two notable changes. First, the gas limit is increased. Specifically, the gas limit per operation and gas limit per block are increased from 800,000 to 1,040,000 and from 8,000,000 to 10,400,000, respectively. We support continuing to increase the capability of smart contracts that enable projects like StakerDAO and programmable staking.

Revised Reward Formala

In addition to fixing the reward calculation bug, the block reward in Carthage is altered to reduce the effectiveness of certain attacks while holding expected long-term rewards constant.

In the Babylon reward formula, the 80 XTZ total block reward (16 XTZ for baking + 64 XTZ for endorsing) is split between the baker and endorsers. Bakers receive up to 16 XTZ weighted by the number of endorsements and the priority of the block; 2 XTZ is given to each of the (up to) 32 endorsers. This formula was designed to incentivise the inclusion of endorsements and disincentivise selfish baking. However, forms of non-cooperative baking are still profitable under this reward formula when considering notions of profitability other than absolute rewards.

In Carthage, the reward formula is altered to grant up to 40 XTZ to the baker and 1.25 XTZ to each endorser. This change holds expected rewards constant and makes selfish baking effectively unprofitable for bakers who control less than 20-25% of stake.

While there has been some concern that this reward scheme would negatively impact small bakers, rewards are expected to converge to their Babylon-equivalent over the course of a few weeks (see below).

Building off Alexander Eichhorn’s work, the chart below shows the average change in rewards for a baker with a given number of rolls over 5 and 100 cycles—over both the short- and long-term, the impact is insignificant across the board.

It’s also worth noting that the Carthage upgrade has been tested more thoroughly than any protocol proposal to date. Carthage has had the Carthagenet test network up and running since before the upgrade was officially injected. This testnet included the first-ever dry run of the upgrade process itself, allowing us to catch any errors that may have occurred in the protocol transition phase. Carthage has set a new standard for how proposals ought to be tested.

There is no invoice for the Carthage upgrade. This follows the symbolic payouts of 500 XTZ in the Athens and Babylon upgrades, merely used to buy a round of drinks for the developers. Going forward, beginning with protocol 007, we need to start sufficiently compensating developers through the on-chain upgrade process to sustainably support decentralized development of Tezos.

Our Vote

Unit 410 will be voting yay to the Carthage proposal.

We view the Carthage upgrade as the obvious next step in the progression of the Tezos network. Following the imperfect but successful Babylon upgrade, the Carthage proposal is a conservative upgrade that cleans up errors and puts Tezos on track for more ambitious protocol upgrades in 007, 008, and beyond. Just as the Athens upgrade played an important role in ensuring the successful promotion of Babylon, Carthage represents another opportunity for the Tezos community to iron out kinks in its upgrade process before another major upgrade.

Carthage 2.0 and Onward

The power of Tezos is its ability to evolve as a protocol and community, a power derived from decentralized participation in Tezos’s governance process. Here, we see plenty of room for improvement to strengthen the process through which Tezos is governed.

Voter turnout in this upgrade process has been notably lower than turnout in Babylon and Athens. We encourage all bakers to voice their opinion through on-chain voting in the final phase of the Carthage 2.0 promotion process.

Unit 410 is incredibly excited for what is ahead of Tezos in 2020. Carthage 2.0 is the first stop on the roadmap. We encourage all bakers to continue voicing their thoughts and concerns (which we review regularly!) on the Tezos Agora Forum as we continue to pave the way for the future of the self-amending ledger.