ADR: First Implementation of a Storage Node

[evan-forbes]

Summary

We need to decide which type of storage node to implement first, full node based or light client based, and then create an ADR for that type of storage node.

Details

Storage nodes have two main categories of responsibilities. First, to hold and serve some portion of the block data for the purposes of data availability sampling. Second, to help create and distribute fraud proofs. Overtime, there will likely be a wide variety in the types of storage nodes that exist, but those two pillars of responsibility will remain steadfast.

Storage nodes will either be a full Celestia node, or a light client to a full Celestia node. Either type of these storage nodes could also keep some portion of block data. For simplicity’s sake, the first storage nodes that we create will archive the entirety of the block data for a Celestia chain, but in the future there will also be storage nodes that only archive arbitrary sections of the block data.

The next step from an implementation perspective is to decide if we first want to make a storage node that is a full Celestia node, or a storage node that is a Celestia light client. If we want to make a full node based storage node, then we should figure out a suitable storage API for the full node to interact with. If we want to make a light client based version first, then we should modify/configure a standard tendermint light client to subscribe to block data from a full Celestia node.

After we decide on the type of storage node that we are going to implement first, we should create an ADR that describes in more depth what is actually needed for that first implementation. This will likely consist of calling PutBlock, as described in #427, and then scheduling for periodic providing of that block data.

References and Context

[liamsi]

The next step from an implementation perspective is to decide if we first want to make a storage node that is a full Celestia node, or a storage node that is a Celestia light client.

The decision made on our offsite is that a Celestia node will run alongside with a core node and interact with it via the public APIs tendermint exposes (RPC seems like the best approach for now). I'm closing this, as this will be dicsussed in more depth as part of celestiaorg/celestia-node#1