Was ist CometBFT und wie funktioniert es?

Was ist CometBFT?

CometBFT ist Open-Source-Software, die dafür sorgt, dass sich mehrere Computer über dieselben Blockchain-Daten einigen können. Einfach gesagt: Sie hilft Nodes, Transaktionen in dieselbe Reihenfolge zu bringen und alle denselben aktualisierten Zustand einer Blockchain zu speichern.

Dieser Prozess heißt Byzantine Fault Tolerant, oder BFT. Dabei geht das System davon aus, dass einige Teilnehmer Fehler machen, offline gehen oder sogar absichtlich falsch handeln können. Solange sich weniger als ein Drittel der gesamten Stimmkraft so verhält, verhindert CometBFT, dass zwei verschiedene Blocks an derselben Stelle in der Blockchain endgültig gemacht werden.

CometBFT ist der Nachfolger von Tendermint Core und nutzt den Tendermint-Konsensalgorithmus. Es ist keine fertige Blockchain und auch kein komplettes Krypto-Projekt mit eigenen festen Regeln. Die Software regelt vor allem Konsens, die Kommunikation zwischen Nodes und die Produktion von Blocks. Die Regeln der Blockchain selbst, etwa welche Transaktionen gültig sind, liegen in einer separaten Anwendung.

Die Verbindung zwischen CometBFT und dieser Anwendung heißt ABCI, kurz für Application Blockchain Interface. Du kannst ABCI als feste Kommunikationsschicht sehen: CometBFT fragt zum Beispiel, ob eine Transaktion gültig ist, und die Anwendung antwortet. So können Entwickler ihre eigene Blockchainlogik bauen, ohne auch noch selbst eine Konsens-Engine entwickeln zu müssen.

Wichtigste Erkenntnisse

• CometBFT ist Open-Source-Software für Konsens und die Synchronisierung von Blockchain-Daten zwischen Nodes.
• Es nutzt BFT-Konsens, wodurch Fehler oder böswilliges Verhalten eines Teils der Validatoren abgefangen werden können.
• CometBFT ist ein Fork und Nachfolger von Tendermint Core.
• Die Software entscheidet nicht selbst, welche Transaktionen inhaltlich gültig sind; das übernimmt die angeschlossene Anwendung.
• ABCI bildet die Verbindung zwischen CometBFT und der Blockchain-Anwendung.

Wie funktioniert der Konsens von CometBFT?

CometBFT lässt Validatoren pro Block in drei festen Schritten zusammenarbeiten: propose, prevote und precommit. Ein Validator ist dabei ein Teilnehmer, der Blocks und Stimmen signieren darf. Nicht jeder Node ist also automatisch ein Validator.

Jede neue Position in der Blockchain heißt Block Height. Auf jeder Height versucht das Netzwerk, einen neuen Block zu beschließen. Zuerst weist das Protokoll einen Proposer zu. Das ist der Validator, der für diese Runde einen Vorschlag für einen neuen Block verbreiten darf.

Danach prüfen die anderen Validatoren den Vorschlag. Ist der Block gültig und rechtzeitig angekommen? Dann geben sie ein Prevote ab: eine erste Stimme für diesen Block. Gibt es genug Übereinstimmung, folgt ein Precommit: die zweite und entscheidende Stimme.

Ein Block ist gecommittet, sobald mehr als zwei Drittel aller Stimmkraft ein Precommit für genau denselben Block abgegeben haben. Stimmkraft hängt nicht zwingend von der Anzahl der Validatoren ab. Ein Validator kann zum Beispiel mehr Stimmkraft haben als ein anderer, abhängig von den Regeln der Blockchain-Anwendung.

Beispiel: Angenommen, die gesamte Stimmkraft beträgt 100. Dann sind mehr als 66 Stimmen nötig, um einen Block zu committen. Dabei spielt es keine Rolle, ob diese Stimmkraft von vielen kleinen Validatoren oder von einer kleineren Zahl größerer Validatoren kommt.

Kommt kein gültiger Vorschlag an, ist der Proposer offline oder treffen Stimmen zu spät ein? Dann beginnt dieselbe Block Height in einer nächsten Runde erneut. Die Wartezeiten können pro Runde ansteigen, damit langsame Nodes doch noch aufschließen können. Das verhindert keine Verzögerung, gibt dem Netzwerk aber eine Möglichkeit, weiterzumachen, wenn eine Runde scheitert.

