Was sind Solana Commitment-Levels?

Was sind Solana Commitment-Levels?

Solana Commitment-Levels sind eine standardisierte Methode, um den Konsens des Netzwerks über einen Block oder eine Transaktion zu messen. Wenn du den Status einer Transaktion oder Account-Daten über einen Solana RPC-Node abfragst, etwa mit getTransaction, kannst du ein Commitment-Level angeben. Damit legst du fest, wie final die Daten sein sollen. Solana lässt Clients so zwischen Latenz und Gewissheit abwägen: Ein niedrigeres Commitment liefert schneller Feedback, ein höheres gibt Entwicklern mehr Sicherheit, dass der Zustand nicht zurückgesetzt wird.

Solana definiert drei primäre Commitment-Levels, hier in absteigender Reihenfolge ihrer Finalität:

Finalized

Die höchste Stufe der Gewissheit. Eine Supermehrheit des Stakes (≥66 %) hat den Block bestätigt und mindestens 31 weitere bestätigte Blöcke wurden darauf aufgebaut. Dadurch erreicht der Slot den maximalen Lockout von 32 Stimmen. Eine finalisierte Transaktion ist praktisch unumkehrbar.

Confirmed

Eine mittlere Stufe, bei der eine Supermehrheit des Stakes (≥66 %) für den Block gestimmt hat. Er ist aber noch nicht durch eine längere Folge weiterer Abstimmungen finalisiert, die eine Umkehr erschweren. Dies wird häufig als optimistische Bestätigung bezeichnet. Sie bietet hohe Sicherheit, dass sich die Transaktion auf dem „Main Fork“, also der kanonischen Chain, befindet.

Processed

Processed bedeutet, dass ein Leader die Transaktion gerade verarbeitet und in den neuesten dem Node bekannten Block aufgenommen hat. Für diesen Block liegen möglicherweise noch keine clusterweiten Stimmen vor. Die Transaktion könnte weiterhin verworfen werden, wenn der Block nicht Teil des Mehrheits-Forks wird.

Diese Stufen bilden die Phasen im Lebenszyklus einer Transaktion ab. 

Eine neu eingereichte Transaktion durchläuft Processed → Confirmed → Finalized, während immer mehr Teilnehmer im Netzwerk den enthaltenen Block sehen und darüber abstimmen und weitere Blöcke darauf aufgebaut werden. Ein höheres Commitment bedeutet, dass mehr Nodes der Aufnahme der Transaktion zugestimmt haben. Dadurch sinkt das Risiko eines Forks oder Rollbacks. 

Sehen wir uns die einzelnen Stufen genauer an.

Commitment-Level Processed

Eine Transaktion gilt als Processed, sobald ein Validator-Node, also der aktuelle Leader, sie in einen Block aufnimmt. Das ist die früheste Bestätigung: Die Transaktion wurde empfangen und lokal in den Ledger-Zustand aufgenommen.

Zu den wichtigsten Merkmalen von Processed gehören:

• In einen Block aufgenommen: Die Transaktion befindet sich in einem Block, den ein Validator erzeugt hat.
• Keine Garantie für den Mehrheits-Fork: Dieser Block wird möglicherweise Teil des Mehrheits-Forks, also des längsten oder schwersten Forks
• Schnellstes Feedback: Du erfährst sofort, dass ein Node die Transaktion verarbeitet hat. Das eignet sich für schnelle clientseitige Updates, etwa um in einer Wallet-UI eine ausstehende Transaktion anzuzeigen.
• Nicht vollständig sicher: In dieser Phase gibt es keine Garantie, dass andere Validatoren den Block gesehen oder dafür gestimmt haben. Der Cluster könnte diesen Block noch „überspringen“ oder durch einen alternativen Fork ersetzen. Anders gesagt: Processed = aufgenommen, aber noch nicht von anderen bestätigt.

Beispiel für einen Processed-Block: 

Angenommen, Alice sendet eine Übertragung auf Solana. Sobald der aktuelle Leader sie einem Block in Slot N hinzufügt, wird die Transaktion als Processed markiert. Alices Wallet könnte die Transaktion sofort als ausstehend/verarbeitet anzeigen. 

Wenn die Mehrheit der Validatoren den Block dieses Leaders jedoch nicht akzeptiert, etwa weil der Leader langsam oder offline war und sich ein anderer Fork durchgesetzt hat, könnte Alices Transaktion verschwinden, also verworfen werden. Der verarbeitete Block wurde dann nicht Teil der Main Chain.

