14

I've read previous answers such as that posted by user: eth that highlights some of the EIPs such as 103: Serenity and 105: Sharding. These are more long term solutions but this is an emergent problem as of RIGHT NOW

What I'm unaware of is a theoretical upper bound on the size of the blockchain? There is concern of the blockchain going over 1TB. This is on the borders of storage on consumer laptops and over which would drastically reduce the access of Full nodes to the masses.

Improve this question
4
  • 1
    I totally agree. We need to start addressing this issue as soon as possible. Dig into the geth or parity repos, and make suggestions. It's all open source.
    – Thomas Jay Rush
    Commented May 25, 2018 at 18:22
  • 5
    Vitalik's response is here: medium.com/@VitalikButerin/…
    – Richard Horrocks
    Commented May 25, 2018 at 18:32
  • 1
    @RichardHorrocks We don't have sharding as of yet is my concern. So new users would have to run pruned nodes?
    – Vignesh Karthikeyan
    Commented May 25, 2018 at 18:41
  • 2
    The main point to note is that full archive nodes don't have any inherent advantage (thus there is no tendency to centralise with them) nor are they required for securing Ethereum in a shardless or sharded network.
    – James Ray
    Commented May 26, 2018 at 13:06

2 Answers 2

Reset to default
13

You don't need to have lots of full client nodes.

Nowadays you can download the light-client version, which implementing Merkle Tree structures, lets nodes to don't be obligated to store ALL of the data on it's hard drive.

Some use cases for a fully light client, and how the light client meets those use cases, include:

  • A light client wants to know the state of an account (nonce, balance, code or storage index) at a particular time. The light client can simply recursively download trie nodes from the state root until it gets to the desired value.
  • A light client wants to check that a transaction was confirmed. The light client can simply ask the network for the index and block number of that transaction, and recursively download transaction trie nodes to check for availability.

The first three light client protocols require a logarithmic amount of data access and computation; the fourth requires ~O(sqrt(N)) since bloom filters are only a two-level structure, although this can be improved to O(log(N)) if the light client is willing to rely on multiple providers to point to "interesting" transaction indices and decommission providers if they are revealed to have missed a transaction. The first protocol is useful to simply check up on state, and the second in consumer-merchant scenarios to check that a transaction was validated. The third protocol allows Ethereum light clients to collectively validate blocks with a very low degree of trust.

  • In Bitcoin, for example, a miner can create a block that gives the miner an excessive amount of transaction fees, and there would be no way for light nodes to detect this themselves, or upon seeing an honest full node detect it verify a proof of invalidity. In Ethereum, if a block is invalid, it must contain an invalid state transition at some index, and so a light client that happens to be verifying that index can see that something is wrong, either because the proof step does not check out, or because data is unavailable, and that client can then raise the alarm.

Here you got full info of how a light-client is implemented with Merkle Trees:

https://github.com/ethereum/wiki/blob/master/Light-client-protocol.md

https://en.wikipedia.org/wiki/Merkle_tree

Hope it helps!

Improve this answer
3
  • 1
    Would my understanding be correct in asking that if a light node needs to verify a transaction, it can simply download what it requires to do so (independent of a full node) and verify the transaction itself(i.e., different from that of bitcoin's?).
    – Vignesh Karthikeyan
    Commented May 25, 2018 at 19:03
  • 3
    Yep, the positive aspects of using light clients is that you can verify transactions too because you have strategic data and tree hashes that allow you to proof the correctness without having all of the info. With all of the answer i don't want to say that full nodes are not necessary, THEY ARE. But not all the nodes have to store the 1TB full.
    – CPereez19
    Commented May 25, 2018 at 19:17
  • 1
    Ah I didn't even know that. I assumed wrongly they were very important like bitcoin's were. Appreciate the answer.
    – Vignesh Karthikeyan
    Commented May 25, 2018 at 19:19
5

Someday the Ethereum blockchain will hit 1TB, but it won't be soon. I've been installing full mining and non-mining nodes with geth with "fast" disabled. A fresh install of the blockchain fits nicely in under 120GB today, and that is only up about 40GB from last December. That's around 40GB in nearly half a year. Even if the Ethereum blockchain triples it's growth rate, 1TB isn't going to happen any time soon.

That would be why people are satisfied with long term solutions.

I'm wondering if some of the people claiming the ledger is growing to 1TB real soon haven't perhaps tried creating a node multiple times on their computer without clearing away previous attempts?

Improve this answer
1
  • Parity has an option to sync a non-pruned blockchain with debug traces that is about 1.1TB
    – Vignesh Karthikeyan
    Commented Jun 26, 2018 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.