Textile | Introduction to the Filecoin Bridge

hello everybody i'm andrew with textile you can find us at textile.io i'm really excited to be here today with carson farmer to share with you some work that we've been doing to make it easy for application developers on ethereum or polygon or near make use of permissionless storage on the filecoin blockchain directly with their native application so that means that you can build a native dap or nft or smart contract that can store data on filecoin and access that data over the ipfs network with nothing more than your native wallet this system is currently running free for you to use and we think a lot of cool things will be built on it so with that let me kick it over to carson cool thanks andrew um so what are we talking about here um bridges are shaping up to be a really powerful open protocol and concept for providing permissionless filecoin storage to blockchain users and applications in their native token and so what i mean by that is you and your users can actually start storing data on filecoin from any blockchain that we support without any conversions signups developer tokens or secrets or any anything like that and so i want to go through a little bit of what these bridges look like and how we're building them um so we're building a filecoin bridge for just about every blockchain that we can get our hands on and so right now that includes ethereum polygon mir and insert your favorite blockchain here soon hopefully so for those who aren't familiar filecoin itself brings a lot of the best parts of the ipfs stack including verifiable data peer-to-peer data exchange deduplication and a lot more and so essentially we can create a lot more secure data storage layer for decentralized applications and their users and their developers by bridging filecoin uh with other blockchains so when using uh the bridge your users or your app or your smart contract they actually still reference data and retrieve data over ipfs like normal but the raw data itself is available in storage contracts created with filecoin miners on the filecoin network and so the metadata for that storage and that storage deal can actually be reported back to the native blockchain as open reusable building blocks for other dap and app interactions and so i want to just go through kind of what the structure of this filecoin storage bridge system looks like so the bridge revolves around kind of two key concepts deposits and storage and the deposits api that all happens on chain and whatever native chain we're talking about so that's ethereum polygon near whatever and then the storage apis these actually interact off-chain with a storage validator that will actually interact with or interface with filecoin and so the validators they handle things like compiling batching and deal making with the file coin network and then they can report deal success back to the native chain so we have our validators down here which are connected to file coin storage along the way data is actually cached in a highly available ipfs layer while the deal ceiling and proving stages which can be computationally expensive and slow are underway so this means that app users and developers they have sort of fast off chain content addressable data available right away thanks to ipfs caching while the slower provable and incentivized storage is making its way to the file coin chain and then additionally validators can provide things like indexing mapping from a cid a content id to the actual deal on filecoin network and a bunch of other things for you know on-chain apps and dapps and so the way that this whole system works is basically dapps or users have to provide a deposit with the on-chain component of a validator and leaving a deposit this provides sort of degree of sybil resistance so users looking to store data on filecoin via a validator they deposit some funds uh with the validators contract proportional to the length of time that they'd like to keep storing data so by default this is about 100 um gy per second or a very small fraction of matic per hour or about a quarter year for 10 minutes these are the defaults and they're configurable by the actual uh validator then after funds are expired so the session is over then they can be released by the user themselves by the smart contract that initiated the um session or the validator um and this is a nice uh feature because this makes leaves a way for to for a user or a provider to release funds after a storage session is completed without locking funds permanently in the contract during a file coin proof process which can again can be a bit slow uh so then once a valid deposit is available in the contract the app or user can actually then push data to the validator using the validators stated api endpoint and this is available via uh just a simple uh get request to the smart contract um and this off chain rest api simply takes files for upload and sends their bytes via the validator off to the file coin off to file coin for storage in preparation um with the validator the status of each storage request can be queried using its id and the storage process ranges from batching files together to preparing the storage deal to auctioning the actual uh storage deals to um file coin miners uh to actual deal making and success of the final storage on on filecoin and so you get you can get status of this process along the way and they can you can provide this back to the user you can interact with the storage deal along the way etc the other on-chain component is the registry and this is a logically centralized contract that actually stores a reference to all of the off-chain validators and their on-chain component or their on-chain contract and to get into the registry there we are working on some new governance procedures for how that might look at the moment there is very few validators running so it's a pretty simple process but eventually if you're interested in that sort of thing i recommend you get in involved in some of our governance meetings and interact with that interact with us that way um and links can be provided at the end of the session here okay so what do these contracts look like uh they're pretty simple and and that's done on purpose to make it pretty easy to implement these interfaces if you're if you want to provide a validator so the registry is very simple it's just a way to add and remove providers to the registry so um uh the registry is is a pretty simple uh implementation it really only needs to expose the registry to add and delete and list broker or list validators and only the current owner of this contract can actually mutate the registry but any external caller can actually then query it and as i mentioned in the next phase of the development we'll actually be adding and removing some components for governance the next important piece is the validator contracts and these are similarly simple interfaces um and they can be implemented by anyone who wants to run a filecoin validator node so this is what the core interface looks like and unlike the registry interface uh the validator interface can be even simpler than this it doesn't require that the contract is upgradable or that it's ownable um because these contracts are really under the control of the entity behind the validator so it's pretty lightweight interface uh some details do need to be considered when implementing the ad deposit and had the has deposit methods um so ideally uh deposits should have a linear relationship with session time but ultimately it's up to the validator to decide what that looks like and the key piece here is that all these contracts have events in the ethereum or evm context and logging in the near context so that other contracts can listen to these events or other off-chain components can listen to these events and kick off new actions in response to those so you can imagine all sorts of workflows in which when a new deposit is added to a validator some action gets kicked off uh when a deposit is released some action is um kicked off or monitors updates and these types of things so this is designed to really make uh make for building blocks of uh file coin storage updates um so how do you leverage these magical uh this sort of magical bridge to the exciting world of decentralized off-chain storage that's a mouthful if you're a contract developer you could easily just interact with these contracts on chain by across contract calls you could deposit some funds directly from your app or service on behalf of your users or have your users interact you can listen to deposit events and start reading on-chain activity uh we've even started integration with the graph for doing things like indexing of the contracts so you can start to really build expressive dapps that monitor file coin storage in real time and interact with that but if smart contracts aren't your thing um we also have a storage bridge zero config typescript and javascript sdks that make it pretty easy uh to interact with data that's coming from these on-chain components off to the filecoin network in any blockchain based app or service so we have something we have libraries for each storage we have libraries for near storage and these all should feel pretty comfortable to developers already familiar with pretty common east polygon and near javascript libraries so to show you kind of what that might look like you can check out ethe.storage and you can check out the docs there and it has all sorts of information about how you can interact with these libraries if you scroll down to the bottom there is a section on ease of use and there's a live demo that you can interact with and so if you click on that live demo you get an option to check out the east and polygon demo or the near demo so i'm going to go ahead and click on the ethan polygon one and uh that pops up the metamask to get me to sign and interact with this on-chain component so here i'm working with the ethereum rinkeby test net the same contracts are all live and working on polygon mainnet testnet and near um and uh if you've got any specific chains you want to interact with just let us know um and the way this works is basically we've just exposed a lot of those on-chain components for you to play around with so you can deposit some funds and i'm using a test metamask account here and i'll just confirm that and then i can choose a file to upload and i'm going to pick my favorite meme here and then i can upload that file to the filecoin network and it takes a second to send it off to a validator and here i get back right away the ipfsc id and so i can do whatever i would normally do with an ipfsc id in my app i can display it via a gateway i can store that off in my smart contract i can do whatever i want in this demo it saves it down here to interact with i can check the status of that filecoin deal so right now the validator is matching that data with other cids i can copy the cid there and i can even open up a new tab oops and i can view it over an ipfs gateway and it's all very magical and exciting um and so i can give you a quick overview of essentially what we're doing and how we're interacting with that at the sdks in order to actually produce that simple react app so again if you want to check out how to do this by our sdks e-stop storage near dot storage and the demo example i just showed you is available in this github repo here um now i do want to mention that support um for and keeping the storage fees free for the time being is actually provided by the filecoin polygon and near organizations so big thanks to those folks if you want to get started there's zero cost to your you as a developer to get going on that um and storage deals on falcon are free for the time being um so what does that look like here are the main pieces of code or snippets of code that you would need in order to interact with the on-chain and off-chain components of the bridge system so if you're familiar with ether's js development we import the provider and then really you're just importing a few extra things from textiles heath storage library so the initialization function and uh this is a helper function to request a sign in or activate meta mask so you might just request sign in to uh and await that get a reference to a web3 provider and grab a signer if you're familiar at all with ethers.js development these are pretty much standard um interactions then we simply initialize our storage session and we get back a storage object this storage object has a bunch of methods on it that allows us to add deposit release deposit uh get a list of validators um and then store files and get status and that's pretty much it we have a very lightweight api that we can interact with and we can take file objects like native web file objects so in this case i create a simple blob hello world and make a reference to a file and i'm ready to go i add deposit in this case using the default deposit of about one hour's worth of session time and i store the file what i get back is the id for the uh the storage request and the actual cid now i've got that cid it's on ipfs i can do whatever it is that i'd normally want to do add this to an nfts as an as an asset for an nft display data via the gateway whatever i want and then get the status of that later on maybe when my user logs back in the near interactions are very similar so just a sort of best practice wallet setup like you'd normally do if you're developing an app for near you get a reference to the storage objects storage object and the rest is pretty much exactly the same and that's done to make it very easy to do cross train cross cross-chain interactions and build very similar experiences for your users [Music] so that's pretty much what we have to share with you today thanks very much for watching to the end of this presentation if you have any questions don't hesitate to reach out on uh slack twitter by email and of course uh we're always hiring so get in touch if you think some of that stuff looks fun