Commitment-Level Confirmed

Das Commitment-Level Confirmed gibt an, dass die Supermehrheit des Clusters den Block der Transaktion akzeptiert hat und er sich sehr wahrscheinlich auf der kanonischen Chain befindet. Technisch bedeutet „confirmed“, dass ≥66 % der nach Stake gewichteten Validatoren direkt für diesen Block gestimmt haben. 

Wichtige Merkmale:

• Auf dem Mehrheits-Fork: Der Block mit der Transaktion wird als Teil des Mehrheits-Forks im Ledger anerkannt. Das Netzwerk betrachtet ihn somit als kanonischen Block.

• Stimmen einer Supermehrheit: Mindestens zwei Drittel des gesamten Stakes haben für die Bestätigung des Blocks gestimmt. Diese Stimmen werden über den Gossip-Mechanismus von Solana gesammelt. Validatoren übertragen und beobachten dabei netzwerkweit Stimmen für diesen Block. Diese Phase nutzt die mit Solana v1.3 eingeführte optimistische Bestätigung. Dadurch können Nodes einen Block als bestätigt behandeln, sobald eine Supermehrheit dafür gestimmt hat – noch bevor er finalisiert ist.

• Geringes Risiko einer Umkehr: Bei einem Konsens von mindestens 66 % ist es äußerst unwahrscheinlich, aber nicht unmöglich, dass ein konkurrierender Fork diesen Block ersetzt. Alle ehrlichen Validatoren haben sich effektiv auf diesen Block festgelegt, sofern keine größere Reorganisation eintritt. In der fünfjährigen Geschichte von Solana wurde noch kein bestätigter Block zurückgesetzt.

• Schneller als Finalized: Der Status Confirmed wird normalerweise kurz nach der Markierung eines Blocks oder einer Transaktion als Processed erreicht, meist innerhalb von ein bis zwei Sekunden. Validatoren stimmen zeitnah über neue Blöcke ab. Der Status wartet nicht auf viele nachfolgende Blöcke. Unter normalen Bedingungen bietet Confirmed daher ein gutes Verhältnis zwischen Geschwindigkeit und Sicherheit.

• Optimistische Finalität: Wegen des schnellen Konsenses von Solana behandeln Entwickler eine bestätigte Transaktion für die meisten praktischen Zwecke oft als praktisch final. Bis zur Finalisierung bleibt jedoch ein geringes Rollback-Risiko.

Beispiel für einen Confirmed-Block: 

Alices Transaktion aus dem vorherigen Beispiel wird Confirmed, sobald die Validatoren des Clusters über Block N abstimmen. Stimmen die nächsten Validatoren bis Slot N+1, N+2 usw. ab, sehen Block N und erreichen den Schwellenwert von 66 %, markiert das Netzwerk Block N als bestätigt. Alices Wallet kann dem Benutzer die Transaktion nun zuverlässig als bestätigt anzeigen. 

Die Wahrscheinlichkeit, dass Alices Übertragung jetzt zurückgesetzt wird, ist sehr gering. Das würde nur bei einem seltenen Fork oder Netzwerkproblem passieren. Dies ähnelt „N Bestätigungen“ in anderen Chains, basiert bei Solana aber auf Stake-gewichteten Stimmen statt auf einer festen Zahl von Blockbestätigungen.

Commitment-Level Finalized

Eine Transaktion gilt als Finalized, wenn eine Supermehrheit für ihren Block gestimmt hat und genügend weitere Blöcke darauf aufgebaut wurden. Im Solana-Konsens entspricht dies dem Erreichen des maximalen Lockouts, normalerweise nachdem 32 aufeinanderfolgende Stimmen beziehungsweise Slots den Block bestätigt haben. Finalized ist das stärkste Commitment-Level und bietet die höchste Gewissheit, dass die Transaktion nicht rückgängig gemacht wird. 

Zu den Merkmalen von Finalized gehören:

• Unumkehrbarer Block: Der Cluster hat diesen Block als finalisiert anerkannt. Er wurde also im Ledger-Zustand gerootet. Validatoren setzen ihn nicht zurück und er ist praktisch permanent.

• Supermehrheit + Lockout: Wie bei Confirmed haben mindestens 66 % des Stakes den Block bestätigt. Zusätzlich wurden danach mindestens 31 weitere bestätigte Blöcke hinzugefügt. Das Netzwerk hat also eine tiefe Chain auf diesem Block aufgebaut und die Lockout-Tiefe erreicht, ab der eine Reorganisation nicht mehr praktikabel ist.

