Blockchain Reimagined

Evolution of Blockchain State Machines

7 min read

Our chapters so far looked like this: We started with a set of conceptual explanations:

This chapter is essentially a continuation of Execution, Ordering, History and State Machines, but it came with a gap, in order to provide readers with more specific knowledge about blockchains first.

In Execution, Ordering, History and State Machines we modeled a blockchain as a State Machine (or a Computer) whose execution is Resilient[^1], fully or partially depending on the implementation. In this chapter, we will look at the evolution of these State Machines, and see what applications have so far been encoded in them.

This evolution can be categorized into two different eras:

Fixed State Machine

A fixed State Machine blockchain is the simplest one; it has a set of rules that in principle never change. Moreover, this state machine has no way of being extended.

The most famous example in this category is Bitcoin. Its state is merely the balance of users1, and its STF is a simple digital bank, and it offers no way to execute any further logic as a part of its STF2.

As noted, Bitcoin was a great demonstration that creating Science-based Trust is possible, and people will use it, but lacks extensibility.

Custom Blockchains

An early way to create more custom STFs was essentially to create a whole new blockchain. This worked, and it lead to a number of first-generation chains like ZCash, each being different from their predecessor, Bitcoin. ZCash, for example, has a very custom STF which allows for private store and transfer of value in the form of their its token, ZEC.

So, in this mindset, if you want to have a different STF, you would have to create a (yet another) new (fixed-state-machine) blockchain3. This approach has a number of downsides:

  • In the absence of a Bridge, each chain would often have its own custom token, fragmenting the overall liquidity
  • Building a whole new blockchain is time-consuming, hard, and can go wrong for a number of reasons
    • Blockchains often benefit from the “Economies of Scale”, in that the larger the system and the more people who use it, the more resilient it is. Therefore, a young custom blockchain with a small ecosystem is more vulnerable.

Programmable State Machine

What if more blobs of code could be uploaded to the blockchain and stored as a part of its State, and these code blobs could be executed as the part of the STF upon user Transactions? This gave birth to programmable state machines.

Ethereum, EVM and Smart Contracts

Ethereum was the first blockchain to invent such a system. Its STF was equal to that of Bitcoin (simple value transfer of the ETH token), and it allowed blobs of code, Smart Contracts, to be uploaded into the blockchain state, and execute as a part of its STF, if a transaction requested to do so.

These blobs of code had to be in the format of Ethereum Virtual Machine (EVM) byte-code. The default language that could be compiled to EVM was Solidity, yet today more languages can nowadays be compiled to EVM bytecode.

As an example, the transactions of the Bitcoin STF could only be similar to:

  • transfer(alice, bob, 1 BTC): transfer 1 BTC from Alice to Bob

Whereas the Ethereum’s transactions could be either of:

  • transfer(alice, bob, 1 ETH): transfer 1 ETH from Alice to Bob
  • upload_contract(0x123..): upload a new contract with code 0x123...
  • call_contract(0x123, foo, bar) call the (already uploaded) contract with code 0x123’s method foo and pass bar as input.

Achieving this in a Resilience way is no easy feat, and similar to Bitcoin, Ethereum is a great demonstration that this is possible. The main challenges in achieving this are Metering and Determinisms, discussed further below.

By and large, the majority of the blockchain ecosystem is (still, more than a decade after EVM’s inception) focused on optimizing EVM as the main virtual machine on top of which the STF can be expanded. Yet, a number of projects have been pioneering new, more general, virtual machines as the extensible part of the STF.

Polkadot: An STF that can host other blockchains

Polkadot is one such example. Instead of EVM, Polkadot chose a more general virtual machine (initially WebAssembly, later on an alteration of RiscV called PolkaVM) as a more flexible and extensible STF.

This allowed Polkadot to not only run smart contracts (with relatively limited programmability), but also run/host an entire set blockchains within itself, giving birth to the idea of a multi-chain blockchain network. This ideology was later reinforced by Ethereum and its rollup-centric-roadmap and exists to this day the most accepted way to scale blockchains.

This is often called horizontal scaling as is discussed in What Scaling Blockchains Means and further chapters.

Hosting Any Application In Blockchain STF

Yet, even hosting another blockchain is still a very limited degree of programmability. This is because a blockchain is still a State Machine, confined to the boundaries of only being able to transition its state when new input (a block — possibly with some transactions) comes in.

In other words, both a smart contract and a blockchain’s code are primarily written as a set of callback functions that are triggered at specific times.

A typical smart contract and/or blockchain transaction looks like:

/// A blockchain/smart-contract transaction
fn on_transaction(sender, input) -> Result<_, _> { .. }

A blockchain is slightly more flexible than a smart contract. Given the high degree of autonomy that a blockchain has, its STF may include more flexible callbacks that are executed without the need of user Transaction, for example on every block, or every n-th block:

/// A more generic hook that is only readily possible in a blockchain
fn on_every_block(block_number: u32) -> Result<_, _> { .. }

But in both of the above, one can see what we mean by:

..confined to the boundaries of only being able to transition its state when new input (a block of transactions) comes in..

That is, it is increasingly hard in either of the two to express normal application that has a fn main() -> { ... } and runs an execution for a few minutes and then terminates.

This is a fairly novel vertical of the blockchain space, and is still being explored. I will discuss one approach to that I am familiar with, JAM later. Some other projects that I am aware of and are trying to tackle this are:

Not Always Apples To Apples

One note to add here is that

Appendices

The main gist of what I wanted to convey in this chapter is above. Yet, there are many loose threads that we can further explain, coming next.

Upgradability

Hard Foks

Metering

Executing untrusted code

Determinisms

Contract Composability

Bitcoin’s (Actual) Extensibility

Web3 Cloud Narrative

Summary

This built on top of the State Machine model explained in Evolution of Blockchain State Machines, and described the evolution of these STFs.

Next, while we are still exploring what a blockchain is, we will look into the different roles in a blockchain system, and see who executes this STF, and exactly when. See Blockchain Networks.

Footnotes

  1. Stored in a format known as UTXO ↩

  2. People have tried to extend Bitcoin with Ordinals and Bitcoin scripts, but they both extremely limited and we can set the aside for simplicity. ↩

  3. Nowadays, these new standalone blockchains are called “L1”s, see in The Layers Shebang ↩

Graph View

Backlinks