Simple-IT: Signature-Free BFT Consensus

• Simple-IT is a signature-free, leader-based BFT consensus protocol that uses symmetric cryptography and authenticated channels to achieve post-quantum security.
• It adapts the simple round structure of Simplex by replacing quorum certificates with Reliable Broadcast and Reliable Notification to ensure convergence and safety.
• Empirical evaluations show Simple-IT matching state-of-the-art throughput and latency, with a theoretical best-case of 4 message delays and enhanced resilience against quantum attacks.

Searching arXiv for the exact topic and closely related variants to ground the article in the relevant paper(s). Simple-IT is a leader-based, partially synchronous, signature-free Byzantine fault-tolerant (BFT) consensus protocol with optimal resilience $n > 3f$, introduced as a practical low-latency alternative to contemporary signature-based BFT designs in the context of post-quantum security concerns (Yu et al., 12 Jun 2026). Its central premise is that modern BFT protocols rely on quantum-vulnerable public-key signatures such as Ed25519 and BLS12-381, whereas a signature-free design can instead use authenticated point-to-point channels and symmetric cryptography, avoiding public-key signatures on the critical path (Yu et al., 12 Jun 2026). The protocol adapts the simple round structure of Simplex to the signature-free setting, replacing transferable quorum certificates with convergence mechanisms based on Reliable Broadcast (RBC) and Reliable Notification (RN) (Yu et al., 12 Jun 2026). In the reported geo-distributed implementation, Simple-IT achieves throughput and latency competitive with state-of-the-art quantum-vulnerable protocols, while preserving a theoretical latency of 4 message delays in the good case and 3 message delays on its optimistic path (Yu et al., 12 Jun 2026).

1. Motivation and problem setting

The protocol is motivated by the observation that high-performance BFT systems commonly place public-key signatures on the critical path, and that under the stated threat model a sufficiently capable quantum adversary running Shor’s algorithm could recover validators’ secret keys from public keys and forge protocol messages (Yu et al., 12 Jun 2026). The paper identifies two consequences: such an adversary could break safety, by fabricating votes or certificates for conflicting blocks, and liveness, by impersonating validators or disrupting leader and view-change logic (Yu et al., 12 Jun 2026).

A direct migration to post-quantum secure signatures is presented as costly. The paper specifically notes that signing and especially verification lie on the protocol’s critical path, and reports experimentally that in a state-of-the-art BFT protocol, replacing BLS with ML-DSA-65 doubles latency (Yu et al., 12 Jun 2026). This establishes the design space in which signature-free BFT becomes attractive: after setup, the protocol uses only authenticated channels and symmetric cryptography such as HMAC-SHA256, which the paper treats as practically post-quantum secure because Grover’s algorithm provides only a quadratic speedup (Yu et al., 12 Jun 2026).

The main systems question is therefore whether signature-free BFT consensus protocols can match the performance of current state-of-the-art, quantum-vulnerable BFT consensus protocols (Yu et al., 12 Jun 2026). Prior work had already shown that state-of-the-art throughput was attainable signature-free, but the paper identifies latency as the open problem in practice (Yu et al., 12 Jun 2026). Several recent signature-free protocols had low latency in theory, but they were described as intricate and lacking practical implementations (Yu et al., 12 Jun 2026). Simple-IT is proposed as an answer to this gap.

2. Protocol model and architectural principles

Simple-IT operates in an eventually synchronous message-passing model with $n$ parties, up to $f$ Byzantine faults, and the optimal resilience condition

$$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$

A quorum is a set of size $n-f$, and two such quorums intersect in at least one correct party (Yu et al., 12 Jun 2026). Before GST, message delays are arbitrary; after GST, every message from a correct party to a correct party arrives within at most $\delta$, and parties know a public upper bound $\Delta \ge \delta$ (Yu et al., 12 Jun 2026). A predetermined fair leader schedule assigns every round $r$ a leader $L_r$, and every party is leader infinitely often (Yu et al., 12 Jun 2026).

The defining architectural move is to eliminate transferable quorum certificates. In a signature-based protocol, one replica can forward a signed message from another replica and any third replica can verify it. With only authenticated channels, that transferability disappears: if $p_1$ receives a message from $n$0, $n$1 cannot prove to $n$2 that $n$3 sent it (Yu et al., 12 Jun 2026). Simple-IT addresses this by introducing convergence through two broadcast-style abstractions:

• Reliable Broadcast (RBC): used to make a leader’s proposal converge at all correct replicas.
• Reliable Notification (RN): a new abstraction used to make timeout or disable decisions converge.

