Consider potentially merge celestia-node with celesia-app

[liamsi]

Summary

If we decide to to go down the abci++ route earlier than later, it is worth considering and deciding if we want to move the DA logic into the statemachine logic.

Gain

Main benefits are:

• tendermint can potentially be treated even more as a blackbox; we could even use vanilla tendermint (maybe just adding abci++ earlier than upstream through)
• potentially one binary less
• compute the erasure coding only once per actual consensus full node (in this repo now sometimes referred to as bridge nodes

Context

• ADR for switching to ABCI++ early celestia-app#156
• ADR001: Adopt ABCI++ Early celestia-app#157

Implementation ideas

The current celestia-core fork is necessary because we need:

1. modify the mempool txs before proposing a block (split up into state relevant txs and message blobs)
2. take the block data, split it up into shares
3. erasure code the block
4. compute the data root using an NMT and by introducing a DA header

(1.) is already not possible without modifying abci (see this ADR in core for more details.

2.-4. also currently require us to do changes in tendermint because we want the validators to commit to the erasure coded data (instead of the vanilla tx data as in vanilla tendermint).

ABCI++ could allow the following instead:
Continue doing 1. as before in the app/state machine.
Do 2.-4. also also exclusively in the state machine/app.

Proposers run the PrepareProposal step (in the app do step 1.-4. above and feed back the data root into the header somehow), every other consensus node additionally runs ProcessProposal (to verify the data root is actually correct).

Additionally, in this alternative design, the abci app now also ensures that the data is stored in a sampling friendly fashion and the state machine could now directly be the software artefact that is responsible for serving shares to sampling nodes (or non-consensus participating full nodes, and later, partial nodes). Previously that wasn't something we considered because the assumption was that tendermint will have to compute the data root (as it falls into tendermint's responsibility currently).

And that last part (computing the data root) stays the only a bit ugly way because: vanilla tendermint would still compute the data root.
There are two ways we could deal with this: either, still modify tendermint slightly to let the app compute the data root, or, way less invasive: use the app_hash in the header for that. The app_hash can be arbitrary bytes and it could contain essentially both: the state root and the data root.
Celestia light nodes would ignore the data root that tendermint produces but use the data root in the app_hash instead.

Pinging @evan-forbes for awareness here too.

Urgency

Medium

Note, that this is probably out-of scope for test-net as this is also somewhat blocked on celestiaorg/celestia-app#156.

But after this is build in the app, we should revisit this! Maybe for incentivized test-net.

[evan-forbes]

But after this is build in the app, we should revisit this! Maybe for incentivized test-net.

agree. Only doing the erasure step a single time would be a huge optimization, and consolidating the number of binaries would be a welcome change for most imho.

I also agree that I think the best strategy is to get abci++ working first, then move erasure to the app, then possibly consolidate.

[Wondertan]

In the most recent discussions, we agreed that long-term, we want to reverse the dependency between App/Core and Node, s.t., App/Core depends on the DA network, similarly to a Rollup network depending on DA.

As a first step short/mid-term, we decided to:

• Rename BridgeNode to ValidatorNode
• So that celestia-node embeds and setups the App/Core node
• With celestia-node being the storage backend for the App/Core

This first step brings us the first benefit of the long-term dependency switch: storing and computing the EDS only once per validator, as well as sharing the single syncing mechanism between node and App/Core

cc @cmwaters