Consensus bereiken door te stemmen over het volgende block
Tot nu toe bespraken we steeds Proof-of-Stake algoritmen die blocks probeerden te maken volgens hetzelfde principe als Proof-of-Work, namelijk door het oplossen van een puzzel. Een alternatief is de deelnemers te laten stemmen over het wel of niet accepteren van een voorgesteld block.
Dat stemmen gebeurt in meerdere rondes en wordt ook wel Byzantine Agreement genoemd. Het verwijst naar het Byzantine General's Problem, waarbij consensus moet worden bereikt over de situatie, terwijl onbekend is welke deelnemers kapot zijn of frauduleus.
De byzantijnse generaals
Het is het jaar 537 na Christus. Het grote Romeinse Rijk zoals wij dat kennen uit de geschiedenisboeken is een paar eeuwen eerder al uit elkaar gevallen in een oostelijk en een westelijk deel. Van het westelijk deel is weinig meer over. In West-Europa beginnen de donkere Middeleeuwen.
Met het Oost-Romeinse Rijk, ook wel het Byzantijnse Rijk genoemd, gaat het voorspoedig. Vanuit hoofdstad Constantinopel regeert keizer Justinianus de eerste, en hij verovert land na land.
Het verhaal gaat dat het leger eens een vijandige stad omcirkelde. Het leger bestond uit zelfstandige eenheden, elk geleid door een generaal. Om een pijnlijke nederlaag te voorkomen moeten de generaals tot een gezamenlijk besluit komen. Aanvallen of terugtrekken? En op welk moment?
Er is een aantal moeilijkheden.
- Er zijn nog geen mobiele telefoons. De generaals kunnen elkaar alleen bereiken via boodschappers.
- De boodschappers kunnen te laat komen of helemaal niet komen, of twee keer komen. Of ze kunnen de boodschap expres of per ongeluk aanpassen.
- Sommige generaals zijn verraders die niet naar iedereen hetzelfde bericht sturen. Tegen de één zeggen ze aanvallen, tegen de ander terugtrekken.
Wat voor systeem kunnen we verzinnen om de (loyale) generaals tot een verstandig gezamenlijk besluit te laten komen?
Byzantine Fault Tolerant
Het systeem dat we zoeken is trustless - het is niet nodig dat je iemand of iedereen vertrouwt om het systeem te laten werken.
En het systeem moet leiden tot consensus - zonder dat de generaals elkaar zien en vertrouwen moeten ze overeenstemming bereiken over de keuze die ze maken.
Een systeem dat hieraan voldoet noemen we Byzantine Fault Tolerant (BFT).
Het zal je niet verbazen dat Proof-of-Work, zoals dat door Bitcoin gebruikt wordt, hieraan voldoet. Maar Satoshi was niet de eerste.
De bedenkers van de Byzantijnse generaals, die in 1982 voor Byzantijns kozen omdat dit niemand zou beledigen, gaven direct al een aantal mogelijke oplossingen, en in de jaren erna kwamen er verschillende bij.
Niet alleen blockchains gebruiken dit principe. Ook bijvoorbeeld in kerncentrales, vliegtuigen en ruimtevaartuigen worden BFT-systemen gebruikt om te kunnen omgaan met fouten in sensoren en verbindingen.
Andere BFT-algoritmen
Het is dan ook niet verbazingwekkend dat verschillende blockchains een ander BFT-algoritme gebruiken om tot consensus te komen dan Proof-of-Work. Een bekend algoritme is Practical BFT (PBFT), dat gebruikt wordt door Ripple en Stellar.
Bij PBFT hoeven geen puzzels te worden opgelost. Er wordt (in een aantal rondes) gestemd of een voorgesteld block geaccepteerd wordt of niet.
Om deelnemers te stimuleren mee te doen met stemmen, kan een beloning worden gegeven. Die wordt verdeeld naar rato van je inzet. Op die manier is het een andere vorm van Proof-of-Stake.
Die beloning hoeft niet te bestaan uit de block reward, maar kan ook beperkt worden tot de transactiekosten. Zo kun je een blockchain maken zonder inflatie.
Het kan zelfs helemaal zonder beloning. Bijvoorbeeld als het bedrijf achter de blockchain zelf voorziet in de nodes. Een blockchain is dan misschien nog wel publiek maar niet meer permissionless. Zo hebben o.a. IBM en Intel een implementatie gemaakt van de Hyperledger-specificatie waarmee (grote) bedrijven hun eigen op blockchain gebaseerde applicaties kunnen bouwen.
Proof-of-Work is toch beter?
Als nadeel van PBFT wordt soms genoemd dat een aanvaller maar 33% van het netwerk in handen hoeft te hebben om het netwerk over te nemen, waar dat bij Proof-of-Work pas bij 51% lukt.
Dat is maar ten dele waar. Die 51% van Proof-of-Work is het theoretische maximum, en neemt af naarmate het meer tijd kost voordat alle deelnemers van alle informatie op de hoogte zijn. In deze FAQ van Ethereum wordt gesteld dat de fault tolerance bij Ethereum in de praktijk op ongeveer 46% ligt.
Maar al eerder kan een aanvaller een blockchain destabiliseren. Als je 25% van het netwerk in handen hebt is selfish mining al interessant.
Wat dit betreft dus geen reden om PBFT-blockchains te laten liggen!
Andere algoritmen
Veel nieuwe projecten komen met "nieuwe methoden" om consensus te bereiken, maar vaak zijn ze een variatie op het puzzelen van PoW of het stemmen van BFT.
Zo'n variatie heeft dan als doel om een kortere transactietijd, meer transacties per seconde of meer bescherming tegen aanvallers te realiseren.
Bijvoorbeeld Delegated Proof-of-Stake (DPoS) waarbij delegates namens andere nodes mogen stemmen, zoals bij BitShares, EOS, Lisk en Steem.
Een variatie die we in het volgende artikel bekijken zijn masternodes, die aan het netwerk worden toegevoegd om bijzondere taken te vervullen.
Iedereen heeft een mening
Onder de noemer Opinie schrijven we regelmatig over een spraakmakende podcast, video of tweetstorm.
We zijn het niet noodzakelijkerwijs eens met de spreker of schrijver, maar vinden het interessant genoeg om
te delen, duiden en ondertitelen.
Over de auteur
