Node types in Ethereum 2.0


From the Sharding FAQ:

"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."

I have a few questions in the context of Eth 2.0:

  1. Why do these super-full nodes have to verify all transactions (the main chain + all the shards), it will take a LOT of resources and I don’t see the point? Storing everything makes sense (it ensures data availability of all the data), but it will also require a lot of disk space and bandwidth?
  2. I don’t get what/why these top-level nodes do?
  3. The single-shard nodes get periodically reshuffled. How do they “hand over” the data to the next elected node?
  4. So light clients only download the main chain headers (main chain = beacon chain, right? :slight_smile: )?

Is this all maybe outdated (things have changed/will change now when we merged Casper and sharding)?

Thanks! :slight_smile:

  1. These aren’t nodes that have to be run. These are just the possible nodes that can be run. In the case of having a super-full node, some staking pools might want to do that so they don’t have to resync to a different shard each cycle for each validator.

  2. They only validate the beacon chain, so they only have access to headers of shards and do not actually validate shard transactions or process shard blocks.

  3. They generate collations and add them to the shard chain. That’s like asking how do Bitcoin miners hand off data to the next Bitcoin miner.

  4. Yes.


Not necessarily, only validators are being shuffled, “normal” single-shard nodes (e.g. from users who are interacting with some contract on that shard) can stay on one shard permanently.


Thanks @meyer9 and @jannikluhn. :slight_smile:

If we don’t have these super-full nodes, how can we guarantee the data availability of the entire system (what if e.g. a single shard gets corrupted or attacked and we don’t have its data anymore)?

What’s the point/reason for having nodes that do only this? I was thinking that every single validator needs to do this (validate the beacon chain and keep track of all the shards’ headers) anyway, I though of it as some default, base level function?

I believe this comparison makes no sense. If I got it right, “single-shard nodes” are referred to as operators in this presentation by @JustinDrake, and it’s clearly stated that they are being reshuffled e.g. once per week (Bitcon miners/nodes are not being reshuffled). That said, it’s clear that, when the new group of validators is selected, the old operators (single-shard nodes) should “hand over” all the shard data (the whole chain) to the new operators (they don’t have this data, they only have that shard’s headers). Now when I think about t, the problem is even deeper than I originally thought, I might start a new topic on it.

Can you please share where did you get the information that only validators are being reshuffled? That would completely change the model and introduce completely new challenges/concerns (I can go into more details if this is confirmed). And of course, we can have permanent single-shard nodes run by users, but those are irrelevant for the analysis (not mandatory/guaranteed + not staked -> can not be relied on).


Because of shuffling, there’s a strong probabilistic guarantee that a single shard can’t get attacked or corrupted without basically an attacker having close to 50% of the entire validator set, and if/when we add fraud proofs and data availability proofs, the entire network will be able to reject bad blocks without checking all of the data.

Can you please share where did you get the information that only validators are being reshuffled?

From me :slight_smile:

Any node that is not a validator is a node that is simply being run for its own user’s benefit, so that node can of course listen to and download or not download and check or not check whatever it wants. So the protocol has no ability to compel these other nodes to go on any specific shard, and no reason to.


Oh, than I’ll consider that information pretty reliable! :smile: So that means that Sharding FAQs and the Justin’s presentation (or at least their parts) are deprecated?

I think mentioning these user-run nodes just brings confusion, they’re irrelevant because they (as you and I both said) offer no guarantees on anything at all, they are unbonded and might or might not validate and/or keep any shard’s data (or arbitrary portions of it). Validators must not rely on these nodes at any moment, they need nodes that are bonded and will/must validate every shard collation and keep all the shard’s data (the whole, up-to-date shard chain). How many of these nodes will we have per shard? If it’s one, there are several concerns, if it’s more than one, there are several other concerns (again, I can go into more details if I have this answer). :slight_smile: If these things are still not fully specified, it’s understandable, of course.


One detail to keep in mind is that the “light clients” for sharding will likely also have the responsibility of uploading data to full nodes, not something that you’d typically think of as a light client duty. To quote Vitalik et al’s recent light client spec, which I assume uses the same data availability mechanism as eth 2.0: “Each share and valid Merkle proof that is received by the light client is gossiped to all the full nodes that the light client is connected to if the full nodes do not have them”

