Draft: EVM node: Decouple proposal submission from preblock monitoring

What

A complete rework of the EVM node when running in threshold encryption sequencer mode. The new workflow is asynchronous, in that submitting a proposal and receiving a preblock are handled by separate components. Because a proposal can only be submitted once the blueprint corresponding to the latest proposal has been applied into the EVM state, coordination is needed between these two components. The new workflow can be summarised as follows:

• A proposal handler is responsible for receiving requests to submit proposals to the DSN node. Upon receiving a proposal request, the proposal handler will insert it in a queue.
• The proposal handler submits a proposal to the DSN node only when it has detected that the previous proposal has been processed. This means that either (a) the proposal was not submitted because the tx pool is blocked or there are no transactions in the tx pool, or (b) the preblock monitor has received a new preblock, a blueprint has been created from it and it has been applied to the EVM state.
• The preblock monitor monitors both notifications that a blueprint has not been submitted from the proposal handler, or for a new preblock from the DSN node, and provides a function for pulling the next preblock event,
• Access to the preblock monitor is guarded by a Lwt_mutex.t. This is because different components (the main threshold_encryption_sequencer_loop, and the produce_block RPC handler) compete for access to the preblock monitor,
• The main sequencer loop is modified a request to submit a proposal to the proposal handler, after which it waits for a preblock event from the preblock monitor. If a preblock has been generated, the blueprint is constructed, applied and published. Otherwise, the sequencer loop waits for 0.5 seconds before retrying,
• The produce block RPC has been modified similarly, but both the request to submit a proposal and monitoring for the preblock event are placed within a single critical section. This is to avoid a scenario where the main sequencer loop "steals" a preblock event from the produce_block RPC handler, after it has sent requested to submit a blueprint.

TODO: The following improvements will be handled in future MRs.

• Handling timeouts. If the sequencer does not receive a preblock within a given time limit, it must trigger a reproposal. This opens the possibility of preblocks arriving late. We can check on the preblock number to see whether a blueprint with the same number has been applied already, and discard the preblock if that is the case,
• Discarding preblocks means that transactions from the Tx pool can be lost. The Tx pool (for the threshold encryption sequencer only) needs to be reworked so that transactions are removed only after a blueprint has been applied,
• Disconnections to the dsn node must be handled
• In the case the EVM node crashes, it must catch up and request preblocks (with current workflow, at most one) it might have missed from the DSN node,
• Shutdown logic for the preblock monitor
• Adding events and logging information to make the Threshold encryption sequencer node production ready.

Why

Because the design of threshold encryption requires several changes to the way the sequencer works. The main change that this MR addresses is that blueprint production will happen at network speed. It also paves the way to handling timeouts and having to do reproposals.

How

By reorganising the structure of the EVM node when in threshold encryption mode.

• By reworking the "Threshold_encryption_blueprints_producer" module into a "Threshold_encryption_proposals_handler", which is responsible only for submitting proposals to the dsn node when it is possible to do so (the EVM node has applied the latest blueprint),
• By implementing a new "Threshold_encryption_blueprint_monitor" module, which is responsible for monitoring preblocks events from the DSN node and the Threshold_encryption_handler,
• By moving the logic for constructing blueprints out of the Threshold_encryption_blueprint_producer back into the Threshold_encryption_block_producer, and by modifying the latter to receive a preblock in input to the requests to produce blocks

Manually testing the MR

Then tests can be run with

make
make octez-dsn-node
dune exec etherlink/tezt/tests/main.exe -- --file evm_sequencer.ml threshold_encryption

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR