World of Light Clients

Mihir Faujdar

 - 5 min read
World of Light Clients bannner

The ultimate motivation behind public blockchains lies in the concept of decentralisation. This concept refers to empowering individuals by distributing control such that no single entity can exert control over the majority. If consensus can be achieved through a mechanism that ensures no invalid change happens on the ledger, then decentralisation is possible at any scale, including globally. When interacting with public blockchains at this scale, it becomes a right for any individual to verify what is happening on-chain without requiring trust. Primarily, in Ethereum, there are two methods for interaction, either running a full node or relying on a third-party service like Infura or Alchemy. For the average user, these are not ideal ways to interact as the former requires a considerable amount of hardware and storage, and the latter involves trust in the service. A resource-friendly and trustless alternative is to run a light client. This article will explain in-depth what light clients are and their benefits to the Ethereum ecosystem.

Note - Before reading about light clients, it will be helpful to understand what proof-of-work and proof-of-stake is.

Contents:

FAQ
Introduction
Sync Committee
  Initialisation
  Syncing
  Tracking Header
Benefits for the Ethereum ecosystem
Conclusion

FAQ

What are light clients?

To avoid nodes with access to insufficient computational resources not being able to participate in the Ethereum network light clients are proposed to allow for light nodes. Currently there exists clients to allow for full nodes, where a full node will keep track of a subset of the history of the entire blockchain and propagate transactions and blocks. Light nodes would instead rely on the information that full nodes hold (without having to store or process the same information themselves) to keep up to date with the state of the blockchain. Only nodes that do hold a current and accurate state of the blockchain can interact with the chain (though they can’t form consensus). This pattern assists light nodes in avoiding extreme memory and storage requirements that are not possible on devices such as mobile phones and IoT devices.

What are sync committees?

Consisting of 512 validators, sync committees are available for and responsible to the signing of headers of recently attested blocks. Changing every 8192 blocks (to guarantee no validators accrue too much authority) in the form of a sync period, each new committee is determined by a cryptographic random seed. The sync committee signature saved to the fields of each block are an important and concise form in which other nodes, especially light nodes, can determine information such as the currently ‘correct’ chain and how many blocks have elapsed etc. Each sync period that has elapsed since the last check-pointed block a node has access to requires a separate sync.

Introduction

In short, a light client keeps track of the latest block header by downloading and verifying it. It sends requests to full nodes for retrieving information about the changes happening in the chain. Currently, two separate chains exist in parallel: Mainnet and Beacon Chain. In the future, these two chains will be merged to replace the current consensus mechanism Proof of Work with Proof of Stake. The Beacon Chain, in particular, was designed to be light client-friendly. With the introduction of sync committees in the Altair hardfork, light clients can easily sync to the latest header and remain synced as the chain advances. It is necessary to highlight that light clients are not consensus-critical, meaning they do not participate in the voting process of blocks. Instead, they are an alternative for users or applications to interact with the chain in a decentralised manner. All in all, what is a sync committee, and why are they needed?

Sync Committee

A sync committee, made up of 512 validators, is responsible for signing the headers of newly attested blocks. It changes every period that lasts roughly 27 hours (27 hours, 18 minutes, and 24 seconds to be exact), equivalent to 8192 slots where each slot is 12 seconds long. The selection for the next sync committee is based on a random seed to minimise the probability of having a corrupted set of validators. Every new block contains a sync committee signature and bitfield, saved directly into its fields. Using this information, the light client can keep track of the latest header in an environment limited by resources. These environments include browser extensions, mobile phones, IoT devices, and low-powered laptops. Without the sync committee, it will be computationally expensive for the light client to verify blocks because it would involve running the proof-of-stake algorithm, known as LMD (Last Message Driven) ghost, for counting the majority votes of the validators.

Initialisation

To sync to the latest block header, the light client needs to know the current sync committee. That means knowing all the public keys of validators part of that committee. This information, along with proof, is requested from a full node by supplying a trusted checkpoint root. This checkpoint, also known as a weak subjectivity checkpoint, is the Merkle root of a block that is agreed subjectively as part of the canonical chain. The proof is a Merkle branch that proves whether the sync committee provided by the node is part of the chain. After sending the request, the node responds with a snapshot containing the following information stipulated below. If the verification of the branch is successful, the light client stores the snapshot and fetches committee updates until it reaches the latest sync period.

Depiction of the transfer of knowledge that would occur between a light node and a full node when the former wishes to sync to the latest block header. Depiction of the transfer of knowledge that would occur between a light node and a full node when the former wishes to sync to the latest block header.

Block’s header corresponding to the checkpoint root.

Current Sync Committee

Public keys and the aggregated public key of the current sync committee.

Current Sync Committee Branch

Proof of the current sync committee in the form of a Merkle branch.

Syncing

Depending on the recentness of the checkpoint root, the light client needs to sync from the checkpoint’s sync period to the latest sync period. For example, if the provided checkpoint root is for an old block at slot 2000 and the current block is at slot 18384, the light client fetches updates for two sync periods.

LCIE_002.jpg Any light node will need to update at the end of each sync period when a committee changes to reach the current block from the latest checkpoint root they have knowledge of.

Because there is a difference of 16384 slots between 2000 and 18384, and there are 8192 slots in a sync period, that means two sync periods have passed. Therefore, the sync committee has changed twice, and the light client needs to know these changes by fetching two updates. An update is similar to a snapshot, however, it contains information about the next sync committee and additional fields.

Attested Header

Header that will be accepted if the update is valid.

Next Sync Committee

Public keys and the aggregated public key of the next sync committee.

Next Sync Committee Branch

The Merkle branch of the next sync committee.

Finality Header

Header that was signed by the current sync committee.

Sync Committee Aggregate

Contains the sync committee’s bitfield and signature required for verifying the attested header.

Sync Committee Signature

An aggregation of every validator that signed the attested header.

Fork Version

A four-byte value that is used for signing the attested header.

Tracking Header

After syncing to the latest sync period, the light client starts requesting a header update for every slot. Upon receiving, it verifies the header by authenticating its corresponding sync committee signature and checks the bitfield to ensure enough participants had signed it. If this validation is successful, it stores the received header and awaits a new slot. From this point, the light client can trustlessly verify the upcoming headers of blocks without running complex algorithms or requiring excessive storage. Asynchronously, it maintains a local clock for the current slot, epoch, and sync period, knowing exactly when the sync committee changes and to request a header update.

Benefits for the Ethereum Ecosystem

The Ethereum blockchain provides an infrastructure on which decentralised applications can be built using smart contracts. These contracts require access to full nodes for broadcasting transactions to the network. Because running a full node is expensive in hardware, storage, and maintenance, developers often resort to services such as Infura for reliable node access. This case makes light clients ideal for usage as they could remove the unnecessary costs and provide contracts trustless access to the network. Another significant benefit is that light clients can improve the accessibility of the Ethereum network by minimising hardware requirements without sacrificing the need for trust. As mentioned earlier, light clients, although not restricted to, were intended for environments where performance and storage are limited to enable simple processing tasks.

Conclusion

Light clients, currently, are a work in progress and provide the basic functionality of being able to safely sync from a trusted checkpoint to the latest block header. There are, however, working prototypes that can be played with, including Lodestar’s light client demo and a downloadable version developed in C#. At some point in the future, this functionality will be extended to allow reading of contract balances, accessing state, and broadcasting transactions to the network.

Swaps logo

More Leverage. Less Overhead