• Maximaler Lockout (32 Stimmen): Der Mechanismus Tower BFT von Solana verdoppelt die Lockout-Dauer von Stimmen exponentiell. Sobald sich für einen Block 32 Stimmen im Tower angesammelt haben – er also über 32 weitere Slots hinweg Teil des führenden Forks blieb –, erreicht er den maximalen Lockout und wird finalisiert. Ein Validator, der jetzt für einen alternativen Fork stimmt, würde gegen die Konsensregeln verstoßen.

• Höchste Sicherheit, langsamste Bestätigung: Die Finalisierung folgt den Stufen Processed und Confirmed normalerweise mit etwas Verzögerung. Unter normalen Bedingungen dauert sie etwa ~10–20 Sekunden, da 32 Slots mit jeweils ~400 ms ungefähr 13 Sekunden ergeben. Das ist der Preis für die Gewissheit von Finalized. Clients schließen durch das Warten auf die Finalisierung jedes Risiko aus, dass die Transaktion verworfen oder zurückgesetzt wird. Dafür steigt die Latenz.

• Confirmed + darauf aufgebaut: Finalisierung lässt sich auch so verstehen: Es handelt sich um einen bestätigten Block, der unter vielen weiteren Blöcken begraben ist. Alle ehrlichen Nodes haben diesen Block nachweisbar als Teil des permanenten Ledgers festgeschrieben.

Beispiel für einen Finalized-Block:

Alices Transaktion erreicht den Status Finalized, nachdem das Netzwerk über Slot N hinaus weitere Blöcke erzeugt hat. Angenommen, bis Slot N+32 hat eine Supermehrheit der Validatoren für jeden aufeinanderfolgenden Block bis einschließlich N+32 gestimmt, ohne dass sich ein anderer Fork durchgesetzt hat. Block N mit Alices Transaktion ist jetzt finalisiert. 

Alices Transaktion ist nun dauerhaft im Ledger von Solana gespeichert. Auch wenn sie eine Weile wartet, ändert sich der Zustand mit ihrer Übertragung nicht mehr. 

Jede Anwendung, die starke Finalität benötigt, etwa eine Börse vor der Freigabe von Guthaben, kann jetzt sicher auf Grundlage dieser Transaktion handeln. Ein Angreifer müsste mehr als ein Drittel des Stakes kontrollieren und gegen den Konsens verstoßen, um sie zurückzusetzen.

Veraltete Commitment-Levels

Frühere Versionen von Solana vor 2021 boten zusätzliche Commitment-Levels. Diese wurden inzwischen zugunsten der drei oben genannten Stufen eingestellt.

Der Vollständigkeit halber findest du hier die alten Begriffe und ihre Zuordnung zu den aktuellen Stufen:

• recent – Veraltet; entspricht Processed. In älteren Dokumentationen bezeichnet „recent“ einfach den neuesten dem Node bekannten Zustand.

• single und singleGossip – Veraltet; entsprechen Confirmed. Diese Begriffe bezeichneten Bestätigungen durch einen einzelnen Validator oder über Gossip, was der Definition von Confirmed entspricht.

• root und max – Veraltet; entsprechen Finalized. „Root“ bezeichnete den im Cluster gerooteten und finalisierten Zustand, „max“ den maximalen Lockout. Beide bedeuteten effektiv Finalized.

Heute sollten Entwickler beim Festlegen eines Commitment-Levels nur processed, confirmed oder finalized verwenden. Die Solana JSON-RPC API nutzt seit v1.5.5 standardmäßig diese Begriffe und behandelt die veralteten Begriffe als Aliasse für die jeweils zugeordnete Stufe. 

Wenn eine RPC-Anfrage kein Commitment angibt, lautet der Standard außerdem Finalized. Der Node gibt also standardmäßig den am weitesten finalisierten Zustand zurück.

Unterschiede zwischen Commitment-Levels

Die Unterschiede zwischen Processed, Confirmed und Finalized lassen sich daran erkennen, wie viel des Netzwerks die Transaktion bestätigt hat und wie wahrscheinlich eine Umkehr ist. Die folgende Tabelle basiert auf der offiziellen Solana-Dokumentation und fasst die wichtigsten Unterschiede zusammen:

Zusammengefasst bedeutet Processed nur, dass sich die Transaktion in einem Block befindet – nicht mehr. Confirmed bedeutet, dass sich der Cluster mit den Stimmen einer Supermehrheit auf diesen Block geeinigt hat, er aber noch nahe an der Spitze der Chain liegt. Finalized bedeutet, dass der Block mit vielen Bestätigungen tief in der Chain liegt und praktisch unveränderlich ist.

Du kannst den Unterschied auch anhand der Wahrscheinlichkeit betrachten, mit der die Transaktion langfristig im kanonischen Ledger bleibt. 

Direkt nach Processed liegt diese Wahrscheinlichkeit nicht bei 100 %, weil ein Fork oder Fehler auftreten kann. Nach der Bestätigung durch mehr als 66 % des Stakes steigt die Wahrscheinlichkeit einer Aufnahme stark an. Sobald Dutzende Blöcke darauf aufgebaut wurden und der Block finalisiert ist, liegt sie bei ~100 %. 

Das folgende Diagramm zeigt, wie die Wahrscheinlichkeit der Finalisierung einer Transaktion steigt, wenn mehr Slots vergehen und das Commitment-Level zunimmt:

Die Wahrscheinlichkeit, dass eine Transaktion in die endgültige kanonische Chain aufgenommen wird, steigt mit der Zeit. Zu Beginn, in Slot n nach der Verarbeitung der Transaktion, besteht das Risiko, dass sie „übersprungen“ oder durch einen Fork ausgeschlossen wird. Mit der optimistischen Bestätigung steigt die Wahrscheinlichkeit der Aufnahme stark an, während Validatoren abstimmen. Nachdem genügend aufeinanderfolgende Blöcke darauf aufgebaut wurden und die Transaktion Finalized erreicht, sinkt die Wahrscheinlichkeit einer Umkehr praktisch auf null. Dies zeigt, wie das Rollback-Risiko mit steigendem Commitment-Level abnimmt.

Wie bestimmt Solana Commitment-Levels?

Ein Blick auf den Solana-Konsens „unter der Haube“ macht verständlich, warum diese Commitment-Levels existieren:

Proof of History (PoH) und Blockproduktion

Die Leader von Solana erzeugen Blöcke in schneller Folge: ein Leader pro Slot, wobei ein Slot ~400 ms dauert. Transaktionen fließen in eine Proof of History (PoH)-Hash-Chain und bilden Einträge in einem Block. Blöcke verbreiten sich über Turbine, das Blockverteilungsprotokoll von Solana, schnell im Netzwerk. Wenn ein Leader einen Block mit deiner Transaktion erzeugt, wird dieser sofort verteilt, ist aber noch nicht bestätigt. Das entspricht der Stufe Processed.

Abstimmung (Tower BFT)

Solana verwendet einen BFT-Konsensalgorithmus namens Tower BFT. Validatoren, die jeweils einen Teil des Stakes kontrollieren, stimmen über die Blöcke ab, die ihrer Ansicht nach zum nächsten Teil des Ledgers werden sollen. Stimmen sind selbst Solana-Transaktionen und enthalten das Konzept des Lockouts. Jedes Mal, wenn ein Validator in Slot N für einen Block stimmt, entsteht ein Lockout. Stimmt er später für einen konkurrierenden Fork, könnte er dadurch für eine gewisse Zeit seine Stimmberechtigung verlieren. 

Diese Lockouts verdoppeln sich mit jeder aufeinanderfolgenden Stimme für denselben Fork exponentiell: 1, 2, 4, 8 ... Slots Lockout. Die Obergrenze liegt bei 32 Stimmen. Hat ein Validator 32-mal in Folge für einen Fork gestimmt, sodass der Block von vor 32 Slots weiterhin Teil des schwersten Forks ist, befindet sich dieser Block im maximalen Lockout. Dieser Mechanismus motiviert Validatoren, beim Mehrheits-Fork zu bleiben und Blöcke zu finalisieren.

Bestätigung (optimistische Bestätigung)

Wenn ein Block erzeugt wird, übertragen Validatoren ihre Stimmen dafür. Sobald eine Supermehrheit von mindestens 66 % des Stakes für einen Block gestimmt hat, betrachten Solana-Nodes ihn als optimistisch bestätigt. Das entspricht dem Commitment-Level Confirmed. Dies geschieht schnell, oft innerhalb von ein oder zwei Slots nach dem Block, weil sich Stimmen über Gossip verbreiten. 