The protocol is thus best understood as a signature-free analogue of a Simplex-style parent-chain protocol, where explicit certificates are replaced by globally convergent facts established through RBC and RN (Yu et al., 12 Jun 2026).

3. Round structure, safe parents, and state transitions

Simple-IT runs an infinite sequence of rounds $n$4. In each round $n$5, the leader tries to assign a block $n$6 and a parent round $n$7, thereby forming a tree of rounds (Yu et al., 12 Jun 2026). A round may end up in one of two mutually exclusive states: committed or disabled (Yu et al., 12 Jun 2026). A round may be disabled while still having an assigned proposal and safe parent, and such a round may still serve as a parent for a later round (Yu et al., 12 Jun 2026).

The key structural notion is the safe parent. A parent $n$8 is safe for round $n$9 if $f$0 or round $f$1 itself has a safe assigned proposal, and every intermediate round $f$2 with $f$3 is disabled (Yu et al., 12 Jun 2026). Formally, the helper predicate $f$4 returns true iff $f$5, $f$6, and $f$7 for all $f$8 (Yu et al., 12 Jun 2026). This mechanism replaces the lock and quorum-certificate logic typical of HotStuff-style protocols.

Each replica keeps local state including curr_round, submitted, delivered, proposal[r], safe[r], disabled[r], committed[r], and round-specific flags such as voted and timed_out; speculative variants additionally use aborted[r] and proposed[r] (Yu et al., 12 Jun 2026). At the message level, the protocol uses RBC proposal messages of the form $f$9, commit votes $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$0, and RN messages $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$1 and $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$2 for events such as $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$3 (Yu et al., 12 Jun 2026).

In the non-speculative version, the round flow is as follows. On entering round $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$4, a party sets curr_round := r, resets the round timer to

$$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$5

resets voted and timed_out, and, if it is leader $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$6, proposes (Yu et al., 12 Jun 2026). The leader selects the highest round $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$7 such that $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$8, chooses a not-yet-delivered block $$f < \frac{n}{3}, \qquad\text{equivalently}\qquad n > 3f.$$9 not already in $n-f$0, and RBC-broadcasts $n-f$1 (Yu et al., 12 Jun 2026). When a party RB-delivers the proposal, it sets $n-f$2; if the proposal is present and the parent is safe, it marks $n-f$3 (Yu et al., 12 Jun 2026). If the round is safe, the party has not timed out, and has not already voted, it sends $n-f$4 to all parties (Yu et al., 12 Jun 2026). If the timer expires before voting, it invokes RN on the timeout event and marks itself timed out; if RN confirms the timeout, it sets $n-f$5 (Yu et al., 12 Jun 2026). A party commits round $n-f$6 after receiving commit votes from $n-f$7 parties, and if round $n-f$8 is both committed and safe, it delivers all blocks in the chain $n-f$9 not already delivered (Yu et al., 12 Jun 2026).

4. Reliable Notification and the signature-free replacement for quorum certificates

RN is central to the design because it creates convergence for timeout outcomes without signatures. The protocol is a simple two-step-style mechanism (Yu et al., 12 Jun 2026). Upon rn_raise(e), a party broadcasts $\delta$0; after receiving $\delta$1 votes, it broadcasts $\delta$2; it confirms $\delta$3 after receiving $\delta$4 accepts; and if it sees $\delta$5 accepts without having sent accept, it sends accept as a cascade step (Yu et al., 12 Jun 2026).

The paper states three RN properties:

• Unanimity: if every correct party raises $\delta$6, everyone confirms $\delta$7.
• Totality: if one correct party confirms $\delta$8, all eventually do.
• Validity: if $\delta$9 is confirmed, at least $\Delta \ge \delta$0 correct parties raised it.

The significance of RN is that a disable decision is not a certificate but a convergent globally shared fact (Yu et al., 12 Jun 2026). Together with RBC, RN supplies the protocol’s substitute for the transferability normally provided by signatures. RBC makes all correct parties converge on the same leader proposal, RN makes them converge on the same timeout or disable facts, and direct receipt of $\Delta \ge \delta$1 commit votes suffices for commit (Yu et al., 12 Jun 2026).

This architecture yields what the paper describes as a deliberately simple leader-based design. There are no signature-based quorum certificates, no intricate lock-transfer rules, and no entangled fallback logic; instead, safety is organized through parent-chain structure and liveness through round disabling (Yu et al., 12 Jun 2026). This suggests that the protocol’s simplicity is not merely rhetorical but a specific systems design choice.

5. Latency, pipelining, and performance parameters

