By Sunny Aggarwal and Nate Rush

The Tezos Initial Coin Offering is going on right now. It’s certainly one of the most hyped ICOs in recent memory, and this along with its uncapped nature makes it likely to be the largest crowdfunded project ever. (Author’s note: we were right.) Other than the large amount of money it is likely to raise, Tezos is a very interesting project. Its architects and designers have made a variety of unique design decisions that we attempt to explore in this article. Some may work well, some may not. All of them are very interesting.

When we first started this article, we focused heavily on (and were skeptical of) Tezos’s proof of stake algorithm, but we soon realized that its main value propositions instead likely lie in three areas: a ground-up emphasis on security, an automated built-in governance system, and a self-updating protocol. This article will briefly touch on the PoS proposal but will focus on these three main interesting aspects and attempt to give a comprehensive view of Tezos’s value proposal.

Emphasis on Security

Functional programming is cool. While many programmers are unaccustomed to it (us included), it can do a couple of really nice things, like allow for effective and easier formal verification. Formal verification is the process of proving that a program complies with a particular specification.

For blockchain platforms that will (hopefully) one day manage trillions of dollars of value, this sounds pretty nifty. Tezos takes advantage of this by being written in OCaml, a popular functional programming language, which will allow parts of the protocol to be formally verified. This is valuable, especially in the context of open source software, because it makes it easier to catch bugs that might have been added in by contributors, whether accidentally or maliciously.

It’s worth noting that formal verification is not a fix-all solution; it merely proves that some code complies to some specification, but who’s to say there isn’t a mistake in the spec?

Let’s compare this approach to Ethereum’s. Ethereum is different than Tezos (and Bitcoin) in that it is not defined through a reference client; instead, the protocol is defined formally in the Ethereum yellow paper, with implementation left up to client developers. There are trade-offs to both approaches. On one hand, a formally defined protocol allows for a diverse set of client software, such as the Geth and Parity clients, which may help the network be resilient against bugs in specific clients. It also means that Ethereum could see a client built in OCaml. However, this also opens up the possibility for disparities between clients. Such an issue has happened in the past, causing the network to split when there was a difference in the way the Geth and Parity client handled an edge case (see here).

As far as reference clients go, while there is likely not going to be a chain split due to differing clients (since there are no differing clients), this means that the protocol is defined by the code that runs it, which includes any bugs it may have. This is hopefully less of a worry with Tezos, though, because of the aforementioned formal verification. (As we will cover later in the Self-Updating Protocol section, the single client also makes the self-updating nature of Tezos far easier.)

It’s worth noting that OCaml is relatively more obscure compared to languages like Rust and Go, the programming languages of the two main Ethereum clients. To some degree, this could be a centralizing factor, as there are fewer programmers who could directly contribute to the client. Whether using a more esoteric language with fewer developers is worth the potential safety benefits is left to the reader.

In addition to the client code being written in a functional language, Tezos has also created a brand new VM that operates on a stack-based, functional language called Michelson. This runs quite contrary to the common trend in which new blockchain projects tend to just implement the EVM in order to capitalize on its popularity. Proponents of the the Michelson VM’s functional, verifiable nature claim it can help avoid bugs like the re-entry attack that caused the DAO hack and the explicit inputs could have helped avoid the ABI-bug that affected GNT and ERC-20 Tokens (see here). In fact there are now contests like the Underhanded Solidity Coding Contest with the explicit purpose of writing malicious smart contract code with “well disguised vulnerabilities that ensure its actual operation differs significantly from what the reader would expect”. Mathematically verifiable code may make these kinds of malicious activity easier to detect.

One criticism about creating a new VM is that there may be a learning curve for developers. However, the difficulty of a new VM can be resolved by creating easier-to-use, higher-level languages on top of it (like Solidity for the EVM). Doing this will require a lot of commitment and effort from Tezos. Creating Solidity and its associated developer tools (such as Truffle) was a multi-year project that took lots of dedicated effort.

Also, it’s worth noting that the EVM already has a bit of a following. It is, however, important to also note the magnitude of the traction. The EVM community is still relatively very small, and claiming dominance this early is like Netscape claiming victory in the browser wars. Regardless of the merits between the EVM, Michelson, and other potential VMs like WebAssembly, we should not let early traction of any smart contract VM sway us from the best design choices. If we’re building the infrastructure for the future, we should do it right, and not just jump on a VM because it has a few thousand people who already know it.

Note: Michelson is just one of a few verifiable smart contract VMs in development. Rholang is another brilliant one being developed by Greg Meredith over in the RChain project.

