ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Byzantine Fault Tolerance

How to obtain distributed consensus even when a fraction of participants lie, cheat, or behave in arbitrarily strange ways.

Problem

Raft and Paxos assume a fail-stop model: nodes die, but do not lie. The Byzantine model, introduced by Lamport, Shostak and Pease in 1982 (Byzantine Generals Problem), considers that a fraction of nodes may send contradictory messages to different peers, forge signatures, omit responses or collude. In this model, how can N nodes decide on a single value despite f malicious ones? The foundational result: at least 3f+1 nodes are required to tolerate f traitors.

Forces

  • Quorum: 3f+1 nodes to tolerate f Byzantine (vs 2f+1 for fail-stop).
  • Communication cost: O(N²) messages per decision in PBFT — explodes with N.
  • Cryptography: digital signatures mandatory to prevent impersonation.
  • Partial synchrony: safety always holds; liveness requires synchrony windows.
  • Performance: PBFT reaches a few thousand tx/second on 4-7 LAN nodes; drops drastically beyond.

Solution

PBFT (Castro & Liskov 1999) remains the reference for permissioned deployments (known, verified-identity nodes). The protocol uses three phases: pre-prepare (the primary proposes), prepare (replicas broadcast what they saw), commit (each ensures a majority accepted). If the primary is malicious or silent, a view-change mechanism elects a new primary. Each message is signed. Modern variants: HoneyBadgerBFT (asynchronous), Tendermint (used by Cosmos), HotStuff (used by Diem/Libra and Aptos), Istanbul BFT (used by Hyperledger Besu).

Structure

Client                  Replicas (R0=primary, R1, R2, R3)
   │                          │
   │ request ──────────────►  R0
   │                          │
   │                          R0 ── pre-prepare(n, req) ──► R1, R2, R3
   │                          │
   │                          R1, R2, R3 ── prepare(n) ──► all
   │                          │
   │                          R0, R1, R2, R3 ── commit(n) ──► all
   │                          │
   │ ◄────────────── reply ── R0, R1, R2, R3
   │
   │ Client waits f+1 matching replies before accepting.

Quorum: 2f+1 honest replies among 3f+1 total
Tolerance: f=1 → 4 nodes; f=2 → 7 nodes; f=3 → 10 nodes

EDI implementation

BFT is not relevant for a classic EDI hub (partners are identified, signed, and the AS2/AS4 layer already provides integrity). Three cases justify examination: (1) a closed multi-actor B2B consortium where no party trusts the central operator — typical of interbank platforms (R3 Corda, Hyperledger Fabric use BFT for their ordering service); (2) a shared supply-chain traceability registry (TradeLens, IBM Food Trust) where history forgery has criminal consequences; (3) a future European digital product passport network (DPP under ESPR regulation 2024) that could rely on a BFT layer. For standard commercial EDI, payload signature + immutable audit log is sufficient and less costly.

Anti-patterns

  • Deploying BFT "because blockchain" when an audit log + signatures suffice — unnecessary overhead.
  • Permissionless BFT (Bitcoin, Ethereum PoS) on commercial EDI flows — incompatible with validation-time SLAs.
  • Confusing PBFT with simple fault tolerance — wrongly sized quorum, lost safety.
  • No leader rotation — a slow Byzantine primary delays all transactions without triggering view change.
  • Believing BFT removes the need for TLS — application signature does not protect against traffic analysis.
  • Paxos — fail-stop consensus, theoretical foundation.
  • Raft — practical fail-stop consensus.
  • Leader Election — sub-protocol of PBFT (view change).
  • Event Sourcing — often combined with BFT for permissioned blockchains.

Sources

  • Lamport L., Shostak R., Pease M. — The Byzantine Generals Problem, ACM TOPLAS 1982. The foundational paper. lamport.azurewebsites.net
  • Castro M., Liskov B. — Practical Byzantine Fault Tolerance, OSDI 1999. The PBFT algorithm. pmg.csail.mit.edu
  • Yin M. et al. — HotStuff: BFT Consensus in the Lens of Blockchain, PODC 2019. Base of Diem/Aptos.
  • Hyperledger Fabric — Architecture documentation, BFT ordering service. hyperledger-fabric.readthedocs.io
  • Tendermint Core — Tendermint BFT specification. docs.tendermint.com