1

I see a lot of people tout the enormous benefits of using IPFS as a store of data. Meanwhile, the Ethereum blockchain is over 1TB in size, with quesitonable need to keep the earlier blocks.

In bitcoin, it makes sense to me why you would need to keep the entire blockchain hosted somewhere, since unspent transaction outputs need to be kept somewhere. Unlike bitcoin, the latest block in ethereum almost always a snapshot of the most recent state of Ethereum, effectively an auto-calculation of the unspent transaction outputs. So, with the exception of tracking how those who participated in the 80% ethereum ICO have hodled their coins, there doesn't really seem to be much need to store these early ethereum blocks.

Anyway, the point I am getting to is, if we could require a node who was a miner to link only to the IPFS hash of their block, and require them to host said block for only long enough for other miners to validate, would this be a good idea? Each IPFS hash would link to a block which contained each transaction included in said block. Miners would be required to download this block before validating the block included in the chain. Is this any different than say just downloading block hashes? What do we lack in terms of security, because we clearly gain a lot in terms of long-term blockchain storage?

Yes, I am implying that over time (i.e. with enough block confirmations), miners would stop hosting these IPFS blocks.

Improve this question
5
  • 1
    This basically sounds like a light client but with the addition of IPFS instead of just delivering the blocks as part of the Ethereum protocol.
    – user19510
    Jun 7, 2018 at 20:10
  • I am not quite sure we are on the same page... I am implying that over time (i.e. with enough block confirmations), miners would stop hosting these IPFS blocks. To me, it sounds a bit more like Byteball or a DAG-like chain. The result might sound like a bit like a "light" client, but I am really talking about creating a new fork of Ethereum (beginning from the most recent state of Ethereum) where each block uses only these characteristics.
    – nick carraway
    Jun 7, 2018 at 20:12
  • 1
    I think you're just saying no one should run full archive nodes (and everyone should stick with light clients). There's no need for a fork for that to happen; you just need to convince everyone to do it.
    – user19510
    Jun 7, 2018 at 20:13
  • Thanks. You might be right. I need to look more into how a light client works under the hood, although as I recall, it does just get the most recent state of the Ethereum blockchain, which sounds a lot like what I am describing. Still, I can't help but feel like there is some other advantage to this that I am forgetting about...
    – nick carraway
    Jun 7, 2018 at 20:13
  • 1
    Yes, they typically just request the most recent state, but the protocol allows for going back as far as you want. (There's usually no particular reason to, but if you wanted some sort of "recent archive" node, it could fetch everything up to n blocks back or the like.)
    – user19510
    Jun 7, 2018 at 20:15

1 Answer 1

Reset to default
1

  1. The Ethereum blockchan is less than 100GB. The 1TB is for an archive node, which is the blocks as well as a snapshot of the state at every block in history. So realistically if you want to calculate the size of the chain you should sum up the block headers, transactions, and (if you really want) the state tree of the newest block.

  2. Ethereum doesn't have UTXOs, it's account based instead.

  3. Every block header in Ethereum contains the merkle root of the state tree. This means even the newest block contains the state of the accounts that bought eth in the Ethereum crowdsale but haven't sent it to anyone.

A miner is actually incentivized to host their block forever. If the block they mine is lost, then they don't actually get the reward from it.

Realistically this is no different than the miner just sending the block themselves. The miner would be hosting it on IPFS and they would pin it themselves, so it would just move the Ethereum block propagation protocol to running on IPFS.

There are several reasons to at least keep block headers, though. One example is logs, which are a key part of fetching data from the Ethereum blockchain for dapps, and the way to trustlessly fetch them is using the the receiptsRoot, which is stored in the block header.

Improve this answer
4
  • "A miner is actually incentivized to host their block forever. If the block they mine is lost, then they don't actually get the reward from it." - How can this be? How could a new block change the state to ignore a previous block and have it be accepted by other nodes?
    – nick carraway
    Jun 7, 2018 at 20:25
  • If the original block is lost, how can the new miner mine on it? The first miner has the incentive to spread their block around to as much of the network as possible, and to do that, they really want to keep the block.
    – natewelch_
    Jun 7, 2018 at 20:29
  • I guess what I am asking is, why wouldn't a miner just host their block until it has been confirmed e.g. 1,000 times? Why do they need to hold it for "forever"? Once enough PoW has been added to the chain, what reason is there to hold the block?
    – nick carraway
    Jun 7, 2018 at 20:33
  • 1
    The miner doesn't need to keep it forever, and I assume most mining nodes don't keep full block history. But someone will keep it. If nobody keeps old blocks, then full nodes can't fully validate the blockchain, and they would no longer be trustless (just probabilistically safe)
    – natewelch_
    Jun 7, 2018 at 20:35

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.