Further clarify relation of abci-app in the embedded case

[liamsi]

Summary

ADR-001 described the relation between node and core+abci-app. Since then, there was a slight pivot to embed the tendermint process in node directly (ADR-002). ADR 002 does not yet clearly describe how the abci-app fits into the equation.

Gain

No doubt on the relationship between node and abci-app and which components "drives" which. Also, the implications for the user interface (on the command-line) if any should be clarified.

Evidence

#97 (comment)

Implementation ideas

Previously the idea was that the app binary would be used to init core and the app. Now that node embeds the core node, it seems to be necessary that the node exposes the same cli as the app. This needs to be done in a way that does not require writing a lot of code (ideally, the corresponding commands are just "passed through" to the cli of node, similar to how the app, exposes the tendermint node's cli already).

Urgency

High

[Wondertan]

From the attached comment.

The original idea was that core/app and node are different processes and communicate with each other only via RPC. Sure that would have meant running to binaries but the relation would have been very clear: app and core would run in one process and node in another. form the pov of node, app and core would have looked the same.

The approach of splitting different components into different processes is right and we should aim for it. The thing is that we should do it more horizontally rather than vertically. By this I mean we should have different processes for different heavy-weight components like mempool and consensus, with clear API boundaries between them. This is also aligned with @musalbas's vision about future validators being a whole data center where independent machines are responsible for some specific role. The current Tendermint state does not allow us to do so, which is fine for now and we can have one process doing all the things.

Now that node actually embeds core, we need to clarify the relation to the state-machine further. Is it the node that "drives" everything?

Yes. And I think it is fine for us now to run it in the same process as we need to run our application only. Further, we can make the app in the Node swappable in the slow process of molding optimist and celestia-node together.

Now that node embeds the core node, it seems to be necessary that the node exposes the same cli as the app.

👍🏻 As long as we have only one app in celestia-node we can simply import commands from defined in app repo.

[liamsi]

Didn't we remove the embedded case for now? can we close this then?

[renaynay]

Yes @liamsi

[renaynay]

However, we will be revisiting the concept of embedding celestia-app once we think about how full nodes can serve state.