Welche Rolle spielen Validatoren in CometBFT?

Validatoren treffen die Entscheidungen in CometBFT. Sie signieren Blockvorschläge und Stimmen, prüfen Vorschläge und helfen so zu bestimmen, welcher Block hinzugefügt wird. Ein normaler Node kann Informationen an andere Nodes weitergeben, aber ohne privaten Validator-Key kann dieser Node nicht selbst an der Konsensabstimmung teilnehmen.

Der Proposer wird automatisch und vorhersehbar über ein Round-Robin-Schema ausgewählt. Validatoren mit mehr Stimmkraft kommen dabei anteilig häufiger an die Reihe, einen Vorschlag zu machen.

In der Praxis macht ein Validator Folgendes:

• der Validator empfängt einen Blockvorschlag;
• der Validator prüft, ob der Vorschlag nach den Regeln der Anwendung gültig ist;
• bei einem gültigen und rechtzeitig eingegangenen Vorschlag folgt ein Prevote;
• bei genügend Prevotes kann ein Precommit folgen;
• nach genug Precommits wird der Block gecommittet.

Wurde kein gültiger Vorschlag empfangen, kann ein Validator auf nil stimmen. Das bedeutet einfach: keine Stimme für einen bestimmten Block in dieser Runde. So kann das Netzwerk in eine nächste Runde gehen, ohne einfach einen falschen Vorschlag zu akzeptieren.

Das Validatoren-Set und die Verteilung der Stimmkraft kommen als Input aus der Blockchain-Anwendung. Diese Anwendung kann also auch Regeln für die Anpassung des Validatoren-Sets haben. Staking, Delegation und Slashing sind keine festen autonomen Funktionen von CometBFT selbst. Die Anwendung bestimmt, ob solche Regeln existieren und wie sie funktionieren.

Noch etwas Wichtiges: Validator-Signing-Keys müssen gut geschützt sein. Wenn derselbe Validator widersprüchliche Nachrichten signiert, kann das ein Beweis für byzantinisches Verhalten sein. CometBFT kann solche Beweise verarbeiten, aber eine mögliche finanzielle Strafe legt die Anwendung fest.

Wie läuft die Kommunikation zwischen Validatoren ab?

Validatoren kommunizieren über ein Peer-to-Peer-Netzwerk, oft abgekürzt als P2P. Nodes leiten Informationen über Gossip an andere Nodes weiter. Das klingt informell, bedeutet aber einfach, dass sich Nachrichten von Node zu Node durch das Netzwerk verbreiten.

Über diesen Gossip werden unter anderem Transaktionen, Blockteile, Vorschläge, Prevotes und Precommits verteilt. Nodes teilen auch ihren aktuellen Status mit: auf welcher Block Height sie sich befinden, in welcher Runde sie sind und welchen Schritt des Konsenses sie gerade ausführen. Dadurch kann ein Node, der hinterherhinkt, sehen, was passiert, und wieder anschließen.

Auch nicht validierende Nodes können dabei nützlich sein. Sie dürfen Vorschläge, Blocks und Stimmen weiterleiten, auch wenn sie selbst keine Konsensstimme abgeben. Das hilft, Informationen breit im Netzwerk zu verteilen.

Transaktionen, die die Anwendung über CheckTx als ausreichend gültig einstuft, können in die Mempool gelangen. Die Mempool ist im Grunde ein Warteraum für Transaktionen, die möglicherweise in einem nächsten Block landen. Über Gossip können diese Transaktionen weiter verbreitet werden. Das ist allerdings keine Garantie dafür, dass eine Transaktion auch wirklich aufgenommen wird: Der Proposer, die Blockgrenzen und die Regeln der Anwendung spielen dabei alle eine Rolle.

Die Kommunikation zwischen Nodes solltest du nicht mit ABCI verwechseln. P2P und Gossip betreffen Nachrichten zwischen Nodes im Netzwerk. ABCI betrifft dagegen die lokale Kommunikation zwischen CometBFT und der Blockchain-Anwendung, zum Beispiel innerhalb desselben Prozesses, über einen Socket oder über gRPC.

Wie ist CometBFT aufgebaut?

CometBFT besteht grob aus einem Konsens-Teil und einem Anwendungsteil, mit ABCI als Verbindung dazwischen. Diese Trennung ist praktisch: Die eine Seite regelt, wie Nodes sich einigen, die andere Seite bestimmt, was die Blockchain tatsächlich tut.

