I think it’s useful since there is a lot of confusion in the space to comprehend how all blockchain parts fit together. In a multi-chain world there’s a bigger need for clear understanding as multi-chain and modular systems have more moving parts to operate.
So over the last month or so I tried to create a framework to understand blockchains. My plan was to pick a few fundamental properties of blockchains that both explain what is going on and make observable difference to the end users.
Hope you find it useful.
Introduction
There are different ways to explain blockchains. Some like to describe technical terms and dive into each one in detail, some like to give analogies to real life examples and others like to start from first principles of economics and computer science and then slowly build their understanding of blockchains.
My prefer way is to think blockchains is to think about the properties that make observable differences to end users. So I look for properties that are meaningful to end users but also explain what’s happening under the hood.
These properties are who can include transactions in behalf of the end user, when transactions are final and can’t reverted and whether users can check the blockchain using their home computers. We will look into each one of them in detail below.
Who can include transactions?
Blockchain systems are maintained by a swarm of nodes. These nodes are computers connected to the internet that manage what’s happening on the blockchain.
The more nodes in a blockchain, the higher the chance transactions end up included in the chain since transaction inclusion is voluntary. Nodes that are creating blocks are only incentived is to collect fees but it’s up to them to choose which transactions they will include in the block and in which order. Blockchains with only a few nodes, have a higher chance that dishonest nodes are chosen to create the next block.
But including a transaction in a block sometimes is is not always final. In some blockchains such as Ethereum users have to wait certain blocks to be get some certainty that the transaction is irreversible. In other blockchains such as Bitcoin transactions are never final but only practically final (ie. in Bitcoin after 6 blocks there’s a 99.98% chance and 99.99988% after 10 blocks a transaction is final for an attacker with 10% of the hashrate).
What’s the best case:
-
Decentralized validators: The more decentralized a blockchain is the less transaction censorship there could be. That’s because including transactions in blocks is voluntary done by nodes a so nd the more nodes there are the higher the chance one node acts honestly and includes the transaction in the block. Moreover, since the node that creates the next block random, it’s only a few seconds delay until the next node includes the transaction. As a side note, layer 2s are different to layer 1 as they have fewer nodes. In layer 2s, nodes to commit to the transactions they will include in the next block and if they miss-misbehave they pay a penalty.
-
Low hardware requirements: It’s best to have nodes with low hardware requirements. But in practice having more than ~1m nodes creates problems with node communication and most blockchains put financial restrictions on their nodes to keep the node count under that number. Besides participating in consensus, it’s also good if nodes with low hardware specs are able to verify the blockchain. Nodes outside consensus can execute the transactions themselves or use light clients to proof the state of the blockchain (with storage proofs for data availability and zero-knowledge proofs for transaction validity).
-
Transactions are final: In some circumstances where most nodes of a blockchain are offline due to DDOS attack, networking issues or other blockchains have to make a choice. One option is to halt until enough nodes come back online such as Tendermint and the other option is to continue producing blocks with fewer nodes such as Bitcoin. Blockchains that continue to make blocks can’t have their transactions final because the nodes that went offline might return later and reveal they prefer a different version of the chain which might cause a few transactions to revert. Some blockchains aim to get the best of both words such as Ethereum that stays online even with very few nodes but only finalizes transactions when 66% of the network vote for them.
What can go wrong:
-
Double-spend: If a few nodes have controlling power over a network, they can funds to buy stuff and then revert the chain to get their funds back. That’s called a re-org attack or a 51% attack. In this scenario, the attacker would have to can generate blocks but keep them to themselves and reveal them all together after spending their funds. Other nodes would see a longer (and hence more valid chain) and switch to that chain instead.
-
Tx censorship: Nodes that participate in consensus have some extra power over a blockchain. These nodes get to decide which transaction are included and in which order when it’s their turn to create a block. In other words, the node that creates a block has the option to censor specific transactions, or all of them. That’s what happening with Tornado Cash and the OFAC list where nodes that want to be compliant exclude Tornado cash transactions. These censorship does not mean that transactions are censored forever. These transactions stay “pending” and are eventually included in a block if there is at least one non-censoring node.
-
Data eclipse: Another attack vector that is commonly overlooked in crypto is natural disasters. Blockchains need to have access to user balances and smart contract data to be able to operate. If this data is lost from all nodes then the blockchain would be halted forever. This attack is a bigger problem in blockchain with low node count or concentrated in one or two cloud data centers (eg. AWS or GCP).
-
Denial of service: Blockchains with low node count are also more susceptible to direct attacks on nodes by flooding them with requests. Systems belonging to the BFT consensus family are also more vulnerable to this attack since they require >66% of their stake-weighted validator set to be online. In fact, Avalanche requires 75% of their nodes to be online and Algorand needs 80%.
Note: The technical name for nodes including transactions in blocks is “Block production”.
Can I check?
Blockchains allow end users to validate them in a few different ways.
Conventional blockchains such as Bitcoin and Ethereum (pre-EIP4844) require all nodes to process all transactions. In fact every node has to execute all transactions from genesis to the last block to be sync and then all new transactions that come with new blocks.
In contrast, sharded blockchain have their nodes spilt in committees where each committee only validates a portion of the chain that is assigned to. In these blockchains nodes don’t validate all transactions but rely on other shards / committees to validate their part. If nodes in one shard are acting dishonestly one honest node can submit a challenge to have the dishonest nodes slashed and to correct the chain.
A third mechanism that a few blockchains now support are light clients which are nodes that can only verify the chain but can’t participate in consensus. Light clients validate only the block metadata and do not process all transactions themselves. In proof-of-work it means checking that certain amount of work has been spent on the block, in proof-of-stake it means checking a certain amount of votes have been casted to the block and lastly in data availability chains like Celestia and Ethereum (post-4844) it means checking that the data that are stored correclty onchain.
What’s the best case:
- Low hardware requirements: Blockchains with minimal hardware requirements allow more users to run nodes and verify the chain themselves. In practice, there are two types of nodes, nodes participating in consensus and producing blocks and nodes that are just listening to the chain and only verify blocks without creating new blocks. Nodes that participate in consensus are verifying the chain by only creating blocks on top of other valid blocks. Nodes that don’t participate in consensus can’t affect consensus but can only communicate any shenanigans over social channels.
What can go wrong:
- Ghost transactions: Some blockchains are open and permission-less but still have high hardware requirements that home computers can’t verify the chain. The problem with these chains is that invalid transactions might get included and not be noticed by anyone in a way that could defy the purpose of an open and permission-less chain.
Note: The technical name for validating the blockchain is “Block verification”. “Light clients” are nodes that onlu verify the chain without re-executing all transactions up to some confidence levels.
Is it done?
If you heard that Bitcoin transaction need 60 minutes (or 6 blocks) to confirm that’s because not all blockchains transactions are final. In some blockchains such as Bitcoin and Ethereum there’s a possibility that a transaction gets in a block and then gets reverted.
In fact, that’s the reason many centralized exchanges such as Coinbase and Binance have long waiting times for depositing funds. The longer they require users to wait, the lower the chance the blockchain reverts and hence the lower the chance they lose money.
What’s the best case:
- Instant Finality: Instant transaction finality means that transactions that enter a block are settled forever. The fact that blockchains with instant finality can’t revert is not always a good feature. That’s because the finalized state might not representative of the majority of the nodes in case many nodes go offline due to a bug or a network issue.
What can go wrong:
-
Double-spend: Since many blockchains are not instantly finalized there could be two competing versions of the same chain. Each version might have support from a few nodes and it may take a while until the network settles on which chain is the most valid one. This might happen from malicious node controlling the majority of the network stake or hash power or from network issues. These attack are discussed in more detail in the “Who can include transactions?” section above.
-
Long range attacks: Another possible attack on non-finalizing chains are long range attacks. In such an attack an adversary creates a version of the chain that most nodes are off-line and their stake are slashed. After some time the attacking node can accumulate more and more staking rewards (in their version of the chain) and then reveal the chain to other nodes hoping to fool them that this is the longest chain. Major proof-of-stake blockchains attach weights to blocks (so chains that are voted on from only a few nodes are weighted less) and hence avoid this attack.
Note: The technical name for transactions settling forever is “Block finality”.
Summary
One way to look at blockchains systems is to understand 1) who can create blocks 2) when these blocks are final and 3) whether end users can check them.
Creating blocks ie. blocks production is safer if it’s done by multiple nodes with low hardware specs otherwise they are subject to transaction censorship, blockchain data eclipse and double spend attacks. Checking these blocks ie. block verification is preferably done with consumer computers or with proper light clients. Ensuring that a block is final ie. block finality is either instant or delayed for extra safety based on the consensus design (BFT vs Nakamoto).
The goal of this framework is to help understand trade-offs different approaches have and make your own decision on appropriate use cases of various projects in the space.