Blockchains are a radical new computing model where data and applications are secured not by centralized intermediaries but by a decentralized network of computers. Due to their permissionless nature, blockchains enable anyone to opt-in and begin independently verifying the integrity of computations, resulting in a checks and balances system between users and network operators. 

From the creation of new digital currencies with programmatic monetary policies (e.g. Bitcoin) to the execution of programmable trust-minimized applications (e.g. Ethereum), blockchains are rapidly entering the public consciousness as a new form of digital infrastructure, often referred to as Web3. However, while the overarching value proposition of blockchains is recognized by many, the nuances regarding the underlying trust model of blockchains are often misunderstood.

This article will serve to explain how the trust model of blockchains differs from traditional computing by looking at the role of self-verifying full nodes, with particular reference to how they keep block producers (e.g. miners/validators) accountable and how decreasing the cost of verification is at the heart of blockchain scalability. 

The Limitations of Traditional Computing Models

The computing model used by most applications today involves a client-server model where requests are sent to a centralized database server. The participants within the traditional computing model can be broken down into the following:

• Clients: End-users who generate requests, often via a personal device, which are sent to a centralized database server over the Internet via TCP/IP and await a response. Clients trust the database server to faithfully respond to requests.
• Database Servers: A remote computer, often in the form of a centralized cloud provider, that provides information or access to particular services. The backend database server is often a collection of computers which a traditional institution centrally manages.

Often referred to as “Web2,” this computing model empowers developers to quickly launch and scale applications on-demand. Users are also provided with a seamless user experience due to low-latency and high-throughput computation facilitated by data centers. While applications hosted on centralized databases provide immense value to billions of users around the world, they carry certain limitations. 

Most notably, end-users have no way to verify that the computation involved in producing a response to a request is legitimate or that the database entries have not been manipulated over time. Such applications effectively operate in a black box, meaning users must fully trust that third-party intermediates will act in their best interests. 

The trust assumptions associated with centrally hosted applications can negatively impact users, who can experience financial censorship, social media deplatforming, leaks of their personal data, manipulative content selection algorithms, increased reconciliation costs, corrupted data and data loss, and an overall lack of accountability. The end result is a breakdown in societal trust and an increase in the cost of economic coordination.

The Blockchain Computing Model 

Rather than trusting the good faith of centralized intermediaries, blockchains introduce trust-minimization and credible neutrality by using:

1. Cryptography to authenticate data/asset ownership and validate transaction integrity;
2. Decentralized consensus to establish the ordering of transactions and enforce the protocol’s rules;
3. Financial incentives to ensure the immutability of the network’s ledger and its ongoing operation. 

Importantly, blockchains are open networks—anyone in the world can join as either an active contributor or a passive listener. This allows end-users to verify for themselves that any output produced by the network is valid and that ledger entries have not been tampered with. The transparency of blockchains also mitigates risks around opacity, eliminating information asymmetry and ensuring information regarding risk exposure is available to all participants. 

The Different Roles of Blockchain Participants

To ensure the proper operation of a blockchain, there are various (often overlapping) categories of network participants that each play a crucial role.

• Block Producers (BPs): Entities responsible for ordering and packaging transactions into discrete data structures called blocks which are then proposed to the network to validate. If two valid blocks are produced at the same block height, BPs are responsible for determining which version of the chain is canonical (e.g. longest chain rule). A consensus algorithm is used to determine which BP is responsible for generating the next block in the chain of blocks, with Proof of Work (miners) and Proof of Stake (validators) being the two most popular models.
• Full Nodes: The heart of a blockchain network. Full nodes download and self-verify each block proposed by BPs. If the block is found to be valid (i.e. protocol rules have been followed), then the block is added to the full node’s personal copy of the ledger and state changes are applied. Any invalid blocks not in line with the protocol’s rules are ignored and consequently discarded without any state changes occurring. 
• Archive Nodes: Entities that store all of the same information as full nodes but also compute and store previous states of a blockchain. Archive nodes are useful for querying arbitrary historical data, such as a user’s account balance at a specific block height in the past. Note that a full node can be converted into an archive node at any time without having to download any extra information from the network. Archive nodes typically have high hardware requirements and are commonly run by service providers (e.g. block explorers).
• Light Clients: A limited form of a full node where only the headers (i.e. small unique cryptographic fingerprints) of blocks are downloaded. Light clients can verify a transaction was included within a block, but because they do not download or execute all transactions within blocks, they implicitly trust that the majority of block producers are honest. Light clients, also known as Simple Payment Verification (SPV) clients, were first described in the original Bitcoin whitepaper. 
• RPC Providers: Full nodes that facilitate read/write access to a blockchain that other network participants connect to. RPC (Remote Procedure Call) nodes are often used by those who do not or cannot run their own full node or light client, significantly reducing the friction of accessing a blockchain. Any user connected to an RPC provider implicitly trusts the honesty of the provider as no self-verification work is done.
• End-users: The average user who wants to make transactions on a blockchain network. This category can include participants who run a full node or light client, as well as those connected to an RPC provider. Blockchains exist to serve the end-users, otherwise there is no other reason for the network to exist.