Wichtig ist, dass die Implementierung von Solana nicht darauf wartet, bis der Block im Ledger gerootet ist. Sie vertraut der Stimme der Supermehrheit als optimistischem Signal dafür, dass dieser Block später finalisiert wird, sofern sich weniger als <33 % des Stakes fehlerhaft verhalten. 

Daher stammt die Bezeichnung optimistische Bestätigung: Unter normalen Annahmen für byzantinische Fehler, also bei höchstens einem Drittel unehrlicher Teilnehmer, bedeutet die Stimme einer Supermehrheit, dass der Block nicht aufgehoben wird. Damit ein Fork ihn ersetzen könnte, müssten mehr als 33 % der Validatoren für eine alternative Chain stimmen. Das verletzt diese Annahmen.

Finalisierung (Rooting eines Blocks)

Während weitere Blöcke erzeugt und bestätigt werden, wandert jeder bestätigte Block tiefer in den Fork. Sobald ein Block in 32 aufeinanderfolgenden Slots nach ihm Stimmen gesammelt hat, erreicht er den maximalen Lockout. Das Netzwerk rootet diesen Block jetzt und markiert ihn als finalisiert und unumkehrbar. Finalisierung bedeutet, dass der Block mindestens 31 Blöcke hinter dem Head liegt und nie zugunsten eines anderen Forks aufgegeben wurde. Alle Nodes betrachten ihn nun als Teil der unveränderlichen Historie. Der Ledger-Zustand bis zu diesem Slot ist eingefroren. 

Das Commitment Finalized entspricht sinngemäß der Aussage „Block hat mindestens 32 Bestätigungen“ in einer PoW-Chain. Solana erreicht dies jedoch durch zeitgebundene Stimmen statt durch Proof-of-Work-Bestätigungen. Die 32-Slot-Regel ergibt sich aus dem Design von Tower BFT, bei dem sich Lockouts bis 2^32 verdoppeln. Unter der Annahme einer Fehlertoleranz von einem Drittel bietet sie eine mathematische Garantie für Finalität.

Fork-Auswahl und Rollback

Der Solana-Konsens bewertet Forks kontinuierlich. Validatoren wählen mit einem Algorithmus für den schwersten Fork, der auf dem Stake-Gewicht der Stimmen basiert, den Fork aus, auf dem sie weiterbauen. Wenn nur ein Teil der Validatoren einen Block verarbeitet und dieser keine Stimmen erhält, kann ihn ein anderer Fork ersetzen. Deshalb kann eine Processed-Transaktion verworfen werden. 

Sobald zwei Drittel einen Block bestätigt haben, müsste ein alternativer Fork mehr als ein Drittel des Stakes hinter sich haben, um sich durchzusetzen. Das ist sehr unwahrscheinlich und würde auf böswilliges Verhalten hindeuten. 

Nach der Finalisierung ist ein Fork, der diesen Block zurücksetzt, ohne einen katastrophalen Konsensfehler praktisch unmöglich. Selbst wenn das Netzwerk ausfällt oder angegriffen wird, wäre zum Zurücksetzen finalisierter Slots eine Koordination außerhalb der Protokollregeln nötig.

Zusammengefasst funktionieren die Mechanismen so: Processed = Block wurde mit PoH erzeugt, aber noch nicht breit bestätigt; Confirmed = Die Stimmen des Clusters über Tower BFT haben eine Supermehrheit für den Block erreicht, also einen optimistischen Konsens; Finalized = Der Block blieb nach vielen weiteren Stimmen als „Root“ der Chain bestehen und hat absolute Konsensfinalität erreicht. Das Design von Solana sorgt dafür, dass bestätigte Blöcke nach kurzer Verzögerung finalisiert werden. So bietet es schnelle Bestätigungen und letztlich absolute Finalität.

Anwendungsfälle für Entwickler nach Commitment-Level

Beim Entwickeln auf Solana ist die Wahl des passenden Commitment-Levels entscheidend. Anwendungen stellen unterschiedliche Anforderungen an Geschwindigkeit und Gewissheit. 

Hier findest du typische Anwendungsfälle und Best Practices für jede Stufe:

Nutze Processed für sofortiges Feedback und unkritische Vorgänge

Entwickler können das Commitment Processed nutzen, wenn Geschwindigkeit entscheidend und ein gewisses Rollback-Risiko akzeptabel ist. Während der Entwicklung und beim Testen möchtest du beispielsweise möglicherweise sofort wissen, ob ein Validator eine Transaktion empfangen hat. 

UI-Anwendungen wie Wallets oder Spiele könnten eine Transaktion direkt nach der Verarbeitung optimistisch anzeigen, um die User Experience zu verbessern, etwa mit dem Status „ausstehend“. 

