Blockchain beveiligen: de rol van Byzantijnse fouttolerantie

Telkens wanneer u een cryptotransactie verzendt, een betaling ontvangt of interactie hebt met een smart contract, moet een netwerk van computers die elkaar niet kennen of vertrouwen, het erover eens zijn dat uw transactie geldig is en permanent moet worden vastgelegd. Sommige van die computers zijn mogelijk offline. Andere worden mogelijk beheerd door kwaadwillenden die opzettelijk valse informatie versturen. Toch moet de blockchain op elk eerlijk knooppunt tot dezelfde correcte conclusie komen.

Het mechanisme dat dit mogelijk maakt, is Byzantijnse fouttolerantie (BFT). Het is een van de belangrijkste en minst begrepen concepten in gedistribueerde systemen en vormt de basis voor de beveiliging ervan. Blockchain technologie, gedecentraliseerde financiën, bedrijfsbrede grootboeken en het internet der dingen.

Deze gids behandelt Byzantijnse fouttolerantie van de basisprincipes tot de meest geavanceerde moderne implementaties, inclusief de vergelijking met Proof of Work en Proof of Stake, de specifieke aanvalsvectoren waartegen het bescherming biedt, de protocollen die er vandaag de dag op voortbouwen en de uitdagingen waar onderzoekers nog steeds aan werken.

Het probleem van de Byzantijnse generaals: waar het allemaal begon

Om Byzantijnse fouttolerantie te begrijpen, moet je het probleem begrijpen dat het beoogt op te lossen. Het Byzantijnse generaalsprobleem werd voor het eerst formeel beschreven in 1982 door de computerwetenschappers Leslie Lamport, Robert Shostak en Marshall Pease in een artikel getiteld "The Byzantine Generals Problem", gepubliceerd in de ACM Transactions on Programming Languages ​​and Systems.

Het probleem wordt geformuleerd als een militaire analogie. Stel je voor dat verschillende divisies van een Byzantijns leger een vijandelijke stad omsingelen. Elke divisie staat onder bevel van een generaal en ze kunnen alleen met elkaar communiceren via boodschappers. Ze moeten het eens worden over een gezamenlijk plan van aanpak: aanvallen of terugtrekken. Als ze allemaal tegelijk aanvallen, winnen ze. Als ze allemaal tegelijk terugtrekken, overleven ze. Maar als sommigen aanvallen terwijl anderen zich terugtrekken, worden ze vernietigd.

De complicatie is dat sommige generaals verraders kunnen zijn. Een verrader zou verschillende berichten naar verschillende generaals kunnen sturen, sommigen opdragen "aanvallen" en anderen "zich terugtrekken", met als doel overeenstemming te voorkomen. De loyale generaals kunnen berichten die ze verdacht vinden niet zomaar negeren, omdat ze niet direct kunnen vaststellen welke generaals verraders zijn.

De vraag luidt: Welk algoritme kunnen de loyale generaals gebruiken om te garanderen dat ze allemaal tot dezelfde beslissing komen, zelfs wanneer een deel van de generaals verraders zijn die actief proberen onenigheid te zaaien?

Lamport, Shostak en Pease bewezen dat een oplossing alleen mogelijk is als meer dan twee derde van de generaals loyaal is. Anders gezegd: een systeem met n knooppunten kan maximaal f foutieve of kwaadwillige knooppunten tolereren, zolang n maar minstens 3f + 1 is. Met minder dan twee derde eerlijke deelnemers kan geen enkel algoritme overeenstemming garanderen.

Dit wiskundige resultaat vormde de theoretische basis voor elk BFT-consensusalgoritme dat daarop volgde.

Lees ook: Hoe hashing blockchaintechnologie beschermt

Wat is Byzantijnse fouttolerantie?

Byzantijnse fouttolerantie verwijst naar de eigenschap van een gedistribueerd systeem waardoor het correct kan blijven functioneren en consensus kan bereiken, zelfs wanneer sommige knooppunten op willekeurige wijze uitvallen, bijvoorbeeld door tegenstrijdige of onjuiste berichten te verzenden, inconsistent te reageren op verschillende deelnemers of zich kwaadwillig te gedragen om het netwerk te verstoren.

De term "Byzantijns" duidt specifiek op de ernstigste vorm van falen: willekeurig, vijandig en inconsistent gedrag. Dit is veel moeilijker te beheersen dan een simpele crash (waarbij een knooppunt volledig stopt met reageren), omdat een Byzantijns knooppunt zich soms correct lijkt te gedragen, terwijl het op andere momenten actief de consensus ondermijnt.

In het kader van Blockchain technologieByzantijnse fouttolerantie betekent dat het blockchainnetwerk zijn integriteit kan behouden en transacties correct kan blijven valideren, zelfs wanneer sommige validators of knooppunten gecompromitteerd, offline of opzettelijk kwaadaardig zijn.

De regel die in het Lamport-artikel is vastgesteld, geldt overal: zolang minstens twee derde van de knooppunten in het netwerk eerlijk en correct functioneren, zal een BFT-systeem de juiste consensus bereiken. Zodra een enkele aanvaller meer dan een derde van de knooppunten controleert, beginnen de veiligheidsgaranties van klassieke BFT-protocollen af ​​te brokkelen.

Niet-Byzantijnse versus Byzantijnse foutentolerantie: een cruciaal onderscheid

Niet alle fouttolerantie is gelijk. Inzicht in het verschil tussen niet-Byzantijnse en Byzantijnse fouttolerantie verduidelijkt waarom de laatste moeilijker is en waarom dit zo belangrijk is voor blockchain.

