Storage node & protocol

[sync-by-unito]

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
d) light clients that use data availability proofs

┆Issue is synchronized with this Asana task by Unito

[sync-by-unito]

➤ Ismail Khoffi commented:

> 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: celestiaorg/celestia-specs#22 ( celestiaorg/celestia-specs#22 ) and #35 ( #35 )

[sync-by-unito]

➤ Mustafa Al-Bassam commented:

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.