8

Assuming I was deployed a smart contract in a Parachain EVM wanting to cross out to IPFS to save or read data, what is the best way of achieving this in a decentralised way. For example, doing this via a simple React Dapp, is not realistic as the smart contract will have to be able to always connect to the client e.g. emit an event and the client picks it up and pushes it to IPFS Running a webserver will solve the above issue but becomes an attack vector, hence quickly evaporates the decentralisation of IPFS data storage and smart contract execution logic

Improve this question
4
  • 1
    Not sure if you understand IPFS correctly. First, IPFS is a content distribution network rather than a storage. It allows you to discover some content stored in some node in the network. So to my understanding there's no direct way to "save data" to IPFS. Second, contracts can only handle very limited size of data. So there's very small chance you need to read or write to a file within a contract. Generally it's more realistic to just save a IPFS link in your contract (e.g. NFT images). It implies the user need to pin a file on IPFS first, and save the link to the contract later.
    – h4x3rotab
    Mar 23, 2022 at 5:02
  • 2
    (cont.) If you want to make sure the data indeed exists and is stored somewhere, you may need a kind of "proof of storage", the evidence that your data is archived on some decentralized storage. This can be done by a combination of merkle proof and the storage root on a permanent storage chain (i.e. Arweave). Btw, proof of storage is not a commonly used term, at least the one used by Filecoin is very mesleading because it only prove a specific miner stores some data, not the commitment of the data on the blockchain.
    – h4x3rotab
    Mar 23, 2022 at 5:51
  • @h4x3rotab this IMHO should be an answer - it's very on point :)
    – Nuke ♦
    Mar 28, 2022 at 16:56
  • Thanks! I've made it an answer :D
    – h4x3rotab
    Mar 31, 2022 at 7:29

3 Answers 3

Reset to default
2

here's some potentially useful docs: https://rs-ipfs.github.io/offchain-ipfs-manual/substrate-core-modifications.html

Improve this answer
1

Maybe the offchain::ipfs project would help you interact with IPFS as it is a modified substrate node.

Alternatively, you could create a chain extension, which would allow your contract to "call a custom Substrate function from ink!". In this scenario, your chain extension would perform the IPFS operations.

Furthermore, you could create your own pallet, which is an additional library that can be included in the substrate runtime. You could then use this pallet to perform all of your business logic and perhaps not use pallet_contracts at all.

For each example, to be decentralised you would need to have many nodes running the software, which is effectively a blockchain / parachain. I'm not sure if there are established parachains that would implement a chain extension you developed for a fee but this could be a potential route if there were.

Great question and I hope it attracts additional answers as I could also do with some clarity on the interactions of chain extensions and pallets and how to build a network once they're developed. Welcome to the community.

Improve this answer
4
  • Many thanks for all the answers. We are currently at research stage of the best architecture and explore all options available to us. Do you believe fat contracts as described here medium.com/phala-network/… "Access Internet services" is a viable solution? e.g. our sc stores an IPFS link that points to stored 1000 hourly close KSM and DOT prices. Do you see fat contracts as an efficient solution of our sc requesting the data to read and update or is there something critical/limitations we are missing out. Besides Phala we also research Crust.
    – Sokrates
    Mar 23, 2022 at 7:44
  • 2
    Phala certainly looks like a good fit for achieving internet communication to the internet. They are working on support for ink! so you could currently write your contract in ink! and it would be compatible with other parachains and also Phala in future.
    – forgetso
    Mar 23, 2022 at 10:00
  • 2
    not trying to self promote I've been hacking away at a fork of the offchain::ipfs repository and am currently working on developing contracts that take advantage of the underlying IPFS network. As others have noted, the approach taken is to use a chain extension that exposes functionality to manage data and data access. iridium-labs.github.io
    – Tony
    Mar 25, 2022 at 2:10
  • Welcome to join our #dev discussion channel if you are interested in http request from ink! (discord.gg/phala)
    – h4x3rotab
    Apr 12, 2022 at 6:13
1

Not sure if you understand IPFS correctly.

First, IPFS is a content distribution network rather than a storage. It allows you to discover some content stored in some nodes in the network. So to my understanding there's no direct way to "save data" to IPFS. Second, contracts can only handle very limited size of data. So there's very small chance you need to read or write to a file within a contract. Generally it's more realistic to just save a IPFS link in your contract (e.g. NFT images). It implies the user need to pin a file on IPFS first, and save the link to the contract later.

If you want to make sure the data indeed exists and is stored somewhere, you may need a kind of "proof of storage", the evidence that your data is archived on some decentralized storage. This can be done by a combination of merkle proof and the storage root on a permanent storage chain (i.e. Arweave). Btw, proof of storage is not a commonly used term, at least the one used by Filecoin is very misleading because it only prove a specific miner stores some data, not the commitment of the data on the blockchain

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.