Enabling IBC on Filecoin for interoperability with Cosmos Ecosystem

[ma-sonr]

I'd like to start a discussion on enabling IBC on Filecoin, which would enable Cosmos' ecosystem of blockchains to leverage Filecoin's storage resources, while also allowing Filecoin to move towards becoming the go-to permission-less storage solution for the new internet. Cosmos ecosystem includes 100s of chains:

• Cosmos Hub
• Osmosis
• Binance chain
• DyDx
• etc

The Cosmos ecosystem will continue to evolve as more application-specific blockchains emerge, and enabling IBC on Filecoin would create the opportunity for many use-cases across the entire ecosystem. If anyone here is familiar with Cosmos / IBC I'd like to chat!

Lighter-weight trustless bridge approach: Sonr (our Cosmos SDK-based chain) could offer a decentralized, non-custodial Filecoin bridge.

IBC FAQ
IBC overview

[Tom-OriginStorage]

I think this would be a pretty large endeavor. As mentioned on Slack, the requirements for IBC are:

• Module System: The host ledger must support a module system, whereby self-contained, potentially mutually distrusted packages of code can safely execute on the same ledger, control how and when they allow other modules to communicate with them, and be identified and manipulated by a controller module or execution environment.
• Key-value Store: The host ledger must provide a key/value store interface allowing values to be read, written, and deleted.
  Consensus State Introspection: Host ledgers must provide the ability to introspect their current block height and consensus state (as utilised by the host ledger’s light client algorithm), as well as a bounded number of recent consensus states (e.g. past headers).
  Timestamp access: In order to support timestamp-based timeouts, host ledgers must provide a current Unix-style timestamp. Timeouts in subsequent headers must be non-decreasing.
• Port System: Host ledgers must implement a port system, where the IBC handler can allow different modules in the host ledger to bind to uniquely named ports.
• Exception/rollback system: Host ledgers must support an exception or rollback system, whereby a transaction can abort execution and revert any previously made state changes (including state changes in other modules happening within the same transaction),excluding gas consumed and fee payments as appropriate.
• Data availability: For deliver-or-timeout safety, host ledgers must have eventual data availability, such that any key/value pairs instate can be eventually retrieved by relayers.

I believe we would first need to check with the current various Filecoin implementation teams on which requirements they have already met, and how long it would take for them to meet all requirements. Most of the chains you mentioned are built with the Cosmos SDK and is already compatible with IBC by default.

And before heading down to the IBC rabbit hole, it is worth to spend some time comparing & investigating on different interchain communication protocols such as Polkadot/Kusama etc.

[ma-sonr]

Correct the above chains are all built with the Cosmos SDK, which gives them compatibility with IBC out of the box. I agree it'd be worth chatting with the Filecoin implementation teams to see which requirements have already been met and how long the others would take to assess feasibility.

I think exploring different interchain communication protocols is interesting to do in parallel, though I do think Cosmos specifically is an ecosystem worth exploring in it's own right due to the growing number of chains and applications that could benefit from Filecoin's functionality

[jnthnvctr]

tagging @bmann know you guys are straddling worlds!

[jnthnvctr]

Another interesting one to consider is Dydx.

Dydx is moving to cosmos, and building up a decentralized futures / options market could be extremely powerful for:

• miners being able to hedge fil (lock in specific gains for future block rewards to cover opex)
• clients being able to build endowments that are more capital efficient (not requiring all collateral upfront)
• protection for downside risk on fil derivs

[bmann]

Thanks @jnthnvctr -- this is definitely an interesting take.

I don't think IBC would be a fit for the Filecoin sovereign chain.

I do think a repeatable "bridge" module targeting Cosmos SDK would be great. It might even BE an IBC style Interface on the Cosmos end of things.

I put bridge in quotes here. The state of the art here is trustless validation, data availability, and proofs. Roll ups fit in here too, in one direction over the other.

I think a "bridges" working group would be valuable. The Filecoin / FVM side of things should have a repeatable interface for building trustless bridges from/to other changes -- otherwise everyone has to keep building semi-centralized validator sets between Filecoin and other chains to support the bridge.

The goal should be to enable usage of first class resources available on the sovereign Filecoin chain to other networks.

[jnthnvctr]

Do you think this is incongruous with hierarchical consensus stuff? I was thinking perhaps it makes sense for a shard to be spun up that could interface across both - but idk if that's reasonable (perhaps a consensus lab member can weigh in?)

[bmann]

I'm putting "bridges" in quotations marks because the way this is done in Filecoin is up to us. e.g. one could put a Cosmos VM (this has less meaning than other chains because it's a blockchain construction kit) on Filecoin and do "native" IBC possibly....but that's something that is a whole project by itself.

In the let's walk before we run way of things -- a general module / actor / first class support for secure trustless bridge anchoring on the Filecoin side is very important and I what I have been advocating for.

Even the FVM+EVM doesn't actually bridge to any other EVM changes ... and building a bridge out of EVM parts doesn't necessarily expose the first class capabilities of Filecoin to the remote EVM.

[ma-sonr]

Agreed @bmann. Open-Grant in progress with the above in-mind