Self-Updating Protocol

We’re big fans of modularity. It allows for experimentation and development at each layer of the protocol without having to reimplement the entire technology stack. Tezos implements this philosophy very well. In their whitepaper, they split the concept of a blockchain protocol into three distinct layers: the network layer, the consensus layer, and the transaction layer. To compare this to other modular platforms, the Tendermint ABCI platform provides the network and consensus layers and remains agnostic to the transaction processor, allowing it to be defined by the blockchain creator. Tezos takes this idea a step forward, allowing the protocol be agnostic to the consensus layer as well. It does this by having the network layer agree on the hash of an OCaml file that contains the rest of the protocol, so that each node can formally verify it and point its “apply” function to the new protocol file (this is the reason that a single OCaml reference client is necessary).

Any developer can create a new network with an OCaml protocol specification file inputted at genesis. This may make Tezos a great platform to build new blockchains on with the freedom to dictate your own consensus mechanism and transaction processor.

However, as of now, the Tezos team seems to prefer to take the project in a direction more focused on creating a single public blockchain with self-updating capabilities. It can update the protocol to update to through on-chain governance (this will be explored further in the next section). This separation of the network layer means the rest of the protocol can be updated without the needing to hard fork by potentially splitting the network. Regarding in-protocol upgrades, there are two trains of thought: “this modularity combined with Tezos’s self-updating nature and governance is good,” and “this modularity combined with Tezos’s self-updating nature and governance is not good.” To be totally honest, the two authors disagree on this, and so we explore both in depth. As usual, final judgment will be left to the reader.

This is the argument for “this modularity combined with Tezos’s self-updating nature and governance is good.”

Most hard forks are not contentious. Simple optimizations, bug fixes, and protocol upgrades do not need to go through the massive and challenging coordination problems of getting all client software to update their code (without any bugs), getting everyone to install the new software, and dealing with any problems that arise due to incompatibility between those running old and new protocols. Even some soft forks can cause problems without high-levels of coordination (this is why Bitcoin’s SegWit originally required 95% signaling). This is what Tezos tries to solve. In the end, every blockchain upgrade still comes down to social consensus, as people can still choose to fork and not go along with the approved update. In-protocol updatability simply makes the process more efficient and smooth, so that massive coordination efforts associated with hard forks are only necessary when dealing with contentious issues. As of right now, only the hash of the current protocol specification file is in the blockchain, and each user has to get the file itself through some other means, such as GitHub, IPFS, torrent, etc. However, we believe it might even be possible to serialize the OCaml protocol specification file and transmit it to all nodes from within the protocol, getting rid of the need for clients to download anything at all to update the protocol.

This is the argument for “this modularity combined with Tezos’s self-updating nature and governance is not good.”

Good hard forks are both opt-in and not-backwards compatible. Hard forks that fit this description are non-coercive, and allow users to follow the fork of the chain that they most believe in. If Tezos in any way forces updates, then Tezos’s hard forks will not fit the bill as a good hard-fork, and will, in fact, be coercive. If neither of these conditions are met, then Tezos’s proposed governance mechanism is little more than a fancy way of signaling which fork coin holders like, which is entirely possible with a system like Carbonvote as is implemented on Ethereum.

Choose the line of reasoning that best suits you, o’ lovely reader :).

Built-in Governance:

If the protocol can be upgraded from within the protocol, who gets to decide when and how? This is where Tezos’s novel governance layer comes into play. (Note: novel for 2014. There are some similar ideas, lately. See dfinity.) As per Tezos’s white paper, this allows for new protocols to replace the old Tezos protocol though some voting process. In the beginning, this process will be a vote by coin holders.

Again, there are two main trains of thought about this design decision. As above, the two authors each hold a different viewpoint. Below, we will attempt to explore both sides of the argument. In the end, Tezos’s success will likely be determined by the effectiveness of this protocol, and the validity of the arguments described below.

The first train of thought:

This can essentially be summarized as “the danger of incentives and misaligned interests.” To quote Ethereum researcher Vlad Zamfir, the worry is that these protocols will make “whales the kings of crypto,” which becomes an issue if coin holder’s interests are not aligned with the interests of the users of the protocol. It is worth noting that coin holders voting is only the initial proposed mechanism for governance, but it’s unlikely that this will ever change without a very contentious hardfork to remove their power. It’s very unlikely that those in power will ever vote to reduce their power, rewards, or anything else as users may want them to. There is a large amount of power in the default, and giving this power to coin holders as compared to the community is likely a dangerous decision.

The pro-governance train of thought offers the following counter-arguments: