Storing Dash Evolution Data in IPFS

Help Coding
1

Hello,

I’m working on Dash Evolution, specifically on the data storage (DashDrive). Let me tell you a little about this project to make my questions clear for you.

Evolution is a new project of Dash cryptocurrency, which allows third-party developers to build own applications (DAPs) on top of Dash masternodes network and store their user data in DashDrive with validation in the blockchain. DashDrive is a service that deployed on each masternode and implements some logic and API on top of IPFS.

Demo of the first DAP: https://www.youtube.com/watch?v=gbjYhZT2Ulc

Evolution introduces a new type of blockchain transaction - State Transition, which contains DAP objects (user data).
Storing user data in blockchain is pricey, that’s why State Transition consists two parts:

  1. State Transition Header, which goes to chain and necessary for data validation.
  2. State Transition Packet, which contains DAP objects (JSON objects of users data) and goes to DashDrive.

Simplified State Transition Packet structure is:

{
 "somePacketField1": "...",
 "somePacketField2": "...",
 "dapObjects": [
     {
        "objectFiled1": "...",
        "objectFiled2": "...",
        ...
     },
     ...
 ]
}

As you may have guessed, we are storing State Transition Packets in IPFS. I suppose the right way to do that is implementing own IPLD resolver, like ipld-bitcoin. We want to store Packet data as DAG node with links to DAP objects which contains in IPFS blocks. This design is pretty flexible and allow us to work with objects as well as with whole packet using ‘recursive’ option. CID of Packet DAG node should be hash of origin State Transition Packet which we store in the blockchain.

So my questions are:

  1. Is it the right decision to use own IPLD resolver for this purpose?
  2. Can we use our own CID’s hash for storing Packet into IPFS?
  3. I see how to implement this using ipld-dag-pb format of the object, but do not fully understand how it should be in our custom IPLD implementation.
  4. How can we integrate our IPLD implementation with go-ipfs?
2 Likes
2

Hey @shumkov, sorry for the delay.

  1. Is it the right decision to use own IPLD resolver for this purpose?

You could use an ipld resolver for this, or you could simply use the cbor ipld implementation (our ‘default’ ipld type). Anything you represent as json can be represented in cbor, and more.

  1. Can we use our own CID’s hash for storing Packet into IPFS?

I’m not sure what you mean here, do you want to use your own hash function? Or the hash of the CID?

  1. I see how to implement this using ipld-dag-pb format of the object, but do not fully understand how it should be in our custom IPLD implementation.

Here’s a really simple ipld tutorial that might be helpful: http://ipfs.git.sexy/sketches/ipld_intro.html

  1. How can we integrate our IPLD implementation with go-ipfs?

If you write your own resolver, you can embed it into go-ipfs using a plugin, similar to how the ethereum plugin works here: GitHub - ipfs/go-ipld-eth: Plugin of the Go IPFS Client for Ethereum Blockchain IPLD objects

Let me know if that helps, and if you have any other questions for us :slight_smile:

3

Hello,

No worries. We’ve found answers in the code and materials below:

We had concern can we specify CID (multihash) in our IPLD format which is not equal to object hash. The answer was in go-ipfs internals - no we can’t. IPFS is completely CAS.