I think mentioning these user-run nodes just brings confusion

I’m no expert on the game theory here, I’ll just point out that 100% of bittorrent nodes are unbonded and have no duty to serve up data or validate: Default behavior of software (plus a few altruists) can lead to a powerful mechanism with meaningful effects on a distributed software system.


Thanks @drcode1! :slight_smile:

Exactly, and BitTorrent is the perfect example of an unreliable distributed network (everyone experienced unavailable torrent links). The same goes for IPFS, that’s why Filecoin is being built (you need bonded people that have to keep the data if you want to offer guarantees on that data being available, and even then the problem is far from trivial). And that is exactly why I consider these user/altruist-run nodes should not be relied upon at all, i.e. they shouldn’t even be considered when discussing safety and guarantees of the system.

That said, I would still really like to know:

a) are we going to have bonded single-shard nodes (nodes that have to download and keep all the data of a single shard),
b) are we definitely not going to reshuffle them,
c) are they the same thing/entity as proposers (they propose blocks/collations and validators vote on them),
d) how many of them will we have per shard?

I’ve just watched an awesome presentation on Ethereum networking by Peter Szilagyi and Felix Lange, and here you can see that the plan at the time was for collators to constantly switch shards (it it’s unclear whether or not collators are the same as proposers/single-shard nodes, though :slight_smile:).


Very good questions! I’ve been wondering about exactly this topic for quite some time now and I would like to offer some answers that are purely my opinion and intuition for now:

a) Yes! I don’t see another way to guarantee long-term data availability
b) Depends. As of now, I don’t think it would be required to reshuffle them in practice, but I feel like for guaranteeing provable liveness, reshuffling might be necessary. Otherwise a bribing attacker might be able to entirely stall a shard by never proposing any collation to vote on.
c) Yes! I think the highest synergy effect (and therefore efficiency) could be achieved by combining the responsibilities of long-term state storage + execution of transactions + proposing of collations into the same role.
d) That’s an interesting and open question. If we don’t “assign” or “shuffle” (let’s call them) executors, then we have no control over this anyway and it’s up to economic incentives to achieve a reasonable distribution over all shards. If we do assign them, I have not thought about reasonable numbers yet.


Thanks for the comments @daniel! :slight_smile:

I agree with most of the things you wrote. :slight_smile:

From the research standpoint, d) (number of single-shard nodes per shard) is particularly interesting. If we have one, it’s a SPOF of every shard :see_no_evil:; if we have more, a very interesting problem of syncing and coordination is introduced (if this is not solved properly, we can actually end up with “multiple SPOFs” per shard, i.e. any of these nodes can permanently halt the shard :see_no_evil::see_no_evil:). Polkadot, for example, has multiple “collators” (their version of single-shard nodes) per “parachain” (their version of sidechains, quite similar to Eth shards); I’ve discussed this problem with them and they still don’t have the solution (it’s still an open problem).

And yes, in my previous post I forgot to put: e) are we having these super-full nodes (nodes that store every collation of every shard)? :slight_smile:


d) Definitely more than 1. Since validators don’t verify the computational results of executing a transaction, every shard needs at least one executor who was not the proposer, so incorrect results can be challenged. Two is still very low speaking in terms of fault tolerance, however a reasonable number depends a lot on the incentive mechanism given to executors for joining a shard (if we allow them to) or for becoming an executor in the first place (if we assign executors in the protocol as we do with validators). I would be very happy to hear any ideas and thoughts on this :slight_smile:

d.2) I don’t think we would end up with multiple SPOF in this construct. My suggestion would be to require (or incentivize) every executor in shard X to keep up to date with the entire state in shard X. They will be able to acquire the current state the same way full nodes currently do in Ethereum 1.0. Executors are generally implicitly incentivized to

  1. Keep the entire state available for themselves in order to not restrict themselves from which transactions they can execute
  2. Freely share the state in order to enable users (which we assume most will be light clients) to send transactions, which is required to give them something to execute in the first place

e) I guess we will have them, but they are not required or incentivized by the network / protocol itself. Requiring supernodes for the network to function kind of defeats the whole purpose of sharding and poses a great centralization risk. However, some project like might be interested in running a supernode for external motivations.