Was sind Preconfirmations (Preconfs) auf Solana?

Der Lebenszyklus einer Transaktion im Leader

Im Folgenden betrachten wir bewusst nur den Teil des Transaktionslebenszyklus innerhalb des Leaders, der für Preconfirmations und Observability relevant ist. Eine vollständige Beschreibung des Lebenszyklus einer Transaktion auf Solana findest du in unserer technischen Übersicht zur Solana Virtual Machine (SVM).

Vor dem Leader

Auf Solana werden signierte Transaktionen direkt an den Block-Produzenten, also den Leader, und an die kommenden Leader gesendet. Sie treffen über QUIC ein. Die Verbindungskapazität wird nach Stake-Gewichtung vergeben. Deshalb werden Transaktionen, die über Staked Connections weitergeleitet werden, unter Last deutlich eher angenommen.

Zu diesem Zeitpunkt ist eine Transaktion nur für den Absender sowie für den RPC-Knoten oder den Transaction-Landing-Service sichtbar, der sie an den aktuellen und die kommenden Leader weiterleitet. 

Über das Schicksal der Transaktion lässt sich in dieser Phase nichts sagen. 

Phase 1: Aufnahme und SigVerify

Die Transaction Processing Unit (TPU) des Leaders empfängt eingehende Transaktionen als Pakete, deserialisiert sie, prüft ihre Signaturen und verwirft Duplikate. Bei hoher Last werden fehlerhafte Pakete und Spam-Transaktionen verworfen, bevor sie weitere Ressourcen verbrauchen.

Eine Transaktion, die aufgenommen wird und die Signaturprüfung in der SigVerify-Phase besteht, ist lediglich ein Kandidat. Pro Slot treffen Tausende Transaktionskandidaten ein, von denen viele nie in einen Block gelangen.

In dieser Phase gibt es keine sinnvolle Observability, da ein Stream dieser Transaktionen hauptsächlich Rauschen liefern würde. 

Phase 2: Der Scheduler

Die Blockproduktion findet in der Banking Stage statt. Seit Agave 1.18 bildet der zentrale Scheduler ihr Herzstück: ein einzelner Scheduling-Thread mit globaler Sicht auf alle ausstehenden Transaktionen, der Arbeit an einen Pool von Ausführungs-Workern verteilt. Die Idee: Ein einzelner Thread mit vollständigem Kontext packt Blöcke mit deutlich weniger Lock-Konflikten als n Threads, die gierig um eine gemeinsame Warteschlange konkurrieren.

Im Wesentlichen führt der Scheduler Transaktionen durch drei Hauptschritte:

1. Pufferung und Priorisierung

Eingehende Transaktionen gelangen in die Komponente receive and buffer des Schedulers. Dort werden Priorität und Kosten jeder Transaktion berechnet und die Transaktion in einen nach Priorität sortierten Container eingefügt.

Zu diesem Zeitpunkt ist eine Transaktion noch immer eine von Tausenden Möglichkeiten, die verdrängt werden können, wenn sich der Puffer mit höher priorisierter Arbeit füllt.

2. Scheduling 

Die Kontrollschleife im Controller des Schedulers entnimmt dem Container wiederholt die Transaktionen mit der höchsten Priorität, prüft sie auf Konflikte bei Account-Locks und fasst sie zur Ausführung in Batches zusammen.

Seit Agave 2.3 kommt als Scheduling-Algorithmus der Greedy Scheduler zum Einsatz. Er ersetzt das frühere Prio-Graph-Design, nachdem Tests gezeigt hatten, dass der Greedy-Ansatz Blöcke mit weniger Overhead packt.

3. Übergabe 

Der geplante Batch wird über einen Kanal an einen Ausführungs-Worker gesendet. Der Leader hat dieser konkreten Transaktion nun echte Ressourcen zugewiesen: einen Worker-Thread, Account-Locks und einen Platz im Block, der gerade zusammengestellt wird.

Zu diesem Zeitpunkt steht die Transaktion noch aus. Der Leader beabsichtigt, sie auszuführen, aber es wurde noch nichts ausgeführt. Daher gibt es noch kein Ergebnis zu melden. Preconfirmations folgen einen Schritt später.

Wie unterscheidet sich die Scheduler-Architektur von Firedancer von Agave?

Firedancer erreicht denselben Punkt über eine etwas andere Architektur. Statt Threads mit gemeinsamem Speicher verwendet Firedancer isolierte Tiles, die über Shared-Memory-Warteschlangen verbunden sind. Die Scheduling-Logik befindet sich im Pack Tile. 

