Quicknode

30. Juni 2026 – 9 Minuten Lesezeit

Solana schnell, da Blöcke nicht als einzelne monolithische Objekte durch das Netzwerk wandern. Validatoren zerlegen die Blockdaten in kleinere Teile, sogenannte „Shreds“, und verbreiten diese im Netzwerk, noch bevor der Block vollständig wiedergegeben wurde und noch bevor normale RPC-Abonnements Ausführungsmetadaten bereitstellen können.

Blazar, die Solana -Engine Quicknode, umfasst nun shredTransactionSubscribe um dieses frühe Signal in eine für Entwickler bestimmte WebSocket-Methode umzuwandeln. Diese abonniert Transaktionen, die vor der Ausführung bei der Erfassung durch „shred/entry“ beobachtet werden.

shredTransactionSubscribe befindet sich in der Beta-Phase, und die in diesem Beitrag beschriebenen Inhalte können sich noch ändern.

Was ist ein „Shred“?

Ein „Shred“ ist ein Stück eines Solana mit fester Größe, das während der Erstellung des Blocks über das Netzwerk übertragen wird. Durch das Verarbeiten von Shreds können Sie Transaktionsdaten bereits während der Übertragung einsehen, noch bevor der finalisierte Block über RPC-Pfade nach der Ausführung abgefragt werden kann.

Aus diesen Fragmenten lassen sich Einträge rekonstruieren. Einträge enthalten Solana Versionsgesteuerte Transaktion Werte: Signaturen, Nachrichten, statische Kontoschlüssel, Anweisungen, aktuelle Block-Hashes, Verweise auf Adress-Lookup-Tabellen für v0-Transaktionen.

Der entscheidende Unterschied liegt im Zeitpunkt:

• Die Shred-/Eingabe-Erfassung erfolgt vor der Wiedergabe/Ausführung.

• Die Metadaten einer normalen Transaktion stehen erst nach deren Ausführung zur Verfügung.

Transaktionsdaten zum Zeitpunkt der Shred-Verarbeitung können früher liegen als die Ausführungsdaten, dürfen jedoch keine Ergebnisse wie Meta-Daten, Fehlermeldungen, Protokolle, Token-Guthaben, Recheneinheiten oder interne Anweisungen enthalten.

Wie Blazar Daten erfasst und normalisiert

Der Datenpfad für Rohdaten enthält zwei Lücken, die die meisten Entwickler nicht ohne Weiteres schließen können.

Erstens erfordert ein roher „SubscribeEntries“-Stream gRPC, die Dekodierung von Bincode, die Analyse von Transaktionen, die Auflösung der Adress-Lookup-Tabelle sowie ein klares Verständnis davon, was vor der Ausführung bekannt ist und was nicht. Die meisten Anwendungsentwickler wünschen sich ein WebSocket-JSON-RPC-Abonnement und nicht diese Infrastruktur.

Zweitens erfordert die Kontenfilterung die Berücksichtigung von ALT-Adressen. Die meisten Solana nutzen Adress-Lookup-Tabellen. Ohne lokale ALT-Auflösung kann eine Transaktion, die ein Konto ausschließlich über eine Lookup-Tabelle berührt, von kontenbasierten Filtern übersehen werden. Blazar löst statische Schlüssel sowie geladene ALT-Adressen für die Kontenfilterung auf.

Blazar empfängt einen Solana über die Shred-Streaming-Infrastruktur und wandelt dieses Low-Level-Netzwerksignal in ein standardmäßiges WebSocket-JSON-RPC-Abonnement um. Blazar kann Transaktionen beobachten, bevor sie über die üblichen RPC-Pfade nach der Ausführung offengelegt werden, und anschließend eine strukturierte shredTransactionNotification mit dem Transaktionskörper, dem Slot, der Signatur, der Version und den aufgelösten geladenen Adressen, sofern verfügbar.

