Struct Engine 

pub struct Engine<E: Clock + CryptoRng + Spawner + Storage + Metrics, S: Scheme<D>, L: Config<S>, B: Blocker<PublicKey = S::PublicKey>, D: Digest, A: CertifiableAutomaton<Context = Context<D, S::PublicKey>, Digest = D>, R: Relay<Digest = D, PublicKey = S::PublicKey, Plan = Plan<S::PublicKey>>, F: Reporter<Activity = Activity<S, D>>, T: Strategy> { /* private fields */ }

Instance of simplex consensus engine.

Implementations

impl<E: Clock + CryptoRng + Spawner + Storage + Metrics, S: Scheme<D>, L: Config<S>, B: Blocker<PublicKey = S::PublicKey>, D: Digest, A: CertifiableAutomaton<Context = Context<D, S::PublicKey>, Digest = D>, R: Relay<Digest = D, PublicKey = S::PublicKey, Plan = Plan<S::PublicKey>>, F: Reporter<Activity = Activity<S, D>>, T: Strategy> Engine<E, S, L, B, D, A, R, F, T>

pub fn new(context: E, cfg: Config<S, L, B, D, A, R, F, T>) -> Self

Create a new simplex consensus engine.

pub fn start( self, vote_network: (impl Sender<PublicKey = S::PublicKey>, impl Receiver<PublicKey = S::PublicKey>), certificate_network: (impl Sender<PublicKey = S::PublicKey>, impl Receiver<PublicKey = S::PublicKey>), resolver_network: (impl Sender<PublicKey = S::PublicKey>, impl Receiver<PublicKey = S::PublicKey>), ) -> Handle<()>

Start the simplex consensus engine.

This will also rebuild the state of the engine from provided Journal.

Network Channels

The engine requires three separate network channels, each carrying votes or certificates to help drive the consensus engine.

vote_network

Carries individual votes:

• Notarize: Vote to notarize a proposal
• Nullify: Vote to skip a view
• Finalize: Vote to finalize a notarized proposal

These messages are sent to the batcher, which performs batch signature verification, assembles certificates from valid votes, and forwards proposals, certificates, and timeout hints to the voter.

certificate_network

Carries certificates:

• Notarization: Proof that a proposal was notarized
• Nullification: Proof that a view was skipped
• Finalization: Proof that a proposal was finalized

Certificates are broadcast on this channel as soon as they are constructed from collected votes. We separate this from the vote_network to optimistically allow for certificate processing to short-circuit vote processing (if we receive a certificate before processing pending votes, we can skip them).

resolver_network

Used for request-response certificate fetching. When a node needs to catch up on a view it missed (e.g., to verify a proposal’s parent), it uses this channel to request certificates from peers. The resolver handles retries and peer selection for these requests.

All three channels must be scoped to this engine’s epoch. A message from another epoch blocks the sender on the vote and certificate channels, and the resolver rejects it as invalid, which also blocks the peer.