Now that we have looked at the basics of blockchain technology, let us take a closer look at Tezos.
We will begin by asking the question: Why should one learn to develop on yet another public blockchain platform?
After addressing the fundamental question of the value added of learning a new protocol and everything it entails, we will take a closer look at Tezos' architecture and smart contract languages as a first introduction to this platform.
One might well ask why we need another public blockchain platform that runs smart contracts, and why developers are also tasked with adapting to new languages.
Let us explore the value added stemming from Tezos, as well as some of the known risks to keep in mind as we unfold the Tezos architecture and approach.
Reliability of both the network platform and the contracts that run on it is always a concern. After all, if platforms do not behave as expected, or if contracts don't behave as the authors intended, the consequences can be quite serious. Incidents of defects diminish trust in smart contracts, the system, and even cast doubt upon the very workability of smart contracts and blockchain technology in general.
Tezos' design aims for reliability, security, and modularity. How so? Smart contracts in Tezos are more reliable because they more easily facilitate formal verification.
Formal verification is a much discussed topic. There is some resistance from the developer communities; to developers who are accustomed to fast development turnaround methodologies such as Agile, the very idea of formal verification may seem like a foreign concept. It's easy to lose sight of the existence of more disciplined approaches that are more common in mission-critical settings like nuclear and aeronautical engineering.
For Tezos, more easily supporting formal verification allows one to prove smart contract code correctness, and with it make contracts more secure and reliable. The Tezos ecosystem contains a number of specialised tools focused on secure DApp development, and at the same time the opportunity to analyse smart contract code more easily.
Another important design aspect with which the Tezos platform brings additional value to the blockchain ecosystem can be found in regard to its governance mechanism.
Upgrades to blockchains are particularly difficult to execute in decentralised consensus-based systems as the need for agreement among a distributed set of participants is implied and always includes an element of overturning previous agreements. It is also very difficult to remedy such a situation in an environment where change can be considered a bug and where breaking changes may harm software that is already deployed. For example, in informal terms, Ethereum does what it does the way it does it but developers have little assurance about platform invariants. Invariants are not well-defined. The same community resistance that stands as a bulwark against breaking changes is also, arguably, an impediment to progress. The same can be said of Bitcoin. Both networks, Bitcoin and Ethereum, have suffered disagreements about what is progress and what is an anti-feature. Bitter disputes have split their communities and as a result disrupted their network effects, which disrupts their value.
Upgrades are especially challenging absent previously agreed governance processes that define how upgrades are to be achieved. Without clearly defined governance mechanisms, upgrades can be disorderly, inefficient, and damaging to communities. The Tezos governance process is designed to address this problem.
Tezos offers a pre-defined governance mechanism to upgrade the protocol (we will address this mechanism at a later point in time).
These aspects of reliability, security, and upgradeability make Tezos an attractive public blockchain and smart contracts platform for developers to build on.
Performance is always a challenge in public blockchains. Public permissionless smart contract platforms sacrifice transaction throughput for decentralisation. They have, however, demonstrated the need for research into the matter and Tezos is designed with new theoretical foundations in mind. While Ethereum aims to upgrade its consensus system to Proof-of-Stake (currently Proof-of-Work), such an upgrade is challenging for the reasons mentioned above, among others. Tezos uses a unique Proof-of-Stake process that incorporates delegation (this is not the same as Delegated Proof-of-Stake systems like EOS or Tron), initially - We say "initially" because the possibility of upgrades could lead it to be amended in the future.
To write smart contracts on Tezos, a domain-specific language called Michelson is used. It is stack-based, with high-level data types and primitives and strict static type checking. On first encounter, it seems to be an odd language choice as it does not have features like polymorphism or named functions. Dealing with the stack is complicated and there is no standard library to rely on. Even though it appears underpowered when compared to languages such as Haskell or OCaml, the language's restrictions are a result of its design goals.
Michelson is designed as a readable compilation target to make the compiler's output understandable. The idea behind it is to empower developers to build analysis tools and compilers by using a language that is simple enough to do so.
Here it becomes evident that Michelson follows a different theoretical assumption: Instead of building on bytecode like with the EVM, which requires confidence in the program and compiler toolchain, using a human-readable bytecode allows to more easily check and verify properties of programs and their compiled outputs.
Michelson has two main properties that make it a more accessible and understandable bytecode:
One of the design choices with Tezos is to allow for a language which makes the output easier to understand. Michelson does not present you with a long row of numbers, but instead offers expressions. A program written in Michelson consists of a series of instructions run in sequence.
Michelson includes elements like maps, lists or sets. This makes it fundamentally different from the EVM.
The development and characteristics of Michelson follow the idea to create a simple core language, which can be amended with features as they are needed. This is different from attempting to create a more overarching language in the beginning, which then breaks backwards compatibility. The goal are to provide a platform:
inclusive of business logic,
with readable bytecode, and
using a small language that can be expanded depending on its use cases.
Michelson follows the line of the general Tezos design that aims to resolve the issues public blockchains typically have with reliability and security, upgradeability, and performance.
Tezos Architecture Overview
To understand the architecture of the Tezos platform, one needs to comprehend the function of:
the node, and
Strong type system: no nulls, no implicit casts, no overflow, no division by 0 etc. A Michelson contracts runs completely before calling other contracts (this avoid many re-entrancy bugs)
LIGO is a statically-typed, high-level language that compiles down to Michelson. The syntaxes currently supported are PascaLIGO (pascal-like syntax) and CameLIGO (caml-like syntax).
The installation is easy. Since we have previously worked with Docker, let us also use it for LIGO:
12$ curl https://gitlab.com/ligolang/ligo/raw/dev/scripts/installer.sh | bash -s "next"3
Although other syntaxes will be supported in the future, here we want to introduce two which are already quite advanced in their development.
1type storage = int23(* variant defining pseudo multi-entrypoint actions *)4type action =5 | Increment of int6 | Decrement of int78let add (a: int) (b: int): int = a + b910let subtract (a: int) (b: int): int = a - b1112(* real entrypoint that re-routes the flow based on13 the action provided *)14let main(p : action) storage =15 let storage =16 match p with17 | Increment n -> add storage n18 | Decrement n -> subtract storage n19 in (( : operation list), storage)
Contract orchestration for OCaml
Truffle and Tezos
Michelson semantics: https://github.com/runtimeverification/michelson-semantics