How to implement arbitrary blockchain protocols on top of IPFS?

Help Old FAQ
1

From @jbenet on Mon Dec 14 2015 12:42:57 GMT+0000 (UTC)

@fsantanna said:

Hi,

I stumbled across IPFS this week and am really excited with its potential to change things for real.

I have a very direct question:

What are the minimal additions to IPFS that would allow arbitrary blockchain protocols to be implemented on top of it?

Some clarification:

  • When I say ā€œon top of IPFSā€ I mean that the blockchain should be manipulated and updated through its commands [1] without deep understanding of the internals. More specifically, I mean not hacking with the Go library.
  • To be more concrete, these are my rants [3](probably non scalable), but Iā€™d rather listen to the opinion of experts.
    In particular, how feasible is to provide user-level broadcast in IPFS? How does the usual broadcast behavior of the IPFS swarm compares to existing flooding techinques in blockchains?

[1] IPFS Documentation | IPFS Docs
[2] ipfs example viewer
[3] ipfs-chain.md Ā· GitHub

Thanks,
Francisco


Copied from original issue: How to implement arbitrary blockchain protocols on top of IPFS? Ā· Issue #82 Ā· ipfs-inactive/faq Ā· GitHub

2

From @jbenet on Mon Dec 14 2015 12:43:24 GMT+0000 (UTC)

I responded:

I stumbled across IPFS this week and am really excited with its potential to change things for real.

Thanks! Weā€™re going to need all the help we can get to pull this off. Please jump in wherever youā€™re interested!

I have a very direct question:

What are the minimal additions to IPFS that would allow arbitrary blockchain protocols to be implemented on top of it?

You donā€™t need anything more, actually. IPFS works well for this already.

You may want to check out this post, by Christian Lundkvist:

And this talk by me:

Some clarification:

  • When I say ā€œon top of IPFSā€ I mean that the blockchain should be manipulated and updated through its commands [1] without deep understanding of the internals. More specifically, I mean not hacking with the Go library.

You should be able to do this all with just:

  • ipfs object get/put
  • ipfs name publish/resolve
  • To be more concrete, these are my rants [3](probably non scalable), but Iā€™d rather listen to the opinion of experts.
    In particular, how feasible is to provide user-level broadcast in IPFS? How does the usual broadcast behavior of the IPFS swarm compares to existing flooding techinques in blockchains?

We do not yet have pub/sub. This is forthcoming:

[1] IPFS Documentation | IPFS Docs
[2] ipfs example viewer
[3] ipfs-chain.md Ā· GitHub

Great thoughts on pub/sub. It would be useful to incorporate them into the pub/sub discussion. Please post on https://github.com/ipfs/notes/issues/64

I will be putting a lot of time into pub/sub the week of Dec 20. It would help to have many pub/sub thoughts on that issue before then.

3

From @fsantanna on Wed Dec 16 2015 13:04:58 GMT+0000 (UTC)

Thanks, @jbenet, for the thoughtful answer.

What are the minimal additions to IPFS that would allow arbitrary blockchain protocols to be implemented on top of it?

You should be able to do this all with just:

  • ipfs object get/put
  • ipfs name publish/resolve

My understanding is that if you use ipfs name you fall into one of the two situations:

  • If you publish to a public key only you can sign, then the blockchain is centralized (only you can ā€œmineā€).
  • If you publish to a public key anyone can sign, then the blockchain is impractical (anyone can ā€œmineā€ w/o being checked).

My guess is that you cannot do that without a pub/sub system.

Iā€™m working on a proof-of-concept pub/sub and will eventually post to ipfs/notes#64.

4

From @mitar on Mon Mar 28 2016 17:03:16 GMT+0000 (UTC)

To my understanding, IPFS can be used to store transactions into something resembling blockchain and get them permanently stored, and even have a linked list between them to have a defined order between transactions levering merkle DAG (a crazy idea is that you do not really need a total order of all transactions, only those which interact with each other, so you can leverage graph-nature of IPFS). (Or would it be simple better to not try to map relations between transaction to internal merkle DAG and simply have each transaction store as data also the parent existing transaction?)

But the issue is that while you can store such linked list of transactions, the issue is how does one know which head of possible competing linked lists is the one community has a consensus on.

As @fsantanna wrote above, you have currently two options to decide which head is the correct one (and store that correct one using ipfs name). But none of those are really decentralized in a way one expects from blockchains. So some service on top of IPFS is maybe needed to compute consensus for the head.

But there is still a question of what attack directions are possible here? When attacking different layers of IPFS? What one can do? Just denial of service of something more? A clearer understanding of this I think is needed. At least listing common issues with blockchains and see how IPFS addressed them.

Also it is unclear what properties IPFS has in terms of how quickly would transactions be published in the network and stored ā€œpermanentlyā€. One issue is that this is linked to the consensus service one should implement. But also the issue is that by default IPFS does not distribute data automatically all around, what one would want for a blockchain. So some additional work to push all transactions to everyone else would be needed as well (or that they pull it).