This post is a brief survey of the cross-chain interoperability problem and solution space, specifically as it relates to Filecoin.
Cross-chain interop refers to sending messages between different blockchains (i.e. different consensus domains), or, equivalently, being able to inspect the state of one chain from another.
This is hard because applications on different chains can’t directly communicate, only accept asynchronous messages from users. These messages may claim to bear a message or piece of state from the other chain, but how can the receiving application be sure? The receiving application needs to prove to itself that the message is genuine.
The problem breaks down into two main parts:
The first problem is by far the harder one, although in Filecoin’s case the use of general-purpose IPLD structures will also add challenges to the second problem.
A wide class of solutions to cross-chain interoperability involve trusting some parties other than the validator sets of the two chains. For example, a collection of relay nodes could sign headers from the chains, attesting to their validity. The functionality and value of every application that spans chains depends on trusting those relay nodes. That trust might be enhanced with incentives like a stake or bond, but is still subject to an economic attack.
We’re not interested in trusting people, so that class of solution won’t be considered further. We want to verify headers between chains without trusting anyone to do it for us.
Blockchain execution is expensive. We cannot fully verify the execution of one chain from inside another. How can we trust a block header without verifying the chain on which it’s built? This boils down to another well-known problem: development of a light client. A light client is a blockchain node that does not compute the state of the chain, or verify the transition function. It only verifies that the block headers are otherwise correctly constructed and chained, and trusts the block producer to have computed the correct resulting state. When other nodes build on that header, the light client gains evidence that the state was correctly computed, and it trusts the header once it reaches finality and is still on the heaviest known chain.
<aside> 💡 To solve interoperability we need to build a light client for Filecoin inside other chains (and vice versa).
</aside>
The key challenge for a light client is to verify that the block producer had the right to produce the block they have claimed. For a POW chain like Bitcoin, this is relatively easy. The hash collision demonstrating the proof of work is self-certifying as a certificate of eligibility; there is no need to inspect the blockchain state or anything else. For supermajority-of-validators style BFT consensus, a light client can verify signatures from a threshold of nodes that authenticate a block, although note that knowledge of who the group of valid signers are is now required.
For a more general POS chain, including Filecoin, the challenge is harder again. A block producer’s right to produce a block depends on their stake (in Filecoin: power), and the entire staking (power) table. This table is contained in the state of a previous block, but the light client doesn’t have that state! It’s not too large, so a fairly light client could store it, but then it would also have to compute the transitions to it, which means receiving and executing/validating every message that can affect that part of the state. All of a sudden it’s not so light.
So, the challenge is to support light client development for Filecoin, specifically targeting implementation of a light client in a smart contract (if we can do that, then development of a traditional light client that someone might run at home should be easy).
Two possible and non-mutally-exclusive directions are: