Wat is CometBFT en hoe werkt het?

Wat is CometBFT?

CometBFT is open-source software die ervoor zorgt dat meerdere computers het eens kunnen worden over dezelfde blockchaingegevens. Simpel gezegd: het helpt nodes om transacties in dezelfde volgorde te zetten en allemaal dezelfde bijgewerkte toestand van een blockchain te bewaren.

Dat proces heet Byzantine Fault Tolerant, of BFT. Daarbij gaat het systeem ervan uit dat sommige deelnemers fouten kunnen maken, offline kunnen gaan of zelfs expres verkeerd kunnen handelen. Zolang minder dan een derde van de totale stemkracht zich zo gedraagt, voorkomt CometBFT dat twee verschillende blocks op dezelfde plek in de blockchain definitief worden gemaakt.

CometBFT is de opvolger van Tendermint Core en gebruikt het Tendermint-consensusalgoritme. Het is geen kant-en-klare blockchain en ook geen compleet crypto-project met eigen vaste regels. De software regelt vooral consensus, communicatie tussen nodes en de productie van blocks. De regels van de blockchain zelf, zoals welke transacties geldig zijn, zitten in een aparte applicatie.

De verbinding tussen CometBFT en die applicatie heet ABCI, kort voor Application Blockchain Interface. Je kunt ABCI zien als een vaste communicatielaag: CometBFT vraagt bijvoorbeeld of een transactie geldig is, en de applicatie geeft antwoord. Zo kunnen ontwikkelaars hun eigen blockchainlogica bouwen zonder ook helemaal zelf een consensusengine te hoeven maken.

Korte samenvatting

• CometBFT is open-source software voor consensus en het synchroniseren van blockchaingegevens tussen nodes.
• Het gebruikt BFT-consensus, waardoor fouten of kwaadwillend gedrag van een deel van de validators kan worden opgevangen.
• CometBFT is een fork en opvolger van Tendermint Core.
• De software bepaalt niet zelf welke transacties inhoudelijk geldig zijn; dat doet de aangesloten applicatie.
• ABCI vormt de verbinding tussen CometBFT en de blockchainapplicatie.

Hoe werkt de consensus van CometBFT?

CometBFT laat validators per block samenwerken via drie vaste stappen: propose, prevote en precommit. Een validator is hierbij een deelnemer die blocks en stemmen mag ondertekenen. Niet iedere node is dus automatisch een validator.

Elke nieuwe positie in de blockchain heet een block height. Op iedere height probeert het netwerk één nieuw block te besluiten. Eerst wijst het protocol een proposer aan. Dat is de validator die voor die ronde een voorstel voor een nieuw block mag verspreiden.

Daarna bekijken de andere validators het voorstel. Is het block geldig en op tijd ontvangen? Dan brengen ze een prevote uit: een eerste stem voor dat block. Is er genoeg overeenstemming, dan volgt een precommit: de tweede en beslissende stem.

Een block is gecommit zodra meer dan twee derde van alle stemkracht een precommit voor precies hetzelfde block heeft gegeven. Stemkracht gaat niet per se over het aantal validators. Eén validator kan bijvoorbeeld meer stemkracht hebben dan een andere, afhankelijk van de regels van de blockchainapplicatie.

Voorbeeld: Stel dat de totale stemkracht 100 is. Dan zijn er meer dan 66 stemmen nodig om een block te committen. Het maakt daarbij niet uit of die stemkracht van veel kleine validators of een kleiner aantal grotere validators komt.

Komt er geen geldig voorstel, is de proposer offline of komen stemmen te laat binnen? Dan begint dezelfde block height opnieuw in een volgende ronde. De wachttijden kunnen per ronde oplopen, zodat trage nodes alsnog kunnen bijtrekken. Dat voorkomt geen vertraging, maar geeft het netwerk wel een manier om verder te gaan wanneer een ronde mislukt.

Welke rol spelen validators in CometBFT?

Validators maken de beslissingen in CometBFT. Ze ondertekenen blockvoorstellen en stemmen, controleren voorstellen en helpen zo bepalen welk block wordt toegevoegd. Een gewone node kan informatie doorgeven aan andere nodes, maar zonder private validator key kan die node niet zelf meestemmen in consensus.

De proposer wordt automatisch en voorspelbaar gekozen via een round-robin-schema. Validators met meer stemkracht komen daarbij naar verhouding vaker aan de beurt om een voorstel te doen.

In de praktijk doet een validator het volgende:

• de validator ontvangt een blockvoorstel;
• de validator controleert of het voorstel geldig is volgens de regels van de applicatie;
• bij een geldig en tijdig voorstel volgt een prevote;
• bij voldoende prevotes kan een precommit volgen;
• na genoeg precommits wordt het block gecommit.