Das Pack Tile verwaltet alle ausstehenden Transaktionen, verfolgt, welche Accounts jedes Bank Tile aktuell hält, und wählt konfliktfreie, gebührenmaximierende Transaktionen für Microblocks aus. Diese übergibt es den Bank Tiles zur Ausführung. 

Die gleiche Übergabe findet statt: Ausgewählte Transaktionen fließen von der Packing-Logik zu den Ausführungseinheiten, wo ihre Ergebnisse bestimmt werden.

Phase 3: Ausführung

Worker in Agave beziehungsweise Bank Tiles in Firedancer führen den geplanten Transaktions-Batch gegen die aktuelle Bank aus. Dabei laden sie Accounts, führen Programme aus und schreiben die Ergebnisse fest.

Hier kann eine geplante Transaktion auch aus verschiedenen Gründen fehlschlagen, etwa wegen unzureichender Mittel, eines Programmfehlers, einer fehlgeschlagenen Slippage-Prüfung oder anderer Laufzeitbedingungen. Unabhängig davon existiert das Ergebnis jetzt nur lokal auf dem Rechner des Leaders.

In diesem Moment wird eine Preconfirmation ausgegeben. Ein Leader streamt jede Transaktion unmittelbar nach ihrer Ausführung zusammen mit ihrem Status. Das geschieht, bevor die Ergebnisse in einem Entry aufgezeichnet werden und lange bevor Blockdaten den Rechner verlassen.

Dies ist der erste Moment im gesamten Lebenszyklus, in dem das Ergebnis einer Transaktion sowohl existiert als auch gemeldet werden kann. Vor der Ausführung gibt es nur einen Pool ausstehender Kandidaten ohne streambare Ergebnisse. Danach werden die Informationen bereits in den Block gepackt, der sich auf den Weg zum übrigen Netzwerk macht.

Die Ausführung ist daher der einzige Punkt, an dem ein solches frühes Signal existieren kann. Deshalb enthält jede Preconfirmation das tatsächliche Ergebnis der Transaktion und keine Vorhersage.

Eine Preconfirmation kann dir jedoch nicht sagen, ob der Block mit der Transaktion kanonisch wird. Dieser Block wurde noch nicht in Shreds zerlegt, verbreitet oder zur Abstimmung gestellt. 

Deshalb sind Preconfirmations ein Signal und keine Garantie.

Phase 4: Proof of History und Entries

Ausgeführte Batches werden im Proof-of-History-Stream aufgezeichnet, um Entries zu erzeugen. Das sind gehashte Transaktionsbündel, die in die verifizierbare Uhr des Leaders eingebettet werden. Entries sind das native Format des Ledgers, existieren zu diesem Zeitpunkt aber nur auf dem Rechner des Leaders.

Für alle außerhalb des Leaders ist die Observability praktisch null.

Beachte, dass Proof of History mit dem Alpenglow-Update entfernt wird, da Rotor und Votor eine dezentrale Uhr auf Solana überflüssig machen. Das Preconfirmation-Modell bleibt davon unberührt: Leader führen Transaktionen weiterhin aus, bevor sie diese verbreiten. Das früheste beobachtbare Signal bleiben daher die lokalen Ausführungsergebnisse des Leaders. 

Phase 5: Shredding und Verbreitung

Entries werden in Shreds zerlegt, also in Fragmente von MTU-Größe, die zur Ausfallsicherheit mit Erasure Coding versehen werden. Diese Shreds werden signiert und über den nach Stake gewichteten Baum von Turbine verbreitet.

Hier öffnen sich die Schleusen der Observability. Shreds sind das erste Artefakt eines Blocks, das den Rechner des Leaders verlässt. Deshalb setzen alle anderen Produkte für frühe Daten auf Solana, einschließlich Shred-Streams, hier an. Wer Transaktionen aus Shreds rekonstruiert, ist im Vergleich zu RPC-Commitment-Levels schnell, im Vergleich zu einer Preconfirmation aber spät, da der Leader die Transaktion ausgeführt hat, bevor Shreds existieren. 

Danach spielen Validatoren den Block erneut ab, stimmen darüber ab und Transaktionen durchlaufen die Commitment-Levels processed, confirmed und finalized. 

Wo liegen Preconfirmations auf der Latenzleiter?

Preconfirmations sind das schnellste Signal auf Solana. Sie sind schneller als alle anderen Optionen, einschließlich roher und dekodierter Shreds, LaserStream und anderer Methoden zum Datenstreaming. 

Preconfs lassen sich jedoch am besten als eine Stufe auf einer Latenzleiter verstehen. Jede Stufe tauscht eine Form von Vollständigkeit oder Sicherheit gegen eine frühere Beobachtung ein.