While each of these network participants plays a key role in blockchain ecosystems, full nodes operate at the heart of a blockchain network as they are the entities responsible for maintaining full replicas of the network’s ledger. Other network participants, such as block producers and light clients, connect to full nodes to stay informed on the state of the network. The resulting network topography is illustrated below.

The Limited Powers of Block Producers

A common misconception about blockchains is that since block producers are responsible for generating new blocks containing transactions, then they must unilaterally control a blockchain. Put another way, the belief is that if a majority of BPs are corrupted/colluding (commonly known as a 51% attack), then the network is wholly compromised and everything of value can be irrevocably destroyed. In reality, BPs have a limited scope of power, where only specific types of malicious activity can take place. 

What block producers can do:

• Censor Transactions: Individual BPs determine which transactions are included in blocks they create, allowing them to selectively ignore specific transactions. While colluding BPs can prevent transactions from being included in blocks they create, there only needs to be one honest BP in order for a transaction to be included within a valid block.
• Rewrite the Chain: If the majority of BPs collude (e.g. a 51% attack), then previously created valid blocks can be forked out of the network through a process called block reorganization (reorg), where a new chain of blocks becomes the canonical chain. Note that some blockchains have a notion of “economic finality” via a checkpoint system, with reorgs of blocks older than the checkpoint resulting in a chain halt which requires resolution via social consensus. 

What block producers cannot do:

• Change the Protocol’s Rules: BPs cannot arbitrarily change the protocol’s rules such as adding/removing functionalities (e.g. opcodes), increasing/decreasing the maximum allowed block size or block time interval, or increasing/decreasing the block rewards issued for producing blocks. 
• Steal User Funds: BPs cannot spend coins/tokens from addresses for which they do not have the private key, as the cryptographic signatures of such transactions would be invalid. Note that while chain reorgs can lead to double-spend attacks, this involves simply removing a transaction from the chain’s ledger that was signed by the private key holder, not falsifying a transaction signature. 

To understand why the power of BPs is inherently limited, it is important to understand the relationship between BPs and self-verifying full nodes. 

How Full Nodes Keep Block Producers Accountable

While BPs ensure the liveness of a blockchain by proposing new blocks, they do not determine the validity of blocks on behalf of the network. Rather, it is the role of full nodes—which store a personal copy of the blockchain’s ledger—to independently validate each block and execute all the transactions contained within to determine whether the protocol’s rules are being followed. 

The result is a checks and balances system where full nodes hold BPs accountable by only accepting valid blocks and ignoring blocks that do not conform to the protocol rules. As such, BPs are economically incentivized to only produce valid blocks, as otherwise they would waste economic resources by producing invalid blocks and forfeit any block reward and transaction fees they could have earned. Even if other BPs build valid blocks on top of an invalid block, these blocks will all be ignored by full nodes, resulting in such BPs effectively forking themselves off the network. 

Full nodes are operated by key economic actors within a blockchain’s ecosystem, including cryptocurrency exchanges, stablecoin issuers, oracles, layer-2 validators, RPC providers, custody wallet providers, large crypto asset holders, and average users alike. By self-verifying a blockchain’s ledger, these key economic actors cannot be tricked into accepting invalid blocks. Full nodes do not need to coordinate/communicate with each other to determine if a block is valid either. Rather, by following the protocol’s rules when checking blocks, they will all arrive at the same conclusion regarding block validity. 

With many blockchains, the protocol rules are determined by the community off-chain in a process known as social consensus. This typically involves a formalized process (e.g. Ethereum Improvement Proposals or EIPs), where the community debates the merits of any protocol rule change on various social channels. Once rough off-chain consensus is achieved, blockchain core developers write a new version of the blockchain software client, which implements these changes. Full nodes and BPs can then choose whether or not to run this new software to upgrade the network via a hard fork (non-backward-compatible change) or a soft fork (backward-compatible change). 

If a hard fork upgrade is contentious, then the network may experience a chain split where two different versions of a blockchain are created and individually maintained. Once a split occurs, each blockchain will have a shared history from the genesis block up to the specific block height at which the split occurred. This was seen with the Bitcoin/Bitcoin Cash hard fork in 2017, when differences arose on how to scale transaction throughput. It was also seen in the Ethereum/Ethereum Classic hard fork in 2016, when differences arose on how to handle The DAO hack.

In contrast to off-chain consensus, other blockchains have chosen to handle upgrades via on-chain governance, with a Decentralized Autonomous Organization (DAO) governed by token-holders determining protocol rule changes. Either method of facilitating protocol upgrades presents its own unique benefits and challenges, and the method used depends on the needs of the community. 

Low Hardware Requirements for Full Nodes

