Welcome to the inaugural part of our three-part series aimed at demystifying the world of blockchain architecture. In this first segment, we set the stage by examining traditional monolithic blockchain systems. We describe how validators, full nodes, and light clients interact with each other. Let’s dive in!
Imagine a world where developers can create applications that can be trustlessly accessed from any device. In this world, trust in third-party services is minimized, scalability is no longer a concern, and anyone can access the power of blockchain from any device. This future is closer than it seems.
In this first segment, we will make a compelling case for the emergence of Data Availability light clients which is set to mark a turning point in the blockchain industry. We set the stage by examining traditional monolithic blockchain systems. We describe how validators, full nodes, and light clients interact with each other. We will also hint at some of the inherent challenges and limitations in these systems, and discuss how a new approach offered by modular base layers such as Avail provides a solution that can shape the next wave of blockchain application development.
The Evolution of Light Clients
In a classical blockchain architecture such as Ethereum or Bitcoin, the only way to follow and verify the chain's correctness is to host a full node. Discussions around the "decentralization factor" of a chain often revolve around the question: "Can you run a full node on a laptop?" This approach emphasizes the need for hosting a full node to ensure the security of the chain, requiring more and more intense machinery by the month.
As a stopgap, traditional blockchain light clients offer a lightweight alternative to full nodes. Light clients have been designed to enable users to interact with the blockchain without downloading and storing the entire blockchain data, but these light clients do not and cannot operate alone. This inability to operate independently introduces security vulnerabilities.
Three Types of Network Participants
In current monolithic blockchains, there are three types of peers: validator nodes, full nodes, and light clients. Let's delve into them.
Validator nodes collect transactions from the mempool, execute them, and generate a candidate block that is appended to the network. The block contains a small block header with the digest and metadata of the transactions in the block. These validator nodes can be thought of as full nodes with stake—they are capable of participating in the network.
This candidate block is then propagated to full nodes across the network for verification. Full nodes typically choose to re-execute the transactions contained in the block to ensure its validity. What differentiates full nodes from validator nodes is that full nodes can follow the state of the chain, but do not actively participate in the network.
Finally, in monolithic blockchains, light clients are simpler entities. They serve as an alternative to full nodes for devices with limited resources. These light clients typically fetch block headers alone and request transaction details from neighboring full nodes as needed. However, all they are doing is asking full nodes for their take on the state of the chain. Should a full node decide to lie, light clients remain at their whim.
An Analogy: The Artisan Marketplace
In the vibrant marketplace of traditional blockchain architecture, the roles of validator nodes, full nodes, and light clients mimic an intricate dance of artisans, inspector-distributors, and consumers.
In this bustling ecosystem, validator nodes are the diligent artisans, tirelessly crafting new blocks of transactions. Like potters at the wheel, they collect raw materials (transactions) from the surrounding environment (mempool), mold them into a coherent shape (execute the transactions), and create a new product (generate a candidate block). After this creative process, they're ready to hand off their work to the next player.
The full nodes, much like discerning inspectors and distributors, step into the scene. They receive the new product (candidate block) from the validator nodes and meticulously examine it for any flaws, re-executing the transactions contained in the block to ensure its validity. If they approve, they distribute (propagate) the product across the marketplace. If not, they reject the block, maintaining the high standards of the marketplace.
The end consumers - light clients - are interested in the final products (blocks), but lack the resources or ability to inspect every detail. They trust the inspectors (full nodes) to provide them with the best products, requesting block headers and transaction details as needed. However, they must trust that the product they receive is of good quality, as they lack the means to verify this for themselves.
Real or Fake?
Within this bustling marketplace though, the threat of counterfeit goods (double-spent transactions) looms. Imagine a scenario where a crafty manufacturer (validator node) tries to smuggle in counterfeit goods. Unlike the everyday light client customers, the experienced inspectors (full nodes) have the capacity to scrutinize every product. When a validator node attempts to pass off counterfeit goods, full nodes spot the fakes instantly.
Even in the face of a collusion among manufacturers (validator nodes) to flood the marketplace with counterfeit products, the inspectors (full nodes) have the ability to reject these goods, creating a new market where only authentic products are allowed—a fork, if you will.
However, the everyday customers (light clients) who are not equipped to verify the goods are left at the mercy of these manufacturers and inspectors. Light clients trust the merchant's (full node's) word implicitly, without the resources or capacity to verify the authenticity of the goods they receive. They are stuck following the consensus of the marketplace, illustrating their precarious position.
This situation highlights the vulnerability of the light clients in the face of potential double-spend attacks. They are at the mercy of the full nodes, dependent on their honesty and integrity to provide authentic and valid information. This delicate balance underscores the need for a more robust solution, setting the stage for our exploration of Avail's architecture in the following parts of this series.
In the meantime, you can find other analogies we’ve used to describe how blockchains operate in our post on modular blockchains here.
A Better Way
Light clients rely on full nodes for information, but don’t have the ability to independently verify the information they receive. This means that, in practice, in Ethereum or Bitcoin, if a double-spend is included in a block (an activity that breaks the “rules” of the chain), it will be rejected by all full nodes and validators. Even if two-thirds of the validators collude and include a double-spend, full nodes can fork off. However, if a dishonest majority of full nodes decides to act maliciously, light clients cannot reject those invalid blocks.
There’s a better way for blockchains to be built. In fact, Avail’s architecture almost entirely removes the need for one of these peers. In part 2, we shift our focus to Avail's distinct architecture and explore how it contrasts with the traditional blockchain systems outlined in this piece, with a special emphasis on the unique role of data availability light clients. Stay tuned.
The Avail public testnet is already live, and we’re looking forward to making further announcements on our roadmap and public mainnet plans soon.
We invite you to join us on this journey. Follow us on Twitter, or reach out to us on Discord.