Da nicht garantiert ist, dass Processed-Transaktionen bestehen bleiben, wird diese Stufe jedoch nicht für produktionskritische Abläufe empfohlen. Wenn du sie nutzt, dann für Transaktionen mit geringem Wert oder unkritische Vorgänge, bei denen ein möglicher Rollback keine schwerwiegenden Probleme verursacht.

Nutze Confirmed für die meisten Transaktionen

Für viele Anwendungsfälle auf Solana ist Confirmed die allgemein empfohlene Standardeinstellung. Diese Stufe bietet hohe Erfolgssicherheit bei minimaler zusätzlicher Latenz. 

Eine DeFi-Anwendung, die einen Token-Swap ausführt, oder ein Benutzer, der Guthaben überträgt, verlässt sich normalerweise auf den Status Confirmed. Sobald die Transaktion bestätigt ist, kann die App sie im Normalfall als abgeschlossen behandeln. Gegenüber Processed verringert diese Stufe die Wahrscheinlichkeit deutlich, dass eine Transaktion verworfen wird. Besonders beim Abrufen aktueller Blockhashes und Senden von Transaktionen empfiehlt es sich, Confirmed als Commitment-Level zu verwenden. Es bietet ein besseres Verhältnis zwischen Latenz und Sicherheit.

Nutze Finalized für hochwertige und kritische Transaktionen

Wenn absolute Gewissheit erforderlich ist, etwa bei der Übertragung hochwertiger Assets, Cross-Chain-Bridges oder der Bestätigung von Einzahlungen auf Börsen, sollten Entwickler das Commitment-Level Finalized verwenden. Das gilt für Szenarien, in denen selbst ein minimales Rollback-Risiko inakzeptabel ist. 

Eine Börse könnte beispielsweise warten, bis eine Transaktion finalisiert ist, bevor sie eine Einzahlung dem Account eines Benutzers gutschreibt. So schließt sie das Risiko einer späteren Reorganisation aus, die die Einzahlung rückgängig machen könnte. 

Ein weiterer Anwendungsfall folgt auf eine Reihe von Transaktionen: Bevor ein komplexer Vorgang als abgeschlossen gilt, kannst du sicherstellen, dass der endgültige Zustand finalisiert ist. Das ist etwa bei Audits oder Abwicklungsprozessen relevant, die einen endgültigen Ledger-Zustand benötigen. 

Entwickler sollten beachten, dass ein erforderliches Commitment von Finalized die Latenz erhöht. Bei hoher Netzwerklast kann außerdem die Wahrscheinlichkeit steigen, dass eine Transaktion abläuft, da du effektiv auf die Finalisierung des Hashes eines älteren Blocks wartest. Nutze Finalized daher gezielt und nur für die kritischsten Transaktionen, bei denen die zusätzliche Sicherheit die höhere Latenz rechtfertigt.

Zusammengefasst eignet sich Processed hauptsächlich für schnelles Feedback und nicht produktive Anwendungsfälle. Confirmed ist die Standardwahl für die meisten Vorgänge und bietet ein ausgewogenes Verhältnis zwischen Sicherheit und Performance. Finalized ist für Fälle reserviert, in denen du trotz Wartezeit garantierte Finalität brauchst. 

Viele Anwendungen kombinieren die Stufen: Sie aktualisieren die UI bei Processed, betrachten Vorgänge bei Confirmed als abgeschlossen und protokollieren sie bei Finalized.

Auswirkungen auf Zuverlässigkeit, Performance und Sicherheit von Transaktionen

Die Wahl des Commitment-Levels wirkt sich direkt auf die Zuverlässigkeit – bleibt die Transaktion bestehen? –, die Performance beziehungsweise Latenz und die Sicherheit gegen Double-Spends oder Fork-Probleme aus:

Zuverlässigkeit

Höhere Commitment-Levels erhöhen die Zuverlässigkeit, mit der eine Transaktion dauerhaft gespeichert wird. Eine finalisierte Transaktion befindet sich mit praktisch 100-prozentiger Zuverlässigkeit im Ledger, sofern keine außergewöhnlichen Ereignisse eintreten. Eine bestätigte Transaktion bietet eine sehr hohe, aber keine 100-prozentige Zuverlässigkeit. Bei Processed-Transaktionen ist sie geringer. 

