> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# IntentionBFT
> Konsens: wie eine Reihenfolge und ein zertifizierter Preisvektor gemeinsam festgeschrieben werden und wie das Netzwerk aufgebaut ist.
IntentionBFT ist das Konsensprotokoll von Intention – ein BFT-Protokoll aus der HotStuff-Familie, erweitert für Finanzinfrastruktur. Safety gilt unterhalb der Fehlerschwelle bedingungslos; Liveness gilt, sobald sich das Netzwerk stabilisiert hat.
Der Konsens leistet hier zwei Dinge, die der Konsens einer Allzweck-Chain nicht leistet: Er schreibt eine **Reihenfolge** als eigenständiges Objekt fest, und er schreibt im selben Ereignis einen **zertifizierten Preisvektor** fest. Alles, was der [Kernel](/de/protocol/architecture/kernel) über die Ausführung garantieren kann, hängt daran, dass beides feststeht, bevor die Ausführung beginnt.
Modell
IntentionBFT toleriert einen byzantinischen Angreifer, der bis zu einem Drittel des gesamten Stakes kontrolliert. Der ehrliche Stake liegt damit immer über zwei Dritteln, und das Standard-Quorum ist jede Menge von Validatoren, deren gemeinsamer Stake zwei Drittel überschreitet – auf diesen Seiten **stake-gewichtetes Quorum von $2f+1$** genannt. Das Netzwerk ist partiell synchron: Vor einem Stabilisierungspunkt sind Verzögerungen beliebig, danach sind Verzögerungen zwischen ehrlichen Validatoren beschränkt.
Oracle-Sidecarje Validator
Der Validator prüft und signiertsamt Aktualität gegen konfigurierte Schwellen
Gossip zwischen Validatorenals Nachricht im Konsensnetz
Zertifizierte Preiseje Epoche und Runde
Preisverfügbarkeit begrenzt die BlockproduktionEin Validator darf nur dann einen Block vorschlagen, wenn er gültige Preisbeobachtungen für die aktuelle Runde vorweisen kann – dieselben Signaturen, die die Transaktionen festschreiben, schreiben also auch die Preise fest, gegen die sie abgerechnet werden.
Was das nicht behauptetEs bindet den Preis an die Transaktion. Korrekt wird der Preis dadurch nicht – der Konsens bezeugt, dass ein Quorum von Validatoren diese Beobachtungen in dieser Runde eingereicht hat, mehr nicht.
Jede Runde hat einen festgelegten Leader. Innerhalb einer Runde sammelt ein Vorschlag aufeinanderfolgende Signaturaggregate über $2f+1$, und die Phasen benachbarter Runden laufen überlappend, sodass ein Block im Normalfall nach zwei Netzwerk-Roundtrips endgültig ist. Unter optimistic responsiveness wird der Fortschritt allein durch die tatsächliche Nachrichtenlaufzeit begrenzt; das Backoff des Pacemakers greift nur, wenn das Netzwerk feindlich oder partitioniert ist.
Eine Reihenfolge festschreiben
Die Transaktionsreihenfolge innerhalb eines Blocks wird zu einem konsensbestätigten Objekt erhoben, statt ein Nebenprodukt der Ausführung zu bleiben. Der Block-Hash deckt die geordnete Nutzlast ab, sodass jede Umsortierung nach dem Konsens die Signaturen ungültig macht, die sie festgeschrieben haben.
Die Wirkung: Sobald ein Block endgültig ist, hat ein stake-gewichtetes Quorum von $2f+1$ eine Festlegung auf genau diese Reihenfolge signiert, und kein ehrlicher Validator wird in derselben Runde eine abweichende Reihenfolge derselben Transaktionen signiert haben. Zusammen mit der sequenziellen Ausführung über diese festgeschriebene Reihenfolge macht das aus dem deterministischen Replay statt einer Implementierungskonvention eine Eigenschaft, die jeder prüfen kann.
Der Ermessensspielraum des Leaders innerhalb eines einzelnen Vorschlags – welche verfügbaren Batches er aufnimmt und wie er sie anordnet – bleibt eine Restangriffsfläche. Gedämpft wird sie durch die Leader-Reputation und dadurch, dass ein Leader ohne gültige Preisbeobachtungen überhaupt keinen Block erzeugen kann. Stärkere Fair-Ordering-Konstruktionen sind als möglicher künftiger Upgrade-Schritt vorgemerkt.
Verfügbarkeit von Batches
In einem naiven Protokoll schlägt ein Leader einen Block vor, dessen Nutzlast alle Transaktionen der Runde enthält – damit hängt die Größe der Konsensnachrichten am Durchsatz. IntentionBFT trennt die Datenverbreitung von der Reihenfolge.
Validatoren verbreiten laufend im Hintergrund Transaktions-Batches. Jeder Batch wird quittiert, bis sein Urheber eine stake-gewichtete Verfügbarkeit von $2f+1$ nachweisen kann; erst dann darf ein Vorschlag ihn referenzieren – über den Digest, nicht über den Inhalt. Konsensnachrichten bleiben unabhängig vom Durchsatz klein, und ein festgeschriebener Block ist immer erneut ausführbar, weil kein Block Daten referenzieren kann, die allein eine byzantinische Minderheit vorgehalten hat.
Preise zertifizieren
Validatoren sind zugleich Preisbeobachter, und ein Block führt die Preise mit, gegen die er ausgeführt wurde.
Sie verbinden sich mit Full Nodes, nie mit Validatoren. Wer die vollständigste Sicht bei geringster Latenz braucht, betreibt eine eigene.
Vier Stufen, vom Konsens nach außen
Wozu die Stufe da ist
Jeder Validator betreibt seinen eigenen [Oracle-Sidecar](/de/protocol/architecture/oracle), der Daten von Handelsplätzen sammelt und daraus je Instrument einen Indexpreis erzeugt. Der Validator holt sich diesen Preis, prüft ihn – einschließlich der Aktualität gegen konfigurierte Schwellen –, signiert ihn und verteilt die signierte Einreichung per Gossip als Konsensnachricht an die anderen Validatoren. Zertifizierte Preise werden je Epoche und Runde zusammengestellt und im Block mitgeführt, sodass dieselben Signaturen, die die Transaktionen festschreiben, auch die Preise festschreiben, gegen die diese Transaktionen abgerechnet werden.
Ein Validator darf nur dann einen Block vorschlagen, wenn er gültige Preisbeobachtungen für die aktuelle Runde vorweisen kann. Preisverfügbarkeit ist damit eine Voraussetzung der Blockproduktion und keine Eingabe, auf die die Ausführung nur hofft.
Das bindet den Preis an die Transaktion; korrekt wird der Preis dadurch nicht. Der Konsens bezeugt, dass ein Quorum von Validatoren in dieser Runde diese Beobachtungen eingereicht hat. Ob die zugrunde liegenden Handelsplätze zutreffend waren, ist eine andere Frage – behandelt von den Aggregationsregeln auf der Seite [Oracle](/de/protocol/architecture/oracle) und begrenzt durch die [Risikohinweise](/de/protocol/security/risks).
## Leader-Reputation
Leader werden Runde für Runde durch deterministische, stake-gewichtete Rotation bestimmt, ergänzt um eine Reputationsheuristik über ein gleitendes Fenster. Ein Validator mit wiederholt gescheiterten Vorschlägen – ein Hinweis auf Nichtverfügbarkeit oder feindliches Verhalten – wird bei späteren Auswahlen zurückgestuft, und seine Slots werden an zuletzt reaktionsfähige Validatoren verteilt. So blockiert ein nicht verfügbarer Validator den Fortschritt nicht dadurch, dass er die Führung in den ihm zugewiesenen Slots beansprucht.
Weil Preisbeobachtungen darüber entscheiden, wer überhaupt vorschlagen darf, muss die Reputation zugleich verhindern, dass sich die Führung bei den Validatoren mit der besten Marktdatenanbindung konzentriert. Eine Anforderung an die Quellenvielfalt – Beobachtungen aus mehreren unabhängigen Quellen je Instrument – schließt diesen Weg.
Epochen und Rekonfiguration
Die Zeit ist in Epochen (Epochs) gegliedert. Innerhalb einer Epoche sind das Validatorenset und die meisten Parameter konstant. An Epochengrenzen können sie sich durch eine von der Governance autorisierte Rekonfiguration ändern: Änderungen am Validatorenset, Änderungen der Konsensparameter, Aktualisierungen der Risikoparameter und Notfallmaßnahmen. Übergänge sind atomar – jeder ehrliche Validator sieht denselben Übergang auf derselben Blockhöhe.
Netzwerktopologie
Leader
Validatoren
Chain
stake-gewichtetes 2f+1-Aggregat
Reihenfolge und Preise sind jetzt unveränderlich
Block vorschlagen – Batch-Digests und zertifizierte Preise
Verfügbarkeit, Reihenfolge und Preise prüfen
Abstimmen
Runde zertifizieren
Festschreiben
**Validatoren** nehmen am Konsens teil. Jeder betreibt den vollständigen Stack: Konsens, Mempool, einen Oracle-Sidecar, Kernel-Ausführung und Speicher. Sie sind die einzigen Teilnehmer, die abstimmen.
**Validator-Full-Nodes** sitzen unmittelbar hinter den Validatoren. Sie folgen festgeschriebenen Blöcken und führen sie aus, stimmen aber nicht ab. Ihr Zweck ist Abschirmung – sie fangen öffentlichen Lese-Traffic und Peer-Verbindungen ab, damit Validatoren nicht direkt am offenen Internet hängen.
**Öffentliche Full Nodes** sind die offene Stufe. Jeder kann eine betreiben. Sie folgen der Chain, führen festgeschriebene Blöcke aus, beantworten Leseanfragen und beliefern nachgelagerte Systeme.
**Clients** – Front-Ends, Handelsagenten, Market Maker, Indexer – verbinden sich mit Full Nodes, nicht mit Validatoren. Ein Client, der die vollständigste Sicht bei geringster Latenz braucht, betreibt eine eigene Full Node, statt sich auf die eines anderen zu verlassen.
Nodes, die dem Netzwerk beitreten, führen standardmäßig nicht die gesamte Chain ab dem Genesis-Block erneut aus; wie eine neue Node aufholt, steht unter [State Sync](/de/protocol/architecture/state/sync).
Wie es weitergeht
Was den Konsens erreicht, in welcher Reihenfolge, und was verworfen wird.
Was mit einem Block geschieht, sobald Reihenfolge und Preise festgeschrieben sind.
Wie ein Indexpreis entsteht, bevor ein Validator ihn signiert.
Warum das Validatorenset geschlossen ist und wie man nach einem Beitritt fragt.