What Changes are Coming?

“Babylon” — the third proposed protocol amendment for Tezos was injected on July 26th, 2019 by Cryptium Labs in collaboration with Nomadic Labs and Marigold. A big step up from Athens, more developer teams are collaborating amongst each other to work on Babylon and there are some significant changes being proposed.

Since we’ve already discussed the nature behind the name given to the Babylon proposal, for the sake of deducing what changes are being proposed with Babylon, we will examine responses from key developers associated with the teams behind the proposal. Below in bold are questions I complied and following in quotation are provided responses.

With Babylon, a new version of the Tezos consensus algorithm, Emmy+, is proposed. Can you explain the motivation behind Emmy+ and how it entails a more robust and simpler to analyze consensus?

A. — et4te (RIOT)

The motivation behind it was to improve safety, efficiency and get to a step closer to guaranteed finality (rather than probabilistic). The simplicity of the algorithm is what makes it simpler to analyse from the point of view of constructing proofs — in Emmy we rely on probabilistic assumptions and game theory a lot. To give a concrete example consider that in Emmy technically bakers are not obliged to endorse a block (no finality). They do it because it pays (rational actors). In Emmy+ you need to provide endorsements to bake a block or you will miss your priority. Emmy+ takes some ideas from Tendermint which has a few concrete proofs, one of which we are constructing ourselves based on how it will work in Tezos.

Can you explain some of the significant improvements to Michelson that will enable easier to write smart contracts aided by Ligo, SmartPy, and Serokell?

A. — u/taebles (Reddit)

Michelson is a stack-based language, which means that its operations manipulate data that is present in a stack, which is a common data structure that operates in last-in-first-out order (aka LIFO). This means that you can only access the element that is on top of the stack. For programmers (and higher-level languages) convenience, there are new stack manipulation instructions that allow you to specify the “depth” at which these operate. While this was possible before, these operations will make it a lot nicer. A lambda is an anonymous function that we can apply to compute something. They can accept a number of arguments that you have to specify when you apply it. There is a new instruction that will allow you to apply it partially, which means that you don’t have to specify all the arguments at once. It is a common idiom in functional programming that aids programmers convenience. Entrypoints make calling contracts a lot nicer. You no longer have to know the full type of the contract’s parameter, only the part you care about. They will also automatically wrap the argument that you pass in to the call for you to match the full parameter type, if necessary. The other Michelson changes enable programmers to do things that weren’t possible to do before: • ⁠We are no longer limited to a single big map per contract

• ⁠Comparable types can be composed from other comparable types

• ⁠We can distinguish between e.g. mainnet and testnet with CHAIN_ID instruction

• ⁠Plus several improvements in gas accounting

Babylon seeks to enable an account overhaul to be able to distinguish accounts and smart contracts. Can you explain what this process entails and the motivation behind it?

A. — u/taebles (Reddit)

One of the main motivations behind this is to have a clear separation between regular (implicit) accounts and scripted (originated) accounts. At the moment, only originated accounts can delegate their funds to bakers, which means that if you want to delegate, you have to create originated account (without any script) and send funds to it. What we’re proposing is to enable delegation from implicit accounts, so you no longer have to do this. This enables us to make originated accounts truly dedicated to scripted (smart) contracts only. With this, we can also simplify originated contracts as the manager field and delegatable and spendable flags will become unnecessary.

On the last and final feature — quorum floors and caps, there has been intensive discussion and previous material released regarding the motivation behind inducing changes to these mechanisms. In short, through a simple eli5 style, Babylon seeks to enable a new 5% proposal quorum and quorum floors/caps. A proposal will require 5% support in the Proposal Period to proceed to the Exploration Vote Period. Additionally, a Quorum floor of 20% and a quorum cap of 70% will be set.

Adrian Brink of Cryptium Labs on Tezonomics: