Vishakh's Blog

It’s been seven years since the Tezos fundraiser and six years since the launch of Tezos Mainnet. I was involved in helping launch the platform through my company and we built tools and apps to try to help grow the ecosystem. Now that Tezos is moving in a new direction and I have meaningfully stopped working on the platform, it feels like a good time to take stock of the original vision of Tezos and how it worked out.

The Tezos fundraiser happened when the block size wars on Bitcoin were at their peak and onchain governance appealed to many people. Tezos implemented onchain governance in a much more substantial manner than had been done before. The first few protocol upgrades performed using the governance process, although quite involved, were exciting to see as a global decentralized network was able to spontaneously amend itself on infrastructure run by hundreds of bakers around the world. Initially, the core development team at Nomadic Labs funded by the Tezos Foundation (TF) understandably planned, developed and released protocol upgrades. However, the protocol roadmap is still driven by Nomadic and, to my knowledge, no other entity has meaningfully inserted an independent proposal on their own for community review. Tezos users have occasionally balked at proposals from Nomadic, but no incentive mechanisms or social structure has emerged to drive Tezos outside of TF’s purview. Furthermore, I expected that the protocol upgrade process would become fully automated but network participants still have to manually upgrade their software when instructed to do so by Nomadic and related entities. In fact, the manual upgrades of software controlled by Nomadic are only generally coupled with protocol governance. The actual utility of the onchain governance process is to let the Tezos community ratify each step in the roadmap. Meanwhile, other blockchain platforms have also been able to make substantial progress through informal social consensus using soft and hard forks. The block size wars subsided a while ago and Bitcoin has carried on in a largely ossified form. Even when former Tezos luminaries Ocaml Pro forked Tezos, they chose a plain hard fork over working through the governance process. Certainly, nothing is stopping anyone from adding an unscheduled protocol upgrade of their own but I feel the financial and technical incentives are not yet in place for it to happen, especially due to the dominance of TF. Maybe in the future when blockchains find widespread application, the incentives to contentiously and skillfully create protocol amendments will fall into place. Until then, the onchain governance process acts at best as a signalling mechanism for the Tezos community to veto any especially unpopular moves by the principal entities in TF’s orbit.

In 2017, several notable smart contract hacks had already taken place. Tezos was built on Ocaml to make formal verification easy and effective with the goal of making smart contract vulnerabilities rarer. Things began promisingly with the core Tezos code using the formally verified cryptographic library, HACL*, for its cryptographic functionality and the base smart contract language for Tezos, Michelson, being especially amenable for formal verification. While formal methods for software have been used for a long time to secure software in industries such as aviation, defense and healthcare, the sheer cost, effort and general overhead involved have prevented them from being a true panacea for safety and only select critical bits of software are ever typically formally verified. Since TF had such a large budget after the fundraiser and it helped employ high caliber researchers at Nomadic, I hoped that Tezos developers would eventually have access to tooling and high level programming languages to incorporate formal specification, formal verification, etc into their applications. While Nomadic is actively developing the Mi-Cho-Coq framework, Tezos applications are no more likely to use formal methods compared to, say, Ethereum applications. In fact, the need for rapid development and evolution in the blockchain space makes the overhead of using formal methods so heavy that it becomes untenable. In fact, a decentralized exchange protocol was launched in 2020 after formal verification by Nomadic but it still experienced an exploit because its specification, while correct, wasn’t exhaustive enough, thus demonstrating the limits of formal methods. I suspect much like aviation systems, blockchain systems will tactically use formal methods in the long run on core, long-standing components as a safety measure but still mainly rely on institutional and human methods to maintain safety standards.

In the past seven years, people have slowly forgotten how closely Tezos’ core identity was tied to functional programming for producing correct and performant code. Certainly, Tezos wasn’t alone in this hope as Kadena and Cardano explicitly tied themselves to Haskell. Tezos chose Ocaml and committed to it by using it for its core components. As a functional programming enthusiast, I would say that this was the main reason I was originally drawn to Tezos. Ultimately, Tezos’ experience with functional programming mirrored the software industry’s general experience with functional programming. The Ocaml tie-in attracted a small corpus of strong technologists but acted as a barrier for numerous regular app developers who just wanted to quickly build things. Coupled with accommodations for formal verification, these technology choices hamstrung Tezos. Until higher level languages such as SmartPy emerged and let developers work in a familiar vernacular, the platform lacked real developer activity. Many development teams I talked to were frustrated that they couldn’t directly copy and paste the code from their established Ethereum apps. In the most egregious instance of a limiting technology choice, the use of continuation passing style impaired the composability of smart contracts and prevented DeFi from taking off originally on Tezos. Correspondingly, my team used functional programming for many of our own Tezos tools which considerably limited the number of developers who would work using them due to their unfamiliarity with concepts such as a statelessness and pure functions. Personally, I felt that Tezos’ original technological choices were generally worthwhile in principle and they could have been effective differentiators of the platform. The problem, in my opinion, lay in the non-pragmatic implementation of these choices.

Tezos now has an ambitious new roadmap but most of its pieces are familiar to other blockchain ecosystems. Ethereum is already using rollups to scale itself, Solana, Monad, et al are focused on high throughput, while Lisk previously tried a Javascript-based developer offering and so on. While there is sense in expanding Tezos functionality, I hope the original elements of the Tezos vision are not wholly lost in the shuffle as the blockchain market is already crowded and differentiation is difficult with many following a simple “token go up” strategy. The sheer size of TF’s treasury has itself often felt like a hindrance to me as it has caused centralization, concentration of power and a top-down dynamic in the ecosystem. Once blockchains eventually find mass adoption, I suspect it won’t be a top-down strategy that could bring Tezos back into prominence. Rather, a bottom-up decentralized effort outside the aegis of TF has a shot at substantially using the elements of the original Tezos vision to create a unique and differentiated digital commonwealth.