The paper instantiates Simple-IT with two RBC variants. For Bracha-RBC, the optimistic delay is $\Delta \ge \delta$2, the worst delay is $\Delta \ge \delta$3, and the totality delay is $\Delta \ge \delta$4 (Yu et al., 12 Jun 2026). For Opt-RBC, the optimistic delay is $\Delta \ge \delta$5, the worst delay is $\Delta \ge \delta$6, the totality delay is $\Delta \ge \delta$7, and the optimistic resilience is

$\Delta \ge \delta$8

The general optimistic commit bound is

$\Delta \ge \delta$9

This yields:

• Bracha-Simple-IT: $r$0
• Opt-Simple-IT optimistic: $r$1

The paper also gives the good-case or general latency without the optimistic honesty assumption as $r$2 for the Bracha-based version and $r$3 for the Opt-based version (Yu et al., 12 Jun 2026). These are the core latency numbers behind the statement that Simple-IT achieves a theoretical latency of 4 message delays and 3 on its optimistic path (Yu et al., 12 Jun 2026).

Without speculative proposal pipelining, the block time is $r$4 for the Bracha variant and $r$5 for the Opt variant (Yu et al., 12 Jun 2026). With speculative pipelining, both speculative variants achieve optimistic block time $r$6 (Yu et al., 12 Jun 2026). The protocol defines four variants: a Bracha-RBC version, an Opt-RBC version, and speculative versions of both (Yu et al., 12 Jun 2026).

Speculative proposing allows the leader of round $r$7 to propose before the previous round is fully established as safe, provided several conditions hold, including that round $r$8 is safe and the leader has received the first message of round $r$9’s RBC directly from $L_r$0 (Yu et al., 12 Jun 2026). This creates a proposal pipeline of depth $L_r$1 for Bracha-RBC and $L_r$2 for Opt-RBC (Yu et al., 12 Jun 2026). If a round times out and is disabled, parties that truly timed out there proactively RN-raise timeouts for the next $L_r$3 speculative rounds, marking them aborted and preventing $L_r$4 serial timeouts (Yu et al., 12 Jun 2026).

The paper also reports eventual worst-case view duration. Since

$L_r$5

the Bracha-based variant has $L_r$6 and eventual worst-case view duration $L_r$7, while the Opt-based variant has $L_r$8 and eventual worst-case view duration $L_r$9 (Yu et al., 12 Jun 2026). This makes explicit the cost of Opt-RBC: faster optimistic latency, but worse worst-case timing.

Communication complexity is reported as $p_1$0 bits per view for Simple-IT itself, excluding block dissemination details (Yu et al., 12 Jun 2026). For long messages using erasure-coded RBC, the cost is

$p_1$1

communication per broadcast for an $p_1$2-bit message, where $p_1$3 is the hash output length (Yu et al., 12 Jun 2026). This is contrasted with $p_1$4 per view for Algorithm BFT and Sailfish++, and $p_1$5 for signature-based Simplex (Yu et al., 12 Jun 2026).

6. Safety, liveness, implementation, and empirical evaluation

The safety argument rests on two main invariants. First, no round can be both committed and disabled (Yu et al., 12 Jun 2026). Correct parties vote to commit only if they have not timed out, and they raise timeout only if they have not voted (Yu et al., 12 Jun 2026). Commit requires $p_1$6 commit messages, while disable confirmation implies by RN validity that at least $p_1$7 correct parties raised timeout (Yu et al., 12 Jun 2026). Since

$p_1$8

these sets must overlap, which would force some correct party to both vote and timeout, a contradiction (Yu et al., 12 Jun 2026). Second, committed rounds form one ancestor chain, because a round becomes safe only if its parent is safe and all skipped rounds are disabled; once a round commits, it cannot later be disabled, so future safe rounds cannot skip it (Yu et al., 12 Jun 2026). The paper’s resulting safety theorem is that if a correct party delivers block $p_1$9 before $n$00, then no correct party delivers $n$01 before $n$02 (Yu et al., 12 Jun 2026).

Liveness is based on the fact that every round eventually resolves either to a safe proposal or to a disabled round (Yu et al., 12 Jun 2026). If some correct party RB-delivers the leader’s proposal, RBC totality ensures that all correct parties eventually RB-deliver it; otherwise, all eventually time out and RN-confirm the timeout (Yu et al., 12 Jun 2026). With a round timeout larger than $n$03, and a fair leader schedule with infinitely many correct leaders, all correct parties eventually deliver infinitely many blocks submitted by a correct party that submits infinitely many blocks (Yu et al., 12 Jun 2026). For speculative variants, liveness requires infinitely many windows of $n$04 consecutive correct leaders (Yu et al., 12 Jun 2026).

