BFT
Also called Byzantine Fault Tolerance, Byzantine Fault Tolerant consensus
Origin:
composes, a 40-year-old field of distributed-systems theory Solidus builds on, not something it invented. Solidus status:testnet: the property holds by construction in the shipped consensus engine; it hasn't been stress-tested against real independent adversaries yet.
Byzantine Fault Tolerance is the property of a distributed system that keeps working correctly even if some of its participants are actively malicious, not just offline or slow, but lying, sending contradictory messages to different peers, or otherwise trying to break the system on purpose. It's named after the "Byzantine Generals Problem": a group of generals surrounding a city must agree on a single battle plan (attack or retreat) by messenger, even though some generals might be traitors sending different messages to different peers. A BFT protocol guarantees the honest generals still reach the same decision, as long as the traitors are a small enough minority, typically fewer than one-third of the total.
This matters for blockchains because a validator committee is exactly that group of generals: it needs to agree on the next block even if some validators are compromised or dishonest.
Where it comes from
Leslie Lamport, Robert Shostak, and Marshall Pease posed the Byzantine Generals Problem formally in 1982. It stayed largely theoretical until Miguel Castro and Barbara Liskov's 1999 Practical BFT (PBFT) paper showed it could run fast enough for real distributed systems. Every major non-proof-of-work blockchain consensus design since, Tendermint (Cosmos), the HotStuff family (Diem, Aptos), Algorand, and others, is a different way of achieving the same underlying BFT guarantee with different tradeoffs in speed, message complexity, and committee-selection method.
Solidus didn't invent any of this theory. Its own contribution, described under Proof-of-Identity, is a proposed eligibility rule for who gets to be a validator in the first place, not a new way of achieving Byzantine agreement.
What "up to 33%" means for Solidus today
The shipped HotStuff-based engine is built so that, mathematically, it stays safe as long as fewer than one-third of the active committee is Byzantine, the same bound as PBFT and most other BFT protocols. That bound has been checked exhaustively in a formal model (TLA+/TLC), including scenarios with equivocating and Byzantine replicas.
What that bound has not been checked against is a live network of real, independent, economically-or-politically-motivated adversaries, because the public testnet's validator committee is small (four nodes) and run by the Solidus team itself, not by unrelated third parties. The math is sound; the field test hasn't happened yet.
Check it yourself
The public protocol repository includes the TLA+ specification of the consensus commit rule and the TLC model-checker's results file. A stranger can install TLA+ tools and re-run the exhaustive check themselves against the exact spec checked into the repo.
Related terms: HotStuff · Finality · Committee Election · Validator
Where it comes from
Someone else specified this. Solidus assembles it.
Byzantine Fault Tolerance is decades-old distributed-systems theory: Leslie Lamport, Robert Shostak and Marshall Pease formalized the problem in "The Byzantine Generals Problem" (1982), and Miguel Castro and Barbara Liskov made it practical for real systems with Practical BFT (PBFT, 1999). It underlies most non-proof-of-work blockchains, Tendermint/Cosmos, HotStuff-family chains (Diem, Aptos), Algorand, and many others. Solidus does not originate BFT theory; its consensus engine (see HotStuff) is one specific BFT protocol built on top of it.
How to check this
Running on the test network. Not mainnet.
The public protocol repository's TLA+ specification and TLC model-check results (tla+/TLC_RESULTS.md) model an exhaustive state space that includes equivocating and Byzantine replicas, and report zero safety violations across 963,033 explored states. A stranger can re-run TLC against the checked-in spec.