ADR: DAS node-types aka partial nodes

[liamsi]

Summary

Similar to the ADR for the DAS light-client, we should describe the modifications required for other DAS node-types.

Details

Some aspects are better described in separate focused ADRs. See:

• Block Propagation
• Block Sync
• Fast Sync

Everything else that isn't already covered by these other ADRs, should still be captured in the ADR this issue is about. Including added command-line flags and config options. Non-exhaustive list of these:

• boolean flag: full-body or partial body (maybe with more descriptive names)
• for "partial-body": how much data / how many samples (in total?, per block?)

Other implications, like the inability to serve full block via RPC (related: #189, #195)

[adlerjohn]

Note that the currently-used nomenclature is that:

• full nodes fully download blocks
• partial nodes do DAS and additionally fully download a configurable subset of blocks

So this ADR might be better named "partial node" rather than "DAS full node."

[liamsi]

Thanks, @adlerjohn. I updated the title and the description. As discussed on a sync call this was coming from the perspective on how to modify the existing tendermint fullnodes and prep for DAS. My understanding (also from discussions with @musalbas e.g. here and on calls) was that this should be the immediate next priority. It is debatable if partial nodes need to "participate in consensus" (meaning running the consensus reactor that deals with these messages and basically also running the same code as validators without actively signing messages). It would be good to have a clear decision on this before we move in one or the other direction.

Here is a full overview of the reactors a regular tendermint fullnode runs: https://github.com/tendermint/tendermint/blob/de5cf42ed5ab19d93a4da48b33454f32c1c899d6/docs/architecture/adr-052-tendermint-mode.md#decision

Some of the modes (node-types) in the above ADR should also end up in the specs. Or at least their relation to our node-types IMO. I'll open an issue about this in the specs repo shortly.

[liamsi]

closing this in favour of #435