Interoperability & cross-chain

light-client bridge

A light-client bridge is a trustless bridge built by embedding a light client of one chain inside the other. A light client is the minimal logic needed to follow a chain's consensus without storing its whole history: for proof-of-stake it tracks the validator set and verifies their signatures on block headers; for proof-of-work it checks that headers form a valid, sufficiently-difficult chain. When this light client lives as a smart contract on the destination chain, the destination can independently confirm what the source chain's headers say.

Once the contract holds a verified header (and thus a trusted state root) of the source chain, anyone can prove a specific event happened there by submitting a Merkle proof against that root — for example, 'this deposit log is included in block N, whose root I have verified'. The destination accepts the event because it re-derived the source chain's own commitment, not because a committee vouched for it. An off-chain relayer feeds headers and proofs to the contract but is purely a courier: it cannot fabricate a header that the embedded consensus check would reject.

The price is real engineering and gas cost. Each source consensus algorithm needs its own verifier, signature checks on large validator sets are expensive, and the contract must be kept synced with every new header (or sync committee), which costs ongoing fees. Zero-knowledge techniques help by proving the header-validation work succinctly off-chain — a 'zk light client' lets the destination verify one small proof instead of thousands of signatures. IBC's tendermint light clients and zk bridges for Ethereum are the canonical implementations.

Light-client bridges must respect finality. If they accept a source header before it is final, a reorg on the source can leave the destination acting on an event that never really happened — so they wait for finalized blocks, trading latency for safety.