On the Origin of Tezos
This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at Tezos and how it could threaten to supplant Ethereum as the dominant smart contracts platform.
Tezos is a smart contract platform whose origin dates back to 2014, when Ethereum was just in its early formative stages. So if Tezos was designed to uproot a dominant platform, it would have been Bitcoin. Nonetheless, the original Tezos design was very forward thinking for its time in proposing solutions to governance and scalability problems Bitcoin would later experience as well as providing a higher level language than Bitcoin’s for implementing smart contracts.
Tezos is designed from the ground up as a completely new blockchain that is different from Bitcoin or Ethereum. However, as a platform for running state-based, Turing-complete smart contracts, Tezos now stands as a direct competitor to Ethereum that promises to deliver higher transaction throughput, better governance, and safer smart contracts.
The Tezos project is exceptionally well-funded, both from traditional venture capital and crowdfunding. There is currently no operating production blockchain, but Tezos appears to be in the final stages of implementing and testing it. There is a running testnet but it is not yet generally available to the public. Nonetheless, there is enough technical info on Tezos to perform a useful comparison to Ethereum and evaluate its claims. Let’s take a deeper look at each of these.
Transaction Throughput
A common goal among upstart smart contract platforms is improving on Ethereum’s currently abysmal transaction throughput (before Ethereum improves itself). Nearly all are designed to achieve fast, synchronous block times by using proof of stake (PoS) consensus. Part of Ethereum’s scalability roadmap is to transition from proof of work (PoW) to PoS, though PoS is being phased in slowly, and Tezos will likely launch with pure PoS while Ethereum is still using PoW.
Tezos plans to implement a delegated proof of stake consensus (DPoS) mechanism, which has some significant differences with Ethereum’s proposed Casper PoS protocol. In both systems stakeholders can earn coins and offset inflation by depositing funds in exchange for producing and validating blocks when called upon. Whereas in Ethereum all stakeholders can directly participate in the consensus mechanism, in Tezos most users will delegate block production and validation to pool operators that run full nodes with high availability in exchange for a percentage of the rewards.
This can result in very efficient block production and significantly higher transaction throughput with the fat blocks being proposed by Tezos. The tradeoff is that the higher hardware and bandwidth requirements for running validating nodes will be cost prohibitive for many, leading to a more centralized consensus process. In contrast to Ethereum’s decentralization-favoring PoS design, Tezos deliberately trades off centralization for increased throughput. Tezos CTO Arthur Breitman believes that the desire for dirt cheap validation stems “more from a misplaced egalitarian ideology than from actual economic or security arguments” and expects the Tezos users to ultimately find the right balance to maximize adoption. On the other hand, Casper researcher Vlad Zamfir opines that Tezos is embracing plutocracy and (by presuming an honest majority) ignoring the interesting incentive alignment and mechanism design questions.
Ultimately philosophy and theory will yield to real world, empirical determination of the practically optimal centralization/throughput tradeoff, which will likely be different for public and private networks. With a healthy market of validation pools competing for stakeholder participation, it’s possible that Tezos could operate more efficiently while being decentralized enough to prevent the coordinated choice attacks on public networks that Casper is being designed to prohibit. Conversely, experience from Tezos’ implementation could also factor into Ethereum (e.g. increasing block gas limits) and the two projects may end up converging toward the sweet spot for public networks.
Scaling the consensus layer alone won’t ultimately be sufficient to meet the needs of the world’s dominant smart contract platform. Both projects recognize that other mechanisms will be needed, but their long term approaches are somewhat different. In Ethereum, a number of complementary scaling techniques such as sharding, payment channels, sidechains, and off-chain computation are being investigated. Whereas Tezos recognizes that off-chain mechanisms such as payment channels will be required for micropayments, they believe the best route to a massive on-chain scalability boost lies not in sharding but in recursive SNARK technology. SNARKs can be used to provide cryptographic proof of arbitrarily complex transactions, and recursively to provide a single proof for a block of transaction proofs, enabling a large number of transactions to be quickly validated on cheap hardware. According to Breitman this technology could completely eliminate the need for gas limits and allow users to sync the entire blockchain from genesis in less than one second, thereby making the centralization/throughput tradeoff unnecessary. Two key adoption hurdles are the computational cost to produce the recursive proofs and the requirement for a trusted setup, however recentadvances suggest that this approach to massive scaling without centralizing may soon be viable.
In the near term Tezos can gain a significant advantage by deploying a pure PoS blockchain ahead of Ethereum and widening the transaction throughput gap with fat blocks and powerful validators. Tezos plans to start out with parameters that heavily favor decentralization and evolve them in the direction of higher throughput using a “security first, scaling second” methodology. This incremental approach will not be implemented through gas limit increases or hard forks, but through a self-amending protocol mechanism that lies at the heart of Tezos claim to improved governance via forkless protocol updates.
Governance
The Tezos position paper identifies and addresses some key issues associated with protocol forks as an innovation upgrade mechanism. Having predated both the Bitcoin and Ethereum hard forks, this paper was visionary for its time in identifying the difficulty of coordinating social consensus around proposals, the economic cost of network splits, and the vulnerability of core development teams as a source of centralized control.
To address these issues Tezos is implementing a formalized and automated on-chain governance mechanism that empowers stakeholders to coordinate on upgrades and enables innovations to be incorporated directly into a self-amending protocol. The governance mechanism itself is amendable but the initial upgrade process will be based on two rounds of democratic voting. Innovations are introduced as formal upgrade proposals (including code), which are then voted on by stakeholders and, upon approval, loaded onto the test network. After sufficient experience is gained testing the proposal, a second stakeholder vote decides whether or not to deploy the proposal code into production. Upon approval the proposal’s code is integrated into the production system and the updated protocol code is distributed to everyone without a fork. The whole process is automated, giving users a sense that there is a democratic “rule of law” associated with protocol upgrades.
Tezos proposes that a stake-based democratic process will better retain network effects by avoiding contentious splits while allowing protocol upgrades to keep pace with innovation. Initially, only proposals with a high level of stakeholder support (80% supermajority) will get deployed, which, in theory, should minimize network splits. However, in practice we’ve seen ideological splits from small minorities in both the Ethereum and Bitcoin community create economically viable coins (i.e. ETC and BCH). Keeping pace with innovation can be challenging for democratic systems where other political factors are involved (e.g. SegWit was stalled for reasons mostly unrelated to the merits of the proposal). In contrast, Ethereum’s foundation-led, hard fork-friendly approach to governance seems to be outpacing Bitcoin’s more decentralized community process. Although the Tezos foundation will have veto power on proposals (for a limited time), it will not have power to expedite innovation; Tezos is relying solely on the democratic process to rapidly evolve the protocol.
The democratic process itself comes with some issues. Upgrade proposals are inherently technical; the vast majority of stakeholders won’t be able to directly evaluate what they’re voting on. Instead they will be informed by the explanations of a few who understand the Tezos code, which puts great power in the hands of a small tech-savvy minority. Getting enough stakeholders to vote on any given proposal is another challenge. Tezos is looking to address both these issues with a voting scheme in which stakeholders are free to cast their votes or delegate them to others as they see fit.
A major concern with stake-based voting on arbitrary protocol upgrades is that it can give a small cartel of whales (i.e. entities holding a large stake, such as exchanges) too much power to change the rules and enrich themselves at the expense of non-staking users. According to Ethereum’s Vlad Zamfir there is a big difference between stake-based voting in PoS, which provides minimal power with strong penalties for abuse, and stake-based voting on proposals, which provides maximal power with essentially no accountability. However such a cartel would risk significant financial loss if a proposal was so egregious as to destroy confidence in the network, and specific protections could be provided by a blockchain constitution enumerating a set of properties that no proposal can violate. The Tezos position paper briefly describes formalizing “constitutionality” by requiring that proposals come with a formal proof that they don’t violate any constitutional properties. It remains to be seen whether such mechanisms are practically possible and how effective they would be at deterring abuses of power that a self-amending governance process allows.
In a time when “code is law” was commonly considered a viable governance policy, Tezos displayed prophetic insight into the governance issues that would play out on major blockchains. Subsequently the need for mechanisms that allow a blockchain to keep pace with innovation while remaining decentralized and retaining its network effects has become more apparent. Tezos’ automated, on-chain governance mechanisms as currently implemented are unlikely to exceed the pace of innovation set by Ethereum’s foundation-led governance, but its self-amending nature may allow it to evolve a more decentralized protocol upgrade mechanism that is safer than hard forks. However, forkless upgrade capability doesn’t necessarily threaten Ethereum’s dominance as a smart contract platform. Whereas Ethereum has implemented several hard forks, the one community split it has experienced thus far was not due to a protocol upgrade, but contention over the decision to reverse the exploit of a vulnerability in Solidity code. The vulnerability and hence the fork could have been avoided entirely with better smart contract security, something Ethereum desperately needs to maintain its incumbency.
Smart Contract Security
At the present time nearly all Ethereum smart contracts are written in Solidity, a language in which easily exploitable vulnerabilities have been introduced in audited, peer reviewed, open source contracts written by top notch programmers using best practices and tools. The vulnerability in the Parity multisig wallet code, which affected 596 wallets, put all funds (cumulatively over 200 million USD) at risk. As long as Solidity remains the only practical language for developing smart contracts and its fundamental security flaws are not fixed, all Ethereum contracts will be subject to the risk of exploit and substantial financial loss at any time.
Tezos plans to greatly improve security with Michelson, a new smart contracting language designed specifically to facilitate formal verification of on-chain code. Unlike Solidity, Michelson is not compiled to anything; it is a low level, stack-based, Turing-complete programming language that is directly interpreted by the Tezos virtual machine. So technically it is more analagous to EVM bytecode than Solidity, however it includes high-level constructs such as maps, sets, lambdas, cryptographic primitives, and contract-specific operations to make it easier for humans to read and write. It is purely functional, strongly typed, and statically type-checked to simplify the construction of correctness proofs and eliminate several types of vulnerabilities that have afflicted Solidity contracts.
A correctness proof is not a universal proof that nothing bad can happen, but a proof that all of the assertions enumerated in a certain specification will be satisfied by the program. So if a developer creates a specification that includes an assertion that only authorized users can change the owner of a contract, then the verifier would catch the Parity multisig vulnerability before it got deployed. However, to be effective, the developer needs to think of the assertion (which is obvious only in retrospect) and include it in the specification before deploying the code and witnessing the attack.
Although there is no substitute for human analysis and reasoning in preventing bugs, formal verification is a powerful, complementary tool that is appropriate in situations where bugs can have catastrophic consequences, such as in airplane software and smart contracts controlling large amounts of assets. The Ethereum community recognizes this and there are multiple projects investigating the formal verification of smart contracts and the Ethereum virtual machine itself. The Ethereum community is also researching new programming languages such as Bamboo and Viper that are more suitable for formal verification and more constrained such that many vulnerabilities can be discovered by compilers rather than by hackers. Since these languages also compile to EVM code, it would be necessary to formally verify both the high-level code as well as the EVM bytecode produced (and/or the compiler producing the bytecode). In contrast, Michelson is interpreted directly by the Tezos VM so requires only a single correctness proof of the contract code.
Once the Tezos blockchain is launched, Michelson will likely provide a programming environment that enables development of significantly safer smart contracts than Solidity by developers with less than expert-level capability. Currently there are at most only a handful of expert Michelson programmers, and being a new, stack-based language without many of the features programmers are used to, the learning curve may present an adoption hurdle for developers. However, Michelson provides a foundation upon which a higher level, more developer-friendly functional language that facilitates “full stack” formal verification could be developed. There is currently active research and development on the Liquidity programming language, which provides an OCaml-like syntax and transpiles to and from Michelson.
Legend has it that Michelson is named after the famous Michelson-Morley experiment that disproved the prevailing theory that the universe was made up of ether. This “cheeky” indulgence foreshadows an end to the prevailing theory that smart contracts can be written in Ethereum’s Solidity language without costly vulnerabilities. The high-profile exploits of Solidity code are experiments that call this view into question and each new exploit will weaken the theory further. Although formal verification is no silver bullet, Michelson could demonstrate significant immunity to the types of vulnerabilities found in Solidity contracts and raise the bar for smart contract security.
Conclusion
The Tezos project is both visionary and promising in the way it has recognized and is addressing key problems faced by today’s blockchains. It proposes a codified governance model that may provide enough structure to prevent community splits, though it’s not clear whether on-chain stakeholder voting on proposals will be sufficient to address the types of complex issues that led to the Ethereum Classic and Bitcoin Cash splits. Automating protocol updates may facilitate evolution and fine-tuning of protocol performance and scalability, providing small but meaningful improvements (in the context of pure PoS consensus) until the orders of magnitude scaling solutions get deployed. Automated updates also allow innovations to be incorporated directly into the Tezos protocol. This “fat protocol” philosophy may preserve network effects better than Ethereum’s thin protocol model where new features are incorporated as separate apps often issuing their own tokens. This opposition of philosophies is reminiscent of Microsoft Windows vs Linux Kernel for operating systems, and, like Linux, Ethereum’s network effects and pace of innovation do not appear to be suffering with the proliferation of new apps and coins.
Whether the improvements brought about by a self-amending ledger and pure PoS consensus mechanism will threaten Ethereum’s dominance remain to be seen. However, if Michelson with formal verification can provide a significantly more secure way to write smart contracts that prevents real people from losing real money, that improvement alone could unseat Ethereum as the first choice platform for smart contracts where participants are concerned about losing the assets under control (i.e. all smart contracts). But a smart contract platform is only as secure as its weakest link. If and when Tezos gains traction, its new DPoS and on-chain governance mechanisms will be tested and a major exploit of either subsystem could easily tarnish Tezos’ reputation for security and derail its path to dominance.
Dominance threat levels are explained in the introduction to the series. Below is a brief legend.
Thanks to Klas Harrysson, Zero-Hour-Zulu, and Evan Van Ness for their input on early drafts.
If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9
Your support allows and encourages me to devote more time to these articles and is greatly appreciated.
