api: What should be surface of celestia-node API in relation to the state machine?

[liamsi]

What should be surface of celestia-node API in relation to the state machine?

This discussion covers two related questions. One is about the shorter-term scope of the "state" module in the current node, the other is more forward looking:

1. What should be the scope of the current "state module", e.g. in the next v0.15.0 release? https://node-rpc-docs.celestia.org/?version=v0.13.7#state
2. Longer term, should celestia-node provide an API to submit any transactions that celestia-app supports (besides PayForBlobs ofc)? If yes, should it support all txs or just a subset?

1: Current state module

The current state module includes the following methods:

Particularly, the write methods are just a subset of what celestia-app supports. It is very unclear if anyone uses them. Rollups devs are mostly concerned with a small subset of the currently exposed API. A lot of the methods like delegating/unbonding etc are usually a manual process and not the right place for an API for developers. Not to mention that a lot of actual users will use ledgers to initiate these (which is still not possible).

Proposal

I would recommend to remove all "writing" methods from the API and only keep those that query state and SubmitPayForBlob.

2: Long Term

(In the absence of a celestia-node native mempool,) should node expose state machine related APIs at all? IMO, yes but then they should be separate from the developer-facing API and instead be in a separate API for "power-users".

Also, ideally, the methods would be mere proxies to the existing (grpc) API of celestia-app and the cosmos-sdk instead of some simplified version of them (see screenshot in point 1.). That is somewhat related to the point about a signing API / key management raised here: #3022 (comment)