Avalanche Igloo

Store large amounts of data on the blockchain using subnets— efficiently.

Comment

Problem Statement

  • Right now, storing data on the blockchain SUCKS
  • It’s hard and most solutions are off-chain and rely on centralized providers
  • For NFTs this greatly restricts the kinds of data that an NFT can represent. Data is either stored somewhere in web2 centralized server or through IPFS

Current Ecosystem

  • Storing large amounts of information (or data) on the blockchain is very inefficient and expensive
    • The most popular blockchains Ethereum or Bitcoin have slow transaction speeds, have high gas fees, and have low capacity for transactions per second (TPS)
  • People store data on IPFS or a centralized server
    • IPFS is a peer-to-peer protocol that provides a decentralized way to store files across multiple people. The easiest way to think about this is a 1000 people each having 1/1000th of the piece of data at a time. This is decentralized, but still relies on using elements not on the blockchain
    • Centralized servers kind of undermine the entire point of a decentralized system
  • But What’s New???
    • New L1s like Avalanche have introduced innovations in the space that are allowing for new approaches to the data storage problem in the blockchain world
    • Recently the Avalanche network rolled out subnets which are essentially private blockchains
    • We are leveraging Avalanches subnets to allow NFTs data to be stored directly to a chain as opposed to IPFS or a URI pointer

Our Solution

  • We are employing the use of a subnet that has two separate blockchains each running an instance of the EVM to enable efficient storage.
  • We are treating one of the chains as designated for solely for storage of data in the NFT and the other chain will be where other smart contracts are deployed and users interact with the chain through dapps

  • We will be using a relayer and bridge architecture to generate NFTs upon each instance of data being stored, you put the data for your NFT in the storage chain (SpacesVM by Avalanche for ex.) and it uses the bridge to create an NFT representing ownership of that data on an EVM/contract chain that dapps interact with

  • General Order of Events:

    • A user on the storage chain will call a putData function that stores the data in a key-value store
    • This emits a PutData event to the relayer that has the address of user’s wallet on the general chain as well as the key from the k-v store
    • The relayer(s) will then submit a proposal to a bridge contract and subsequently vote on it, until enough votes have been achieved to validate the proposal.
    • Once the proposal has been accepted, the proposal is executed.
    • The bridge calls a method in the handler contract leading to an NFT being minted to the specified address
      • The NFT holds the address and the key for the k-v store

  • End Outcome: We have produced a way to store data on-chain in a subnet and produce a pointer via an NFT

Next Steps

  • Evident from the demo, we don’t have implemented a way to actually store the NFT data in an actual SpacesVM subnet chain
    • Future-proofed architecture so that we can easily revise contract to support SpacesVM support once it is provided
  • Two-way bridge
    • Right now there is no way for us to actually write to the data on the storage chain side
    • We plan to implement this for v2
  • Frontend UI
    • Clearly, no way for users to actually upload and mint NFTs non-programmatically
    • Also a v2 feature
  • Functioning Relayer
    • Issues at compile-time with abi versioning led to issues with deploying a functional relayer
  • Shared Memory
    • Using shared memory would allow for truly on-chain transactions and avoid the issues of using a bridge that relays on a third party (potentially centralized) relayer network

Misc

In order to test our implementation, we needed a way to locally build and run multiple subnet chains. We ran into a ton of issues setting up this necessary environment and compiled this document to hopefully ameliorate the frustration and shed light on some inconsistencies in documentation regarding this topic.

Built With

Share this project:

Updates