docs: draft ADR 023

[rootulp]

Related to #3729

[rootulp]

I'm not sure what to add here. My next step is to repeat module extraction for the remaining state machine modules so maybe we can potentially merge this as-is and then I can update it when I resume work on the prototype after all the state machine modules are extracted.

[cmwaters]

Thanks @rootulp for writing this up. I think this is a good start and we can add to it as necessary. For example, this misses details on:

• How the protobuf registry will work in this setup or any other globally defined variables
• How ABCI might change (i.e. when we use a later version of the SDK we might have VoteExtensions and FinalizeBlock)

It would also be nice if your diagram showed a venn diagram of modules i.e. v3 can have overlap but also a different subset of modules.

Also in practice v1, v2 and v3 will probably be rolled together as a single state machine and v4 will be a different set of dependencies etc.

[rootulp]

Two variants on the current design proposed by @tac0turtle:

1. Extract old state machines to run out of process so they aren't contained in the latest app binary

   

2. Extract celestia-core to run out of process from the multiplexer

   

[rootulp]

this misses details on:

Agreed, added those questions to the ADR.

It would also be nice if your diagram showed a venn diagram of modules i.e. v3 can have overlap but also a different subset of modules.

Added a module unique to v4.

Also in practice v1, v2 and v3 will probably be rolled together as a single state machine and v4 will be a different set of dependencies etc.

Good call, updated the diagram to v3 and v4.