Is er geen geldig voorstel ontvangen, dan kan een validator op nil stemmen. Dat betekent simpelweg: geen stem voor een specifiek block in deze ronde. Zo kan het netwerk naar een volgende ronde gaan zonder zomaar een onjuist voorstel te accepteren.

De validatorset en de verdeling van stemkracht komen als input vanuit de blockchainapplicatie. Die applicatie kan dus ook regels hebben voor het aanpassen van de validatorset. Staking, delegatie en slashing zijn geen vaste autonome functies van CometBFT zelf. De applicatie bepaalt of zulke regels bestaan en hoe ze werken.

Nog iets belangrijks: validator signing keys moeten goed beveiligd zijn. Als dezelfde validator conflicterende berichten ondertekent, kan dat bewijs zijn van Byzantijns gedrag. CometBFT kan dit soort bewijs verwerken, maar een eventuele financiële straf bepaalt de applicatie.

Hoe verloopt de communicatie tussen validators?

Validators communiceren via een peer-to-peer-netwerk, vaak afgekort tot P2P. Nodes sturen informatie door aan andere nodes via gossip. Dat klinkt informeel, maar het betekent gewoon dat berichten zich van node naar node door het netwerk verspreiden.

Via die gossip worden onder meer transacties, blockdelen, voorstellen, prevotes en precommits verspreid. Nodes delen ook hun huidige status: op welke block height ze zitten, in welke ronde ze zijn en welke stap van de consensus ze uitvoeren. Daardoor kan een node die achterloopt zien wat er gebeurt en weer aansluiten.

Ook niet-validerende nodes kunnen hierbij nuttig zijn. Zij mogen voorstellen, blocks en stemmen doorsturen, ook al brengen ze zelf geen consensusstem uit. Dat helpt om informatie breed door het netwerk te verspreiden.

Transacties die de applicatie via CheckTx voldoende geldig vindt, kunnen in de mempool terechtkomen. De mempool is eigenlijk een wachtruimte voor transacties die mogelijk in een volgend block komen. Via gossip kunnen die transacties verder worden verspreid. Dat is alleen geen garantie dat een transactie ook echt wordt opgenomen: de proposer, blocklimieten en de applicatieregels spelen daarbij allemaal mee.

De communicatie tussen nodes moet je niet verwarren met ABCI. P2P en gossip gaan over berichten tussen nodes in het netwerk. ABCI gaat juist over de lokale communicatie tussen CometBFT en de blockchainapplicatie, bijvoorbeeld binnen hetzelfde proces, via een socket of via gRPC.

Hoe is CometBFT opgebouwd?

CometBFT bestaat grofweg uit een consensusdeel en een applicatiedeel, met ABCI als verbinding ertussen. Die scheiding is handig: de ene kant regelt hoe nodes het eens worden, de andere kant bepaalt wat de blockchain daadwerkelijk doet.

De CometBFT-engine bevat onder meer onderdelen voor consensus, P2P-communicatie, de mempool, het verspreiden van blocks, het bewaren van toestand en een RPC-server. Via die RPC-server kunnen clientapplicaties gegevens over consensus en de blockchain opvragen.

De applicatie beheert juist de eigen regels en gegevens. Denk aan de vraag of een transactie geldig is, hoe saldo's veranderen of welke andere handelingen de blockchain ondersteunt. In veel Cosmos SDK-nodes draaien CometBFT en de applicatie samen in één daemon, maar ze kunnen ook als aparte processen samenwerken via ABCI.

Belangrijk om te weten: CometBFT roept de applicatie aan via ABCI. De applicatie stuurt CometBFT dus niet aan, maar geeft antwoorden wanneer CometBFT daar tijdens de lifecycle van een transactie of block om vraagt.

Wat doet de consensuslaag?

De consensuslaag van CometBFT regelt wanneer en hoe nieuwe blocks worden besloten. Deze laag verzorgt BFT-consensus, P2P-netwerking, blockproductie en het verspreiden van blocks naar nodes.

Bij ieder nieuw block kiest het protocol een proposer en begeleidt het de propose-, prevote- en precommit-rondes. Zodra er meer dan twee derde van de stemkracht voor hetzelfde block heeft geprecommit, is dat block gecommit.

De consensuslaag beheert ook de mempool. Wanneer een node een transactie ontvangt, vraagt CometBFT via ABCI aan de applicatie of die transactie geschikt is voor de mempool. Die controle heet CheckTx. Een geslaagde CheckTx betekent nog niet dat de transactie definitief is uitgevoerd. Het betekent alleen dat de transactie in aanmerking kan komen voor een later blockvoorstel.

