The earlier comparison claimed that original IBFT used only one round and a static leader, then presented rounds and leader changes as new in IBFT 2.0. That premise was incorrect: original IBFT already had a round-change subprotocol.
The correctness analysis of IBFT examines safety and liveness limitations under an eventually synchronous network model. The IBFT 2.0 paper presents a variation intended to address those limitations. The distinction is in protocol rules and their guarantees under stated assumptions.
Ask two different questions
Safety concerns whether honest nodes can finalize conflicting histories. Liveness concerns whether the network can keep making progress. A protocol’s finality claim does not mean it continues producing blocks with an unavailable quorum or an arbitrary partition.
Besu’s IBFT 2.0 configuration includes validator selection, proposal timing, and round timeouts. Those choices and the client version belong in an actual deployment record; the name IBFT alone is not a complete specification. See Besu IBFT 2.0 documentation.
The source’s unqualified performance ranking and automatic-recovery guarantee are removed. No validators were started, failures injected, or throughput measured for this revision.