Light what (take 2)?

In the previous six articles, I’ve spent a lot of time looking at what light clients look like in Ethereum - past, present, and future. But, what if we start over again and say, what is a light client, but just change the setting.

Where

So, first, the setting. We're moving away from Ethereum to the land of Cosmos, "the internet of blockchains", an early starter in the "multi-chain" land where it's not just one blockchain but all sorts of chains with different validator sets, different security assumptions, different use cases, all joined together by hopes, dreams, and INTER-BLOCKCHAIN COMMUNICATION!!! Sorry, that was a bit dramatic, but maybe you get the idea. In the Cosmos world, there isn't just Ethereum and its rollups on top, all running more or less the same EVM with the same general purpose smart contract platform. Cosmos has all manner of different chain types, from the Cosmos Hub, which is a sort of central hub that in theory lots of chains connect to, to Osmosis (a chain devoted to trading with a DEX baked into the base layer), to Secret Network (a general purpose zero-knowledge smart contract platform), to Evmos (an EVM compatible chain running on top of the Cosmos consensus protocol - called Tendermint), to things more or less interesting, depending on where you look.

What For

To be the "internet of blockchains", Cosmos needed something to be able to communicate between these different chains and some way to secure that communication. That something is the Inter-Blockchain Communication protocol, hereafter IBC. The idea of IBC is for someone on one chain to be able to send a message reliably and trustlessly to another chain. "What kind of message" do you ask? In theory, anything but probably the easiest to think about is the simple cross-chain token transfer. Say you have ATOM tokens on the Cosmos Hub chain that you really, really want to trade for some EVMOS tokens so you can stake them for the juicy staking rewards currently being offered on Evmos. I bet you're thinking, great, I'll just go to the Gravity/Wormhole/bridge of your choice, lock my tokens on Cosmos and mint the equivalent on Evmos, and then trade my tokens for EVMOS and be on my way to staking riches. Isn't that how we always do it? Yes, but the question is, how trustworthy is that bridge of yours? Remember this (a glorified multisig on each side with a bridge operator with deep pockets sitting in the middle), or this (something more sophisticated and theoretically trustless but still subject to simple errors when those with the admin keys make mistakes when upgrading the contract)?

How

IBC promises bridge security that's as good as that of your chain's consensus. So, if you trust Cosmos and you trust Evmos, then as long as the IBC channel is open between them, you can rest easy knowing your token transfer message can be safely and trustlessly transmitted between them. Sounds great. But, you ask, "what does all this have to do with light clients?" Remember how we said that one of the value propositions of a good light client is the ability to to get a good view of chain history? Well, that's what drives IBC. The basic idea is that an IBC channel is a pair of smart contracts implemented on each of two chains where each smart contract is actually a light client capable of verifying that a block header from the opposite chain is valid and that state updates in transactions attached to that block header are therefore also valid. Let's break that down.

Block Header

All blockchains produce blocks with block headers. Think of the header as some metadata (maybe the time the block was produced, which validator/miner produced it) and then some sort of fancy mathematical bits of data that prove (usually a "merkle state root" or something similar) the header is part of the chain.

Verification

In IBC, the smart contract on each side of a connection has logic embedded in the smart contract that allows it to verify the consensus rules of the other chain. So going back to our example, if you (or anyone) submits a header from the Cosmos chain to the IBC light client on the Evmos chain, that client can verify if the header is a valid next header in the Cosmos chain (and vice versa). So, if you run a bridge between Cosmos and Evmos and you have a transaction where you send ATOM tokens to the contract on the Cosmos side of the IBC channel, through the magic of cryptography and merkle trees, you (or anybody) can take the Cosmos block header that contains the transaction where you sent the tokens and submit it to the light client on the Evmos side. The Evmos light client will verify the header and the associated transactions and confirm that the Cosmos chain correctly executed the transaction, and then take the corresponding action on the Evmos side (i.e. mint ATOM tokens to you or the sender of the ATOM tokens on the Cosmos side). What's magical about all this is that there's nothing beyond just the already established consensus rules for each chain required to make this work. And, better yet, anybody can pass a new header to the opposite chain. You don't have to do anything extra. There's no trusted middlemen, no bridge operators, no signatures required beyond those of the validators on each chain to make this stuff work.

Reality

Admittedly, I've glossed over lots and lots of details about IBC. It's hard work to implement a light client capable of verifying another chain's consensus in your own chain and requires ongoing maintenance to keep them up and running. But, the magic of these light clients make for perhaps the most trustless form of interchain communication available. And, to top it off, they're real and they're running right now on a number of chains, so light clients can and do work.