Na consensus over een block zorgt CometBFT ervoor dat de applicatie het block uitvoert en de nieuwe toestand opslaat. De consensuslaag bepaalt dus niet zelf of een transactie inhoudelijk klopt. Dat blijft de taak van de applicatie.

Wat doet de applicatielaag?

De applicatielaag bepaalt de regels van de blockchain. Daar staat bijvoorbeeld welke gegevens worden bijgehouden, welke transacties geldig zijn en hoe een geldige transactie de toestand verandert.

Deze laag is de deterministische state machine van de blockchain. Dat is een technische term voor iets simpels: krijgen twee nodes dezelfde input, dan moeten ze ook precies dezelfde uitkomst berekenen. Anders kunnen nodes verschillende versies van de blockchain krijgen, en dat werkt natuurlijk niet.

In een Cosmos SDK-applicatie bestaat deze laag onder meer uit modules, transactieverwerking en state stores. De actuele toestand krijgt ook een cryptografische samenvatting, de AppHash. Als nodes na hetzelfde block verschillende AppHash-waarden berekenen, wijst dat op een probleem met de uitvoering.

Via ABCI behandelt de applicatie verschillende momenten in het proces:

• CheckTx: controleert of een ontvangen transactie in de mempool mag.
• PrepareProposal: laat de proposerapplicatie transacties voor een blockvoorstel kiezen, sorteren, weglaten of toevoegen binnen de geldende limieten.
• ProcessProposal: laat andere validators beoordelen of zij het voorstel accepteren.
• FinalizeBlock: voert een block uit nadat consensus is bereikt.
• Commit: slaat de nieuwe toestand blijvend op.

Niet elke ABCI-aanroep heeft exact dezelfde eisen. PrepareProposal mag bijvoorbeeld verschillen, omdat alleen de proposer deze uitvoert. ProcessProposal en de uitvoering van blocks moeten juist deterministisch zijn, zodat alle validators tot dezelfde uitkomst komen.

Waarvoor wordt CometBFT gebruikt?

CometBFT wordt gebruikt als algemene consensus- en replicatie-engine voor blockchains met eigen regels. Ontwikkelaars kunnen er dus een deterministische applicatie achter zetten, in plaats van vanaf nul een systeem te bouwen waarin nodes het over blocks eens moeten worden.

De mogelijke toepassingen lopen uiteen. Een blockchainapplicatie kan bijvoorbeeld draaien om currencies, e-voting of infrastructuurorkestratie. CometBFT legt daarbij niet vast wat de toepassing moet zijn. Het levert de technische basis om dezelfde transacties en toestand betrouwbaar over meerdere nodes te kopiëren.

Binnen de Cosmos Stack heeft CometBFT een duidelijke rol: het regelt consensus, netwerkcommunicatie en blockproductie. De Cosmos SDK levert vervolgens de bouwstenen voor de applicatielogica. Zo hoeven ontwikkelaars niet beide onderdelen helemaal zelf te ontwikkelen.

CometBFT heeft daarnaast een eigen RPC-server. Een wallet, dApp of andere client kan die gebruiken om gegevens over blocks en consensus op te vragen, naast de API's van een Cosmos SDK-applicatie.

Hoe werkt CometBFT samen met Cosmos SDK?

CometBFT en Cosmos SDK vullen elkaar aan: CometBFT regelt consensus en de Cosmos SDK regelt de blockchainapplicatie. Het zijn dus twee verschillende onderdelen die samen één werkende blockchainnode kunnen vormen.

De Cosmos SDK biedt modules, transactieverwerking, state management en andere applicatieregels. CometBFT regelt ondertussen de P2P-communicatie, de mempool, het kiezen van een proposer en het bereiken van consensus over nieuwe blocks.

De brug tussen beide is ABCI. In een Cosmos SDK-applicatie implementeert BaseApp deze interface. CometBFT doet vervolgens verzoeken zoals CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock en Commit. BaseApp verwerkt die verzoeken en stuurt een antwoord terug.

Bij een nieuw voorstel kiest CometBFT eerst een proposer op basis van validatorstemkracht. Daarna kan de applicatie van die proposer via PrepareProposal bepalen welke transacties in het voorstel komen en in welke volgorde, binnen de blocklimieten. Andere validators beoordelen het voorstel via ProcessProposal voordat ze stemmen.

Die verdeling is praktisch. Ontwikkelaars kunnen werken aan een eigen blockchainapplicatie, terwijl de beproefde consensusengine apart blijft. Daardoor kan dezelfde CometBFT-engine ook bij verschillende SDK-applicaties worden gebruikt.

Wat zijn de voordelen van CometBFT?

Een belangrijk voordeel van CometBFT is de duidelijke BFT-safety. Zolang minder dan een derde van de relevante validatorstemkracht Byzantijns gedrag vertoont, worden geen conflicterende blocks op dezelfde block height gecommit.

