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