Von der frühesten bis zur spätesten Stufe:

Aus dieser Tabelle ergeben sich zwei Beobachtungen. 

Erstens ergänzen sich all diese Signale, statt einander direkt zu ersetzen.

Preconfirmations melden beispielsweise, was ein Leader gerade ausgeführt hat, bevor das Netzwerk davon weiß. Eine Nachricht von LaserStream zeigt dagegen mit vollständigen Metadaten, was geschehen ist.

Produktivsysteme müssen in der Regel beides nutzen: Sie reagieren auf Preconfirmations und verwenden nachgelagerte Signale zur Verifizierung.  

Zweitens sind die Abstände zwischen den Stufen nicht gleich groß.

Der Schritt von processed-Streams zu Shreds spart Millisekunden im einstelligen Bereich. Der Schritt von Shreds zu Preconfirmations überspringt dagegen den Rest der Blockproduktions-Pipeline, also das Aufzeichnen von Entries, das Shredding und die Verbreitung. Der Beobachtungspunkt verschiebt sich vom ersten öffentlichen Artefakt des Blocks zu Ergebnissen, die nur innerhalb des Leaders existieren. 

Dadurch sind Preconfirmations etwa 5 bis 50 Millisekunden schneller als Shreds. 

Das Vertrauensmodell von Preconfirmations: Signal statt Garantie

Alles, was eine Preconfirmation verspricht, passt in einen Satz: Der Leader hat diese Transaktion mit diesem Ergebnis ausgeführt. Alles, was eine Preconf nicht verspricht, folgt aus demselben Satz.

Eine ausgeführte Transaktion ist noch keine gelandete Transaktion. Der Block, der sie enthält, wurde also noch nicht in Shreds zerlegt, verbreitet oder zur Abstimmung gestellt. Dieser Block kann weiterhin übersprungen oder abgespalten werden, bevor das Netzwerk ihn bestätigt. Fast alle vorab bestätigten Transaktionen landen erfolgreich onchain. Jedes System, das auf Preconfirmations reagiert, muss die Ergebnisse jedoch durch andere Observability-Prüfungen bestätigen, bevor es sie als endgültig behandelt.

Die Abdeckung ist bewusst unvollständig. Preconfirmations gibt es nur für Slots, deren Leader seinen Stream geplanter Transaktionen an Helius weiterleitet. Die Abdeckung wächst daher mit dem Anteil des teilnehmenden Netzwerk-Stakes, und der Stream ist nicht zwangsläufig lückenlos.

Wenn Dienste eine lückenlose Abdeckung als absolute Garantie benötigen, sollten sie bei Lücken auf LaserStream oder Shred Delivery zurückgreifen.

Da Preconfirmations nach der Ausführung ausgegeben werden, sieht ein Abonnent bereits entschiedene Ergebnisse und keinen ausstehenden Orderflow, der noch ausgenutzt werden könnte. Das Zeitfenster, um innerhalb des Blocks vor dieser Transaktion zu handeln, ist also bereits geschlossen. Das ist der entscheidende Unterschied zwischen frühzeitiger Sichtbarkeit und der Offenlegung von Orderflow vor dem Scheduling: Ersteres lässt Abonnenten schneller als das übrige Netzwerk reagieren. Letzteres würde ihnen erlauben, gegen genau die Transaktionen zu handeln, die gestreamt werden. Preconfirmations gehören ausschließlich zur ersten Kategorie.

Das Signal macht klar, was es ist: Hinter einer Preconfirmation steht keine wirtschaftliche Verpflichtung, und eine solche wird auch nicht behauptet. Der Leader meldet seine lokalen Ergebnisse, setzt aber nichts darauf, dass sie tatsächlich eintreten. Für die Strategien, denen Preconfirmations dienen, ist das der richtige Kompromiss.

Ein Liquidations-Bot braucht beispielsweise kein unfehlbares, mit Slashing durchsetzbares Versprechen, dass eine Transaktion landen wird. Er muss das Ergebnis einer bestimmten Transaktion Millisekunden vor seinen Konkurrenten kennen.

Wie funktionieren Helius Preconfirmations?

Helius Preconfirmations werden über ein einzelnes WebSocket-Abonnement bereitgestellt. Ein Client kann sich mit unserem Gatekeeper-Endpunkt, also wss://beta.helius-rpc.com, verbinden und eine preconfSubscribe-Anfrage senden:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Filter werden serverseitig nach Account, also include, exclude und required, sowie nach Region und Status angewendet. Lookup Tables (LUTs) werden unterstützt. So empfängt und bezahlt ein Abonnent nur die geplanten Transaktionen, die für seine Strategie relevant sind. 