Niet-Byzantijnse (crash) fouttolerantie Dit behandelt het eenvoudigere geval waarin knooppunten kunnen uitvallen door te stoppen: ze crashen, gaan offline of worden onbereikbaar. Het systeem moet blijven functioneren, ondanks dat sommige knooppunten geen berichten meer versturen. Dit is gemakkelijker te verwerken, omdat een gecrasht knooppunt geen berichten verzendt en geen actieve verwarring veroorzaakt. Systemen zoals Apache ZooKeeper en oudere gedistribueerde databases zijn ontworpen met fouttolerantie bij crashes in gedachten.

Byzantijnse fouttolerantie Dit behandelt het lastigere geval waarin defecte knooppunten zich willekeurig kunnen gedragen en onjuiste, tegenstrijdige of strategisch misleidende berichten naar verschillende delen van het netwerk kunnen sturen. Een Byzantijns knooppunt zwijgt niet zomaar; het neemt actief deel op manieren die bedoeld zijn om verwarring te zaaien of overeenstemming te voorkomen. Blockchainnetwerken zijn vatbaar voor dit lastigere probleem omdat ze opereren in open, gedecentraliseerde omgevingen waar iedereen een knooppunt kan beheren, inclusief tegenstanders.

In blockchain-technologie omvatten Byzantijnse fouten onder andere: een miner die frauduleuze transacties in een voorgesteld blok opneemt, een validator die tegenstrijdige blokken ondertekent om een ​​fork te proberen, een node die verschillende transactievolgorde-informatie naar verschillende peers stuurt, en nodes die dubbele uitgaven uitvoeren door tegenstrijdige transacties gelijktijdig naar verschillende delen van het netwerk te verzenden.

Een systeem dat bestand is tegen crashes, maar niet tegen Byzantijnse fouten, zou ongeschikt zijn voor een openbare blockchain, waar knooppunten worden beheerd door onbekende, mogelijk vijandige partijen.

Hoe BFT wordt bereikt: de kernmechanismen

Byzantijnse fouttolerantie wordt bereikt door een combinatie van drie primaire mechanismen die samenwerken om eerlijke knooppunten in staat te stellen tot overeenstemming te komen, ondanks vijandige deelnemers.

Redundantie

In plaats van te vertrouwen op één enkele node om een ​​transactie te registreren of te valideren, gebruiken BFT-systemen meerdere redundante nodes. Zolang meer dan twee derde van deze redundante nodes betrouwbaar is, kan het systeem de minderheid van valse of tegenstrijdige berichten identificeren en negeren. Redundantie is de structurele basis van BFT: het is onmogelijk om Byzantijnse fouttolerantie te bereiken zonder meer nodes te gebruiken dan strikt noodzakelijk is om transacties te verwerken.

Cryptografische handtekeningen

BFT-protocollen gebruiken cryptografie met publieke sleutels om berichten tussen knooppunten te authenticeren. Wanneer een knooppunt een bericht verzendt (bijvoorbeeld een stem over de geldigheid van een voorgesteld blok), ondertekent het dat bericht met zijn privésleutel. Andere knooppunten kunnen de handtekening verifiëren met behulp van de publieke sleutel van de afzender, waarmee wordt bevestigd dat het bericht daadwerkelijk afkomstig is van de beweerde afzender en niet is gewijzigd tijdens de overdracht. Dit voorkomt een van de gevaarlijkste Byzantijnse aanvallen: een kwaadwillend knooppunt dat zich voordoet als een ander knooppunt door diens berichten te vervalsen.

Gestructureerde consensusprotocollen

BFT-consensusprotocollen definiëren precieze regels voor hoe knooppunten nieuwe gegevens voorstellen, erover stemmen en deze finaliseren. Deze protocollen zijn specifiek ontworpen zodat, zelfs als sommige knooppunten tegenstrijdige stemmen uitbrengen, de eerlijke meerderheid tot hetzelfde eindantwoord kan komen. De structuur van het protocol elimineert ambiguïteit: er is een gedefinieerd proces voor wat er gebeurt wanneer stemmen conflicteren, wanneer een leider faalt en wanneer knooppunten het oneens zijn over de huidige status.

De drie eigenschappen die de BFT-consensus definiëren

Elk BFT-consensusprotocol, ongeacht het specifieke ontwerp, moet aan drie fundamentele eigenschappen voldoen:

Veiligheid Dit betekent dat geen twee correcte (eerlijke) knooppunten ooit tot verschillende waarden zullen komen. Als een eerlijk knooppunt een transactie als geldig vastlegt, zal geen enkel ander eerlijk knooppunt deze als ongeldig vastleggen. Veiligheid zorgt ervoor dat de blockchain niet splitst in tegenstrijdige geschiedenissen tussen eerlijke deelnemers.

Levendigheid Dit betekent dat het systeem uiteindelijk vooruitgang boekt. Als voldoende correcte knooppunten een transactie indienen, zal die transactie uiteindelijk worden vastgelegd. Het netwerk loopt niet permanent vast. Liveness zorgt ervoor dat eerlijke deelnemers niet voor onbepaalde tijd worden geblokkeerd en hun transacties niet kunnen worden verwerkt.

Een overeenkomst Dit betekent dat als een correct knooppunt een transactie aflevert, elk correct knooppunt diezelfde transactie aflevert. Alle eerlijke knooppunten zien dezelfde gegevens in dezelfde volgorde.

Veiligheid en levendigheid kunnen elkaar tegenspreken. Het beroemde CAP-theorema in gedistribueerde systemen laat zien dat geen enkel gedistribueerd systeem tegelijkertijd consistentie, beschikbaarheid en tolerantie voor partities kan garanderen. BFT-protocollen maken bewust afwegingen. De meeste protocollen geven prioriteit aan veiligheid boven levendigheid: ze stoppen liever dan een potentieel verkeerd resultaat vast te leggen als te veel knooppunten zich onjuist gedragen.

Lees ook: Wat is consensus in blockchain?

Soorten Byzantijnse fouttolerantie-algoritmen

