💡 Hackathon idea (bonus points for submission of this)

Using the materials provided, build services that retrieve, store and interact with small pieces of data on IPFS through FVM smart contracts. Bonus points for implementing retrieval services with rewards and/or useful processing of data in a smart contract. Note that this is a proof of concept and we invite you to hack with it and build new solutions!

Introducing state/storage with FVM

Imagine you are able to access a massive global database and want to programmatically pull small bits of data from that database to your FVM smart contracts. State-storage enables this with IPFS!

State-storage involves a smart contract on FVM taking retrieval requests from your dApp, retrieving the data from IPFS and returning it to the dApp.

NFT metadata, genetic information, archival documents, or the Internet Archive (from the wayback machine) are a subset of what is stored on IPFS. If the dataset is prepared correctly, you can access it with state/storage using the tutorial below. You can also add in datasets to IPFS in order to make that data later accessible with state/storage.

How state/storage works

Key Components:

• Client application/smart contract

  • sends the request to the Data Management Contract (DMC) to retrieve content from IPFS for consumption.
  • continue any process in the smart contract once the content is served to DMC by relayer.

• Data Management Contract (DMC)

  The main functions of DMC include:

  • taking retrieval requests from client/application
  • temporarily storing data severed by Relayer from IPFS
  • serving data back to the client/application to continue their process

• Relayer:

  listen to the event logs emitted from the Data Management Contract. If there is an IPFS content request event log - BlobLoadReq, the relayer will retrieve content from IPFS and send it to the Data management Contract.

👇🏻 Fork this example repo

This repository contains the DMC, minimal functions of the client/application, and relayer. Its purpose is to demonstrate the end-to-end workflow of this Proof of Concept (PoC).

What can you build?

• Reward the directed retrieval of certain data stored on IPFS. These rewards can happen through game mechanics, token drops, or some other approach. Storage capabilities are coming soon.
  • Retrieved data can be thrown away, or be stored in contract state
  • Bonus points to complete the cycle — to run store side operations to store mutated data. Note that this mutated data will have a new CID, so smart contract mappings tracking updated datasets will need to mutate their CID rather than store the 1-4 KB data inside the smart contract itself
• Process data within a smart contract before delivering retrieval. This can be in the form of programmatic authentication/verification of data or light computation of data, to provide additional value to delivery of data.
• Pin your own dataset to IPFS for industry-specific retrieval solutions. If you’re pinning your own dataset to IPFS to use state/storage, each “row” should less than 4 KB in size — each training sample should be an individually prepared IPLD node that is accessible to the State / Storage PoC
  • https://www.kaggle.com/datasets/ahmedaliraja/customer-rating-data-by-amazon
  • https://www.kaggle.com/datasets/bwandowando/2-million-formerly-twitter-google-reviews
  • https://www.kaggle.com/datasets/zalando-research/fashionmnist
  • https://www.kaggle.com/datasets/oddrationale/mnist-in-csv
• Load side — ideal for retrieving (and doing some compute) on small pieces of data already inside IPFS
  • Build your own NFT viewer — render metadata.json from famous NFT collections already stored on IPFS
    • The NFT contract that is being queried might be deployed on Polygon or ETH mainnet, but given the CID, FVM can retrieve and render these files
    • Some examples of famous NFTs and how to get to their respective IPFS CIDs:
      • Azuki 8568:
        • Contract address: 0xed5af388653567af2f388e6224dc7c4b3241c544 (mainnet)
        • Token ID: 8568
        • Step 1: Go to 0xed5af388653567af2f388e6224dc7c4b3241c544, and call tokenURI(8568)
        • Step 2: This returns ipfs://QmZcH4YvBVVRJtdn4RdbaqgspFU8gH6P9vomDpBVpAL3u4/8568
        • Step 3: Return the image with State-Storage and render it on your dapp!
      • BAYC 554:
        • Contract address: 0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d (mainnet)
        • Token ID: 554
        • Step 1: Go to 0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d and call tokenURI(554)
        • Step 2: This returns ipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/554
        • Step 3: Parse the image from the above JSON payload, this returns: ipfs://QmVy5LYCoiqtuDJNSxU93senGT1C2zkLS2vYgmfSDhduvi
        • Step 4: Return the image with State-Storage and render it on your dapp!
      • MAYC 9730:
        • Contract address: 0x60e4d786628fea6478f785a6d7e704777c86a7c6 (mainnet)
        • Token ID: 9730
        • Step 1: Go to 0x60e4d786628fea6478f785a6d7e704777c86a7c6 and call tokenURI(9730)
        • Step 2: This returns https://boredapeyachtclub.com/api/mutants/9730
        • Step 3: Parse the image from the above JSON payload, this returns: ipfs://QmdDN9JZ6gKRNV148LZ2zzqLXUiC9vMygAUKM7qq55qxjH
        • Step 4: Return the image with State-Storage and render it on your dapp!
    • Why do this onchain to begin with? Several reasons…
      • Build an onchain points system (with $GAME tokens) in order to reward users that can guess a puzzle with an NFT collection as the answer — points reward onchain allows for transparency in the game mechanics
      • Build a version of https://docs.ethxy.com/ where people can bet 0.1 FIL, 1 FIL or 10 FIL and then “win” an NFT based on a PvP round
      • Build an onchain NFT annotation engine — leverage retrieval from state-storage and onchain comments in order to build an annotation tool for the world’s most popular NFTs