Behandeln Sie den Stream als ein frühes „Best-Effort“-Signal: Benachrichtigungen treffen in near Reihenfolge near ein, es gibt jedoch keine strenge Reihenfolgegarantie, und dieselbe Transaktion kann gelegentlich mehrmals beobachtet werden. Führen Sie eine Deduplizierung anhand der Signatur durch, wenn Ihr Anwendungsfall eine „Exactly-Once“-Garantie erfordert.

Blazar bereinigt zudem die aus den Shreds gewonnenen Transaktionsdaten vor der Übermittlung. Anstatt ein unbearbeitetes Frühsignal weiterzuleiten und es jedem Client zu überlassen, die gleiche Aufbereitungsarbeit zu leisten, normalisiert Blazar die Transaktionsstruktur und löst, soweit möglich, die in der Adress-Lookup-Tabelle geladenen Adressen auf. Dadurch erhalten Abonnenten eine umfassendere Übersicht über den Kontostand vor der Ausführung, ohne eine spezielle Solana betreiben oder einen eigenen Shred-Parsing-Stack aufbauen zu müssen.

Einblicke in die Transaktionszeitleiste Solana

Die Transaktionstransparenz bei „Shred-time“ schafft einen neuen Punkt auf der Solana :

Transaktionsübertragung → Shreds erkannt → Einträge dekodiert → Wiedergabe/Ausführung → verarbeitete/bestätigte/abgeschlossene RPC-Daten

Die meisten Solana Methoden werden nach der Ausführung oder im Zusammenhang mit Zustandsübergängen der Validatoren ausgeführt. shredTransactionSubscribe gibt den früheren Dekodierungspunkt des Eintrags preis.

Das Ergebnis ist kein Ersatz für transactionSubscribe. Es handelt sich um ein frühzeitiges, vor der Ausführung eingesetztes Hilfswerkzeug für Workflows, bei denen es von Vorteil ist, die Transaktionsabsicht so früh wie möglich zu erkennen.

Beispiele für Anwendungsfälle

shredTransactionSubscribe unterstützt Anwendungsfälle, die von Methoden nach der Ausführung nicht abgedeckt werden können, und bietet gegenüber anderen Methoden den Vorteil, dass Transaktionsdaten bereits vor der Ausführung bereitgestellt werden.

Frühe Transaktionsabsicht

Handelssysteme, DEX-Analysen, Routing-Engines und Marktinfrastrukturen können Transaktionen bereits vor der Ausführung erfassen. Dadurch lassen sich Kontodruck, Programmaktivitäten oder eingehende flow erkennen als bei herkömmlichen streams nach der Ausführung.

Kontobezogene Überwachung vor der Ausführung

Ein Kunde kann Transaktionen abonnieren, die bestimmte Konten betreffen, einschließlich Konten, die über Adress-Lookup-Tabellen geladen wurden. Nutzen Sie diese Funktion, um „Hot Accounts“, Pool-Konten, Token-Konten, Tresore oder protokollspezifische Statuskonten zu überwachen.

Lebenszyklusverfolgung auf Signatur-Ebene

In Kombination mit signatureSubscribe und enableReceivedNotification: true, kann ein Client vor der Ausführung feststellen, wann eine Signatur zum ersten Mal erkannt wurde, und später überprüfen, ob sie erfolgreich war oder fehlgeschlagen ist.

Betriebsdiagnostik

Support- und Infrastrukturteams können Fragen beantworten wie: Wurde die Transaktion vor der Ausführung erfasst? Ist sie später angekommen? Wurde sie gar nicht erfasst? Beruhte sie auf Adressen aus einer Nachschlagetabelle? Dies ermöglicht eine bessere Diagnose des Transaktionslebenszyklus.

Abstimmungs- und Spielautomaten-Signale

Blazar nutzt denselben Shred-/Entry-Erfassungspfad auch für Benachrichtigungen über Abstimmungen vor der Ausführung und für Signale zu neuen Slots. „shredTransactionSubscribe“ ist die transaktionsspezifische Schnittstelle, die auf derselben frühen Datenquelle aufbaut.

Methodenübersicht