Da Preconfirmations nach der Ausführung ausgegeben werden, arbeitet der Statusfilter mit echten Ergebnissen: failed: false. Fehlgeschlagene Transaktionen werden somit weder gestreamt noch abgerechnet.

Die Preise basieren auf Credits und entsprechen anderen Helius-WebSocket-Abonnements: 10 Credits pro Nachricht und eine Nachricht pro gestreamter Transaktion. Verfügbar ist dies ab dem Professional-Plan. 

Anschließend trifft jede geplante Transaktion, die den Filtern entspricht, als kompakter Binär-Frame ein. Er besteht aus einem festen 18-Byte-Header mit der Transaktionsversion, dem Slot, für den sie geplant ist, dem Index der Transaktion innerhalb des Slots und ihrem Status. Darauf folgen die vollständigen Transaktions-Bytes. 

Das Format ist bewusst minimalistisch, da ein fester Header in Nanosekunden dekodiert werden kann, ohne dass im Hot Path JSON geparst werden muss. Das einzige JSON, das wir bei diesem Austausch benötigen, ist der Einfachheit halber die Bestätigung des Abonnements. 

Beachte, dass eine Preconfirmation nur die Hälfte eines Trades ist. Eine Transaktion zuerst zu sehen, ist nur dann relevant, wenn auch die Reaktion zuerst landet. Deshalb haben wir außerdem Sender Max eingeführt, die leistungsstärkste Stufe von Helius Sender.

Sender Max leitet eine Einreichung, also eine einzelne Transaktion oder ein atomares Bundle aus bis zu vier Transaktionen, über jeden verfügbaren Hochgeschwindigkeitspfad. Außerdem gelangt sie in einen Priority-Tip-Puffer, der die höchsten Tips bevorzugt. Der Mindest-Tip beträgt 0,001 SOL.

Empfange Signale mit preconfSubscribe und lande Transaktionen mit Sender Max.  

Was kannst du mit Preconfirmations entwickeln?

Jede Strategie, deren Gewinn mit jeder Millisekunde zwischen der Entscheidung über eine Transaktion und ihrer Beobachtung sinkt, profitiert von Preconfs. Dazu gehören unter anderem die folgenden Anwendungsfälle: 

Sniping

Neue Pool-Erstellungen und Token-Launches werden in dem Moment sichtbar, in dem die bereitstellende Transaktion im Leader ausgeführt wird. Ein Sniper, der Preconfirmations nutzt, reagiert, während Beobachter von Shreds noch auf die ersten Fragmente des Blocks warten. 

Copy-Trading

Die Bewegungen eines Ziel-Wallets erscheinen im Preconfirmation-Stream, sobald der Leader sie ausführt. Wenn du mit accountInclude nach der Adresse eines Ziels filterst, wird der Stream zu einem maßgeschneiderten Spiegel-Feed. So erhältst du Einblicke in Bewegungen vor anderen Copy-Tradern.

Liquidationen

Ein Oracle-Update, das eine Position unter Wasser setzt, ist unmittelbar nach seiner Ausführung bekannt. Ein Liquidations-Bot, der es dort erkennt, startet seine gesamte Pipeline früher als ein Bot, der Shreds oder ein processed-Commitment beobachtet. Deshalb sind Preconfirmations für Liquidationen äußerst wichtig.

Market-Making und propAMMs

Eingehender Flow, der im Moment der Ausführung sichtbar wird, verschafft propAMMs und anderen Quoting-Systemen einen Vorsprung. Sie können Preise neu festlegen oder veraltete Quotes zurückziehen, bevor der Flow öffentlich wird. 

In jedem Fall verschieben Preconfirmations den Reaktionszeitpunkt der Strategie von „nachdem das Netzwerk davon erfährt“ zu „sobald der Leader die Transaktion ausführt“.

Verdiene durch die Weiterleitung von Preconfirmations

Die Abdeckung von Preconfirmations ist ein Netzwerkeffekt, bei dem Validatoren die Angebotsseite bilden. Jeder Validator kann seinen Stream an Helius weiterleiten und damit Umsatz erzielen. So wird ein Nebenprodukt der Blockproduktion zu einer Einnahmequelle, unabhängig davon, ob der Validator seine Position anderweitig monetarisiert.

Je mehr Stake teilnimmt, desto größer ist die Abdeckung. Interessierte Validatoren können uns kontaktieren und weitere Informationen in unserer Dokumentation zu Preconfirmations für Validatoren finden. 

Was ist der Unterschied zwischen Ethereum-Preconfs und Solana-Preconfs?