Wie bereits erwähnt, könnten etwa ~5 % der Transaktionen verworfen werden, wenn du nur Processed berücksichtigst, etwa durch häufige Fork-Wechsel. Confirmed senkt dieses Risiko auf nahezu 0 %. 

In kritischen Anwendungen verhindert das Commitment Finalized, dass sich deine Transaktion in einem später verworfenen Fork befindet.

Performance (Latenz)

Zwischen der Geschwindigkeit einer Bestätigung und dem Commitment-Level besteht ein klarer Zielkonflikt. 

Eine Bestätigung mit Processed erfolgt nahezu sofort, innerhalb der Blockzeit und häufig in weniger als einer Sekunde. 

Confirmed verursacht eine geringe zusätzliche Verzögerung von etwa ein bis zwei Slots oder ~0,5–1 Sekunde, um Stimmen der Validatoren zu sammeln. Diese Stufe ist weiterhin sehr schnell und für Benutzer in der Praxis meist nicht wahrnehmbar. 

Finalized verursacht die größte Verzögerung, da eine Transaktion erst als finalisiert gemeldet wird, nachdem ungefähr 30 weitere Blöcke erzeugt wurden. Das Erreichen der Finalität dauert normalerweise ~10–20 Sekunden. 

Bei Netzwerküberlastung oder langsamer Blockproduktion kann diese Verzögerung länger ausfallen. Wenn du Finalized zu häufig verlangst, kann dies daher die User Experience und den Durchsatz beeinträchtigen. Wartet eine Anwendung auf die Finalisierung, muss sie diese zusätzliche Zeit einplanen. Das bedeutet jedoch nicht, dass die Ausführung der Transaktion selbst on-chain länger dauert. Der Client wartet lediglich länger auf die Gewissheit, dass sie finalisiert wurde. Solana verarbeitet währenddessen weiterhin neue Transaktionen.

Durchsatz und Ablaufzeit

Ein wichtiger, aber leicht zu übersehender Effekt betrifft das Ablaufen von Transaktionen und die Verwendung von Blockhashes. Solana-Transaktionen enthalten einen aktuellen Blockhash und sind nach diesem Blockhash nur für ~150 Slots gültig. 

Wenn du zum Signieren deiner Transaktion einen finalized Blockhash anforderst, ist dieser älter, da Finalized hinter der Spitze zurückliegt. Dadurch bleiben weniger Slots, bevor die Transaktion abläuft. Bei einem überlasteten Netzwerk kann dies die Wahrscheinlichkeit erhöhen, dass sie abläuft, wenn sie nicht schnell verarbeitet wird. 

Ein aktuellerer Blockhash mit Confirmed bietet ein längeres Zeitfenster. Die offizielle Empfehlung lautet, für getLatestBlockhash Confirmed zu verwenden, um das Ablaufrisiko zu reduzieren. 

Wenn du Finalized für den Preflight oder Blockhash verwendest, verkürzt sich also möglicherweise die Zeit, in der deine Transaktion aufgenommen werden kann. Unter hoher Last kann das ihre Zuverlässigkeit beeinträchtigen. 

Kurz gesagt: Ein Commitment von Finalized kann bei hoher Last die Liveness beeinträchtigen. Du gewinnst Gewissheit, musst bei einem nahezu ausgelasteten Netzwerk aber möglicherweise mehr Timeouts in Kauf nehmen.

Sicherheit

Aus Sicherheitssicht, etwa zum Schutz vor Double-Spends und Forks, ist Finalized am sichersten. 

Nach der Finalisierung müssten mehr als ein Drittel des gesamten Stakes böswillig handeln, um eine Transaktion rückgängig zu machen. Das würde wahrscheinlich erkannt und bestraft. 

Unter normalen Bedingungen ist Confirmed sehr sicher. Ein Angreifer müsste einen konkurrierenden Fork erstellen und mehr als 33 % der Validatoren davon überzeugen, ihn zu unterstützen, nachdem bereits eine Supermehrheit abgestimmt hat. Ohne einen großen koordinierten Angriff ist das äußerst unwahrscheinlich. 

Theoretisch könnte ein bestätigter Block jedoch verwaisen, wenn einige Validatoren knapp unter 33 % ihre Stimmen zurückhalten oder sich ein Fork gerade an der Schwelle befindet. Das Solana-Design mit optimistischer Bestätigung setzt jedoch eine ehrliche Mehrheit voraus, um dies zu verhindern. 