shredTransactionSubscribe abonniert Benachrichtigungen zu Transaktionen vor der Ausführung aus der shred/entry-Erfassung. Es handelt sich dabei bewusst nicht um eine Konfigurationsvariante von transactionSubscribe. Die Nutzdaten unterscheiden sich, da die Datenstufe eine andere ist.

Sie akzeptiert ein optionales Filterobjekt als ersten und einzigen Parameter.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "vote": false,
      "signature": "optional-signature",
      "accounts": {
        "include": ["optional-pubkey"],
        "exclude": ["optional-pubkey"],
        "required": ["optional-pubkey"]
      }
    }
  ]
}

Alle Felder sind optional. Jede Kontenliste (einbeziehen, ausschließen, erforderlich) kann bis zu 50.000 Einträge enthalten.

Unterstützte Filter

Abstimmung

• Richtig: nur einfache Abstimmungstransaktionen.

• false: Einfache Abstimmungstransaktionen ausschließen.

• ausgelassen: sowohl Transaktionen mit Stimmrecht als auch solche ohne Stimmrecht einbeziehen.

Der „vote“-Filter entspricht der Klassifizierung von „Simple-Vote“-Transaktionen durch Agave. Das bedeutet nicht, dass „jede Transaktion, die irgendwo eine ‚Vote‘-Programmanweisung enthält“, darunter fällt. Gemischte Transaktionen mit einer „Vote“-Anweisung werden nicht als „Simple-Vote“-Transaktionen klassifiziert. „voteSubscribe“ ist eine andere Methode mit einem eigenen Parsing-Verhalten für Gossip-Vote-Transaktionen.

Unterschrift

• Gibt nur die Transaktion mit der angegebenen Signatur zurück.

accounts.include

• Liefert Transaktionen, die mindestens ein aufgeführtes Konto betreffen.

• Gleicht statische Kontenschlüssel mit aufgelösten, über ALT geladenen Adressen ab.

accounts.exclude

• Löscht Transaktionen, die eines der aufgeführten Konten betreffen.

• Gleicht statische Kontenschlüssel mit aufgelösten, über ALT geladenen Adressen ab.

accounts.required

• Liefert nur Transaktionen, die alle aufgeführten Konten betreffen.

• Gleicht statische Kontenschlüssel mit aufgelösten, über ALT geladenen Adressen ab.

Nicht unterstützte Parameter

„commitment“, „encoding“, „transactionDetails“, „showRewards“, „maxSupportedTransactionVersion“ und „failed“ werden nicht unterstützt, da von „shred“ abgeleitete Transaktionen JSON-Nutzdaten vor der Ausführung sind, die keine Ausführungsergebnisse oder Commit-Stufen aufweisen.

Beispielanfragen

Alle Transaktionen ohne Stimmrecht vor der Ausführung abonnieren

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "shredTransactionSubscribe",
  "params": [
    { "vote": false }
  ]
}

Eine bestimmte Signatur abonnieren

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
    }
  ]
}

Transaktionen abonnieren, die ein Konto betreffen

{
  "jsonrpc": "2.0",
  "id": 13,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "accounts": {
        "include": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"]
      }
    }
  ]
}

Mehrere Konten erfordern und ein anderes ausschließen

{
  "jsonrpc": "2.0",
  "id": 14,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "accounts": {
        "required": [
          "AccountA11111111111111111111111111111111111",
          "AccountB22222222222222222222222222222222222"
        ],
        "exclude": [
          "AccountC33333333333333333333333333333333333"
        ]
      }
    }
  ]
}

Antwort zum Abonnement

Bei Erfolg gibt der Server eine Abonnement-ID zurück. Verwenden Sie diese ID, um das Abonnement zu kündigen.

{
  "jsonrpc": "2.0",
  "result": 123,
  "id": 14
}

Abmelden

{
  "jsonrpc": "2.0",
  "id": 15,
  "method": "shredTransactionUnsubscribe",
  "params": [123]
}

Benachrichtigungsform

Eine Benachrichtigung verwendet den Standard-JSON-RPC-PubSub-Envelope, der innere Transaktionswert besteht jedoch aus Daten, die vor der Ausführung vorliegen.

