Light Clients
Light clients give users an easy and trustless way to interact with Zilliqa 2.0 from any device, with no need to run a full node on the network.
Zilliqa 2.0 introduces protocol improvements that enable the use of light clients, making it possible for end-user applications to efficiently serve users on the network.
Light clients are nodes connected to the Zilliqa network which do not store a full copy of the digital ledger but can serve users and interact with full nodes on the blockchain via a trustless communication protocol.
The rollout of light client support in Zilliqa 2.0 unlocks a host of scalable multi-shard end-user applications, making many services far more cost-effective and efficient to operate.
Light Clients on Zilliqa 2.0
Light clients on Zilliqa 2.0 have minimal storage and hardware requirements, as they only need to store the chain of block headers to verify transactions, events, and the state.
This enables lightweight applications to be deployed directly on end-user devices, as light clients are highly efficient and far more cost-effective to run than full nodes, enabling end-users to run them independently instead of relying on nodes operated by others.
Due to their lower hardware requirements, light clients can be run on mobile phones or embedded in browser applications, enabling services such as locally-secured decentralised wallets and unlocking new ways to interact with the Zilliqa network.
Trustless Data Verification
To enable light clients to verify on-chain data securely without storing and processing transactions themselves, block headers on Zilliqa 2.0 are designed to include Bloom filters and the state, transaction, and receipt root hashes.
Block headers are used by light clients to determine which blocks have been finalised, and request untrusted full nodes to provide them with cryptographically verifiable data they cannot compute themselves.
Using the Merkle proof supplied by full nodes, light clients are able to verify the validity of transaction hashes, event logs and account state included in a block.
Zilliqa 2.0 also includes weak subjectivity checkpoints, which allow light clients to more quickly and efficiently join and synchronise with the network.
They find out if validators were slashed based on the bloom filter in the incoming block headers and take that into account when verifying the block proposers and the supermajority of subsequent blocks. Knowing the block proposers, light clients can verify whether the signatures and the RANDAO reveals in the block headers were supplied by the expected validators and whether the RANDAO mixes were derived correctly. Their knowledge of the validators and stakes also enables them to verify whether the supermajority signed the QC referencing the parent block in the block header.
When they see three subsequent block headers conforming to the Pipelined Fast-HotStuff commit rule, light clients mark the first of them (and its ancestors) as finalised. By following the described steps, light clients can ensure that they have a correct chain of block headers and know which blocks have been finalised. They utilise the transaction, receipt and state root hashes in the block headers to verify the inclusion of transactions, event logs and state values that they obtain from full nodes. The verification is based on Merkle proofs that must match the respective root hash in the block header. Furthermore, they can use the bloom filter in the block header to find out if a block contains relevant event logs that they are interested in before they request the logs from a full node.
Efficient Intershard Communication
On Zilliqa 2.0, all validator nodes act as light clients of the x-shards to which their x-shard is connected, facilitating efficient intershard communication.
This allows validators to detect and process intershard messages produced in a block by a remote x-shard to which they are connected.
X-shards can communicate with other x-shards via the Zilliqa mainnet using a hub-and-spoke architecture, or they can communicate directly in a point-to-point model using the Universal Cross-Chain Broker (UCCB) contract.
Trustless and Decentralised
Light clients enable Zilliqa-linked applications to be deployed and secured locally on lightweight devices, as they require only a fraction of the storage and computing power required by full nodes.
The rollout of light client support to Zilliqa 2.0 enables new, lightweight clients to be deployed on more devices, each able to trustlessly verify state and transaction data through the network’s light client protocol.
This reduces reliance on trusted, centralised nodes by end-user applications, improving the resilience and decentralisation of the network while unlocking new opportunities for applications building on Zilliqa 2.0.