If the hardware requirements for operating a full node are too high (e.g. non-consumer hardware is required), then fewer entities will be capable of or willing to run a full node, instead, relying on centralized solutions to read/write to the blockchain. This can result in a blockchain network becoming more vulnerable to exploitation from BPs.

To support a healthy network of full nodes, many blockchains purposely limit the transaction throughput of the network to that of the lowest spec computer that the community desires to self-verify the ledger. Low hardware requirements not only help those who wish to run a full node during normal operations, but also make it easier to spin up a new self-verifying full node if the blockchain is actively being attacked by a colluding group of BPs. The exact hardware requirements necessary to stay fully synchronized to the network vary from blockchain to blockchain, however, a common target goal is average consumer hardware.

The following logic describes how low hardware requirements lead to the core value proposition of blockchains: 

Low hardware requirements → low cost to verify blocks → more entities can run full nodes → stronger resistance to BP attacks → increased network security → superior credible neutrality → increased adoption

While the minimum hardware requirements capable of running a full node are not explicitly defined in the rules of a blockchain protocol (improvements in hardware/software efficiency is perpetually occurring), the transaction throughput rules of a blockchain (commonly determined by the size and frequency of blocks) are tuned to target a specific range of device specifications. 

Although targeting average consumer hardware is a common approach, some blockchains opt to target beefier server-grade hardware as the minimum hardware requirements for verification in order to increase transaction throughput. This comes with the acknowledgment that while fewer entities may be able to self-verify the ledger using self-hosted equipment, a sufficient number of key economic actors may still have the resources necessary to run a full node. 

Reducing the Costs of Blockchain Verification

Everyone in the world running their own full node to self-verify a blockchain is an idealistic goal. However, in practice, the time and resources required to spin up a full node may introduce too much friction for many end-users. As blockchains become more widely adopted, users familiar with trusting centralized service providers may find the process of setting up a full node too cumbersome, and would rather be able to immediately start interacting with on-chain applications. 

As a result, most end-users of widely used blockchains today do not run their own full node, but rather connect to and implicitly trust RPC providers to relay transactions to the network and inform them on the current state of a blockchain. Such users may not enjoy the full self-verification benefits of blockchains and the security of the network is not as strong as it could be, however, it is still an order of magnitude improvement in trust-minimization over traditional computing models.

A middle-ground solution to this problem could entail the integration of light clients into blockchain wallets. While this would be an improvement over the status quo by reducing trust in RPC providers, light clients still implicitly trust that the majority of BPs are producing valid blocks and that all of the transaction data within a block has been made publicly available.

In order for light clients to verify the work of BPs without simply downloading and executing the entire block (i.e. running a full node), technical improvements in light client implementations can increase their trust-minimization properties, resulting in what can be considered “trust-minimized light clients”. These technical improvements can include:

• Fraud Proofs: A cryptographic proof generated by full nodes that can be sent to light clients to prove that a block is invalid and violates the protocol’s rules without the light client needing to re-execute the entire block. 
• Validity Proofs: An alternative to fraud proofs where a zero-knowledge proof is generated, allowing block producers to directly prove to light clients that blocks are valid and follow the protocol’s rules.
• Data Availability Sampling (DAS): A probabilistic sampling technique that verifies that all of the data in a block has been made available to the network without light clients needing to download the entire block.

As additional trust-minimization techniques are created and deployed successfully in production, the cost and friction of verifying the work of block producers without downloading and executing entire blocks improve, leading to more secure blockchain networks. Notably, the methods of creating trust-minimized light clients can even enable more scalable blockchain networks to emerge.

Scaling Blockchains While Retaining Self-Verification

Scaling a blockchain is commonly thought of as being equivalent to increasing transaction throughput. However, a more holistic interpretation would be increasing transaction throughput while maintaining a low verification cost. Thanks to the properties of trust-minimized light clients, the throughput of a blockchain network can be increased (e.g. increasing block size and/or block interval time) yet still retain the low verification costs required to keep BPs accountable. 

Furthermore, layer-2 scaling solutions such as rollups leverage similar techniques as trust-minimized light clients by using cryptographic proofs to prove transaction validity without the blockchain network needing to execute every transaction. In this case, the blockchain operates an enshrined trust-minimized light client for the layer-2 rollup. Combined with transaction batching and storage of transaction data on-chain for data availability, transaction throughput can be increased by multiple orders of magnitude with minimal to no additional verification costs imposed on the underlying blockchain.

Conclusion 

Blockchain are highly secure, credibly neutral, and transparent append-only ledgers that offer a new paradigm for computing. By incorporating a checks and balances system between block producers and full nodes, a blockchain can serve the needs of its community and evolve over time while also remaining resistant to manipulation. While more work needs to be done to lower verification costs, blockchains in their current state still offer an order of magnitude increase in trust-minimization over traditional computing models. 

—

The opinions expressed within this post are solely the author’s and do not reflect the opinions and beliefs of the Chainlink Foundation or Chainlink Labs.