Hacker News Reader

Hacker News

Comment by shawn | Hacker News Reader

Full thread

shawn

What will BTC or ETH hard drive usage look like 100 years from now? Has anyone run the numbers?

It seems like the disk usage will become untenable, but maybe someone has a plan to deal with it.

View on HN

Actual disk-storage-use* data here:

https://anduck.net/bitcoincore_vs_geth_full_node_stats.png

Ethereum's blockchain has a growth rate 2X bitcoin's. If it continues to grow at this pace, it'll eclipse 1 TB in size in 2018. If you aren't verifying the blockchain that you're reading and writing to, then you're using a trusted third party. If you're using a trusted third party, why are you even using a blockchain to begin with?

Even BitGo, a commercial payment company, has trouble maintaining datacenter servers that can keep up with the io demands of running an Ethereum node. [1] Doesn't bode well for the long-term viability of ethereum.

Bitcoin's philosophy has been, rather than broadcast every single state update to every single network participant (an unscalable network design approach[2])

[1] The Challenges of Building Ethereum Infrastructure https://medium.com/@lopp/the-challenges-of-building-ethereum...

[2] Lightning Network enables Unicast Transactions in Bitcoin. Lightning is Bitcoin’s TCP/IP stack. https://medium.com/@melik_87377/lightning-network-enables-un...

*Storage is only one part of the scaling engineering issues. Also important is the CPU and time requirements to keep a blockchain node synced.

Having authority be federated is a vast improvement. It's not hard to understand that I might be willing to pick an authority I trust out of a pool of the entire globe when I might not be willing to trust the authority of the US government and a handful of proximate banks.

You're ignoring pruning, which appears to reduce disk usage from ~1TB to ~30GB.

Pruning only reduces the permanent storage required. You still have to deal with bandwidth, io demand / sync time.

And as far as I understand, someone still needs to have that data to enable syncing of pruned nodes correct?

If that's correct, then doesn't widespread usage of pruning threaten the ability of new nodes to get up to date?

Yes, there needs to be a dozen or so archive nodes.

...so, we're back to trusting a set of centralized parties, then? What if those get wiped? Altered (though that seems less likely)? Is such an archive a fork vector?

I wrote a blockchain explorer on Bitcoin as a technical exercise, and the intermediate state thing caught my attention, too. If all copies of a block disappear and all you're left with is a hash, what do you have? A complete blockchain?

Don't we have the hashes to assert on?

This is extremely widely misunderstood, one of those rampant FUD topics.

Archive nodes in Ethereum are almost completely superfluous.

An Ethereum archive node is not the same thing as a full node.

Archive nodes add zero extra security to the network. They are only useful for historical analysis of past states.

100% of the blockchain information is stored in non-archival full nodes.

The Ethereum system is a series of transactions that modify a state. The system is completely defined by the transactions. The latest state can be derived from them.

An archive node is a node that stores all past states for efficient retrieval.

No, pruning in ethereum means not storing old states (=results of executing all blocks at height H), not removing old blocks. As of now the bare blockchain + the state takes only about 20+2GB. It takes more on a live node due to db space amplification (45-50GB in parity), but that can theoretically get very close to 1x with future updates.

So ... deriving balances?

Smart contracts can have arbitrary state, but in general, yes. An archival node stores the state for each block which is only useful for block explorers and similar. That's indeed likely to take 1TB in 2018 - hardly a problem.

Which is solved by fast sync/warp sync?

>>Ethereum's blockchain has a growth rate 2X bitcoin's. If it continues to grow at this pace, it'll eclipse 1 TB in size in 2018.

This statistic keeps being trotted out despite having been repeatedly shown to be extremely misleading:

https://www.reddit.com/r/ethereum/comments/7gcheo/the_ethere...

In short: the intermediate states do not need to be stored for full trustless validation. Ethereum nodes now prune intermediate states by default. Bitcoin nodes don't even have an option to store intermediate states. Intermediate state storage is an entirely optional feature and comparing Ethereum nodes that do it to Bitcoin nodes that don't is disingenuous.

If you aren't verifying the block chain you don't have to rely on a trusted third party. You ask a third party and then check with a couple other third parties to verify what the first gave you. Big difference.

At my startup, we have created a geth fork that uses Postgresql instead of leveldb. It took quite some effort...but we are running a full node right now. I think we are going to put in more effort there - we already implemented soft deletes,etc. Smarter people than me can probably build a better data model for the merkle trees leveraging postgres.

It's 2x slower than leveldb (if that matters to you), but given how slow a blockchain really is ...it is plenty fast enough.

https://github.com/RedCarpetUp/go-ethereum/tree/dev?files=1

I believe that it is time for developers to start thinking of single node scalability and infrastructure that is maintainable..rather than convenience.

Can you give me your reasoning to port the db to Postgresql? Thanks.

I have a long-ish discussion at https://github.com/tendermint/tendermint/issues/674

Thanks. Blends in with our opinion.