The implementation emphasizes practicality. The paper presents what it calls the first practical implementation of a signature-free, leader-based BFT protocol (Yu et al., 12 Jun 2026). It implements two dissemination styles:

Variant family	Dissemination strategy	Reported role
Mempool-Simple-IT	Shared mempool dissemination adapted from Autobahn’s mempool	Consensus orders digests or batches
Dispersed-Simple-IT	Leader-driven erasure-coded block dissemination based on AVID-style techniques	Avoids leader bottleneck

For large blocks, the dispersed design uses Reed-Solomon coding and can recover from $n$05 fragments, which equals $n$06 when $n$07 (Yu et al., 12 Jun 2026). For $n$08, the code rate is about $n$09, corresponding to about a $n$10 communication overhead on payloads (Yu et al., 12 Jun 2026). The paper reports that in practice data dissemination dominates both network cost and CPU cost, while signature-free control traffic is negligible by comparison (Yu et al., 12 Jun 2026). For dispersed variants at 50 MB blocks, proposal construction latency is reported as 212/227 ms p50/p95 and reconstruction latency as 42/49 ms p50/p95 (Yu et al., 12 Jun 2026).

The empirical evaluation uses 50 nodes on Google Cloud Platform, distributed across five regions on three continents, with machine type c2-standard-16, 16 vCPUs, 64 GB RAM, and inter-region RTTs from roughly 30 ms to 260 ms (Yu et al., 12 Jun 2026). Transactions are 512 random bytes; dispersed blocks scale up to 50 MB; experiments run for 120 s with 50 nodes and 60 s with 10 nodes (Yu et al., 12 Jun 2026). Throughput is measured in committed tx/s, and latency is measured from transaction creation to commit by 50% of non-faulty nodes (Yu et al., 12 Jun 2026).

The main reported results are as follows. Mempool-Simple-IT outperforms Autobahn across the latency-throughput curve, reaching about 170,000 tx/s, about 92 MB/s, at roughly 0.5 seconds latency (Yu et al., 12 Jun 2026). The paper attributes this to a shorter combined mempool and consensus delay path (Yu et al., 12 Jun 2026). Dispersed-Simple-IT reaches essentially the same peak throughput as DispersedSimplex, about 120,000 tx/s and about 61 MB/s, while latency in the pre-saturation region is only up to 9% higher; specifically, Opt-Dispersed-Simple-IT is only about 35 ms slower on average before saturation (Yu et al., 12 Jun 2026). With 10 nodes, threshold effects disappear and performance becomes very similar (Yu et al., 12 Jun 2026).

A particularly strong comparison is with post-quantum signatures. PQ-DispersedSimplex, obtained by replacing BLS with ML-DSA-65, exhibits roughly 2x the latency of even Bracha-Dispersed-Simple-IT at about 1 second latency (Yu et al., 12 Jun 2026). This is the paper’s clearest practical argument that signature-free BFT is a more viable post-quantum route than simply swapping in current post-quantum signatures.

The protocol is compared with several related systems. Sailfish++ had already shown state-of-the-art throughput in the signature-free setting, but it is DAG-based, has average optimistic commit latency around 5.6 message delays in the optimistic Opt-RBC setting, and uses $n$11 bits per view (Yu et al., 12 Jun 2026). IT-HS is listed at $n$12, TetraBFT at $n$13, Forget-IT at $n$14 but described as single-shot and intricate, and Simplex at $n$15 but signature-based (Yu et al., 12 Jun 2026). Simple-IT’s contribution is therefore the combination of low latency, $n$16 communication per view, structural simplicity, practical pipelining, and a real implementation (Yu et al., 12 Jun 2026).

The limitations are explicit. The 3-delay optimistic path via Opt-RBC requires the stronger honesty condition $n$17 among non-leaders (Yu et al., 12 Jun 2026). Opt-RBC also worsens the eventual worst-case view duration relative to Bracha-RBC (Yu et al., 12 Jun 2026). Speculative pipelining weakens liveness assumptions because it requires windows of consecutive correct leaders, and a Byzantine leader can poison a speculative window and force several rounds to be disabled (Yu et al., 12 Jun 2026). Erasure coding introduces CPU and bandwidth overhead, and the general-case protocol still remains one message delay from the absolute optimum (Yu et al., 12 Jun 2026).

A plausible implication is that Simple-IT is significant less because it proves a new asymptotic extreme than because it demonstrates a practical systems point: a signature-free, post-quantum-oriented BFT protocol can be simultaneously simple, implementable, and competitive with leading signature-based designs (Yu et al., 12 Jun 2026). In that sense, its main place in the literature is as a bridge between theoretical signature-free consensus and deployable low-latency BFT engineering.