Die CometBFT-Engine enthält unter anderem Komponenten für Konsens, P2P-Kommunikation, die Mempool, das Verteilen von Blocks, das Speichern des Zustands und einen RPC-Server. Über diesen RPC-Server können Client-Anwendungen Daten zu Konsens und Blockchain abfragen.

Die Anwendung verwaltet dagegen die eigenen Regeln und Daten. Dazu gehört etwa die Frage, ob eine Transaktion gültig ist, wie sich Salden verändern oder welche anderen Aktionen die Blockchain unterstützt. In vielen Cosmos SDK-Nodes laufen CometBFT und die Anwendung gemeinsam in einem Daemon, sie können aber auch als getrennte Prozesse über ABCI zusammenarbeiten.

Wichtig zu wissen: CometBFT ruft die Anwendung über ABCI auf. Die Anwendung steuert CometBFT also nicht, sondern gibt Antworten, wenn CometBFT im Verlauf des Lebenszyklus einer Transaktion oder eines Blocks danach fragt.

Was macht die Konsensschicht?

Die Konsensschicht von CometBFT regelt, wann und wie neue Blocks beschlossen werden. Diese Schicht übernimmt BFT-Konsens, P2P-Netzwerkkommunikation, Blockproduktion und das Verteilen von Blocks an Nodes.

Bei jedem neuen Block wählt das Protokoll einen Proposer aus und begleitet die Runden für propose, prevote und precommit. Sobald mehr als zwei Drittel der Stimmkraft für denselben Block geprecommittet haben, ist dieser Block gecommittet.

Die Konsensschicht verwaltet auch die Mempool. Wenn ein Node eine Transaktion empfängt, fragt CometBFT über ABCI die Anwendung, ob diese Transaktion für die Mempool geeignet ist. Diese Prüfung heißt CheckTx. Ein erfolgreiches CheckTx bedeutet noch nicht, dass die Transaktion endgültig ausgeführt wurde. Es bedeutet nur, dass die Transaktion für einen späteren Blockvorschlag infrage kommen kann.

Nach dem Konsens über einen Block sorgt CometBFT dafür, dass die Anwendung den Block ausführt und den neuen Zustand speichert. Die Konsensschicht entscheidet also nicht selbst, ob eine Transaktion inhaltlich korrekt ist. Das bleibt Aufgabe der Anwendung.

Was macht die Anwendungsschicht?

Die Anwendungsschicht bestimmt die Regeln der Blockchain. Dort steht zum Beispiel, welche Daten gespeichert werden, welche Transaktionen gültig sind und wie eine gültige Transaktion den Zustand verändert.

Diese Schicht ist die deterministische State Machine der Blockchain. Das ist ein technischer Begriff für etwas Einfaches: Wenn zwei Nodes dieselbe Eingabe erhalten, müssen sie auch exakt dasselbe Ergebnis berechnen. Sonst können Nodes unterschiedliche Versionen der Blockchain bekommen, und das funktioniert natürlich nicht.

In einer Cosmos-SDK-Anwendung besteht diese Schicht unter anderem aus Modulen, Transaktionsverarbeitung und State Stores. Der aktuelle Zustand bekommt außerdem eine kryptografische Zusammenfassung, den AppHash. Wenn Nodes nach demselben Block unterschiedliche AppHash-Werte berechnen, weist das auf ein Problem bei der Ausführung hin.

Über ABCI behandelt die Anwendung verschiedene Momente im Prozess:

• CheckTx: prüft, ob eine empfangene Transaktion in die Mempool darf.
• PrepareProposal: lässt die Proposer-Anwendung Transaktionen für einen Blockvorschlag auswählen, sortieren, weglassen oder hinzufügen, innerhalb der geltenden Grenzen.
• ProcessProposal: lässt andere Validatoren beurteilen, ob sie den Vorschlag akzeptieren.
• FinalizeBlock: führt einen Block aus, nachdem Konsens erreicht wurde.
• Commit: speichert den neuen Zustand dauerhaft.

Nicht jeder ABCI-Aufruf hat exakt dieselben Anforderungen. PrepareProposal darf zum Beispiel abweichen, weil nur der Proposer diesen Schritt ausführt. ProcessProposal und die Ausführung von Blocks müssen dagegen deterministisch sein, damit alle Validatoren zum selben Ergebnis kommen.

