Simplex internals and whether a more explicit deterministic protocol core would fit the current design

[diegomrsantos]

Hi, I’ve been reading through Simplex and had a design question.

From the docs, my understanding is that the current split between Batcher, Voter, Resolver, and Application is intentionally non-blocking, so consensus can continue progressing while verification, proposal construction, or artifact fetching are still in flight, and the Automaton boundary is already async. 

I’m curious what the main reasoning was behind this shape of the internals, and whether maintainers see it as the right long-term boundary.

The reason I’m asking is that I wonder if there is room for a more explicit deterministic protocol core underneath the current architecture — not replacing the async shell, but making the safety-critical logic operate as deterministic transitions over protocol state and events, while timers, relay, WAL, verification, proposal construction, and fetching remain outside.

My motivation is that deterministic runtime is great for testing task interleavings, but protocol bugs themselves may be cheaper to reproduce and understand when core protocol decisions are expressed through explicit deterministic event scheduling. The async glue could still be tested with the deterministic runtime, so you keep both worlds.

Mostly trying to understand whether that sounds directionally aligned, or whether the current design is already considered the right abstraction boundary.