Processed bietet die geringste Sicherheit: Solange keine Stimmen vorliegen, gibt es keine Garantie, dass ein anderer Validator überhaupt von der Transaktion weiß. Ein böswilliger Leader könnte eine Transaktion aufnehmen und den Block anschließend nicht korrekt übertragen. 

Verlasse dich daher bei sicherheitskritischen Bestätigungen nicht auf Processed. Es ähnelt eher einer „Benachrichtigung“, dass der Vorgang begonnen hat. 

Zusammengefasst gilt für die Sicherheit vor Forks und Double-Spends: Finalized > Confirmed > Processed.

Commitment bei Lese- und Schreibvorgängen

Auch beim Lesen des Solana-Zustands über RPC, etwa beim Prüfen eines Account-Guthabens, gibst du ein Commitment-Level an. Mit Processed siehst du möglicherweise sehr aktuelle Daten, die jedoch aus einem nicht finalisierten Fork stammen könnten. Finalized bietet beim Lesen absolute Konsistenz, also den Zustand, auf den sich alle geeinigt haben. Dieser kann allerdings einige Slots zurückliegen. Für die meisten Zustandsabfragen bietet Confirmed wie bei Transaktionen eine gute Balance. So stellst du sicher, dass du keine Entscheidungen auf Grundlage eines Forks triffst, der zurückgesetzt werden könnte. 

Bei Schreibabfragen, also beim Senden von Transaktionen, bestimmt das Commitment hauptsächlich, wie die Client-Bibliothek auf die Bestätigung wartet. Ein übliches Muster besteht darin, eine Transaktion mit einem bestimmten preflightCommitment zu senden, das die TX möglicherweise anhand des neuesten Zustands simuliert, und anschließend confirmTransaction mit demselben Commitment-Level aufzurufen. Entwickler können bei Bedarf auf die Bestätigung mit Finalized warten.

Konkrete Zahlen aus aktuellen Messungen: Solana hat eine Transaktion in ~0,4 Sekunden processed, erreichte den Status confirmed nach ~0,6 Sekunden und die Finalisierung nach ~13 Sekunden. 

Wenn deine Anwendung, etwa eine Zahlungs-App, nicht ~13 Sekunden pro Transaktion warten kann, solltest du Confirmed verwenden. Diese Stufe bietet weiterhin hohe Sicherheit. 

Wenn du einen großen Betrag zwischen Chains verschiebst, kannst du die vollen ~13 Sekunden warten, um vollständig sicher zu sein. Entwickelst du dagegen etwas, bei dem Geschwindigkeit entscheidend und ein geringes Risiko akzeptabel ist, etwa eine optimistisch aktualisierte UI, kannst du mit dem Status Processed eine schnelle User Experience bieten.

Fazit

Die Commitment-Levels von Solana – Processed, Confirmed und Finalized – sind eine zentrale Funktion, mit der Entwickler für jede Transaktion das Verhältnis zwischen Geschwindigkeit und Gewissheit anpassen können.

Processed liefert sofortige, aber unsichere Ergebnisse. Confirmed bietet innerhalb von ein bis zwei Sekunden eine fast endgültige Sicherheit, die für die meisten Anwendungen ausreicht. Finalized bietet nach zusätzlicher Wartezeit absolute Finalität. 

Unter der Haube entsprechen diese Stufen dem Fortschritt des Solana-Konsenses: von der Erzeugung eines Blocks über die Abstimmung durch eine Supermehrheit bis zum Rooting im Ledger mit maximalem Lockout.

Beim Entwickeln auf Solana ist es entscheidend, das richtige Commitment-Level für die jeweilige Aufgabe zu wählen:

• Nutze niedrigere Commitments für schnelles Feedback oder unkritische Aktionen
• Nutze Confirmed für Standardvorgänge, bei denen du Geschwindigkeit und Sicherheit brauchst
• Nutze Finalized, wenn nur vollständige Finalität akzeptabel ist

Jede Stufe beeinflusst, wie zuverlässig die Transaktion aufgenommen wird und wie lange du warten musst. 

Wenn Entwickler die technische Bedeutung von 66 % der Stimmen, 32 Blöcken, Forks und Lockouts verstehen und aktuelle Best Practices befolgen, erhalten sie die von Solana versprochene Performance, ohne die Konsistenz und Sicherheit ihrer Anwendungen zu gefährden.

Weitere Ressourcen

• Solana-Dokumentation – State Commitment konfigurieren, Tabelle der Commitment-Status
• Helius-Blog – Konsens auf Solana (Mechanismen für Konsens und Finalität)