Light Clients (Part 2): How Avail light clients overcome the challenges of monolithic chains

Welcome to the second post in our three-part series aimed at demystifying the world of blockchain architecture. In the first segment, we set the stage by examining traditional monolithic blockchain systems, and describing how validators, full nodes, and light clients interact with each other. In part two, we look at how these network participants in Avail are improved, with a focus on light clients in particular. Let’s dive in!

In the second installment of our three-part series, we're shifting our focus from the limitations of traditional blockchain architectures, explored in part one, to the innovative framework proposed by Avail. We'll delve into how Avail redefines the roles of network participants, particularly transforming the functionality of light clients. By offering novel solutions to inherent challenges in traditional blockchain systems, Avail's data availability light clients usher in a more decentralized, efficient, and secure future. If you haven't read our first post yet, we recommend it for a better understanding of this discussion.

A Better Way

In part one, we discussed the limitation of traditional blockchain light clients. Their need to trust full nodes, and inability to verify the information given to them by full nodes introduces trust requirements into a system meant to be trustless. This light client/full node dependency is present across the industry. To combat this, Avail’s architecture almost entirely removes the need for one of these peers: full nodes.

Avail is laser focused on the task of data availability, which has given us the opportunity to rethink how each network participant of the blockchain can be improved, and optimized for the task. There’s a better way for blockchains to be built.

The primary attack vector on Avail is not a double spend attack as is the case with Ethereum or Bitcoin, but rather data unavailability. Avail’s solution addresses the limitations of traditional light clients by empowering them with the ability to perform data availability sampling. This simple new power allows light clients to achieve security equivalent to full nodes.

Data availability sampling is the process light clients use to request small, random pieces of each block. Confidence builds progressively with each successful sample. Once verified, the data's availability allows confident interaction with the rest of the modular blockchain stack.

For this to work, all of the network peers on Avail are redefined. In Avail, validators accept transactions and create blocks. Once a block is created, if data is not available, light clients can recognize this.

In Avail, to identify whether the rules of the chain have been correctly followed, all one needs to do is host a light client. Full nodes, while they exist in Avail, play a supplementary role to keep high redundancy, marking a massive departure from the critical role full nodes play in traditional, monolithic architectures.

To go into more detail, in Avail's ecosystem, validator nodes are responsible for packaging transactions and constructing candidate blocks - without executing the submitted data blobs. These validator nodes also generate KZG commitments for the data. These KZG commitments are critical, as they are ultimately what enable light clients in later steps to identify missing data.

Again, while Avail full nodes do exist, they are treated almost as a backup tool to maintain high redundancy of data on the network. We expect the vast majority of applications and services built on Avail to use light clients alone, as Avail light clients have the ability to make data available for applications entirely on their own.

Avail's Data Availability light clients then eliminate the need for light clients to trust anyone. They have the power to achieve equivalent security guarantees as traditional full nodes, because they are actually critical of the information they receive. In a modular ecosystem like Avail, light clients fetch tiny pieces of data through data availability sampling and verify it against the KZG commitments generated by the validator nodes.

Even if all Avail validators are wrong (i.e., two-thirds plus one of consensus nodes collude to not completely reveal block data), light clients can recognize data unavailability on their own. This is similar to how traditional full nodes in monolithic architectures can identify when validators are colluding and acting incorrectly. By contrast, with Avail, you can achieve the same security guarantees with light clients alone, reducing the heavy computational requirements often associated with full nodes in traditional blockchains.

This process as a whole allows Avail light clients to exist with minimal reliance on the Avail consensus for data availability. This distinction between monolithic and modular ecosystems underscores the powerful and trustless approach Avail offers, enabling light clients to independently verify information without depending on full nodes.

Avail light clients also play an active role in maintaining the availability of data. As light clients sample the network, they populate a Distributed Hash Table (DHT) to keep the data available in the peer-to-peer network, essentially creating a copy of all recent Avail transactions to ensure data is still available on the network in the case some, or even all full nodes and validators go offline.

This process ultimately gives light clients security guarantees equivalent to those of full nodes, with orders of magnitude fewer resource requirements. With this approach, Avail reduces reliance on full nodes, giving even the lightest of computers full security that they’re not being deceived by others on the network, with regard to data availability.

Continuing the analogy from part 1

Stepping into the realm of Avail's ecosystem, we find a revolutionary shift in the roles of the marketplace. The artisans, inspector-distributors, and consumers undergo a transformation, bringing forth an efficient, robust, and more decentralized blockchain architecture.

In Avail's marketplace, the validator nodes still play the artisans, but their role is slightly different. They are no longer molding and firing the clay (executing transactions) but rather, they are preparing the raw materials (packaging transactions) and constructing the shape of the product (creating candidate blocks). These artisans are also responsible for generating the unique signatures (KZG commitments) for the products, an essential feature that will empower the consumers in this marketplace.

While the full nodes are still present in Avail's marketplace, their role has diminished. They aren't the main inspectors or distributors anymore, rather, they act more like a reserve or a backup, ensuring the high redundancy of the products. They are no longer the gatekeepers of the marketplace, and the majority of the marketplace's operations can proceed without them.

What's revolutionary in Avail's marketplace is the role of the consumers, the light clients. Imagine giving the consumers a magical magnifying glass that can verify the authenticity of the products they receive. The consumers are now empowered to sample tiny pieces of each product (data availability sampling), comparing it to the unique signatures (KZG commitments) provided by the artisans (validators). If the pieces match the signature, the consumers can rest assured that the product is genuine. The consumers are no longer dependent on the word of the inspector-distributors (full nodes); they can verify the authenticity of the products themselves.

This transformative approach deals with the primary threat in Avail's marketplace, which is not counterfeit goods but rather data unavailability. In case the artisans (validator nodes) decide to withhold information about the products (data unavailability), the consumers, now equipped with their magical magnifying glasses, can identify the missing data on their own. If data is not available, consumers are no longer at the risk of purchasing flawed products; they can simply wait until the data becomes available.

Not only that, but these empowered consumers also contribute to maintaining the marketplace's liveliness. As they sample the products, they keep a record of their findings in a shared ledger (Distributed Hash Table - DHT), ensuring the continuous availability of data in the marketplace. In a sense, they collectively create a 'backup' of all the recent transactions, ensuring that the marketplace stays alive even if some or all artisans (validator nodes) and inspector-distributors (full nodes) go offline.

Avail's innovative approach gives the power back to the consumers (light clients), providing them with security equivalent to that of full nodes, all without the heavy computational requirements often associated with full nodes in traditional marketplaces. By eliminating the need to trust the inspector-distributors (full nodes), Avail's marketplace allows for truly decentralized and efficient operations, paving the way for a new era in blockchain technology.

In part 3 of this series, we will look at how these changes in roles within Avail's marketplace can have far-reaching implications, addressing issues of scalability, improving interoperability, and enhancing the overall experience in the blockchain ecosystem.

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.