Wofür wird CometBFT verwendet?

CometBFT wird als allgemeine Konsens- und Replikations-Engine für Blockchains mit eigenen Regeln verwendet. Entwickler können also eine deterministische Anwendung darauf aufbauen, statt von Grund auf ein System zu entwickeln, in dem sich Nodes über Blocks einigen müssen.

Die möglichen Anwendungsfälle sind vielfältig. Eine Blockchain-Anwendung kann sich zum Beispiel um Währungen, E-Voting oder Infrastruktur-Orchestrierung drehen. CometBFT legt dabei nicht fest, wofür die Anwendung gedacht sein muss. Es liefert die technische Basis, um dieselben Transaktionen und denselben Zustand zuverlässig über mehrere Nodes zu kopieren.

Innerhalb des Cosmos Stack hat CometBFT eine klare Rolle: Es regelt Konsens, Netzwerkkommunikation und Blockproduktion. Das Cosmos SDK liefert anschließend die Bausteine für die Anwendungslogik. So müssen Entwickler nicht beide Teile komplett selbst entwickeln.

CometBFT hat außerdem einen eigenen RPC-Server. Eine Wallet, dApp oder ein anderer Client kann ihn nutzen, um Daten zu Blocks und Konsens abzufragen, zusätzlich zu den APIs einer Cosmos SDK-Anwendung.

Wie arbeitet CometBFT mit dem Cosmos SDK zusammen?

CometBFT und Cosmos SDK ergänzen sich: CometBFT regelt den Konsens und das Cosmos SDK regelt die Blockchain-Anwendung. Es sind also zwei verschiedene Bausteine, die zusammen eine funktionierende Blockchain-Node bilden können.

Das Cosmos SDK bietet Module, Transaktionsverarbeitung, State Management und andere Anwendungsregeln. CometBFT regelt währenddessen die P2P-Kommunikation, die Mempool, die Auswahl eines Proposers und das Erreichen von Konsens über neue Blocks.

Die Brücke zwischen beiden ist ABCI. In einer Cosmos SDK-Anwendung implementiert BaseApp diese Schnittstelle. CometBFT stellt dann Anfragen wie CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock und Commit. BaseApp verarbeitet diese Anfragen und sendet eine Antwort zurück.

Bei einem neuen Vorschlag wählt CometBFT zuerst einen Proposer auf Basis der Validator-Stimmkraft. Danach kann die Anwendung dieses Proposers über PrepareProposal bestimmen, welche Transaktionen in den Vorschlag kommen und in welcher Reihenfolge, innerhalb der Blockgrenzen. Andere Validatoren bewerten den Vorschlag über ProcessProposal, bevor sie abstimmen.

Diese Aufteilung ist praktisch. Entwickler können an einer eigenen Blockchain-Anwendung arbeiten, während die bewährte Konsens-Engine separat bleibt. Dadurch kann dieselbe CometBFT-Engine auch mit verschiedenen SDK-Anwendungen verwendet werden.

Was sind die Vorteile von CometBFT?

Ein wichtiger Vorteil von CometBFT ist die klare BFT-Sicherheit. Solange weniger als ein Drittel der relevanten Validator-Stimmkraft byzantinisches Verhalten zeigt, werden keine widersprüchlichen Blocks auf derselben Block Height gecommittet.

Außerdem ist die Trennung zwischen Konsens und Anwendungslogik sehr praktisch. Über ABCI kann ein Entwickler eigene Blockchain-Regeln erstellen, ohne selbst eine vollständige BFT-Konsens-Engine bauen zu müssen. Das macht die technischen Aufgaben übersichtlicher: CometBFT regelt die Einigung, die Anwendung regelt den Inhalt.

Weitere Vorteile sind:

• Klarer Abstimmungsprozess: Ein Block wird erst nach mehr als zwei Dritteln Precommits für genau diesen Block beschlossen.
• Wiederverwendbare Technik: Dieselbe Engine kann verschiedene Blockchain-Anwendungen unterstützen.
• Flexible Anbindung: ABCI kann in-process in Go arbeiten, aber auch über Socket oder gRPC.
• Trennung der Verantwortlichkeiten: Konsenscode und Anwendungscode können getrennt voneinander entwickelt werden.

