trustless bridge

A trustless bridge removes the external committee and instead has the destination chain verify the source chain's own security directly. There is no separate group whose honesty you must assume; if you already trust the source chain's consensus and the destination chain's consensus, the bridge adds no new trusted party. The slogan is 'trust-minimized': you inherit exactly the security of the two chains and nothing weaker in between.

There are two main ways to achieve this. A light-client bridge runs a verifier of the source chain's consensus as a contract on the destination — it checks the source chain's validator signatures or proof-of-work headers and then accepts Merkle proofs of specific events against a verified block root. A validity-proof bridge has the source chain (or a prover) produce a succinct zero-knowledge proof that a state transition or event occurred, which the destination verifies cheaply. In both cases an off-chain relayer merely delivers data and proofs; it cannot forge anything, because the destination re-checks the cryptography itself.

The catch is cost and engineering difficulty. Verifying another chain's consensus on-chain can be expensive — checking Ethereum's validator committee or a proof-of-work header chain inside a contract is gas-heavy — and you need a new verifier for every distinct consensus algorithm, which is why these bridges are slower to ship. Finality differences also bite: a light-client bridge must wait for the source block to be final, or risk relaying a state that later gets reorged away. IBC in Cosmos and emerging zk light-client bridges are the leading practical examples.