Blockchain is often presented as a novel way to store data. The data storage is often explained as a distributed ledger. I think this emphasis of the ledger-ness is misleading and hides its potential. In a ledger, the emphasis is on accounting and bookkeeping (see e.g. this definition). In the following, I will outline how a blockchain do more, in particular store program state, a crucial component for the distributed execution of programs, smart contracts or chain code, and point to current implementations of this idea. A program state is, given a sequence of instructions (think: a recipe), the current instruction we execute, as well as the outcome of all the previously executed instructions (think: taking a snapshot during cooking the recipe).
Even in use-cases where recording a ledger is central, such as in Bitcoin or other cryptocurrencies (or any other cases of transferable ownership, e.g. real-estate like tested in Sweden), there is more to the transactions of cryptocurrencies than keeping a simple list of transfers (like “give 5 bitcoins from account A to account B”): A critical component of each transaction in Bitcoin is a piece of program code, called a script, that needs be be executed to make a transaction valid. The scripts are included in transaction messages and run on the computers of the network (the nodes). The script executions, i.e. the end-result of running the program, help to ensure the correctness of the transaction, i.e. that the coins are owned by the sender (i.e. “give 5 bitcoins from account A to account B” AND “here is proof that I own the bitcoins; use the following instructions to mathematically verify the proof”). Every node executes the script on its own, and all nodes have to agree on the script’s output. Only then the transaction (and with it the programs output becomes) part of the consensus on the data on the blockchain.
Bitcoins language for programs is called “Script”. The Script language powering Bitcoin is has only a limited set of instructions: It is not possible to write any arbitrary program in it, e.g. to retrieve data from REST APIs, or implement arbitrary algorithms in it. To make an analogy: Think of a calculator that only has operations for addition and subtraction, but not for multiplication. You can derive multiplication from that, but getting logarithms or square roots is not quite possible.
If you are interested, you can learn about script here and use the BitcoinIDE to explore it (also shown in Figure 1).
The limitations of Script are not surprising: Bitcoin was designed as a currency and the language was tailored for that specific purpose. Nevertheless, its small set of instructions plays a key role in multi-signature or hashlock transactions that extend Bitcoin’s capability beyond immediate 1-to-1 transactions and are heavily used in protocols like the Lightning network (just like deriving multiplication from repeated addition in a simple calculator model). Moreover, there is space to add new instructions to the language in the future.
Why are scripts exciting? What is the full potential of “programs on the blockchain” (in essence, Bitcoin’s scripts are small already programs on the blockchain)? They read input from the blockchain and run on the computers forming the blockchain (the individual nodes of the peer-to-peer network). The output of executing a script in turn becomes part of the blockchain.
The reasons for excitement are as follows: Because every node runs and verifies the computations, the possibility of mistakes or malicious cheating in during the program execution is essentially eliminated. To include data in the blockchain, the network needs to agree on it during the network’s consensus finding process, so everybody also needs to agree on the program’s output so it can become part of the blockchain’s data.
Programs in turn can automate a wide range of tasks, e.g. timed and scheduled money and ownership transfers once pre-defined conditions are met, or running market places and auction houses. Once two or more parties agree upon a contract (which boils down to: agree on a sequence of events and conditions), the correct execution of the contract can be guaranteed by codifying it and storing it on a blockchain for execution. It is even possible to handle escrow payments with programs on the blockchain.
Contrast this with the traditional way of doing business, involving notaries, banks or lawyers for escrow, etc. The “contract programs” on the blockchain do not rely on middle man. These small programs are often called smart contracts. They don’t just store terms and conditions, but also include and automate their execution.
Thanks to computer models in computer science and the theory of programming languages, we know exactly what components are needed for a script or programming language to archive a desired level of expressive power/computational capabilities.
In the following, I will outline some of the blockchain implementations of the idea “programs on the blockchain” and try to contrast the different approaches taken by different groups to make “smart contracts” reality.
Proposed in 2013 and live since 2015, Ethereum was (to my knowledge) the first fully working “distributed computer” running on a blockchain. Instead of transactions, initially the code for a computer program is stored on the blockchain. The program then is executed by each computer on the Ethereum network, and the result of the execution in turn is stored on the blockchain again.
(More technically: It runs a virtual machine, an abstract model of computation: A carefully selected set of instructions that can model the desired operations together with a “machine model”. To give an example, think of an Abacus as a machine model of a calculator, and usage instructions for the abacus as the set of instructions. The nodes on the blockchain simulate the operation of this machine by taking the program code from users and advancing the machine state, i.e. simulating the computations of the program.)
Ethereum programs can be written in Solidity, a programming language offering a high level of abstraction (hiding the specifics of the virtual machine from the programmer) as well as in the go programming language. Programs running on Ethereum are sandboxed, meaning that they cannot read data from outside the blockchain. Data can be written to the blockchain manually using “special accounts”. This provides an interface between the program (also called smart contract) running on the Ethereum system and the real outside world (e.g. other data on the internet).
To prevent faulty or malicious programs from using up all resources, the execution of programs and the use of memory has a cost. It consumes tokens, a kind of currency also included in the Ethereum blockchain. Miners, i.e. people operating the virtual machine by executing the programs on the blockchain and participating in consensus finding, are also rewarded with tokens for their work.
Probably the most famous user of Ethereum is the Decentralized Autonomous Organization (DAO). It is a distributed investment vehicle (similar to a hedge fund) with more than 10.000 stake holders voting on investment decisions. The DOA holds (depending on the exchange rate) up to USD 150 million in assets. The DAO already demonstrates the complexity of “contracts” that are possible: It’s not only a simple transfer of ownership, or a rental contract. It can include voting systems, statutes for (legal) entities, or any other kind of deterministic agreement.
You can find out more about Ethereum on Medium, for example here.
Tendermint is a blockchain platform that is more abstract than the virtual machine on Ethereum. Instead of prescribing a specific way of computing by providing a machine model, it wants to only provide the distributed consensus finding component: Any program should be able to run on it, and Tendermint verifies the correct execution of the program across all computer on the network. It achieves this by providing a way for programs to communicate with the Tendermint blockchain via an interface called Application BlockChain Interface (ABCI).
Tendermint uses the BFT consensus algorithm (see also my old post here). It also differs from Ethereum in the way the blockchain is set up: Ethereum runs one single virtual machine across a large distributed network. Thanks to the BFT algorithm, it is possible to commission smaller, individual Tendermint blockchains with a more private group of participants, rather than running an open-for-all public system.
The Hyperledger project, an open-source initiative backed by numerous companies, also fits into this context: It aims at providing a “full-stack” blockchain infrastructure. It does not want to prescribe what application runs on it, how consensus is archived, or how nodes communicate, etc.. All of these core functionalities are exchangeable. The core advantage of this approach is that everyone can tailor-make their own blockchain system.
There are multiple sub-projects within Hyperledger, each providing different implementations of the modules. Within the Hyperledger Fabric sub-projecct, it is possible to interact with the blockchain data/ledger using chaincode, which are short programs written in go or java.
While the Hyperledger project has strong backing from industry, it seems to be the most experimental solution currently only targeting developers and alpha-testers at the moment. Similar to Tendermint, it requires everyone to set up their own system instead of having a central, monolithic blockchain that’s open to everybody.
To summarize: it is now possible to write programs that read and write to and from the blockchain and are executed on many nodes distributed over the blockchain’s network. The program execution in turn is guarded by the network’s consensus finding algorithm, making sure that the program instructions are all executed correctly. Any task that can be written in programmatical form can be automated without any middle man, without trusting specific individuals, or relying on a potential single point-of-failure.
There are still some challenges: Programs need to be deterministic, i.e. every execution has to give the same output. This limitation is due to the distributed nature of the nodes on the network: Since every node has to agree on the program’s output, each run of the program has to return the same result — otherwise the nodes will never be able to come to a consensus on the program’s output. Imagine a program that flips a coin and outputs the result: About half of the nodes will see head, the other half will see tail. It’s not possible to agree on the output. There are some ways to introduce randomness by relying on (future) data on the blockchain: Since everyone reads from the same blockchain, everyone will see the same values (e.g. a property of the hash value of the next block).
In a more traditional sense, cloud computing often emphasizes computation power and memory resources (for example AWS or Azure) or end-device independent access (for example most software-as-a-service products). In the case of blockchain, the current emphasis is different: it provides an independent, trust-less, guaranteed to be correct execution in the background. But current developments move towards faster, more efficient protocols, and therefore more powerful autonomous programs running on blockchains.
If you liked my article, make sure recommend it, share it, and follow me on here on Medium.
If you or your organization need support to get your head into the blockchain game, check out our webinars and consulting services over at alatus sigma consulting. Comment or contact me if you have any open questions, found mistakes or have requests for specific topics.