What are Light Client Bridges and How do they Work?

In this article, we will discuss a key piece of Electron Protocol’s Interoperability technology — Bidirectional Light Clients. BDLC enables a smart contract to verify transactions from a different blockchain, without additional trust assumptions.

Let’s dive in.

Consider that two cross-chain smart contracts are trying to communicate with each other.

Since smart contracts can only work with on-chain data, and the underlying blockchain does not support connecting with the “outside” world, an off-chain entity (called relayer) is required that will read data from one contract and make it available on the cross-chain contract.

However, now we must devise a way so that we don’t need to trust the relayer to act honestly. One way to do this is to enable the smart contracts to verify the translation themselves.

We achieve this by running the Light Node of Chain A inside the smart contract on chain B, and vice versa. This way, whenever the relayers submit faulty/malicious transactions from chain A, the B smart contract can simply verify each transaction using the A light client it now has access to. Since Light Clients of both the chains are run inside the opposite chains’ smart contracts, this approach is called Bi-Directional Light Client (BDLC).

Lets us now understand the details of how this works, and how we fit a Light Node inside a smart contract.

Before that, let us understand what a light client is, and how it works?

Light Client is a piece of code that can independently verify whether a particular transaction is a valid blockchain transaction or not. The exact logic of this code is open source and fixed for a given blockchain. Light Clients do not require access to the entire blockchain data, and require little compuational power. They were originally designed to be implemented within IoT devices.

A Light Client works in two steps:-

1. First, check whether the concerned transaction is part of a given block or not.
2. Then, check whether the given block is “valid” or not. Valid means that it is part of the canonical chain.

Let us understand each step in more detail.

Step 1: Check whether the concerned transaction is part of a given block or not?

We do this by following the Merkle path. As shown below

Blockchains store transactions by organizing them in a Merkle tree. A Merkle tree is formed by successively hashing transactions with each other in pairs, until one single hash is left, which is called the Merkle root. This Merkle root is included in the block header. In essence, the Merkle root encapsulates all the transactions of that block.

Now, if we want to check whether tx[6] was part of the given block, we simply need to hash tx[6] (along with the data on the Merkle path, as shown in the diagram) successively until we reach a single hash. If this hash matches the Merkle root, then we know that tx[6] was indeed included in this block.

Now, if we can show that this block is “valid”, we can be confident that this transaction is indeed part of the blockchain.

Step 2: Check whether the given block is “valid” or not?

In order to be called a valid block, the given block (or rather block header) must be signed by at least ⅔ validators, and, the block must point to the previous valid block.

Now, checking signatures from thousands of validators on a smart contract would be computationally very expensive (and infeasible within a smart contract). But, we don’t need to verify all signatures, just 19 actually. Let us discuss how.

Verifying a Subset of Validators instead of All

To check validity, typically one needs to check that the block has at least two-thirds of validator signatures. However, instead, if one takes a random subset of just 19 validators, and checks all the 19 signatures, then almost the same level of security is achieved.

This is shown through the probabilistic analysis below.

Consider n validators, out of which ⅓ validators are malicious (⅓ is the maximum dishonest nodes that PoS blockchains can tolerate). n can be any number between 10 and 1 million.

Now we must select ‘x’ random validators from total ’n’, such that the probability that all ‘x’ validators are malicious is less than 1 in a billion. This can be described in the below formula (derivation of this formula can be found here).

Solving this equation, we get the result that

Verifying 19 signatures inside a smart contract is computationally feasible. (More about this will be added here as link)

Now, we must check if our block points to the previous canonical block or not. At first, it might seem that we would need to download all previous block headers. However, light clients avoid this by using a trick called block checkpoints. For now, we will not discuss this in detail, instead please see how Tendermint does this here and see Vitalik’s thoughts on this here (which is also the basis for Ethereum PoS light client). If you want this discussed in detail, please leave a comment.

At Electron Labs, we have used BDLC technology to build an interoperability protocol that exists completely as L2 smart contracts and only relies on the security of the underlying chains themselves. This is as opposed to existing protocols in the ecosystem that use either multi-sig, oracle, or some other centralized approach.

Ending Note

BDLC is the same technology that is powering Cosmos IBC, and NEAR’s rainbow bridge. It seems that Solana wormhole aims to implement this tech in the future as well.

Since posting this article, we have upgraded our technology to zero knowledge proofs based light clients. Check out https://medium.com/electron-labs/what-is-zklc-and-how-it-works-a5aaadf70fc0