Preconfirmations: Das früheste Transaktionssignal auf Solana

​

Überblick

Preconfirmations streamen Transaktionen zum frühestmöglichen Beobachtungszeitpunkt – bevor sie in Entries gesammelt und in shreds umgewandelt werden. Dies ist das Transaktionssignal mit der niedrigsten Latenz, das Helius anbietet – früher als Shred Delivery und früher als stream mit processed commitment. Du abonnierst über einen WebSocket mit der Methode preconfSubscribe und erhältst jede Transaktion, sobald sie stattfindet. Der stream kombiniert zwei Quellen, die beide standardmäßig enthalten sind und an unterschiedlichen Punkten der Pipeline Daten ausgeben:

• Helius Preconfirmations von Validatoren, die Daten an Helius weiterleiten. Sie werden genau in dem Moment ausgegeben, in dem der Leader die Transaktion ausführt, zusammen mit ihrem Ausführungsstatus – der erste Zeitpunkt, zu dem das Ergebnis irgendwo existiert.
• BAM Preconfirmations von Validatoren, auf denen der Block Assembly Marketplace (BAM) Client von Jito läuft. Sie werden ausgegeben, wenn sich der Validator zur Ausführung verpflichtet, also bevor die Transaktion ausgeführt wird. Daher enthalten sie keinen Ausführungsstatus.

​

Position von Preconfirmations in der Pipeline

Eine Transaktion durchläuft innerhalb eines Validators mehrere Phasen, bevor sie Onchain landet. Die Latenz steigt von links nach rechts. Je weiter rechts du beobachtest, desto später erfährst du von der Transaktion. Helius Preconfirmations werden in der Ausführungsphase ausgegeben – genau in dem Moment, in dem der Leader die Transaktion ausführt und ihr Status bekannt ist, aber bevor das Ergebnis in einer Entry aufgezeichnet und in shreds umgewandelt wird. Dies ist der erste Punkt im Lebenszyklus, an dem das Ergebnis einer Transaktion sowohl existiert als auch gemeldet werden kann. BAM Preconfirmations werden eine Phase früher ausgegeben, wenn sich der Validator zur Ausführung der Transaktion verpflichtet, sie aber noch nicht ausgeführt hat. Beide treffen ein, bevor die Transaktion in shreds umgewandelt wird. Dadurch haben sie bei derselben Transaktion eine grundsätzlich niedrigere Latenz als die auf shreds basierende Übertragung.

​

BAM Preconfirmations

BAM (Block Assembly Marketplace) ist das Block-Building-System von Jito für Solana. Validatoren mit BAM-kompatiblen Clients geben genau in dem Moment eine Preconfirmation aus, in dem sie sich zur Ausführung einer Transaktion verpflichten. Helius übernimmt diese Daten von den regionalen BAM-endpoint von Jito und stellt sie über dasselbe preconfSubscribe-Abonnement und dasselbe binäre payload wie Helius Preconfirmations bereit. Zum Start erweiterte BAM die Abdeckung um Validatoren, die mehr als 34 % des Netzwerk-Stakes repräsentierten. BAM Preconfirmations verwenden dieselbe payload-Struktur, unterscheiden sich aber in einigen Feldern:

• tx_index ist immer 0. BAM ordnet Transaktionen nach Sequenz-ID und Bundle-Position statt nach einem slot-Index. Keiner dieser Werte lässt sich dem Helius-Feld zuordnen, und beide werden nicht im stream übertragen. Siehe Die beiden Quellen unterscheiden.
• regionInclude entspricht dem regionalen BAM-endpoint, der die Preconfirmation ausgegeben hat, nicht der Helius-Region, die sie übernommen hat.
• Ein kleiner Teil der Transaktionen erreicht Helius über beide Quellen. Daher kann dieselbe Signatur zweimal eintreffen. Siehe Doppelte Benachrichtigungen.

Um nur eine Quelle zu empfangen, übergib includeSource: ["helius"] oder includeSource: ["bam"] im Abonnementfilter.

​

Wann du Preconfirmations verwenden solltest

​

Preise

Preconfirmations ist in allen kostenpflichtigen Tarifen verfügbar: Developer, Business, Professional und Enterprise. Kostenlose Tarife sind nicht berechtigt. slot ohne zugestellte Nachrichten kosten keine Credits, selbst wenn für den slot eine Preconfirmations-Abdeckung besteht. Sobald ein slot mindestens eine Nachricht zustellt, werden für jedes offene preconfSubscribe-Abonnement entweder 300 Credits oder 10 Credits pro zugestellter Nachricht berechnet, je nachdem, welcher Betrag höher ist. Nicht abgedeckte slot kosten nichts. Weitere Informationen findest du unter Credits. Ob ein slot abgerechnet werden kann, hängt davon ab, wie sein Leader abgedeckt ist und welchen Wert du für includeSource festgelegt hast: regionInclude schränkt die abrechenbare Auswahl weiter ein. Abgedeckte slot außerhalb der ausgewählten Regionen kosten für dieses Abonnement nichts. Für passende slot fallen nur Kosten an, wenn das Abonnement mindestens eine Nachricht empfängt. Jedes gleichzeitige Abonnement wird separat abgerechnet, sobald es mindestens eine Nachricht empfängt. Schließe nicht mehr benötigte Abonnements mit preconfUnsubscribe. Mit includeSource: ["helius"] werden slot, die nur durch BAM abgedeckt sind, von der Abrechnung ausgeschlossen.

​

Abdeckung

Preconfirmations ist nur für Transaktionen verfügbar, die von Validatoren geplant werden, die ihren stream an Helius weiterleiten oder einen BAM-kompatiblen Client ausführen. Die Abdeckung hängt vom Anteil des Netzwerk-Stakes ab, den diese beiden Quellen abdecken. Der stream ist daher nicht kontinuierlich. Mit includeSource: ["helius"] beschränkst du die Abdeckung auf Validatoren, die direkt an Helius weiterleiten. Rufe mit getPreConfCoverage die Preconfirmations-Abdeckung als Prozentsatz des Netzwerk-Stakes ab, aufgeschlüsselt nach Region. Die Abdeckung wächst, wenn mehr Validatoren ihre Daten an Helius weiterleiten. Wenn du einen Validator betreibst, kannst du helfen, diese Lücken zu schließen, und Einnahmen erzielen.

​

Für Validatoren

Betreibst du einen Validator? Leite deinen Preconfirmations-stream an Helius weiter, um Einnahmen zu erzielen und die Abdeckung für alle Nutzer von Preconfirmations zu verbessern.

​

Nächste Schritte