4

It seems that using a HDD to sync the node is no longer possible/recommended, and it seems this is because of the many active adresses. What if the number of active adresses increase? Will it eventually become impossible to sync with an SSD as well? And when might this happen?

Thanks and kind regards Soebgst

1 Answer 1

5

First of all, just say that there's a loooooong way until we arrive to a scenario where sn SSD node isn't able to sync propperly. An exponential increase of addresses will be needed. And sincerely, nowadays, it's sad to say it but lots of the active addresses are only speculators buying and selling ether continuously. As soon as the fashion finnishes, we will be again soooo far away from the scenario you're talking about.

But in order to explain what can help if this scenario becomes true:

One of the Ethereum's milestones seems to be the development of sharding on blockchains. This solution of sharding will make viable to still sync with SSDs.

What is Sharding?

We split the state and history up into K = O(n / c) partitions that we call “shards”. For example, a sharding scheme on Ethereum might put all addresses starting with 0x00 into one shard, all addresses starting with 0x01 into another shard, etc. In the simplest form of sharding, each shard also has its own transaction history, and the effect of transactions in some shard k are limited to the state of shard k. One simple example would be a multi-asset blockchain, where there are K shards and each shard stores the balances and processes the transactions associated with one particular asset. In more advanced forms of sharding, some form of cross-shard communication capability, where transactions on one shard can trigger events on other shards, is also included.

How it will look like?

There exist nodes called collators that accept blobs on shard k (depending on the protocol, collators either choose which k or are randomly assigned some k) and create collations. A collation has a collation header, a short message of the form "This is a collation of blobs on shard k, the parent collation is 0x7f1e74 and the Merkle root of the blobs is 0x3f98ea". Collations of each shard form a chain just like blocks in a traditional blockchain.

A "main chain" processed by everyone still exists, but this main chain's role is limited to storing collation headers for all shards. The "canonical chain" of shard k is the longest chain of valid collations on shard k all of whose headers are inside the canonical main chain.

So we arrive to the answer, but before, we need to know one last thing:

Note that there are now several "levels" of nodes that can exist in such a system:

  • Super-full node - fully downloads every collation of every shard, as well as the main chain, fully verifying everything.
  • Top-level node - processes all main chain blocks, giving them "light client" access to all shards.
  • Single-shard node - acts as a top-level node, but also fully downloads and verifies every collation on some specific shard that it cares more about.
  • Light node - downloads and verifies the block headers of main chain blocks only; does not process any collation headers or transactions unless it needs to read some specific entry in the state of some specific shard, in which case it downloads the Merkle branch to the most recent collation header for that shard and from there downloads the Merkle proof of the desired value in the state.

So now, by knowing that not all of the nodes must be "Super-full nedes", the other ones will have less sync charge, and then, will be still possible to use SSD.

At least that's how I see it, there's lots of ways on which Ethereum needs to grow, but solutions will be found before the number of active addresses is that high.

Hope it helps.

6
  • 1
    I agree generally with what is said here, but many of the statements are unsupported. Particularly the first few comments saying we a "soooooo far away..." The chain is growing very quickly, plus the more it grows, the more it grows due to network effects. The growth will be exponential as soon as one, real killer app emerges (ERC 721 is a possible candidate in my opinion). To anyone reading the above answer, you might want to take some of it with a grain of salt. Commented May 31, 2018 at 9:37
  • Think about it. Do you really think that a cryptocurrency that fluctuates it's value between a 5% to a 30% of it's value every day is tha way on which people will come to the blockchain? By the other hand, it doesn't matter how big the chain is, only a few full nodes are required, the rest can be light clients with the same capacity to validate blocks. So (even thinking that we will arrive to 1TB soon (which is ridiculous nowadays, and by the time we arribe, solutions will be implemented )) it won't be a problem.
    – CPereez19
    Commented May 31, 2018 at 9:46
  • To add also that ERC721 is not the key here, maybe other implementations like a derivation of the ERC725 will achieve it. But not the 721. Also add that "very quickly" as you say, doesn't mean quickly on this scenarios where we are nowadays.
    – CPereez19
    Commented May 31, 2018 at 9:49
  • 1
    A full Ethereum archive node is already more than 1TB. Having "a few full nodes" sounds seriously centralized, so that's not viable. Plus--I was only saying that readers of the above answer should be aware that the statements you make are unsupported. Trust me--I've thought about this for a very long time, so your admonition for me to "think about it" is unnessassary. Commented May 31, 2018 at 9:51
  • 1
    Sorry. I apologize. Just wanted to temper your answer. Commented May 31, 2018 at 10:53

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.