Alex NorthThis post is a brief survey of the cross-chain interoperability problem and solution space, specifically as it relates to Filecoin.
The interoperability problem
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:
- Verifying that the block header or state root provided is indeed sourced from the remote chain; and
- Verifying that the message or state in question is committed by that block header.
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.
Trust someone?
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.
Light client chain validation
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.
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.
Directions
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:
- Change Filecoin consensus and block header rules to make election ticket checking easy without full state validation; and/or
- Use SNARKs to compress expensive computation involved in light client block validation.
Why?
Interoperability is only awesome if it solves a concrete user need or problem. Let me clarify that need and problem here to set bounds on our direction.
My specific motivation for Filecoin interoperability is to enable storage of data in Filecoin from other blockchains. We should enable NFTs and data DAOs and markets and bounties and automation and derivatives and compute networks on any blockchain to interact with storage on Filecoin. Filecoin actors can provide the low-level primitives (the “hard drive controller” or “operating system” for our web3 storage), but the applications that use storage can be anywhere.
A concrete use case that I think can guide development is that of a storage marketplace (like the built-in storage market) on Ethereum. That’s just one point in the possibility space, but something to aim for.
I believe the solution that enables that will probably also enable more generic cross-chain exchange, asset portability/encumbrance, and oracles. But the reason we’re all here is storing files.