{
  "jsonrpc": "2.0",
  "method": "shredTransactionNotification",
  "params": {
    "result": {
      "context": { "slot": 418437508 },
      "value": {
        "slot": 418437508,
        "signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW",
        "transaction": {
          "signatures": [
            "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
          ],
          "message": {
            "header": {
              "numRequiredSignatures": 1,
              "numReadonlySignedAccounts": 0,
              "numReadonlyUnsignedAccounts": 2
            },
            "accountKeys": [
              "FeePayer11111111111111111111111111111111111",
              "Program111111111111111111111111111111111111"
            ],
            "recentBlockhash": "Eit7...",
            "instructions": [
              {
                "programIdIndex": 1,
                "accounts": [0],
                "data": "3Bxs4NN8M2Yn4TLb",
                "stackHeight": 1
              }
            ]
          }
        },
        "version": "legacy"
      }
    },
    "subscription": 123
  }
}

Beispiel für eine versionierte Transaktion mit geladenen Adressen

Bei v0-Transaktionen werden in `transaction.message.addressTableLookups` die Verweise auf die Nachschlagetabellen gespeichert, und `value.loadedAddresses` enthält die aufgelösten öffentlichen Schlüssel.

{
  "jsonrpc": "2.0",
  "method": "shredTransactionNotification",
  "params": {
    "result": {
      "context": { "slot": 418437509 },
      "value": {
        "slot": 418437509,
        "signature": "7rYg...",
        "transaction": {
          "signatures": ["7rYg..."],
          "message": {
            "header": {
              "numRequiredSignatures": 1,
              "numReadonlySignedAccounts": 0,
              "numReadonlyUnsignedAccounts": 1
            },
            "accountKeys": [
              "FeePayer11111111111111111111111111111111111",
              "Program111111111111111111111111111111111111"
            ],
            "recentBlockhash": "AbCd...",
            "instructions": [
              {
                "programIdIndex": 1,
                "accounts": [0, 2, 3],
                "data": "3Bxs4NN8M2Yn4TLb",
                "stackHeight": 1
              }
            ],
            "addressTableLookups": [
              {
                "accountKey": "LookupTab1e11111111111111111111111111111111",
                "writableIndexes": [12],
                "readonlyIndexes": [3]
              }
            ]
          }
        },
        "version": 0,
        "loadedAddresses": {
          "writable": ["Writab1eLoaded11111111111111111111111111111"],
          "readonly": ["Readon1yLoaded11111111111111111111111111111"]
        }
      }
    },
    "subscription": 124
  }
}

Wenn Blazar eine oder mehrere Nachschlagetabellen nicht aus dem Cache abrufen kann, werden folgende v0-Benachrichtigungen gesetzt:

"loadedAddresses": null

Selbst bei der Startphase undgRPC Solana gRPC kann es vorkommen, dass eine gerade erweiterte Tabelle mit dem Cache um die Wette läuft. In diesem Fall sorgt Blazar für eine korrekte Benachrichtigung, indem es für v0-Transaktionen, deren geladene Adressen unvollständig sind, `loadedAddresses: null` setzt.

Bei älteren Transaktionen wird „loadedAddresses“ weggelassen.

Was in der Nutzlast nicht enthalten ist

Da es sich hierbei um Daten vor der Ausführung handelt, enthält die Benachrichtigung Folgendes nicht:

• Meta

• ähm

• Protokolle

• interne Anweisungen

• Salden vor und nach der Umstellung

• Token-Guthaben vor und nach der Transaktion

• Verbrauchte Recheneinheiten

• Daten zurückgeben

• Belohnungen

• Index der letzten Transaktion im Block

shredTransactionSubscribe ist eine Methode zur frühzeitigen Beobachtung, keine Methode zur Ermittlung des Ausführungsergebnisses.

Erste Schritte

1. Melden Sie sich bei Ihrem Quicknode an.

2. Wählen Sie Ihre Solana endpointaus.

