---
title: 'Simple-IT: Signature-Free BFT Consensus'
url: https://www.emergentmind.com/topics/simple-it
type: topic
---

# Simple-IT: Signature-Free BFT Consensus

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 [2606.14404]. 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 [2606.14404]. 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) [2606.14404]. 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 [2606.14404].

## 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 [2606.14404]. 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 [2606.14404].

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** [2606.14404]. 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 [2606.14404].

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** [2606.14404]. 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 [2606.14404]. Several recent signature-free protocols had low latency in theory, but they were described as intricate and lacking practical implementations [2606.14404]. 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 [2606.14404]. 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\) [2606.14404]. A predetermined fair leader schedule assigns every round \(r\) a leader \(L_r\), and every party is leader infinitely often [2606.14404].

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 \(p_3\), \(p_1\) cannot prove to \(p_2\) that \(p_3\) sent it [2606.14404]. 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 [2606.14404].

## 3. Round structure, safe parents, and state transitions

Simple-IT runs an infinite sequence of rounds \(1,2,\dots\). In each round \(r\), the leader tries to assign a block \(b\) and a parent round \(r' < r\), thereby forming a tree of rounds [2606.14404]. A round may end up in one of two mutually exclusive states: **committed** or **disabled** [2606.14404]. 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 [2606.14404].

The key structural notion is the **safe parent**. A parent \(r'\) is safe for round \(r\) if \(r' = 0\) or round \(r'\) itself has a safe assigned proposal, and every intermediate round \(r''\) with \(r' < r'' < r\) is disabled [2606.14404]. Formally, the helper predicate \(\text{SafeParent}(r,r')\) returns true iff \(0 \le r' < r\), \(\text{safe}[r'] = \text{true}\), and \(\text{disabled}[r''] = \text{true}\) for all \(r' < r'' < r\) [2606.14404]. 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]` [2606.14404]. At the message level, the protocol uses RBC proposal messages of the form \(\{L_r, r, \{r', b\}\}\), commit votes \(\{\text{commit}, r\}\), and RN messages \(\{\text{vote}, e\}\) and \(\{\text{accept}, e\}\) for events such as \((\text{timeout}, r)\) [2606.14404].

In the non-speculative version, the round flow is as follows. On entering round \(r\), a party sets `curr_round := r`, resets the round timer to

\[
\Delta_{\text{to}} = (d_s + d_t)\Delta,
\]

resets `voted` and `timed_out`, and, if it is leader \(L_r\), proposes [2606.14404]. The leader selects the highest round \(r'\) such that \(\text{SafeParent}(r,r')\), chooses a not-yet-delivered block \(b\) not already in \(\text{Log}(r')\), and RBC-broadcasts \(\{L_r, r, \{r', b\}\}\) [2606.14404]. When a party RB-delivers the proposal, it sets \(\text{proposal}[r] := \{r', b\}\); if the proposal is present and the parent is safe, it marks \(\text{safe}[r] := \text{true}\) [2606.14404]. If the round is safe, the party has not timed out, and has not already voted, it sends \(\{\text{commit}, r\}\) to all parties [2606.14404]. 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 \(\text{disabled}[r] := \text{true}\) [2606.14404]. A party commits round \(r\) after receiving commit votes from \(n-f\) parties, and if round \(r\) is both committed and safe, it delivers all blocks in the chain \(\text{Log}(r)\) not already delivered [2606.14404].

## 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 [2606.14404]. Upon `rn_raise(e)`, a party broadcasts \(\{\text{vote}, e\}\); after receiving \(n-f\) votes, it broadcasts \(\{\text{accept}, e\}\); it confirms \(e\) after receiving \(2f+1\) accepts; and if it sees \(f+1\) accepts without having sent accept, it sends accept as a cascade step [2606.14404].

The paper states three RN properties:

- **Unanimity**: if every correct party raises \(e\), everyone confirms \(e\).
- **Totality**: if one correct party confirms \(e\), all eventually do.
- **Validity**: if \(e\) is confirmed, at least \(n-2f\) correct parties raised it.

The significance of RN is that a disable decision is **not a certificate but a convergent globally shared fact** [2606.14404]. 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 \(n-f\) commit votes suffices for commit [2606.14404].

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 [2606.14404]. 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 \(d_o = 3\), the worst delay is \(d_s = 3\), and the totality delay is \(d_t = 2\) [2606.14404]. For **Opt-RBC**, the optimistic delay is \(d_o = 2\), the worst delay is \(d_s = 4\), the totality delay is \(d_t = 4\), and the optimistic resilience is

\[
f_o = \frac{n}{2} - f.
\]

The general optimistic commit bound is

\[
(d_o + 1)\delta.
\]

This yields:

- **Bracha-Simple-IT**: \(4\delta\)
- **Opt-Simple-IT optimistic**: \(3\delta\)

The paper also gives the good-case or general latency without the optimistic honesty assumption as \(4\delta\) for the Bracha-based version and \(5\delta\) for the Opt-based version [2606.14404]. 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 [2606.14404].

Without speculative proposal pipelining, the block time is \(3\delta\) for the Bracha variant and \(2\delta\) for the Opt variant [2606.14404]. With speculative pipelining, both speculative variants achieve optimistic block time \(\delta\) [2606.14404]. The protocol defines four variants: a Bracha-RBC version, an Opt-RBC version, and speculative versions of both [2606.14404].

Speculative proposing allows the leader of round \(r\) to propose before the previous round is fully established as safe, provided several conditions hold, including that round \(r-k\) is safe and the leader has received the first message of round \(r-1\)’s RBC directly from \(L_{r-1}\) [2606.14404]. This creates a proposal pipeline of depth \(k = 3\) for Bracha-RBC and \(k = 2\) for Opt-RBC [2606.14404]. If a round times out and is disabled, parties that truly timed out there proactively RN-raise timeouts for the next \(k-1\) speculative rounds, marking them aborted and preventing \(k\) serial timeouts [2606.14404].

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

\[
\Delta_{\text{to}} = (d_s + d_t)\Delta,
\]

the Bracha-based variant has \(\Delta_{\text{to}} = 5\Delta\) and eventual worst-case view duration \(5\Delta + 2\delta\), while the Opt-based variant has \(\Delta_{\text{to}} = 8\Delta\) and eventual worst-case view duration \(8\Delta + 4\delta\) [2606.14404]. This makes explicit the cost of Opt-RBC: faster optimistic latency, but worse worst-case timing.

Communication complexity is reported as **\(O(n^2)\) bits per view** for Simple-IT itself, excluding block dissemination details [2606.14404]. For long messages using erasure-coded RBC, the cost is

\[
O(nL + \kappa n^2 \log n)
\]

communication per broadcast for an \(L\)-bit message, where \(\kappa\) is the hash output length [2606.14404]. This is contrasted with \(O(n^3)\) per view for Algorithm BFT and Sailfish++, and \(O(n^2)\) for signature-based Simplex [2606.14404].

## 6. Safety, liveness, implementation, and empirical evaluation

The safety argument rests on two main invariants. First, no round can be both committed and disabled [2606.14404]. Correct parties vote to commit only if they have not timed out, and they raise timeout only if they have not voted [2606.14404]. Commit requires \(n-f\) commit messages, while disable confirmation implies by RN validity that at least \(n-2f\) correct parties raised timeout [2606.14404]. Since

\[
(n-f) + (n-2f) = n + (n-3f) > n,
\]

these sets must overlap, which would force some correct party to both vote and timeout, a contradiction [2606.14404]. 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 [2606.14404]. The paper’s resulting safety theorem is that if a correct party delivers block \(b\) before \(b'\), then no correct party delivers \(b'\) before \(b\) [2606.14404].

Liveness is based on the fact that every round eventually resolves either to a safe proposal or to a disabled round [2606.14404]. 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 [2606.14404]. With a round timeout larger than \((d_t + d_s)\delta\), 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 [2606.14404]. For speculative variants, liveness requires infinitely many windows of \(k\) consecutive correct leaders [2606.14404].

The implementation emphasizes practicality. The paper presents what it calls the **first practical implementation of a signature-free, leader-based BFT protocol** [2606.14404]. 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 \(\frac{n-f+1}{2}\) fragments, which equals \(f+1\) when \(n=3f+1\) [2606.14404]. For \(n \approx 3f\), the code rate is about \(1/3\), corresponding to about a \(3\times\) communication overhead on payloads [2606.14404]. The paper reports that in practice data dissemination dominates both network cost and CPU cost, while signature-free control traffic is negligible by comparison [2606.14404]. 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 [2606.14404].

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** [2606.14404]. 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 [2606.14404]. Throughput is measured in committed tx/s, and latency is measured from transaction creation to commit by 50% of non-faulty nodes [2606.14404].

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** [2606.14404]. The paper attributes this to a shorter combined mempool and consensus delay path [2606.14404]. **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 [2606.14404]. With **10 nodes**, threshold effects disappear and performance becomes very similar [2606.14404].

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 [2606.14404]. 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 **\(O(n^3)\)** bits per view [2606.14404]. IT-HS is listed at \(6\delta\), TetraBFT at \(5\delta\), Forget-IT at \(3\delta\) but described as single-shot and intricate, and Simplex at \(3\delta\) but signature-based [2606.14404]. Simple-IT’s contribution is therefore the combination of **low latency, \(O(n^2)\) communication per view, structural simplicity, practical pipelining, and a real implementation** [2606.14404].

The limitations are explicit. The 3-delay optimistic path via Opt-RBC requires the stronger honesty condition \(f_o = \frac{n}{2} - f\) among non-leaders [2606.14404]. Opt-RBC also worsens the eventual worst-case view duration relative to Bracha-RBC [2606.14404]. 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 [2606.14404]. Erasure coding introduces CPU and bandwidth overhead, and the general-case protocol still remains one message delay from the absolute optimum [2606.14404].

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** [2606.14404]. In that sense, its main place in the literature is as a bridge between theoretical signature-free consensus and deployable low-latency BFT engineering.

Source: https://www.emergentmind.com/topics/simple-it