Skip to main content
added 446 characters in body
Source Link

Note that putting the blockchain (and state etc) on swarm is already planned and thought out.

Integration with IPFS is also in the plan but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS, while light clients download by hash, see this reddit post.

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

EDIT: actually as Christian Lundkvist points out, this may not answer the question since "The question asks if we can encode the blockchain data structure into the IPFS Merkle DAG using IPFS objects, so that it is completely linked by IPFS hashes"

The answer to that is that it is easy with swarm manifest trie and a little unclear to me if it is just as easy in IPFS or not

Note that putting the blockchain (and state etc) on swarm is already planned and thought out.

Integration with IPFS is also in the plan but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS, while light clients download by hash, see this reddit post.

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

Note that putting the blockchain (and state etc) on swarm is already planned and thought out.

Integration with IPFS is also in the plan but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS, while light clients download by hash, see this reddit post.

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

EDIT: actually as Christian Lundkvist points out, this may not answer the question since "The question asks if we can encode the blockchain data structure into the IPFS Merkle DAG using IPFS objects, so that it is completely linked by IPFS hashes"

The answer to that is that it is easy with swarm manifest trie and a little unclear to me if it is just as easy in IPFS or not

added 57 characters in body
Source Link
q9f
  • 33k
  • 47
  • 157
  • 399

Note that putting the blockchain (and state etc) on swarm is already planned and thought out: https://github.com/ethereum/go-ethereum/issues/2049planned and thought out.

Integration with IPFS is also in the plan https://github.com/ethereum/go-ethereum/issues/2050is also in the plan butbut may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS  , while light clients download by hash, see https://www.reddit.com/r/ethereum/comments/44qpks/what_would_be_needed_to_store_the_blockchain_as_a/czs5qnhsee this reddit post.

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

Note that putting the blockchain (and state etc) on swarm is already planned and thought out: https://github.com/ethereum/go-ethereum/issues/2049

Integration with IPFS is also in the plan https://github.com/ethereum/go-ethereum/issues/2050 but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS  , while light clients download by hash, see https://www.reddit.com/r/ethereum/comments/44qpks/what_would_be_needed_to_store_the_blockchain_as_a/czs5qnh

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

Note that putting the blockchain (and state etc) on swarm is already planned and thought out.

Integration with IPFS is also in the plan but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS, while light clients download by hash, see this reddit post.

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

Source Link

Note that putting the blockchain (and state etc) on swarm is already planned and thought out: https://github.com/ethereum/go-ethereum/issues/2049

Integration with IPFS is also in the plan https://github.com/ethereum/go-ethereum/issues/2050 but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS , while light clients download by hash, see https://www.reddit.com/r/ethereum/comments/44qpks/what_would_be_needed_to_store_the_blockchain_as_a/czs5qnh

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.