Wichtig ist aber: Solche Vorteile bedeuten nicht automatisch, dass jede Blockchain mit CometBFT schnell, sicher oder stark dezentralisiert ist. Das hängt auch von der Validatoren-Set, den Netzwerkverbindungen, der Hardware, der Konfiguration und dem Code der Anwendung ab.

Welche Einschränkungen und Risiken hat CometBFT?

CometBFT hat klare Sicherheitsbedingungen und operative Risiken. Die wichtigste Voraussetzung ist, dass weniger als ein Drittel der Validator-Stimmkraft byzantinisch sein darf. Byzantinisch bedeutet hier, dass Validatoren sich fehlerhaft oder böswillig verhalten, etwa indem sie widersprüchliche Informationen senden, Regeln nicht befolgen oder zusammenarbeiten, um das Netzwerk zu manipulieren. Wird diese Grenze überschritten, gilt die Sicherheitsgarantie gegen widersprüchliche Commits nicht mehr.

Auch für den Fortschritt ist genug aktive Stimmkraft nötig. Wenn Validatoren mit ausreichender Stimmkraft offline sind oder durch eine Netzwerkpartition nicht miteinander kommunizieren können, kann das Netzwerk kein Quorum erreichen. Dann folgen neue Runden und die Blockproduktion kann sich verzögern oder vorübergehend stillstehen.

Netzwerkverzögerungen spielen dabei eine große Rolle. Kommen Vorschläge, Blockteile oder Stimmen nicht rechtzeitig an, läuft die Runde ab und das Protokoll versucht es erneut. Die Time-outs können dann ansteigen. Das hilft langsamen Teilnehmern, bedeutet aber auch, dass Bestätigungen länger dauern können.

Die Anwendung hinter ABCI ist ein weiterer wichtiger Punkt. Wo Determinismus erforderlich ist, muss jeder Node bei derselben Eingabe dasselbe Ergebnis liefern. Ein Fehler, durch den Nodes unterschiedliche Resultate berechnen, kann AppHash-Mismatches und Konsensprobleme verursachen. Die Trennung zwischen CometBFT und der Anwendung verhindert also nicht alle Folgen von schlechtem Anwendungscode.

Validator-Keys und Node-Infrastruktur sind ebenfalls sensibel. Schlecht geschützte Signing-Keys können missbraucht werden, und Validatoren können Ziel von Denial-of-Service-Angriffen werden. Eine Sentry-Node-Architektur kann helfen, Validator-Nodes weniger direkt solchen Angriffen auszusetzen.

Außerdem ist eine Transaktion in der Mempool noch nicht sicher in einem Block aufgenommen. Nodes können abstürzen, bevor eine Transaktion in einen Vorschlag gelangt, wodurch die Transaktion aus der Mempool verloren gehen kann. Wer eine Transaktion sendet, sollte also warten, bis sie wirklich in einem gecommitteten Block steht.

Zuletzt können Versions-Updates Kompatibilitätsprobleme mit sich bringen. Breaking Changes in einem Minor Release können eine neue Chain oder eine eigene Datenmigration nötig machen. Ein Upgrade erfordert deshalb gute Vorbereitung, sowohl bei der Anwendung als auch bei den Nodes, die die Blockchain betreiben.

Fazit

CometBFT ist der technische Motor, der Blockchain-Nodes dabei hilft, sich über neue Blocks zu einigen und denselben Zustand zu bewahren. Es arbeitet mit einem BFT-Konsensprozess, in dem Validatoren Vorschläge machen, abstimmen und einen Block erst dann committen, wenn mehr als zwei Drittel der Stimmkraft denselben Block bestätigen.

Die Stärke liegt vor allem in der Arbeitsteilung. CometBFT regelt Konsens, P2P-Kommunikation und Blockproduktion, während die Anwendung hinter ABCI die Regeln der Blockchain bestimmt. In Kombination mit dem Cosmos SDK können Entwickler dadurch eine eigene Blockchain-Anwendung bauen, ohne selbst die komplette Konsensschicht zu erstellen.

Gleichzeitig bleibt die Praxis wichtig. Die Sicherheit hängt von der Validator-Stimmkraft, zuverlässigen Netzwerken, gut geschützten Keys und einer Anwendung ab, die immer dasselbe Ergebnis berechnet. CometBFT bietet also eine starke technische Basis, aber die tatsächliche Funktionsweise einer Chain hängt immer auch davon ab, wie diese Basis genutzt wird.