3. Kopieren Sie endpoint Ihres endpoint (wssendpoint.mainnet.quiknode.pro/abc123) und stellen Sie mithilfe Ihres bestehenden WebSocket-Client-Codes eine Verbindung her.

4. In den obigen Beispielanfragen finden Sie eine Anleitung zum Senden einer „shredTransactionSubscribe“-Anfrage mit einem optionalen Filter.

5. Verarbeiten Sie „shredTransactionNotification“-Nachrichten, sobald sie eintreffen.

Sind Sie neu bei Solana ? Der Leitfaden „So erstellen Sie Solana Abonnements“ enthält alles, was Sie wissen müssen.

Für Teams, die Solana mit geringerer Latenz benötigen, das über WebSockets hinausgeht, QuicknodeSolana gRPC bietet Yellowstone Echtzeit streams demselben endpoint .

Häufig gestellte Fragen

Ist „shredTransactionSubscribe“ dasselbe wie „transactionSubscribe“ mit einem früheren Commit?

„transactionSubscribe“ wird nach der Ausführung aufgerufen und enthält Metadaten zum Transaktionsstatus. „shredTransactionSubscribe“ wird vor der Ausführung aufgerufen und enthält keine Protokolle, Metadaten, Fehlermeldungen, Salden oder Recheneinheiten.

Kann eine Shred-Transaktion später fehlschlagen?

Ja. Eine anhand von Shreds beobachtete Transaktion kann später bei der Ausführung fehlschlagen, verfallen oder nicht im endgültigen Ledger erscheinen. Diese Methode dient als Signal für eine vorläufige Beobachtung, nicht als Signal für die Endgültigkeit.

Umfassen die Kontenfilter auch Konten aus der Adress-Lookup-Tabelle?

Ja. Kontofilter gleichen statische Kontoschlüssel mit aufgelösten, über ALT geladenen Adressen aus dem lokalen Lookup-Tabellen-Cache von Blazar ab.

Was passiert, wenn ein ALT deaktiviert wird?

Ein deaktivierter ALT kann während seines SlotHashes-Abklingzeitfensters weiterhin verwendet werden. Blazar wertet deaktivierte Tabellen während dieses gültigen Abklingzeitraums aus und behandelt eindeutig abgelaufene deaktivierte Tabellen als nicht ausgewertet.

Für wen ist diese Methode geeignet?

Setzen Sie diese Lösung ein, wenn die Absicht einer Transaktion in der frühen Phase wichtiger ist als das Ergebnis der Ausführung: Analysen mit geringer Latenz, Überwachung der Kontoaktivitäten, Diagnose des Transaktionslebenszyklus, Handelsinfrastruktur und Beobachtbarkeit vor der Ausführung.

Wer sollte diese Methode nicht anwenden?

Verwenden Sie diese Methode nicht, wenn Sie den endgültigen Transaktionsstatus, Protokolle, Guthaben, Änderungen des Token-Guthabens, Recheneinheiten, Belohnungen oder die Zugehörigkeit zu finalisierten Blöcken benötigen. Verwenden Sie hierfür die RPC-/WebSocket-Methoden nach der Ausführung.

Das Fazit

Bislang waren für Transaktionsdaten vor der Ausführung spezielle Solana erforderlich: gRPC , Bincode-Dekodierung und Pipelines zur Shred-Auswertung. Die Funktion „shredTransactionSubscribe“ von Blazar macht diese Anforderungen überflüssig und stellt die Transaktionsabsicht vor der Ausführung als standardmäßiges WebSocket-JSON-RPC-Abonnement bereit.

Die Funktion ist endpoint auf jedem endpoint verfügbar. Melden Sie sich in Ihrem Quicknode an, um loszulegen, oder erstellen Sie ein Quicknode , falls Sie noch keines haben.

Da sich shredTransactionSubscribe derzeit in der Beta-Phase befindet, freuen wir uns über Ihr Feedback und Ihre Vorschläge. Bitte senden Sie uns eine E-Mail an quicknode oder kontaktieren Sie uns auf Discord.