Storage node & protocol

[liamsi]

We need to define the public API and the protocol to interact with a storage node.

This also plays into data availability (which might be started being spec'ed out in #2) as consensus participants (validators) that do not want to be storage nodes themselves will need to query them for data availability.

Quoting musalbas here:

So there should be an option to run:
a) validator that is also a storage node
b) storage node only
c) validator that just uses data availability proofs(update: not planned anymore)
d) light clients that use data availability proofs

[liamsi]

c) validator that just uses data availability proofs

Question: this was still assuming that there is no state in the LL main chain? Wouldn't validators still verify validity of transactions while they could only use data availability proofs for the messages the transactions pay for (@musalbas).

also ref: #22 and celestiaorg/celestia-core#35

[musalbas]

I consider the LL token app to logically be an optimistic rollup sidechain. Therefore validators can just download the latest state root for it and accept state transition fraud proofs.

[liamsi]

Update on the above: while you could still argue that the LL token app will be treated as an ORU chain in the sense that clients could accept state transition fraud proofs, this does not hold for validators who will download all Tx (and actually all block data) and hence do not need to care about state fraud proofs.