Daarnaast is de scheiding tussen consensus en applicatielogica erg handig. Via ABCI kan een ontwikkelaar eigen blockchainregels maken zonder zelf een volledige BFT-consensusengine te bouwen. Dat maakt de technische taken overzichtelijker: CometBFT regelt het eens worden, de applicatie regelt de inhoud.

Andere voordelen zijn:

• Duidelijk stemproces: een block wordt pas besloten na meer dan twee derde precommits voor datzelfde block.
• Herbruikbare techniek: dezelfde engine kan verschillende blockchainapplicaties ondersteunen.
• Flexibele koppeling: ABCI kan in-process in Go werken, maar ook via socket of gRPC.
• Scheiding van verantwoordelijkheden: consensuscode en applicatiecode kunnen los van elkaar worden ontwikkeld.

Wel belangrijk: zulke voordelen betekenen niet automatisch dat iedere blockchain met CometBFT snel, veilig of sterk gedecentraliseerd is. Dat hangt ook af van de validatorset, netwerkverbindingen, hardware, configuratie en de code van de applicatie.

Welke beperkingen en risico’s heeft CometBFT?

CometBFT heeft duidelijke veiligheidsvoorwaarden en operationele risico's. De belangrijkste voorwaarde is dat minder dan een derde van de validatorstemkracht Byzantijns mag zijn. Byzantijns betekent hier dat validators zich foutief of kwaadwillend gedragen, bijvoorbeeld door tegenstrijdige informatie te versturen, regels niet te volgen of samen te werken om het netwerk te manipuleren. Wordt die grens overschreden, dan geldt de safety-garantie tegen conflicterende commits niet meer.

Ook voor voortgang is genoeg actieve stemkracht nodig. Als validators met voldoende stemkracht offline zijn, of door een netwerkpartitionering niet met elkaar kunnen communiceren, kan het netwerk geen quorum bereiken. Dan volgen nieuwe rondes en kan blockproductie vertragen of tijdelijk stilstaan.

Netwerkvertraging speelt hierbij een grote rol. Komen voorstellen, blockdelen of stemmen niet op tijd aan, dan loopt de ronde af en probeert het protocol het opnieuw. De time-outs kunnen vervolgens oplopen. Dat helpt trage deelnemers, maar betekent ook dat bevestigingen langer kunnen duren.

De applicatie achter ABCI is een ander belangrijk aandachtspunt. Waar determinisme vereist is, moet iedere node bij dezelfde input dezelfde uitkomst geven. Een fout waardoor nodes verschillende resultaten berekenen, kan AppHash-mismatches en consensusproblemen veroorzaken. De scheiding tussen CometBFT en de applicatie voorkomt dus niet alle gevolgen van slechte applicatiecode.

Validator keys en node-infrastructuur zijn eveneens gevoelig. Slecht beveiligde signing keys kunnen misbruikt worden en validators kunnen doelwit zijn van denial-of-service-aanvallen. Een sentry-node-architectuur kan helpen om validatornodes minder direct bloot te stellen aan zulke aanvallen.

Verder is een transactie in de mempool nog niet veilig opgenomen in een block. Nodes kunnen crashen voordat een transactie in een voorstel terechtkomt, waardoor de transactie verloren kan gaan uit de mempool. Wie een transactie verstuurt, moet dus wachten tot die echt in een gecommit block staat.

Tot slot kunnen versie-upgrades compatibiliteitsproblemen geven. Breaking changes in een minor release kunnen een nieuwe chain of een eigen datamigratie nodig maken. Upgraden vraagt daardoor om goede voorbereiding, zowel bij de applicatie als bij de nodes die de blockchain draaien.

Conclusie

CometBFT is de technische motor die blockchainnodes helpt om het eens te worden over nieuwe blocks en dezelfde toestand te bewaren. Het werkt met een BFT-consensusproces waarin validators voorstellen doen, stemmen en een block pas committen wanneer meer dan twee derde van de stemkracht hetzelfde block goedkeurt.

De kracht zit vooral in de verdeling van werk. CometBFT regelt consensus, P2P-communicatie en blockproductie, terwijl de applicatie achter ABCI de regels van de blockchain bepaalt. In combinatie met Cosmos SDK kunnen ontwikkelaars daardoor een eigen blockchainapplicatie bouwen zonder zelf de volledige consensuslaag te maken.

Tegelijk blijft de praktijk belangrijk. De veiligheid hangt af van de validatorstemkracht, betrouwbare netwerken, goed beveiligde keys en een applicatie die steeds dezelfde uitkomst berekent. CometBFT biedt dus een sterke technische basis, maar de uiteindelijke werking van een chain hangt altijd ook af van hoe die basis wordt gebruikt.