Hello everyone,
I thought about trying to modify an IPFS Kubo node to accept cid push request with crypto guarantee instead of only pulling cid.
The idea will be the following :
- In the storage in Jam, keep the hash, it’s the key, but replace the value by a Reed Solomon sharding (erasure root, the shards cid, k and m). If a node assigned to a core need the value of a service, it will load it from its Kubo node, then check the result against the hash of the key. But how can you be sure the validators will have the needed cid to execute the service ?
- Create a ts dapp with a Jam service where Polkadot account can rent their browser’s IPFS node(Helia) for a determined period of time, then add onchain their Libp2p address. The dapp has a Jam light node and read the world state, for each shards cid, it compute if it needs to be on their Helia node.
- Once the world state is read and all the shards in the browser’s IPFS node, the storage renter can enter the protocol. The dapp reads the waiting pool of the extrinsic, check the services needed, if they are supposed to have a shard of it, and if it’s the case, sign its metadata with the bloc number and send it to the Kubo node of the validators.
- Modify the Kubo node to read the Jam waiting pool, check the services required, check theirs cid shards, and listen to push of cid from eligible storage renter (present in the Jam service and supposed to possess this shard).
- On accumulate, their could be a lottery for the storage’s participants to be rewarded if they provided the needed shards.
That way, the data are prepared for the Jam node, it can focus on STF without stocking a lot of data.
A few of the limits of this protocol are :
- how to quickly verify for the lottery’s reward if a data renter is supposed to possess this cid on chain ?
- how can I be sure there is no hole in the repartitions of the shards on the IPFS node at any given time ?
Do you think it could be useful and does anybody want to do it with me to see it that works ?