BFT is sinds het artikel uit 1982 aanzienlijk geëvolueerd. Het vakgebied omvat nu verschillende afzonderlijke protocolfamilies, elk met verschillende prestatiekenmerken, vertrouwensveronderstellingen en implementatiecontexten.

Praktische Byzantijnse fouttolerantie (PBFT)

Practical Byzantine Fault Tolerance werd in 1999 geïntroduceerd door Barbara Liskov en Miguel Castro aan het MIT. Het was het eerste BFT-algoritme dat praktisch genoeg was voor daadwerkelijke implementatie in gedistribueerde systemen, waarbij het probleem in asynchrone netwerken werd opgelost met een lage overhead in vergelijking met eerder academisch BFT-werk.

PBFT werkt via drie communicatiefasen tussen knooppunten:

Voorbereidingsfase: Het primaire (leidende) knooppunt ontvangt een clientverzoek, kent er een volgnummer aan toe en verzendt een voorbereidingsbericht naar alle andere knooppunten (replica's genoemd). Dit bericht bevat het verzoek, het volgnummer en het huidige weergavenummer.

Voorbereidingsfase: Elke replica die de pre-prepare accepteert, zendt een prepare-bericht uit naar elke andere replica. Een replica gaat pas naar de volgende fase wanneer deze overeenkomende prepare-berichten heeft ontvangen van ten minste 2f knooppunten (waarbij f het maximale aantal defecte knooppunten is dat het systeem tolereert). Deze quorumvereiste voorkomt dat een defecte leider verschillende replica's misleidt om verschillende volgnummers te accepteren.

Commitfase: Zodra een knooppunt voldoende overeenkomende voorbereidingsberichten heeft verzameld, verzendt het een commitbericht. Een replica voert het verzoek uit en antwoordt de client pas wanneer het commitberichten heeft ontvangen van ten minste 2f + 1 knooppunten. Dit laatste quorum zorgt ervoor dat, zelfs als sommige knooppunten die commitberichten hebben verzonden later uitvallen, er nog steeds voldoende gecommitteerde knooppunten overblijven om de duurzaamheid van het resultaat te garanderen.

Een client accepteert een resultaat wanneer deze f + 1 overeenkomende antwoorden ontvangt, waarmee wordt gegarandeerd dat ten minste één betrouwbaar knooppunt het resultaat heeft bevestigd.

De communicatiecomplexiteit van PBFT is O(n kwadraat), wat betekent dat het aantal berichten kwadratisch toeneemt met het aantal knooppunten. Dit is beheersbaar voor tientallen of een paar honderd knooppunten, maar wordt onhaalbaar op grote schaal. PBFT is bovendien afhankelijk van een vaste, bekende set validators, waardoor het het meest geschikt is voor blockchainomgevingen met toegangsbeheer of consortiumblockchains.

PBFT kan tolereren dat tot een derde (33%) van de knooppunten Byzantijns is. Deze drempelwaarde is wiskundig bewezen als het theoretische maximum voor klassieke BFT-protocollen.

Het gebruik van PBFT-afgeleide consensus door Hyperledger Fabric Het meest prominente voorbeeld binnen de bedrijfswereld is Hyperledger Fabric. Fabric maakt gebruik van een bestelservice (voorheen gebaseerd op PBFT, nu gebaseerd op Raft met een BFT-upgradepad via SmartBFT) die een hoge doorvoer en lage latentie biedt voor bedrijfsapplicaties. Walmart gebruikte Hyperledger Fabric om voedselproducten te traceren van boerderij tot schap, waarmee de praktische implementatie van BFT in een echte supply chain-omgeving werd aangetoond.

Federatieve Byzantijnse Overeenkomst (FBA)

Federated Byzantine Agreement (FBA) hanteert een fundamenteel andere benadering van het vertrouwensprobleem. In plaats van te vereisen dat alle validators de volledige set van vertrouwde validators kennen en het daarover eens zijn, staat FBA elke node toe om zijn eigen "quorum slice" te definiëren, de subset van andere nodes die het persoonlijk vertrouwt.

Het systeem bereikt wereldwijde consensus wanneer deze individuele vertrouwenssegmenten overlappende sets vormen. Als knooppunt A de knooppunten B en C vertrouwt, en knooppunt B de knooppunten A en D vertrouwt, creëert hun overlappende vertrouwen een impliciet wereldwijd quorum, ook al heeft geen centrale autoriteit er een gedefinieerd.

FBA is het consensusmechanisme dat ten grondslag ligt aan het Stellar-netwerk en, in een aangepaste vorm, het Ripple-netwerk. De FBA-implementatie van Stellar zorgt voor de definitieve afhandeling van transacties binnen drie tot vijf seconden en ondersteunt duizenden transacties per seconde, waardoor het praktisch is voor grensoverschrijdende betalingen. MoneyGram en andere aanbieders van geldovermakingen gebruiken Stellar specifiek omdat het FBA-consensusmechanisme de snelle en betrouwbare definitieve afhandeling biedt die betaalapplicaties vereisen.

De FBA-aanpak maakt een andere afweging dan PBFT: het biedt ruimte aan een meer gedecentraliseerde vertrouwensstructuur, maar vereist een zorgvuldige opzet van quorumsegmenten om ervoor te zorgen dat de eigenschap van wereldwijde overeenstemming behouden blijft. Als quorumsegmenten slecht gedefinieerd zijn, kunnen delen van het netwerk losgekoppelde consensusgroepen vormen die het eens zijn over verschillende toestanden.

HotStuff

HotStuff is een BFT-consensusprotocol dat in 2019 werd geïntroduceerd door de onderzoekers Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta en Ittai Abraham. Het protocol werd zeer invloedrijk als basis voor Facebooks LibraBFT-protocol (gebruikt in het Diem-blockchainproject) en heeft de basis gevormd voor het ontwerp van diverse moderne blockchain-consensussystemen.

De belangrijkste innovatie van HotStuff is het bereiken van een lineaire communicatiecomplexiteit, O(n), in plaats van de kwadratische O(n²) van PBFT. Dit wordt bereikt door een op een leider gebaseerd ontwerp, waarbij de leider stemmen verzamelt in drempelhandtekeningen en n individuele stemmen samenvoegt tot één compact bewijs. Dit betekent dat de communicatiekosten niet explosief stijgen naarmate de set validators groeit.

HotStuff maakt gebruik van een driefasenstructuur (voorbereiden, vooraf vastleggen, vastleggen) die conceptueel overeenkomt met de fasen van PBFT, maar efficiënter werkt door middel van pipelining: terwijl één blok wordt vastgelegd, wordt het volgende blok al voorgesteld, waardoor de doorvoer aanzienlijk wordt verbeterd.

HotStuff ruilt een iets hogere latentie (drie round-trips versus twee in PBFT) in voor een aanzienlijk betere schaalbaarheid. Voor grote sets van honderden of duizenden validators is deze afweging zeer gunstig. CometBFT (voorheen Tendermint Core) van het Cosmos-ecosysteem en het consensusmechanisme dat wordt gebruikt in Aptos en Sui zijn beide gebaseerd op ontwerpen uit de HotStuff-familie.

Tendermint en CometBFT

Tendermint is een BFT-consensusalgoritme dat specifiek is ontworpen voor blockchaingebruik en in 2014 werd geïntroduceerd door Jae Kwon. Het scheidt de consensuslaag van de applicatielaag via de Application Blockchain Interface (ABCI), waardoor elke applicatie Tendermint-consensus kan gebruiken zonder een eigen netwerk- en consensusinfrastructuur te hoeven bouwen.

Tendermint bereikt consensus in rondes. In elke ronde zendt een voorsteller een blok uit. Validators stemmen in twee fasen (prevote en precommit). Een blok wordt gecommit wanneer ten minste twee derde van de validators overeenkomende precommit-stemmen uitbrengen. Als de ronde mislukt (omdat de voorsteller een fout maakt of het netwerk te traag is), begint een nieuwe ronde met een nieuwe voorsteller.

Tendermint biedt onmiddellijke finaliteit: zodra een blok is vastgelegd, kan het niet meer worden teruggedraaid zonder de aanname van een eerlijke meerderheid van twee derde te schenden. Dit is een significant voordeel ten opzichte van probabilistische finaliteitssystemen zoals proof-of-work, waarbij een transactie pas als definitief wordt beschouwd nadat meerdere opeenvolgende blokken zijn toegevoegd.

Tendermint verwerkt duizenden transacties per seconde met een latentie van ongeveer één seconde. In 2023 werd de naam gewijzigd in CometBFT om een ​​breder model voor community-governance te weerspiegelen. De Cosmos Hub en elke op de Cosmos SDK gebaseerde blockchain (meer dan 100 actieve blockchains in 2025) gebruiken CometBFT als consensuslaag. Een opvallend voorbeeld uit de praktijk was de stopzetting van de Cosmos Hub v17.1 blockchain, die niet het gevolg was van een fout in het kernbeveiligingsbewijs van CometBFT, maar van een softwarefout in de code voor het bijwerken van de validator-set rond EndBlock. Dit illustreert hoe BFT-garanties live worden toegepast binnen een volledige implementatiestack, en niet in theoretische isolatie.

BFT in Proof of Stake: Casper en Ethereum

De overgang van Ethereum naar proof-of-stake via de Merge in september 2022 introduceerde Casper FFG (Friendly Finality Gadget) in combinatie met de LMD-GHOST fork-keuze, waarmee samen het Gasper-consensusprotocol werd gevormd. Casper biedt BFT-achtige finaliteit bovenop een proof-of-stake validator-set.

Casper functioneert als een finaliteitsmechanisme bovenop de blokproductie. Validators stemmen elke 32 slots (ongeveer 6.4 minuten) over checkpoints. Wanneer tweederde van de totale ingezette ETH voor een checkpoint heeft gestemd, is deze "gerechtvaardigd". Wanneer twee opeenvolgende checkpoints gerechtvaardigd zijn, wordt de eerste "gefinaliseerd". Gefinaliseerde blokken kunnen niet worden teruggedraaid zonder dat de aanvaller minstens een derde van alle ingezette ETH verbrandt, wat een krachtige economische garantie vormt voor BFT (Block Freight Trading).

Dit economische strafmechanisme is Ethereums aanpassing van klassieke BFT: in plaats van puur wiskundige garanties wordt finaliteit afgedwongen door de economische kosten van wangedrag. Als een validator tegenstrijdige blokken ondertekent, verliest hij zijn volledige inzet (wordt "geslasht"). De dreiging van het verlies van aanzienlijk kapitaal zorgt ervoor dat eerlijk gedrag aansluit bij economisch eigenbelang.

Byzantijnse fouttolerantie in bewijsvoering

Bitcoin's Proof of Work bereikt een probabilistische vorm van Byzantijnse fouttolerantie via een ander mechanisme dan klassieke BFT-protocollen. Satoshi Nakamoto introduceerde PoW in zijn Bitcoin whitepaper uit 2008 als een oplossing voor het Byzantijnse Generaalsprobleem in een omgeving zonder toestemming, waar deelnemers onbekend zijn en niet vooraf geïdentificeerd kunnen worden.

Bij Bitcoin's Proof-of-Work (PoW) betekent Byzantijnse fouttolerantie dat zolang eerlijke miners meer dan 50% van de totale rekenkracht van het netwerk beheren, een aanvaller met minder dan 50% de bevestigde transactiegeschiedenis niet kan herschrijven. De kosten van een 51%-aanval nemen toe met de hash rate van Bitcoin en de moeilijkheidsgraad van de mining-puzzels.

In tegenstelling tot klassieke BFT-protocollen die na één stemronde absolute finaliteit garanderen, is de finaliteit van Bitcoin probabilistisch: de kans dat een transactie wordt teruggedraaid, neemt exponentieel af met elk extra blok dat erna wordt toegevoegd. Daarom worden voor grote Bitcoin-transacties traditioneel bevestigingen van 6 blokken (ongeveer een uur) gebruikt.

De afweging is aanzienlijk: PoW biedt BFT in een omgeving zonder toestemming, maar dit gaat ten koste van een enorm energieverbruik, trage finaliteit (10-60 minuten) en de kwetsbaarheid voor de 51%-aanval, een probleem waar klassieke BFT-protocollen onder hun drempelwaarde nooit mee te maken krijgen.

Vergelijking van BFT-protocollen: een direct overzicht

Protocol	Foutdrempel	beslistheid	Berichtcomplexiteit	beste voor
PBFT (Castro-Liskov)	1/3 Byzantijns	Moment	O(n kwadraat)	Kleine netwerken met toegangsbeheer
HotStuff	1/3 Byzantijns	Moment	O(n) lineair	Grote validatiesets
Tendermint / CometBFT	1/3 Byzantijns	Direct (~1s)	O (n)	Cosmos-ketens, openbare blockchains
Federatieve Byzantijnse overeenkomst	Overlappende quorumsegmenten	3-5 seconden	Veranderlijk	Betaalnetwerken (Stellar, Ripple)
Casper FFG (Ethereum PoS)	1/3 van de ingezette ETH	Elke 6.4 min	O(n) met BLS-aggregatie	Openbare PoS-blockchains
Bitcoin PoW	50% hashkracht	Probabilistisch (6+ blokken)	O(1) uitzending	Netwerken zonder toestemming en zonder vertrouwen
Algorand BA	1/3 Byzantijns	~4.5 seconden	Sublineair met VRF	Zonder toestemming en met snelle definitieve afhandeling

Praktische toepassingen van BFT in 2025

Hyperledger Fabric en Enterprise Blockchain

Hyperledger Fabric is het meest gebruikte blockchain-framework voor bedrijven in productie. Het vormt de basis van Walmart's voedseltraceerbaarheidssysteem, IBM's oplossingen voor de toeleveringsketen en honderden financiële en logistieke applicaties. De orderservice van Fabric heeft een aanzienlijke evolutie doorgemaakt: na de overstap van PBFT naar Raft (een crash-fouttolerante consensus voor eenvoudigere implementaties) introduceerde Fabric SmartBFT als zijn Byzantijnse fouttolerante orderservice voor omgevingen die volledige BFT-garanties vereisen. SmartBFT volgt het bekende driefasen-broadcastpatroon dat is overgenomen van PBFT en biedt een hoge doorvoer met een lage latentie, geschikt voor bedrijfsapplicaties.

Stellar's gefedereerde Byzantijnse overeenkomst voor wereldwijde betalingen

De FBA-implementatie van Stellar verwerkt dagelijks miljoenen transacties, waarbij MoneyGram, Wirex en andere financiële instellingen het gebruiken voor grensoverschrijdende betalingen. Het consensusmechanisme van Stellar zorgt voor een definitieve afwikkeling binnen drie tot vijf seconden, wat vele malen sneller is dan traditioneel correspondentbankieren (één tot vijf dagen) en sneller dan de meeste blockchain-alternatieven. Het FBA-model stelt elk knooppunt in staat om zijn eigen vertrouwensrelaties te definiëren en tegelijkertijd wereldwijde overeenstemming te bereiken. Dit maakt het consensusmodel van Stellar bij uitstek geschikt voor een betalingsnetwerk waar niet alle deelnemers elkaar volledig vertrouwen, maar wel allemaal een betrouwbare afwikkeling willen.

Byzantijns Overeenkomstprotocol van Algorand

Algorand maakt gebruik van een unieke BFT-aanpak genaamd Pure Proof of Stake, gecombineerd met cryptografische loting. In elke consensusronde wordt een willekeurig comité van validators geselecteerd met behulp van een verifieerbare willekeurige functie (VRF). Alleen de geselecteerde leden van het comité weten dat ze zijn gekozen (en kunnen dit aan anderen bewijzen), waardoor gerichte aanvallen op leden van het comité vrijwel onmogelijk zijn, aangezien de aanvaller van tevoren niet weet wie hij moet aanvallen.

Het BA-protocol van Algorand bereikt finaliteit in ongeveer 4.5 seconden met een doorvoer van meer dan 1,000 transacties per seconde in een productieomgeving. Het ontwerp biedt BFT in een omgeving zonder toestemming en zonder de energiekosten van proof-of-work, een combinatie die het onderscheidt van zowel Bitcoin als klassieke, gereguleerde BFT-systemen.

Cosmos Ecosystem en CometBFT

Het Cosmos-ecosysteem in 2025 omvat meer dan 100 soevereine blockchains, die allemaal CometBFT als consensuslaag gebruiken. Het Inter-Blockchain Communication (IBC)-protocol vertrouwt op de directe finaliteitsgarantie van CometBFT: IBC-bewijzen zijn alleen geldig omdat de Cosmos Hub en de bijbehorende blockchains kunnen bewijzen dat een transactie daadwerkelijk is afgerond, en niet slechts waarschijnlijk is afgerond. Zonder de sterke finaliteitsgaranties die het BFT-consensusmechanisme biedt, zou dit type communicatie tussen blockchains veel moeilijker te beveiligen zijn. Het ecosysteem verwerkt dagelijks miljarden dollars aan waardeoverdrachten tussen blockchains, die allemaal worden beveiligd door het Byzantijnse fouttolerante consensusmechanisme van CometBFT.

Klaytn's Istanbul BFT

Klaytn, ontwikkeld door het Zuid-Koreaanse Kakao, maakt gebruik van Istanbul BFT (IBFT) met een verwerkingssnelheid van meer dan 4,000 transacties per seconde en bloktijden van één seconde. IBFT is een EVM-compatibele BFT-variant die Klaytn in staat stelt compatibel te blijven met Ethereum-tools, terwijl het aanzienlijk betere prestaties levert dan de basislaag van Ethereum. De hybride publiek-private architectuur stelt bedrijven in staat om beheerde sidechains te draaien, terwijl de publieke hoofdketen de gedecentraliseerde BFT-garanties waarborgt.

Aanvalsvectoren waartegen BFT bescherming biedt

Inzicht in waartegen BFT bescherming biedt, verduidelijkt de waarde en de beperkingen ervan.

Dubbel-uitgaven-aanvallen

Bij een dubbele-uitgave-aanval probeert een kwaadwillende partij hetzelfde geld twee keer uit te geven door gelijktijdig twee conflicterende transacties uit te zenden. Het BFT-consensusmechanisme voorkomt dit door te vereisen dat tweederde van de validators het eens is over één enkele transactievolgorde voordat een transactie kan worden afgerond. Zodra een transactie is vastgelegd in een BFT-systeem, kan er geen concurrerende transactie voor hetzelfde geld worden vastgelegd zonder de tweederde-drempel te overschrijden.

Eclips-aanvallen

Bij een eclipse-aanval isoleert een aanvaller een specifiek knooppunt door het te omringen met kwaadwillende peers, waardoor alle informatie die het knooppunt ontvangt, wordt gecontroleerd. Een succesvol geëclipseerd knooppunt kan valse informatie over de blockchainstatus ontvangen. BFT-protocollen beschermen hiertegen door overeenstemming te vereisen van een supermeerderheid van alle validators, en niet alleen van de directe buren van een knooppunt. Zelfs als één knooppunt wordt geëclipseerd, zal de bredere, eerlijke meerderheid transacties afwijzen die in strijd zijn met de werkelijke blockchainstatus.

Sybil-aanvallen

Een Sybil-aanval houdt in dat een aanvaller meerdere valse node-identiteiten creëert om een ​​onevenredig grote invloed op een netwerk te verkrijgen. In permissioned BFT-systemen worden Sybil-aanvallen voorkomen door te vereisen dat validators formeel geregistreerd en geauthenticeerd zijn. In proof-of-stake BFT-systemen zoals Ethereum komt de Sybil-resistentie voort uit de economische kosten van staking: het creëren van meerdere validators vereist het staken van reële waarde voor elk ervan, waardoor Sybil-aanvallen duur zijn om op grote schaal uit te voeren.

De aanvalsdrempel van 33%

Klassieke BFT-protocollen bieden alleen veiligheidsgaranties wanneer minder dan een derde van de knooppunten Byzantijns is. Als een aanvaller meer dan een derde van de validators (of meer dan een derde van de ingezette waarde in PoS-BFT-systemen) beheert, vervalt de veiligheidsgarantie van het protocol. Dit is de fundamentele beperking van BFT-consensus. Het betekent niet dat een aanvaller met 33% controle willekeurige fondsen kan stelen, maar wel dat hij de finaliteit kan belemmeren of, in het ergste geval, eerlijke knooppunten ertoe kan brengen tegenstrijdige statussen vast te leggen.

Daarom is de drempel van 33% een cruciale factor in het beveiligingsmodel van elk op BFT gebaseerd systeem. Protocollen zoals Casper van Ethereum voegen daar bovenop de BFT-drempel economische slashing toe: zelfs als een aanvaller een derde van de ingezette ETH bereikt, zou een succesvolle aanval op de finaliteit vereisen dat de volledige inzet wordt geslasht, waardoor de aanval economisch verwoestend is voor de aanvaller.

Berichtmanipulatie en replay-aanvallen

zonder cryptografische handtekeningenEen Byzantijns knooppunt zou berichten tussen eerlijke knooppunten kunnen onderscheppen en wijzigen, of oude geldige berichten opnieuw kunnen versturen om het consensusproces te verstoren. BFT-protocollen beschermen zich tegen berichtmanipulatie door te vereisen dat elk consensusbericht wordt ondertekend met de privésleutel van de afzender. Sequentienummers en ronde-identificaties die in berichten zijn ingebed, voorkomen dat geldige berichten uit de ene ronde in een latere ronde opnieuw worden verstuurd om verwarring te veroorzaken.

Voordelen van Byzantijnse fouttolerantie in blockchain

Deterministische, onmiddellijke transactieafhandeling

Het misschien wel belangrijkste praktische voordeel van BFT-consensus ten opzichte van proof-of-work-systemen is de onmiddellijke finaliteit. In Bitcoin is een transactie nooit wiskundig definitief; het wordt alleen maar moeilijker om de transactie terug te draaien naarmate er meer blokken worden toegevoegd. In een BFT-systeem is de transactie, zodra de drempel van tweederde is bereikt in de commitfase, met zekerheid definitief onder de aannames van het protocol. Er is geen wachttijd voor verdere bevestigingen.

Dit is van enorm belang voor financiële toepassingen. Betaalnetwerken kunnen niet efficiënt werken als elke transactie uren later nog kan worden teruggedraaid. Gedecentraliseerde financiële toepassingen vereisen betrouwbare finaliteit voor liquidaties, leningen en de afwikkeling van derivaten. Communicatie tussen verschillende blockchains via protocollen zoals IBC vereist dat de ene blockchain aan de andere bewijst dat een specifieke transactie daadwerkelijk definitief is.

Energie-efficiëntie

Het klassieke BFT-consensusmechanisme vereist niet de enorme rekenkracht die Bitcoin's proof-of-work vereist. Validators stemmen met behulp van digitale handtekeningen, niet door rekenintensieve puzzels op te lossen. Dit maakt BFT aanzienlijk energiezuiniger. De overgang van Ethereum naar PoS-BFT verminderde het energieverbruik met ongeveer 99.95%, een reductie die specifiek mogelijk werd gemaakt doordat proof-of-work werd vervangen door een BFT-achtig stemmechanisme voor validators.

Weerstand tegen netwerkstoringen en kwaadwillige knooppunten

Een goed geïmplementeerd BFT-protocol blijft correct functioneren zolang tweederde van de knooppunten betrouwbaar en verbonden blijft. Het protocol kan crashes, netwerkonderbrekingen (tijdelijk), Byzantijnse knooppunten en combinaties hiervan tegelijkertijd afhandelen. Deze veerkracht is precies wat openbare blockchainnetwerken nodig hebben: ze kunnen niet van tevoren weten welke knooppunten zullen uitvallen of zich kwaadwillig zullen gedragen, dus het consensusprotocol moet willekeurige storingen op een elegante manier kunnen opvangen.

Hoge doorvoer voor toegangsbeheersystemen

BFT-protocollen in omgevingen met toegangsbeheer, zoals Hyperledger Fabric, kunnen een zeer hoge transactiedoorvoer bereiken. Omdat de set validators vast en bekend is, zijn de communicatiekosten voorspelbaar en optimaliseerbaar. Implementaties in grote bedrijven bereiken routinematig duizenden transacties per seconde met een finaliteit van minder dan een seconde, prestaties die onmogelijk zijn met proof-of-work en zelfs een uitdaging vormen voor veel proof-of-stake-systemen.

Beveiliging tegen Byzantijnse fouten en gecoördineerde aanvallen

BFT-mechanismen bieden robuuste bescherming tegen gecoördineerde Byzantijnse aanvallen. Een groep samenspannende kwaadwillende knooppunten die minder dan een derde van de validatoren vertegenwoordigt, kan de consensus niet verstoren, ongeacht hoe strategisch ze te werk gaan. Ze kunnen eerlijke knooppunten niet beletten overeenstemming te bereiken, kunnen geen valse transacties in de overeengekomen geschiedenis injecteren en kunnen eerlijke knooppunten niet dwingen tot conflicterende acties. Deze sterke veiligheidsgarantie is wiskundig bewezen, niet alleen empirisch waargenomen.

Uitdagingen en beperkingen van de Byzantijnse fouttolerantie

Schaalbaarheidsbeperkingen

De fundamentele uitdaging bij klassieke BFT-algoritmen is dat de communicatiecomplexiteit toeneemt met het aantal validators. De berichtcomplexiteit van PBFT van O(n²) betekent dat het toevoegen van meer validators al snel onpraktisch wordt. Een netwerk met 100 PBFT-validators vereist tot 10,000 berichten per consensusronde. Bij 1,000 validators loopt dit op tot 1,000,000 berichten.

HotStuff en zijn afgeleiden pakten dit drastisch aan door de complexiteit te reduceren tot lineair O(n) via drempelwaarde-signatuuraggregatie. Maar zelfs lineaire complexiteit heeft praktische beperkingen. De meeste huidige BFT-gebaseerde openbare blockchains hebben validator-sets van enkele honderden tot een paar duizend, in plaats van de tienduizenden die het miningnetwerk van Bitcoin omvat.

Deze schaalbaarheidslimiet is de reden waarom BFT-consensus gebruikelijk is in permissioned blockchains en proof-of-stake-netwerken met een beperkt aantal validators, terwijl permissionless proof-of-work het mechanisme blijft voor netwerken die onbeperkte deelname prioriteren.

Afhankelijkheid van een bekende validatieset

De meeste BFT-protocollen vereisen een gedefinieerde, geauthenticeerde set validators. Dit werkt goed in omgevingen met toegangsbeperkingen en in proof-of-stake-netwerken waar validators kapitaal inzetten om hun plaats te verdienen. Het is veel moeilijker in volledig toegangsvrije omgevingen waar iedereen zonder registratie kan deelnemen. Bitcoin's proof-of-work heeft de toegangsvrije versie van het Byzantijnse Generaalsprobleem specifiek opgelost omdat PoW niet vereist dat van tevoren bekend is wie de deelnemers zijn.

Prestatie overhead

Het bereiken van Byzantijnse fouttolerantie vereist aanzienlijk meer communicatie tussen knooppunten dan niet-Byzantijnse fouttolerante systemen. De meerfasige stemming die nodig is in PBFT-achtige protocollen, de noodzaak om grote aantallen cryptografisch ondertekende berichten te verzamelen en te verifiëren, en de coördinatiekosten van view-change-protocollen (het afhandelen van uitvallende leiders) verhogen allemaal de latentie en de rekenkosten. Voor toepassingen die duizenden transacties per seconde met een zeer lage latentie vereisen, zijn deze overheadkosten een zorgvuldige engineering.

Complexiteit van een correcte implementatie

De wiskundige bewijzen die ten grondslag liggen aan BFT-algoritmen zijn exact: het protocol is veilig en operationeel als het precies volgens de specificaties wordt geïmplementeerd. Maar software is zelden exact zoals gespecificeerd. Werkelijke implementaties bevatten gelijktijdigheidsfouten, randgevallen in netwerkafhandeling, kwetsbaarheden in berichttiming en cryptografische implementatiefouten die de garanties van het protocol in de praktijk kunnen schenden, zelfs als het theoretische ontwerp deugdelijk is. De ketenstoring van Cosmos Hub v17.1 illustreert dit: de kernveiligheidsgarantie van BFT bleef gehandhaafd, maar een softwarefout in de omringende code veroorzaakte een productiestop. Een correcte BFT-implementatie vereist extreme nauwkeurigheid in de gehele implementatiestack, niet alleen in de logica van de consensusronde.

Kwetsbaarheid bij de drempel van 33%

De eis van een eerlijke meerderheid van 33% is zowel de kracht als de harde grens van BFT. Zolang aan deze aanname wordt voldaan, is het systeem veilig. Maar als een aanvaller de controle krijgt over een derde of meer van de validators (of een derde van de ingezette waarde in PoS-BFT-systemen), vervallen de veiligheidsgaranties. In de praktijk vereist dit enorme middelen voor gevestigde netwerken, maar kleinere netwerken met een lagere totale ingezette waarde zijn kwetsbaarder voor deze aanval.

De toekomst van Byzantijnse fouttolerantie in blockchain

Post-Quantum BFT

De huidige BFT-protocollen zijn gebaseerd op cryptografische handtekeningschema's die kwetsbaar zijn voor kwantumcomputers. Een voldoende krachtige kwantumcomputer zou de publieke-sleutelcryptografie kunnen kraken die BFT-protocollen gebruiken om de stemmen van validators te authenticeren. Onderzoek naar post-kwantum BFT richt zich actief op handtekeningschema's die bestand zijn tegen kwantumaanvallen, waaronder op roosters en hash gebaseerde cryptografie. De hardwarewallet Trezor Safe 7 implementeert al NIST-gestandaardiseerde post-kwantumcryptografie voor firmwareverificatie, wat aangeeft dat het bredere cryptografische ecosysteem zich ontwikkelt richting kwantumresistentie. BFT-protocollen zullen dit voorbeeld moeten volgen naarmate kwantumcomputers zich verder ontwikkelen.

Asynchrone BFT-protocollen

Klassieke PBFT en de meeste afgeleide varianten ervan zijn gebaseerd op de aanname van gedeeltelijke synchronisatie: ze gaan ervan uit dat berichtvertragingen uiteindelijk begrensd zijn, zelfs als die grens onbekend is. Onder volledig asynchrone omstandigheden (waarbij berichtvertragingen willekeurig lang kunnen zijn) bewijst de FLP-onmogelijkheidsstelling dat deterministische consensus onmogelijk is. Gerandomiseerde asynchrone BFT-protocollen die gebruikmaken van verifieerbare willekeurige functies kunnen echter probabilistische consensus bereiken, zelfs onder volledige asynchronie. HoneyBadgerBFT en Dumbo zijn voorbeelden van asynchrone BFT-protocollen die zijn ontworpen om betrouwbaar te werken, zelfs wanneer de netwerkcondities ernstig verslechterd zijn.

Schaalbaarheid door middel van sharding en Layer 2

Een veelbelovende aanpak om de schaalbaarheidslimiet van BFT te bereiken, is het parallel uitvoeren van meerdere BFT-instanties via sharding. Hierbij wordt het netwerk verdeeld in subsets (shards) die elk hun eigen BFT-consensus uitvoeren op een deel van de transacties. De roadmap van Ethereum omvat sharding in combinatie met BFT-achtige finaliteit. De app-chain-architectuur van Cosmos is een andere vorm van horizontale schaling: elke applicatie draait zijn eigen CometBFT-chain, waardoor de consensuslast wordt verdeeld. Layer 2-oplossingen zoals rollups voegen een extra dimensie toe door transacties off-chain te bundelen en BFT-beveiligde chains te gebruiken voor de uiteindelijke afwikkeling.

BFT in het Internet der Dingen

IoT-netwerken bieden een overtuigende toepassing voor BFT-consensus. Miljarden IoT-apparaten moeten veilig data coördineren en delen via gedistribueerde netwerken, waar individuele apparaten fysiek kwetsbaar kunnen zijn, zonder stroom kunnen komen te zitten of opzettelijk gemanipuleerd kunnen worden. Onderzoek uit 2025 toont aan dat op BFT gebaseerde algoritmen de lage latentie bieden die IoT-toepassingen vereisen, hoewel de hoge rekenkosten en de kwetsbaarheid voor aanvallen van 33% toegangsbeheer vereisen voor IoT-implementaties. Internet van dingen Het vertegenwoordigt een van de snelstgroeiende gebieden voor BFT-onderzoek en -implementatie.

BFT in gedecentraliseerde financiën

Gedecentraliseerde financiering Applicaties, die in 2025 een totale waarde van meer dan $56.3 miljard aan vastgezette waarde hadden, zijn fundamenteel afhankelijk van BFT-consensus voor de betrouwbaarheid van hun werking. Liquidaties, orakelprijsfeeds, leenposities en de afwikkeling van derivaten vereisen allemaal betrouwbare en snelle finaliteit. Elk belangrijk DeFi-protocol draait op blockchains met BFT-consensus: Ethereum met Casper, Cosmos Chains met CometBFT en Stellar met FBA. Naarmate DeFi-applicaties geavanceerder worden en meer waarde verwerken, wordt de vraag naar BFT-garanties juist crucialer.

Interoperabiliteit tussen BFT-systemen

De toekomst van blockchain is steeds meer gericht op meerdere blockchains. Activa en berichten worden uitgewisseld tussen Ethereum, Cosmos Chain, Stellar, Hyperledger-netwerken en andere. Cross-chain interoperabiliteit vereist dat elke keten de finaliteitsbewijzen van transacties op andere ketens verifieert. De directe finaliteit van BFT maakt dit aanzienlijk eenvoudiger: een gefinaliseerd BFT-bewijs is compact en verifieerbaar, in tegenstelling tot probabilistische finaliteit. proof-of-workDit vereist dat er op veel bevestigingen wordt gewacht voordat een cross-chain-transactie veilig kan worden uitgevoerd. Het IBC-protocol in het Cosmos-ecosysteem en de cross-chain-brugontwerpen in het bredere ecosysteem zijn beide afhankelijk van BFT-finaliteit om veilig te functioneren. Onderzoek naar interoperabiliteit is een van de meest actieve onderzoeksgebieden in het ontwerp van BFT-protocollen.

Veelgestelde Vragen / FAQ