Ethereum-Preconfirmations sind Zusagen von Proposern, die garantieren, dass eine Transaktion in einem zukünftigen Block landet. Solana-Preconfirmations sind dagegen Onchain-Transaktionssignale in Echtzeit für Transaktionen, die der Leader gerade lokal für den aktuellen Block ausgeführt hat. Bei Ersteren geht es darum, früher Gewissheit zu haben, bei Letzteren darum, etwas früher zu sehen.

Ethereum-Preconfirmations

Auf Ethereum sind Preconfirmations – in der Forschungsliteratur häufig als based preconfs bezeichnet und erstmals 2023 von Justin Drake beschrieben – Zusagen zur Aufnahme. Ein Proposer verspricht vor seinem Slot, dass eine Transaktion in einen zukünftigen Block aufgenommen wird. Dieses Versprechen wird durch einen wirtschaftlichen Mechanismus wie Slashing abgesichert. 

Es gibt mehrere aktive Implementierungen: 

• MEV-Commit von Primev, ein Marktplatz, auf dem Wallets, Searcher und Intent-Protokolle bei Ausführungsanbietern, also Block-Buildern und Sequencern, auf Zusagen bieten
• ETHGas, ein wirtschaftlich abgesichertes Preconfirmation-Netzwerk
• Bolt von Chainbound, das erlaubnisfreie, MEV-Boost-kompatible Zusagen von Proposern bietet

Am wichtigsten ist, dass Ethereum-Preconfirmations:

• sich auf deine eigene Transaktion beziehen
• vor der Ausführung ausgegeben werden
• auf Sicherheit optimiert sind

Ethereum-Preconfirmations garantieren, dass deine Transaktion landet, bevor dies tatsächlich geschieht.

Ethereum benötigt diese Mechanismen aufgrund der Art, wie seine Blöcke erstellt werden. Die meisten Proposer versteigern die Blockerstellung kurzfristig über MEV-Boost. Deshalb lässt sich nichts über einen Block glaubwürdig versprechen, bevor die Auktion abgeschlossen ist. Auf Solana gab es diese Lücke jedoch nie. Der Leader-Zeitplan ist im Voraus bekannt, es gibt keinen Mempool und ein einzelner Leader empfängt, sortiert, verarbeitet und streamt seinen Block kontinuierlich innerhalb des Slots. Das frühe Signal, das Ethereum mithilfe wirtschaftlicher Strukturen erzeugen muss, existiert nativ in der Blockproduktions-Pipeline von Solana. Es musste nur zugänglich gemacht werden.

Solana-Preconfirmations

Solana-Preconfirmations sind Onchain-Signale in Echtzeit und kein Versprechen für die Zukunft: Der Leader meldet Transaktionen, die er bereits ausgeführt hat, bevor sie an das übrige Netzwerk weitergegeben werden.

Am wichtigsten ist, dass Solana-Preconfirmations:

• die Transaktionen aller Teilnehmer umfassen
• nach der Ausführung ausgegeben werden
• auf Latenz optimiert sind

Mit Solana-Preconfirmations siehst du ausgeführte Transaktionen Millisekunden bevor sie über Shreds oder RPC-Anfragen auf den üblichen Commitment-Levels im gesamten Netzwerk beobachtet werden.

Das nächstliegende Solana-Pendant zu Ethereums Preconfirmation für die Reservierung von Blockspace ist Raikus Compute-Unit-Marktplatz für Ahead-of-Time (AOT) Transactions. Damit können Apps eine garantierte Aufnahme in zukünftige Blöcke reservieren.

Fazit

Jede Transaktion auf Solana durchläuft genau einen Moment, in dem ihr Schicksal von unbekannt zu entschieden wechselt: den Augenblick, in dem der Leader sie ausführt. Preconfirmations streamen genau diesen Moment, bevor das übrige Netzwerk ihn sehen kann. Auf der Latenzleiter stehen sie über Shreds, da sie die Ausführungsergebnisse des Leaders und nicht die öffentlichen Artefakte des Blocks beobachten. Preconfirmations sind ein Signal und keine Garantie, weil ein Block erst als kanonisch gilt, wenn das Netzwerk ihn bestätigt.

Bei latenzkritischen Systemen – Snipern, Copy-Tradern, Liquidatoren, Market-Makern und Searchern – abonnierst du mit preconfSubscribe, filterst nach den relevanten Accounts, reagierst mit Sender Max auf Signale und verifizierst die Ergebnisse über die üblichen Commitment-Prüfungen.

Die vollständige Referenz für Abonnements, das Nachrichtenformat und Integrationsbeispiele findest du in unserer Dokumentation zu Preconfirmations.