fill out more faq

docs/architecture/adr-023-multiplexed-app.md

@@ -3,6 +3,7 @@
 ## Changelog
 
 - 2024/10/14: Initial draft (@rootulp)
+- 2024/10/20: Expand on alternative options (@rootulp)
 
 ## Status
 
@@ -11,11 +12,11 @@ Draft
 ## Glossary
 
 **Single binary syncs**: the ability for a single binary to sync the entire history of the chain from genesis to the most recent block.
-**Donwtime-minimized upgrades**: the ability for the network to upgrade app versions within the expected block time (i.e. 12 or 6 seconds).
+**Donwtime-minimized upgrades**: the ability for the network to upgrade app versions within the expected block time. The expected block time for app versions 1 and 2 is 12 seconds. The expected block time for app version 3 is 6 seconds.
 
 ## Context
 
-Celestia-app v2.x and v3.x binaries support multiple versions of the state machine. This capability is necessary for single binary syncs and downtime-minimized upgrades. The current implementation of this feature involves conditionals littered throughout the codebase to perform version-specific logic. This ADR proposes a new design that abstracts the version-specific logic into separate Go modules (i.e. `celestia-app/v2`, `celestia-app/v3`). Each module will contain an implementation of the state machine for a particular app version. In other words `celestia-app/v2` will not contain any conditional statements to implement features in v3 and vice versa. A multiplexer will be responsible for routing ABCI messages to the appropriate module based on the app version.
+Celestia-app v2.x and v3.x binaries support multiple versions of the state machine. This capability is necessary for single binary syncs and downtime-minimized upgrades. The current implementation of this feature involves conditionals littered throughout the codebase to perform version-specific logic. This ADR proposes a new design that abstracts the version-specific logic into separate Go modules (i.e. `celestia-app/v2`, `celestia-app/v3`). Each module will contain an implementation of the state machine for a particular app version. In other words `celestia-app/v2` will not contain any conditional statements to implement features in v3 and vice versa. A multiplexer will be responsible for routing ABCI messages to the appropriate Go module of the state machine based on the app version.
 
 ## Decision
 
@@ -25,15 +26,34 @@ TBD
 
 ![multiplexer-diagram](./assets/adr023/multiplexer-diagram.png)
 
-As a prerequisite to this work, Go modules must be extracted for all state machine modules. This is necessary so that the types defined by one module do not conflict with the types defined by the same module imported via a different state machine version.
+As a prerequisite to this work, Go modules must be extracted for all state machine modules (e.g. `x/blob`, `x/mint`). This is necessary so that the types defined by one module do not conflict with the types defined by the same module imported via a different state machine version.
 
-How the protobuf registry will work in this setup or any other globally defined variables?
+### Potential issues
 
-TBD
+1. The protobuf registry. There exists a protobuf registry where proto types are registered via auto-generated code. For example, `celestia-app/x/blob/types/tx.pb.go` contains:
 
-How ABCI might change (i.e. when we use a later version of the SDK we might have VoteExtensions and FinalizeBlock)?
+    ```go
+    func init() {
+        proto.RegisterType((*MsgPayForBlobs)(nil), "celestia.blob.v1.MsgPayForBlobs")
+        proto.RegisterType((*MsgPayForBlobsResponse)(nil), "celestia.blob.v1.MsgPayForBlobsResponse")
+    }
+    ```
 
-TBD
+    In order to avoid warnings of the form: `proto: duplicate proto type registered:`, we must define repeat Protobuf types in distinct packages (for example: `celestia.blob.v1.MsgPayForBlob`, `celestia.blob.v2.MsgPayForBlob`)
+
+2. The Cosmos SDK interface registry. There exists a Cosmos SDK interface registry that contains a map from typeURL to protobuf message. For example `celestia-app/x/blob/types/codec.go` contains:
+
+    ```go
+	registry.RegisterImplementations((*sdk.Msg)(nil),
+		&MsgPayForBlobs{},
+	)
+    ```
+
+    In order to avoid registering duplicate messages, we can de-duplicate the Protobuf messages defined in state machine modules by extracting them into Go modules.
+
+3. How to handle changes to the ABCI interface? For example, when we use a later version of the SDK we might have VoteExtensions and FinalizeBlock.
+
+    We can add new methods to the ABCI interface that the multiplexer implements but older state machines will have no-op implementations for these methods.
 
 ## Alternative Approaches