devgrants
devgrants copied to clipboard
filecoin-project
Enabling Filecoin interoperability with Cosmos Ecosystem
Open Grant Proposal: Enabling Filecoin interoperability with Cosmos Ecosystem
Name of Project: Filecoin IBC interoperability with Sonr
Proposal Category: core-dev
Proposer: ma-sonr
(Optional) Technical Sponsor: Boris Mann
Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT, APACHE2, or GPL licenses?: Yes
Project Description
The problem
In its journey to become the decentralized storage layer for the new internet, Filecoin must find ways to interoperate several disjoint blockchain ecosystems. Native support of new blockchain-community protocols like IBC requires significant engineering complexity.
What we are building
Sonr is building a light-weight trustless Filecoin bridge to its IBC-enabled blockchain, allowing users of IBC-enabled blockchains to access Filecoin resources.
Why
Our aim in building the describe solution is to cultivate Filecoin use cases, enable technical interoperability with a growing blockchain ecosystem, and ultimately foster ecosystem growth. Cosmos-based chains like Sonr are able to create use-cases involving Filecoin, the Filecoin will subsequently benefit from the increased utilization of resources. Cosmos’ ecosystem inter-blockchain communication protocol makes it specially positioned to accelerate Filecoin’s in its ecosystem growth.
Value
Interoperability with Cosmos ecosystem
With the described solution, Cosmos' ecosystem of blockchains would be able to leverage Filecoin's storage resources. 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. This better positions Filecoin to become the go-to permission-less storage solution for the new internet. The expansion of chain support for Cosmos also adds liquidity to the Cosmos Ecosystem overall, making it more favorable to build DeFi protocols and other projects.
Branding and visibility risks
Without the right partnerships and buy-in across ecosystems, we face the risk of inadequate visibility around the final solution. Beyond access to the best-in-class protocols and frameworks, this project will require intentional co-branding and broadcasting of its implications to both the Cosmos and Filecoin ecosystems.
Interoperability with Filecoin
While the Sonr team has visibility into the construction of its IBC-enabled blockchain, we are external to the Filecoin team and thus have less visibility into the construction of the Filecoin chain. The execution difficulty risk arises in their being adequate Filecoin resources (documentation, Slack channels) in the event that assistance with the project is needed. Our hope is that our ongoing discussions in Filecoin Github, Filecoin Slack, and with other Filecoin stakeholders will mitigate this risk.
Deliverables
Milestone: A decentralized, non-custodial Filecoin bridge to Sonr’s IBC-enabled blockchain.
Function: The ability for Cosmos blockchains to gain access to Filecoin’s storage resources.
Development Roadmap
Milestone 1
Bridge functional specification
- Functionality: Design functional specification for Filecoin bridge to Sonr’s IBC-enabled blockchain based on evaluation of key considerations.
- What built in support is needed on the Filecoin / FVM side to support Cosmos? The key consideration here is the need for Filecoin to understand a proof from Cosmos and then be able to execute on the FVM side.
- What level of decentralization do we want, as compared to similar solutions (i.e: [Textile’s NEAR bridge](https://filecoin.io/blog/posts/textile-intro-to-the-filecoin-bridge/))?
- Should the facilitate the exchange of an IBC-enabled token that represents 1:1 ownership of FIL token? Or direct access to Filecoin resources using the IBC blockchain’s native tokens?
- What security mechanisms need to be in place to prevent against attacks?
- Teammates: Sonr Engineers (1); Sonr Product Manager (1)
- Budgetary Needs: $64,000
- Completed By: October 30th
Note: Milestone One will be a key determinant of the Milestones to follow, as the research and due diligence needed may affect the specifications and budgetary needs.
Milestone 2
Sonr Architectural Decision Record (ADR) for bridge module
- Functionality: Define Sonr ADR for Sonr module that will enable Filecoin bridge.
- Teammates: Sonr Engineers (3); Sonr Product Manager (1)
- Budgetary Needs: $128,000
- Completed By: November 30th
Milestone 3
Configure Sonr to accept IBC data through Cosmos SDK
- Functionality: Ability for Sonr’s native token ($SNR) to be transacted on other IBC-enabled chain.
- Teammates: Sonr Engineers (3); Sonr Product Manager (1)
- Budgetary Needs: $64,000
- Completed By: December 15th
Milestone 4
Connect Sonr to Osmosis chain over IBC
- Functionality: Ability for $SNR to be transacted on Osmosis chain, allowing Cosmos ecosystem tokens to be swapped for $SNR.
- Teammates: Sonr Engineers (3); Sonr Product Manager (1)
- Budgetary Needs: $70,000
- Completed By: January 5th
Milestone 5
Sonr to Filecoin Bridge MVP
- Functionality: The ability to use $SNR on the Sonr mainnet to obtain Filecoin storage resources.
- Teammates: Sonr Engineers (3); Sonr Product Manager (1)
- Budgetary Needs: $60,000
- Completed By: January 30th
Milestone 6:
Sonr to Filecoin Bridge V1
- Functionality: End-to-end flow involving starting with IBC-enabled Cosmos token (2-3 including $SNR on the Sonr mainnet) and obtaining Filecoin storage resources.
- Sonr mainnet flow: Ability to use $SNR to obtain Filecoin storage resources.
- Non-Sonr Cosmos flow: Ability to swap token for $SNR on Osmosis to obtain Filecoin storage resources.
- Teammates: Sonr Engineers (3); Sonr Product Manager (1)
- Budgetary Needs: $128,000
- Completed By: February 28th
Total Budget Requested
The total budget requested based on the assumptions below is $514,000:
- An hourly rate of $200/hr
- Full-time hours worked across Engineers and Product Manager
- Full used towards compensating the needed number of team members
Maintenance and Upgrade Plans
The Sonr team aims to maintain the described software post grant-receipt and launch.
Note: As described by the phases in the Textile team’s blog, the Sonr team will continuously consider the appropriate level of decentralization.
Team
Team Members
Michael Amoako - Chief of Staff
Prad Nukala - CEO
Nick Tindle - Head of Engineering
Team Member LinkedIn Profiles
Team Website
https://www.sonr.io/
Relevant Experience
-
Prad Nukala
Prad has been involved with the tech industry since the introduction of the app store, making one of the first 5,000 apps at age 12. Before founding Sonr he has self developed over 10 projects commercial and open source that have totaled over 1 Million downloads. Most recently Prad has guest lectured at MIT's sloan school alongside Vitalik, Anthony Pompolio, and Yat Siu.
-
Michael Amoako
Michael graduated from the Massachusetts Institute of Technology (2019) with mix of degrees in Business Management, Computer Science, and Mathematics. He was admitted to Harvard Business School’s MS/MBA program 3 years ago in their deferred admission program, which he decided to defer to pursue his current career path.
Before joining forces with Prad and pursuing Sonr, Michael worked at several big technology players including Google and Microsoft, in AI-focused Engineering and Product management roles. While he enjoyed his roles and impact as a leader in the Responsible AI space, he was particularly moved by CEO Prad’s vision at Sonr. To Michael, joining Prad in building Sonr was an opportunity to finally enact Tim Berner's Lee's original goals around a user-owned internet. Michael’s technical product background made him the perfect first hire for Prad.
-
Nick Tindle
Nick is a professional as a dev-ops engineer with a mix of hardware and software skills. When he’s not building the user-owned internet, Nick can usually be found attending hackathons, launching rockets, or building home made machines.
Team code repositories
- https://github.com/sonr-io/sonr
- https://github.com/sonr-io/explorer
- https://github.com/sonr-io/vault
- https://github.com/sonr-io/nebula-react
- https://github.com/sonr-io/nebula-core
- https://github.com/sonr-io/MotorKit
Additional Information
We’ve spoken to several folks from the Protocol Labs and Filecoin ecosystems, who’ve pointed us towards this grants program including:
- Boris Mann, IPFS Fission
- Juan Bennet, Protocol Labs
- Charles Cao, Fileswan
- Kaitlin, Filecoin Governance
- Jonathan Victor, Protocol Labs
The grant proposal was inspired by discussions around Filecoin supporting Cosmos-based chains including Sonr: https://github.com/filecoin-project/FIPs/discussions/398. From our discussions with Filecoin and Interchain, we came to the conclusion that native support of Filecoin on the Sonr blockchain through the bridge solution described would be the most practical short-term approach. This also fits well into Sonr’s overall narrative (described below) and opens the door to many use-cases for Filecoin.
About Sonr
The problem with digital ownership
In the current digital ownership paradigm, user’s personal data is owned and controlled by third parties. Tech giants have access to vast troves of data, putting the power in their hands rather than the users who own this data. While this has proven lucrative for technology companies, users are faced with a number of problems: we’ve heard time and time again of user-data being sold without permission or stolen by hackers. These problems are furthered by the user’s inability to dictate who has access to their data.
What we are building
Sonr is building a blockchain ecosystem where users have full control over their digital identity, and developers are empowered to build peer-to-peer decentralized applications. The Sonr network is collectively made up of motor nodes, which act as clients and represent end-users, and highway nodes, the Sonr network’s servers for data transmission.
- Real-time peer-to-peer network: To enable cross-device discovery, delivery, and transmission, Sonr leverages the
LibP2Pframework. WithLibP2Pnodes in the Sonr network can dial other nodes in the network to exchange messages using various transports, like QUIC, TCP, WebSocket, and Bluetooth. Nodes can run on any device, as a cloud service, mobile application or in the browser and talk to each other as long as they are connected on the Sonr network. - Verifiable user identity: Sonr enables verifiable on-chain identity via its decentralized-identity enabled blockchain. Access to this experience is unlocked via procurement of a .snr subdomain. This subdomain gives users one central point for gaining and granting access to user data.
This peer-to-peer network and identity-enabled blockchain combine to makeup the user-owned internet experience that is Sonr.
How Sonr solves the digital ownership problem
With the described solution, Sonr introduces a new digital ownership paradigm where users can securely control access to their personal data, through their .snr/ domain. To enable this, each .snr/ domain is resolved as a decentralized identity on the Sonr blockchain. Let’s say Prad secures the prad.snr/ subdomain. If he wants to access Netflicks, a blockchain-based movie recommendation platform built on the Sonr blockchain, he can access his data at prad.snr/Netflicks and also grant other users and applications access to his data. With Sonr we put power and control over personal data into the hands of users.
Hi @ma-sonr, thank you for your proposal! We are reviewing this project and will be in touch as soon as we have an update.
@ma-sonr I have some potential questions, Dragan from PL here.
What do we plan to do with:
-
relaying the proofs, we must first think about signature verification, so both cosmos and Filecoin FVM need to support the same types of signature in their runtime. Who will implement this and make it work End to end?
-
What is our plan for managing relayer infrastructure? Who and how will manage this during the implementation + who will manage it after the main implementation phase?
-
When you say October 30th as the end deadline, does that mean to solve all the issues + give users the ability to end, since I believe FVM would be a significant dependency to make all of this work? October 2022 is a bit premature for FVM since we plan to do a network upgrade in February 2023.
Hi @ma-sonr, thank you again for your proposal! We are pleased to approve a $50k grant to support this project. We will send an email to confirm next steps.