Export Filecoin storage to other Web3 systems.

@Alex North and the Cryptonet

The Filecoin cross-chain interop project aims to make Filecoin storage easy and cheap to access from any networked system. When Filecoin storage can be accessed from any chain, it can become the default storage layer for Web3. Network effects might then drive increasing utility, as data accessible to many chains is more useful than data tied to one.

With a well-implemented system, we should be able to support new storage markets, services, and compute platforms (see

Blog:

Cross-chain interoperability (aka bridging) is hard, and not a generally solved problem in Web3. Filecoin’s consensus algorithms and state representation were not designed with cross-chain inter-operability in mind. Exporting consensus validation and state inspection to resource-constrained blockchain execution environments may require trade-offs.

Happily, unlike many systems, Filecoin enjoys a state of continual innovation, and we have the opportunity to change how the core consensus protocols operate in order to support this interoperability.

There are three majors pieces to a complete and secure interop solution

To trust claims about Filecoin storage, applications on other chains need to be able to verify Filecoin block headers. This amounts to running a Filecoin light client inside a smart contract. Light clients for proof-of-stake networks (including Filecoin) are not as simple as proof-of-work networks, because the proof of a miner’s eligibility to produce a block is not self evident, but depends on the chain state which a light client doesn’t compute or store. The computations even for light client validation may be too expensive to execute inside another blockchain. A long chain finality period (currently 7.5 hours) will make for painfully slow cross-chain messaging.

With a trusted block header and state root hash, the next challenge is to prove the inclusion of a specific message or piece of state. Filecoin’s native chain state is DAG-CBOR IPLD and makes heavy use of complex data structures such as HAMTs. This scheme has great self-describing and traversal properties, but is not optimised for efficient proofs. The conceptual equivalent of a merkle inclusion proof would be many times larger and more expensive to verify than a traditional merkle tree.

We need to develop new, proof-friendly data structures that make it easy and cheap for code in other chains to verify important pieces of Filecoin state.

Exporting state is only half the problem. Rich applications will also require Filecoin actors to be able to verify state of other blockchains. These chains all have their own consensus mechanisms and state representation, and we have little influence to change them. Many other teams are building solutions here for interoperability between those chains, but they may not reach the same standards of trust-minimisation

A rough sequencing

Below are notes from the