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.
What is a light client?
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?
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 8,192 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.
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:
- 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.
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.
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 18,384, the light client fetches updates for two sync periods. Because there is a difference of 16,384 slots between 2000 and 18,384, 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, including:
- 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.
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.
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.
If you have anything that you think should be added to this summary, or if you would like to collaborate on a future research task, please reach out to firstname.lastname@example.org.
If you have learnt something and valued this research, please consider supporting mycelium-research.ethDonateETH
© Copyright 2022, Mycelium Ventures Pty Ltd, ALL RIGHTS RESERVED.