Further clarify node-types

[liamsi]

Summary

Currently, node-types are mostly defined by the data they process. While this gives a relatively good idea of what the different node-types are, it does not really inform the implementation as there are open questions around what the node-types actually do.

Suggestions

Think of the node-types more from a less theoretic perspective and fully clarify their roles and responsibilities in the network beyond what the current definitions cover (data and fraud proofs only).

Action Items

• make the node-types section a table #183
• clarify what other network messages a node-type is intended to process/gossip etc (e.g. consensus messages and others) and if this is optional or not
• clarify further node types and their relation in the network that are not yet covered (e.g. seed nodes, sentry nodes, etc)
• if not obvious after the above is done: clarify the relation to the node-types in the specs and existing tendermint "modes" (not sure if this belongs in the specs or rather an adr but we really need this; either way, tracking it here as it should obviously be thought about when writing the specs too)
• this all must result in an overview diagram (!) (could come first actually as it is way easier to discuss and faster to draft than writing a lot of text)

Related

• storage nodes node types: storage nodes #175 and protocol Storage node & protocol #3
• partial nodes adr issue: ADR: DAS node-types aka partial nodes celestia-core#388 (comment)
• Block Data Gossiping celestia-core#384 (comment)
• Make consensus messages DA ready celestia-core#181 (comment)
• Decide if the nodes should repost data to IPFS by default celestia-core#279

[evan-forbes]

Just to spark discussion and for my own clarification, I have a few questions.

1. From what I can tell, the only nodes that do not need the full commit, DAH, and header are the superlight nodes(no bodies), which do not need the DAH. Is this correct? Which of these nodes are participating in gossiping consensus messages as opposed to simply subscribing to a header/commit/dah from a full/partial node?

side note: If we begin to propagate the DAH via IPFS, then this changes as we no longer need to include the DAH in consensus messages as the DataHash will be included in the Header, and the DAH can be downloaded with that. Then the question is how much time does downloading the DAH from IPFS add to each node’s operations and if that added time is worth not including the DAH?

2. As for how each node will be bootstrapped, the only nodes that do not need some form of seed and DHT bootstrapping nodes are again the superlight nodes. Is this correct?

3. What are the security differences between a partial node that downloads 1% block data and 24%, if any? (If it downloads the right 25% of block data, then it’s basically a full node that doesn’t repair the entire square.)

[evan-forbes]

and to forward the more detailed questions from @liamsi

Which nodes care about consensus messages (proposals, votes etc)? (I think this will be answered by the answer to question 1 from the above comment)

Which only care about the headers the moment they are proposed?

Which only care about signed headers (headers plus signatures, plus validator sets)?