What is a blockchain? For Bitcoin, it is a distributed ledger recording all transactions, and updated in real-time as new blocks of transactions are added. It has the important properties that anyone with the necessary private keys is able to create valid transactions to be added and, conversely, uses cryptography to ensure that only those with the necessary private keys are able to create such transactions. Other important properties include that there is a single valid blockchain state, and this state is accessible to anyone connected to the network. Furthermore, immutability requires that once a transaction has been added to the chain and is considered ‘confirmed’, then it should exist unchanged in all future blockchain states. More generally, a blockchain can be thought of as a kind of distributed database with a single shared state, which can be updated via the addition of blocks of transactions.
Let us look at the process of building a blockchain, whether it be Bitcoin, Ethereum, or something else. Users submit transactions to the network for inclusion on the blockchain. Then, miners (or similar) collect these transactions together into blocks, and add any additional required information such as the previous block hash, timestamp, hash root of the transaction data, or nonce required by the proof of work protocol. As long as the block is valid according to the protocol, this is then transmitted to the network for inclusion in the chain. This procedure is graphically displayed in figure 1 below.
The small squares in figure 1 represent transactions that have been transmitted to the network by users. These are collected together into blocks which, along with the header data, are appended to the chain one by one. It is the responsibility of validators on the network, or nodes, to check for valid blocks and arrive at a consensus as to the ‘true’ blockchain.
Consider the work required from nodes to validate a blockchain. It is necessary to check every block header and every transaction within each block. However, it is not possible to determine if a transaction is valid in isolation, since this only makes sense with respect to the current blockchain state. For Bitcoin, the state will contain the list of utxos (unspent transaction outputs) and the amount and public address (the scriptPubKey) associated to each of these. Then, it is necessary to check that the inputs of a transaction all refer to valid utxos, that the signatures satisfy the required cryptographic conditions, and the the total value of the transaction outputs does not exceed the inputs. If it is valid, the state is updated accordingly, and we move on to the next transaction.
The node is performing the work of a state machine or computer, where the transactions represent instructions or sets of instructions to be executed. That is, it is keeping track of a global state, such as a utxo set or list of account values, and parsing through the transactions using them to sequentially update the state, if they are valid. This is a computer with very special properties, such as using cryptography so that instructions are only allowed to update the state if they provide the necessary signatures, and such that all nodes work on the same global computation. It is very different from the idea of personal computers, each of which can privately be set to work on different calculations. A blockchain has a unique global set of instructions (i.e., transactions) and a shared global state. It is intended to make the results of the computations official and permanent, so that everyone can agree.
Figure 2 below demonstrates a state in the utxo model being updated by a transaction. Here, the state is a list of unspent transaction outputs (listed by transaction and output number) together with their values. There should also be key and signature data, although I do not list these in the figure for brevity. The new transaction then swallows up some of the outputs while creating new ones. Figure 3 shows a similar situation for the account model, where the transaction subtracts a value from Alice’s account and adds it to Bob’s, as well as paying a processing fee. To be valid, it should only refer to accounts that exist in the state, and Alice’s account should start with sufficient value to be able to afford the payments.
This idea can be described by a mathematical expression, where σi represents the state at instant i, T represents a transaction to be applied, and F represents the function applying the transaction to the state,
| σi + 1 = F(σi,T). |
If the transaction is invalid, then F returns an error value or throws an exception, and processing of the blockchain halts with an error. Otherwise, we continue iteratively applying transactions to the state σ. Putting the steps together gives the following procedure for validating a blockchain.
- Initialize the state to its genesis (initial) value.
- Iterate through the blocks from n = 1 to n = current block height.
- Apply block pre-processing (e.g., update current block number and timestamp, if this is part of the state).
- Iterate from i = 1 to i = number of block transactions.
- Apply transaction i to the state.
- Apply block post-processing (e.g., pay miner).
The Ethereum yellow paper describes a blockchain as a cryptographically secure transactional singleton machine with shared-state. This removes the emphasis on it being a ledger of transactions and, instead, places the focus on it being a state machine. The kind of state machine represented by blockchains such as Bitcoin and its forks (e.g., Litecoin, Dogecoin) are rather basic and tailored to one specific kind of operation. That is, representing ownership of a cryptocurrency and transferring these between parties. There is nothing stopping us from creating blockchains that can do other kinds of operations. More generally, we could allow ‘transactions’ to store or retrieve arbitrary pieces of data, and perform general calculations on these. The machine state will then not just consist of transaction outputs or account values, but will contain all of these blocks of data that users have added, and possibly stored code to be executed when required. Then, different users of the blockchain can write custom scripts (called smart contracts) in order to use it for different purposes. This is the idea behind smart chains such as Ethereum, Cardano, and others. In fact the Ethereum virtual machine (EVM) is designed to be Turing complete, unlike the simple script used by Bitcoin, potentially allowing any computable operation to be performed on-chain.
The following is a list of examples that smart chains have either been used for, or that have been suggested as possible uses.
- Borrowing/lending.
- Decentralized exchanges (DEX).
- Tokens. These are a kind of cryptocurrency but, rather than natively existing on a blockchain such as Bitcoin, they are constructed on an already-existing smart chain. Ethereum has an ERC20 standard for such tokens, and many thousands of these have been created (UNI, USDT, USDC, HEX, WBTC, GRT, SHIB, …).
- Stablecoins (Eg, USD Tether), which are a special kind of token.
- DAOs (Decentralized Autonomous Organizations).
- Bonds.
- Synthetic stocks and shares.
- Derivatives. (Call/Put options, etc.)
- Betting.
- Online games.
- Inheritance/wills.
- Personal ID/Birth certificates.
- Voter registration records.
- NFTs (non-fungible tokens).
- Supply chain tracking.
- Employment contracts.
It should be noted that, as a state machine, blockchains are extremely inefficient. Every instruction that each user wants to be executed has to be transmitted to the network and recorded on the blockchain in perpetuity. Then, every node is required to execute all of this aggregated code in order to perform validation. This is very different from personal computers, for example, which are used for memory and computationally intensive tasks. In fact, most of the time, we would already know the results of any computation submitted to the chain. The purpose is not to perform a difficult calculation but, rather, to have the results recorded in a way that can be proved to any other parties. Efficient use of a blockchain is important, so that calculations are only done on-chain where having an official record is really necessary, with other calculations being performed off-chain.
Native Currencies
Once we change our focus of a blockchain from being a ledger for transactions in a cryptocurrency, towards being a state machine for general calculations on a shared state, then it naturally leads to a question. Does a blockchain need to have a native currency or asset at all? We could imagine just having transactions where users can create their own ‘smart contracts’, updating stored data without any reference to a specific currency. Yet smart chains do have a native asset. Ethereum has Ether, for example. While it is possible for private and centralized blockchains to manage without an associated asset, public decentralized chains do need a native currency for the following reasons.
- Validators/miners are unlikely to work for free, so require compensating in some way. This can only be done by the protocol of the blockchain if it can reference and create transfers in an asset. Proof of work requires miners to expend considerable energy and, as discussed in an earlier post, other protocols ensuring immutability still require miners or validators to spend significant amounts of some resource. They would only continue to perform the task of creating new blocks if they expect, on average, to receive at least as much in compensation as they spend on the resource in question.
- Transactions take up space on the blockchain and require validators to perform work. Transactions which are either extremely large or contain very computationally intensive calculations could cause problems with the network, as could blocks containing massive numbers of transactions. If we were to allow blocks to be so large or require so much computation that nodes are not able to process them, then the network could grind to a halt. This would be vulnerable to DOS attacks. To help prevent this, users are required to pay a transaction fee dependent on the amount of blockchain and validation resources that the transactions use. This fee is paid in the native currency of the chain.
Some blockchains simply specify a limit for the size of each block. In the case of Bitcoin, the limit is currently set at 1MB although, since the introduction of SegWit, blocks can be larger once signature data is included. As transaction fees are paid to the miner of a block, they would naturally choose those transactions with the largest fees in relation to their size in bytes. Once the number of transactions submitted to the mempool for inclusion in the blockchain becomes large enough that they cannot all fit in a single block, a fee market ensues where those transactions with a larger fee get included in blocks before those with lower fees.
The resources used by a transaction is not just given by the size that takes up in the blockchain, but also by the amount of computation that it requires to validate. This is not much of a problem for Bitcoin, since validation is straightforward and the Script associated with each output only requires processing each command in turn, so is limited in the computation required. For smart chains such as Ethereum, with a Turing complete language, even a short transaction could require a lot of computing resources. In fact, the Halting problem tells us that it is impossible to determine whether a general computation will ever end. A miner could potentially generate a block containing code which takes an infeasible time to compute, or never terminates at all, which would cause the network to come to a halt. For this reason, Ethereum has the concept of gas which incorporates both the data size and computation required to process a transaction. Transactions and blocks have a gas limit, and transactions pay a fee in the native Ethereum currency depending on the amount of gas used. This incentivizes users to not use too many resources, and limits the total computational power required from validators.
For the reasons described above, smart chains still require a native currency. Miners and/or validators are paid for their work in two ways. Either fresh currency is created, causing some inflation, or they are paid from the transaction fees or, commonly, both. The fees paid by users submitting transactions can go directly to the miner (as with Bitcoin), or can be burned, or a combination of the two can be done with part of the fee being burned and part being used to pay the miner. Since the recent London hard fork, Ethereum uses this mixed approach.
Zero Knowledge 