In Trantor, solution c) could be run one per iteration of PBFT or one per iteration of ISS. In the former, we optimize finding disagreements as soon as they happen, in the latter, we optimize throughput. Given that extra communication does not meaningfully takes place in the common case (see next comment), probably the former is the way to go.

If there has been a disagreement, then this extra accountability module receives a certificate that contains equivocating messages. If that occurs, then the accountability module should immediately notify the application layer, and run a reconfiguration followed by a recovery that finds and resolves possible disagreements, at the end of the current ISS iteration. The application layer should not deliver any received output since it is notified of the found disagreement and until it receives the new configuration and the recovery data.

Implementing solution c) -> Added accountability module
The critique of the general solution c) (which can be applied to all cases and ensure accountability) is (i) that a set of deviants (malicious replicas, either Byzantines or rational) that caused a disagreement in the consensus module can decide to give up in the accountability module; and that (ii) the known optimal solution requires implementing threshold signatures.

(i) is not a huge drawback, because if that occurs then the protocol terminates deciding no disagreements, which is not that bad really. As for (ii), a solution that does not require of threshold signatures consists of a pull approach in the following manner:

Step1- replicas broadcast to all their decision from the consensus module (signed)
Step2- if a replica $p_a$ receives a signed decision $v'$ from replica $p_b$ different from its local decision $v$, then $p_a$ sends to $p_b$ the certificate $cert_v$ containing a strong quorum of signed messages it receives from other replicas alleging deciding $v$.
As a result, $p_b$ either:

• Never really outputs $v'$ (does not receive a strong quorum for $v'$), or it can create fraudproofs once it receives $cert_v$ from $p_a$ (by finding equivocating messages from replicas in $cert_v$ and $cert_v'$.

Assuming pairwise channels between replicas, this provides the same optimal bit complexity per channel as regular consensus in the common case (t<n/3 deviants, malicious replicas) in all channels involving 2 correct replicas, though deviants can increase the number of bits sent to them (channels from correct to deviants). This can be solved with threshold signatures only in the general module. Below I detail how to reduce this requirement a notch if we specify the solution for Trantor.

Implementing solution c) specifically for Trantor
For Trantor's implementation of PBFT, the above solution works like a charm if slightly more coupled to the orderers module (without threshold signatures). This is because if we just require the leader to sign its preprepare and require that replicas share in Step1, along with its signed decision, the signed preprepare from the leader, then this means that if somebody sends a certificate in Step2 at least the leader will be found guilty of this disagreement attempt. The fact that someone in the deviating coalition will suffer the effects of the extra communication overhead is enough of a deterrent (once we have slashing of collateral in place).

Implementing solution b)
However, if we decided to not implement c), then we could still get accountability specific for the Orderers module in the following way:

• Require preprepare and prepare messages to be signed
• Require replicas to attach to their commit messages the signed preprepare from the leader
• If a replica ready to send a commit for proposal $v'$ receives a commit message from $p_b$ with a matching and correctly signed preprepare from the leader for proposal $v$ (i.e. $cert_v$), then send to $p_b$ its local strong quorum of signed prepare messages signing for $v'$ (i.e. $cert_v'$), and broadcast to all the fraudproof of the leader. Otherwise, ignore. (only added complexity if at least a fraudproof for the leader is generated).

Also, if any sort of fraudproof were to be generated, we should consider changing many checks on a weak quorum to checks on a strong quorum (for cases where safety can leak from these checks in weird ways not previously considered). Consider this a placeholder for a potential future issue to resolve should we implement fraudproofs/accountability.

Following sync, we settled on implementing b) (solution specifically for Trantor):

• Proposer signatures on preprepare messages (detects at least proposer deviations if safety violation attempted by proposer)
• (Tentative) voter signatures on prepare messages (detects at least n-StrongQuorum() if safety violated)

Room for ideas on how to detect conflicting signatures and generate so-called Proofs-of-Misbehavior (PoMs) (i.e. how nodes collaborate to efficiently exchange signatures). But common agreement towards:

1- Good case (no misbehaviors) should not be affected beyond local signature verification, (same communication complexity)

2- If more messages than good case, then at least proposer is provably faulty (deterrent from adversary causing spam as someone will be slashed)

For block proposer, all replicas must attach the signature of the proposer's preprepare message to their commit message.

For voters, there are still multiple proposals on how to efficiently check for conflicting messages:

1 - Use threshold signatures attached to commit messages. Though optimal push-based approach, mostly discarded for now due to the complexity of the implementation.
2 - Above-described type of approach, (release locally gathered signed prepares upon generating a PoMs for the proposer at least). An honest node $p_i$ must thus send to the node $p_j$ from which the conflicting signature of the proposer was received a list of signed prepares. This way, $p_j$ can create and broadcast PoMs. Alternatively, $p_i$ can broadcast (though unnecessary and extra comm).
3- Other proposals have been put forward that optimistically accuse nodes, (if for example a decision is made on a value different than what a node signed for in their prepare), but these cannot rule out false positives AFAWK, so mainly discarded.

Implementations of general accountability module also discussed (option c) above), but:

• Increases critical path by at least an extra round of communication
• Only by making it a bit specific for Trantor, can it be taken out of the critical path.