Umm..so you agree or disagree ?

Please feel free to comment on our code and point out some obvious flaws. We would love to learn.

I'm affiliated with a cryptocurrency which is using Postgres as its underlying database since the beginning. So I agree with your sentiment.

Single node scalability is often overseen, but in my opinion has to come first, before you can expand scalability network wide. It's like standard computer science practices are not being applied in the crypto world, yet.

That looks pretty cool. Any plans to submit a PR upstream?

Yup. Im a little intimidated by sending it right now - I'm not a crypto "expert". So I'm looking for some informal review and then probably submit it.

You've misunderstood the possibilities -- it's not just "store everything" or "trust someone else". You can download all of the headers but none of the data (resulting in a 27M ETH blockchain today), and then download the full blocks that you need on-demand when you want to query transactions, with no loss of safety. (If someone lied about the block contents, they'd fail to match its header hash.) This is what happens in Ethereum's "light" sync mode:

https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereu...

> with no loss of safety.

That simply isn't true. Accepting a blockchain blindly without validating is the Bitcoin SPV model. In ethereum it amounts to an undiversified risk that the two mining pools needed to constitute a majority hashpower (ethermine and f2pool) will not violate the protocol, or-- if you are accepting state with few confirmations as final-- that _any_ miner will not violate the protocol.

Headers are fingerprints / unique hashes. If someone else has already derived account balances to a particular point, it may be enough to avoid duplicating the chain.

> If you're using a trusted third party, why are you even using a blockchain to begin with?

This is a common misperception of the benefits of a blockchain. It's like saying, if you are trusting a third party on science, why use science at all? You don't have to verify science yourself, but know that you could repeat the experiment if you wanted or needed to. The fact that the blockchain _is_ fully stored and verified by a number of distributed parties, and that you do have the ability of downloading and verifying if you want or need to, is enough to keep the system honest.

Now this statement does make sense if you are referring to your private keys. Don't ever let any third party hold those for you.

> but know that you could repeat the experiment if you wanted or needed to

The point is that at this rate, quite quickly you won't be able to, the costs would just be too high.

It’s not a common misconception if trust is implied or is verified by other means then you only need to be able to effectively verify correctness and there are much much cheaper ways of achieving that.

> The fact that the blockchain _is_ fully stored and verified by a number of distributed parties, and that you do have the ability of downloading and verifying if you want or need to, is enough to keep the system honest.

How will you download and verify the chain when it hits double digit TBs?

How about 10 years from now, when the storage requirements are an order of magnitude greater than that? The rate of growth is far outstripping consumer storage device capacity...

That's wrong, please read this: https://dev.to/5chdn/the-ethereum-blockchain-size-will-not-e...

>Even BitGo, a commercial payment company, has trouble maintaining datacenter servers that can keep up with the io demands of running an Ethereum node.

That company lost 120k of Bitfinex's BTC to a hack, the exact scenario it was apparently created to prevent. Their struggles reflect their competence level: especially the part about _directly_ using network storage, apparently genuinely not realizing that the main point of local instance storage is to function as a last cache level exactly for situations like these.

Buy a $100 4TB external and put it on there.

Problem solved for ~2.5 years.

Well that's exactly what both cryptocurrencies are currently working feverishly to solve.

Bitcoin's idea is to use Lightning Network to keep the extreme majority of transactions from ever having to hit the blockchain. And it's also why the blocksize shouldn't be increased like some forks are doing, because in 100 years (or even 5 years) the size will be unmanageable.

I believe ETH has something similar, but I'm not knowledgeable enough about that ecosystem to say either way.

It's clear to everyone that the blockchain as a "data structure" isn't scalable to anything resembling "widespread usage", and that it will be a hard requirement to figure out how to either quickly and safely "prune" information from a blockchain, or get most of the transactions to stay off of it somehow.

Also, I'm sad that most of the replies to your comment are jokes or comments about how it won't matter, or how you are dumb for even asking the question. It seems when it comes to cryptocurrencies HN is just as bad as other forums online that everyone resorts to insults and "witty" one liners.

The eth devs are busy working on sharding - the same idea as traditional databases like Mongo where a primary key decides which node the data will reside. The main problem here is that a contract residing on shard A might reference a contract on shard B (much like a join between 2 shards). They are approaching this by using "transaction receipts" that would be passed from shard to shard. https://github.com/ethereum/wiki/wiki/Sharding-FAQ

Don't they have something roughly equivalent to the Lightning Network on ETH called the Raiden Network as well? Or am I misunderstanding that?

Indeed - Raiden is all about payment channels - funds are deposited on the main chain and then payments can be sent over channels with no fee. Only in the case of dispute or cashing out is the main chain used to resolve the conflict. This means you could make many transactions per second of very small amounts (useful for things like gambling sites or micro-payments for content). Micro-Raiden is already active which are one-to-one payment channels - the full Raiden network is not yet live but will facilitate one-to-many channels.

* https://raiden.network/faq.html

* https://raiden.network/micro.html

You are correct, and the name Raiden is a reference to the Mortal Kombat character who shoots lightning from his fingertips.

µRaiden (two-party transfers only, no routing) is already live on Ethereum mainnet: https://raiden.network/micro.html

> traditional databases like Mongo

Kids these days. I think my head just exploded.

Mongo: The unreliable partitioned database.

Ok - I meant non-blockchain databases

I think he meant the part where you called Mongo "traditional" as your example. (vs say, DB2)

The ETH system is called Plasma (https://plasma.io/).

Plasma is separate from the sharding I thought?

Raiden and Plasma are different thoughts on scaling.

I suggest your read this:

https://medium.com/@preethikasireddy/how-does-ethereum-work-...

Quote:

But unless a node needs to execute every transaction or easily query historical data, there’s really no need to store the entire chain. This is where the concept of a light node comes in. Instead of downloading and storing the full chain and executing all of the transactions, light nodes download only the chain of headers, from the genesis block to the current head, without executing any transactions or retrieving any associated state. Because light nodes have access to block headers, which contain hashes of three tries, they can still easily generate and receive verifiable answers about transactions, events, balances, etc.

The reason this works is because hashes in the Merkle tree propagate upward — if a malicious user attempts to swap a fake transaction into the bottom of a Merkle tree, this change will cause a change in the hash of the node above, which will change the hash of the node above that, and so on, until it eventually changes the root of the tree.

A voice against light-client nodes

"Peter Todd, a Bitcoin Core developer, concerns what we can say is a fundamental technical argument from small blockers. They argue we can not scale on-chain, because we can not have light-client nodes, because we can not construct what is called fraud proofs."

Vitalik Buterin and Peter Todd Go Head to Head in the Crypto Culture Wars

http://www.trustnodes.com/2017/08/14/vitalik-buterin-peter-t...

<< Fraud Proofs explanation >>

How Fraud Proofs May Improve SPV Node Security in Bitcoin

https://coinjournal.net/how-fraud-proofs-may-improve-spv-nod...

Well if Bitcoin Cash gets to VISA level transactions quantity they will have around 1GB block every 10 minutes, who will be able to run a full mining node?, 2 to 3 corporations worldwide, probably centralized in some geographical region for lower communication latency.

Easy peazy. Just convert each node to a cryptographic sql server. Once that reaches its limit, use a multinode nosql/newsql pocket cluster.

Most people already have the compute, memory, storage, and network infrastructure to support that nowadays.

Using a 3TB, $70 drive from NewEgg as an example, HDD costs for full 1GB blocks would be $3.36/day, today. Surely more than 2-3 corporations can afford that.

The RRP of a terabyte of hard drive on NewEgg has almost nothing to do with the cost of provisioning an additional reliable terabyte of datacenter storage + IOPS

Right now it costs 5$ a month to run a bitcoin node, and blocks are 1MB.

Multiply that by a thousand to get 1GB blocks and it will cost 5000$ a month to run a node.

Sure that's not a home Internet line, but it is a far cry from "2 or 3 corporations".

If you had said "10 thousand corporations" you'd be closer to the truth.

The "Gigablock Initiative" presented at the recent "Scaling Bitcoin" conference tests exactly that. They found that Bitcoin Cash can easily scale on chain to VISA levels using standard desktop machines.

https://news.bitcoin.com/bitcoin-unlimited-reveals-gigablock...

The same would apply to Bitcoin scaling on chain.

Well 3 organizations already control more than 51% of bitcoins mining, I'm sure they're already optimizing communications between each other.

https://blockchain.info/pools

It's mentioned in the BTC whitepaper.

https://bitcoin.org/bitcoin.pdf

Scroll to section 7 "Reclaiming Disk Space"

at the current rate of ~55GB /year, running a full block client shouldn't be too hard, even on SSDs

Here's an up-to-date comparison of Bitcoin and Ethereum's cumulative blockchain size: http://bc.daniel.net.nz/

Would be nice to see transaction throughput next to these.

But that's with a full copy of the state of every block, which is redundant and only needed for efficient historical queries. If you just want to fully verify the current state, all you need is the block headers, the current state, and all the transactions, which adds up to about 30GB.

That's wrong:

https://www.reddit.com/r/ethereum/comments/6zcoja/10_gb_in_2...

It's correct for full nodes, which is the point.

Full nodes include nodes that don't store intermediate state. Storage of intermediate state is optional in Ethereum. It's not even possible in Bitcoin. An apt comparison is between Ethereum full nodes that don't store intermediate state and Bitcoin full nodes.

Please stop being confidently wrong about this.

Storage costs have massively gone down over the last X decades.

A Terra byte hard drive will sell for ~40 dollars these days.

In 2 decades maybe that will be a petabyte drive going for 40$.

* terabyte, not “Terra byte”

Something tells me it won't be a problem.

Ken M must have a new name...

Please tell me you're joking

Reply on news.ycombinator.com