Wir stellen vor: shredTransactionSubscribe – Transparenz bei Transaktionen in der „ Solana “ vor der Ausführung

Quicknode

30. Juni 2026 – 9 Minuten Lesezeit

Teilen

Als bevorzugte Quelle hinzufügen

Solana ist unter anderem deshalb so schnell, weil Blöcke nicht als einzelne große Objekte durch das Netzwerk übertragen werden. Validatoren teilen die Blockdaten in kleine Teile, sogenannte „Shreds“, auf und versenden diese, noch bevor der Block vollständig wiedergegeben wurde. Dies geschieht, bevor normale RPC-Abonnements Ausführungsdaten anzeigen können.

Blazar, die WebSocket-Engine von Quicknode unter Solana , enthält nun shredTransactionSubscribe. Es wandelt dieses frühe Signal in eine WebSocket-Methode um, die Entwickler nutzen können. Es abonniert Transaktionen, die während der Shred- und Entry-Erfassung vor der Ausführung erkannt 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 “-Blocks mit fester Größe, das während der Erstellung des Blocks über das Netzwerk gesendet wird. Durch das Auslesen von Shreds können Sie Transaktionsdaten einsehen, während diese das Netzwerk durchlaufen, noch bevor der fertige Block über RPC-Methoden nach der Ausführung abgefragt werden kann.

Fragmente können zu Einträgen zusammengesetzt werden. Einträge enthalten Solana Versionsgesteuerte Transaktion Werte: Signaturen, Nachrichten, statische Kontoschlüssel, Anweisungen, aktuelle Block-Hashes und 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.

Shred-Time-Daten können früher eintreffen als Ausführungsdaten. Sie dürfen jedoch keine Ausführungsergebnisse wie Meta, Err, Protokolle, Token-Guthaben, Recheneinheiten oder interne Befehle enthalten.

Wie Blazar Daten erfasst und normalisiert

Die Arbeit mit rohen Shred-Daten weist zwei Lücken auf, die die meisten Entwickler nicht ohne Weiteres schließen können.

Zunächst einmal die Tools. Ein roher „SubscribeEntries“-Stream erfordert eine „ gRPC “, eine Bincode-Decodierung, eine Transaktionsanalyse und die Auflösung der Adress-Lookup-Tabelle. Außerdem muss man vor der Ausführung genau wissen, was bekannt ist und was nicht. Die meisten App-Entwickler wollen einfach nur ein WebSocket-JSON-RPC-Abonnement.

Zweitens benötigt die Kontenfilterung Nachschlagetabellen. Die meisten Transaktionen in „ Solana “ Version 0 verwenden Adress-Nachschlagetabellen (ALTs). Ohne die lokale Auflösung von ALTs können Kontenfilter eine Transaktion übersehen, die ein Konto nur über eine Nachschlagetabelle betrifft. Blazar löst bei der Filterung nach Konten sowohl statische Schlüssel als auch geladene ALT-Adressen auf.

Blazar erhält einen frühen „ Solana “-Transaktions-Feed von der Shred-Streaming-Infrastruktur. Es wandelt dieses Low-Level-Netzwerksignal in ein standardmäßiges WebSocket-JSON-RPC-Abonnement um. Blazar kann Transaktionen erkennen, bevor dies bei normalen RPC-Methoden nach der Ausführung der Fall ist. Anschließend sendet es einen strukturierten shredTransactionNotification zusammen mit dem Transaktionskörper, dem Slot, der Signatur, der Version und den aufgelösten geladenen Adressen, sofern verfügbar.

Behandeln Sie den Datenstrom als ein frühes „Best-Effort“-Signal. Benachrichtigungen treffen in etwa in der Reihenfolge ihrer Übermittlung ein, wobei keine strenge Reihenfolge garantiert ist. Dieselbe Transaktion kann gelegentlich mehrmals auftreten; führen Sie daher eine Deduplizierung anhand der Signatur durch, wenn Sie eine „Exactly-Once“-Zustellung benötigen.

Blazar bereichert zudem die aus Shred abgeleiteten Daten, bevor es sie versendet. Anstatt ein Rohsignal weiterzuleiten und jeden Client dazu zu zwingen, die gleiche Arbeit zu leisten, normalisiert es das Transaktionsformat und löst, soweit möglich, die Adressen der Nachschlagetabellen auf. Abonnenten erhalten so bereits vor der Ausführung einen umfassenderen Überblick über die Konten, ohne eine spezielle „ Solana “-Netzwerkinfrastruktur betreiben oder einen eigenen Shred-Parser entwickeln zu müssen.

Einblicke in den zeitlichen Ablauf der „ Solana “-Transaktion

Die „Shred-Time“-Sichtbarkeit fügt der Zeitachse der „ Solana “-Daten einen neuen, früheren Zeitpunkt hinzu:

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

Die meisten WebSocket-Methoden von „ Solana “ werden nach der Ausführung oder im Zusammenhang mit Änderungen des Validator-Zustands ausgeführt. shredTransactionSubscribe zeigt den früheren Punkt auf, an dem die Einträge dekodiert werden.

Es ersetzt nicht transactionSubscribe. Es handelt sich um eine frühere, vor der Ausführung stattfindende Ergänzung 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 verbessert andere, indem es Daten bereits vor der Ausführung bereitstellt.

Frühe Transaktionsabsicht

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

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 vielgenutzte Konten, Pools, Token-Konten, Tresore oder Protokollstatuskonten im Blick zu behalten.

Lebenszyklusverfolgung auf Signatur-Ebene

Kombinieren Sie es mit Anmeldung und enableReceivedNotification: true um zu sehen, wann eine Signatur vor der Ausführung zum ersten Mal erkannt wurde und ob sie später erfolgreich war oder fehlgeschlagen ist.

Betriebsdiagnostik

Support- und Infrastrukturteams können Fragen beantworten wie: Wurde die Transaktion vor der Ausführung erkannt? Ist sie erst später eingegangen? Wurde sie gar nicht erkannt? Wurden Adressen aus der Lookup-Tabelle verwendet? Dadurch lassen sich Probleme im Zusammenhang mit dem Lebenszyklus von Transaktionen leichter diagnostizieren.

Abstimmungs- und Spielautomaten-Signale

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

Methodenübersicht

shredTransactionSubscribe abonniert Benachrichtigungen zu Transaktionen vor der Ausführung aus shred und der Datenerfassung. Es handelt sich bewusst nicht um eine Konfigurationsoption von transactionSubscribe. Die Nutzdaten unterscheiden sich, da die Daten aus einer anderen Phase stammen.

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 Abstimmungsfilter verwendet die Transaktionsklassifizierung „einfache Abstimmung“ von Agave. Das bedeutet nicht „jede Transaktion mit einer ‚Vote‘-Programm-Anweisung“. Gemischte Transaktionen, die eine Abstimmungsanweisung enthalten, werden nicht als einfache Abstimmungen klassifiziert. „voteSubscribe“ ist eine separate Methode mit eigener Auswertung von 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 sowie aufgelöste, über ALT geladene Adressen ab.

accounts.exclude

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

• Gleicht statische Kontenschlüssel sowie aufgelöste, über ALT geladene Adressen ab.

accounts.required

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

• Gleicht statische Kontenschlüssel sowie aufgelöste, über ALT geladene Adressen ab.

Nicht unterstützte Parameter

„commitment“, „encoding“, „transactionDetails“, „showRewards“, „maxSupportedTransactionVersion“ und „failed“ werden nicht unterstützt. Aus Shred abgeleitete Transaktionen sind JSON-Nutzdaten vor der Ausführung, daher weisen sie keine Ausführungsergebnisse oder Commit-Stufen auf.

Beispielanfragen

Alle Transaktionen vor der Ausführung ohne Stimmrecht 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 vor der Ausführung.

{
  "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 Warm-up-Phase beim Systemstart und bei Live- Solana -Updates (gRPC ) kann es vorkommen, dass eine gerade erweiterte Tabelle den Cache überholt. In diesem Fall setzt Blazar für v0-Transaktionen, deren geladene Adressen unvollständig sind, `loadedAddresses: null`, damit die Benachrichtigung korrekt bleibt.

Bei älteren Transaktionen wird „loadedAddresses“ weggelassen.

Was in der Lieferumfang 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 und keine Methode zur Ermittlung des Ausführungsergebnisses.

Erste Schritte

1. Melden Sie sich bei Ihrem „Quicknode “-Dashboard an.

2. Wählen Sie Ihre Solana endpoint.

3. Kopieren Sie die URL Ihres WSS- endpoint s (wss://your-endpoint-name.solana-mainnet.quiknode.pro/abc123) und stellen Sie mithilfe Ihres vorhandenen WebSocket-Client-Codes eine Verbindung her.

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

5. Verarbeite „shredTransactionNotification“-Nachrichten, sobald sie eintreffen.

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

Für Teams, die ein Solana -Streaming mit geringerer Latenz benötigen, das über WebSockets hinausgeht, bietet das Produkt von QuicknodeSolana gRPCYellowstone-kompatibles Echtzeit- streams aus demselben endpoint -Ökosystem.

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 den 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 dieser Abklingzeit aus und behandelt Tabellen, deren Gültigkeit eindeutig abgelaufen ist, als unausgewertet.

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 erforderten Transaktionsdaten vor der Ausführung eine maßgeschneiderte Netzwerk Solana -Infrastruktur: „ gRPC “-Clients, Bincode-Decodierung und Pipelines zur Shred-Auswertung. Die Funktion „shredTransactionSubscribe“ von Blazar macht dies überflüssig. Sie liefert die Transaktionsabsicht vor der Ausführung als standardmäßiges WebSocket-JSON-RPC-Abonnement.

Die Funktion ist ab heute auf jedem Quicknode Blazar WebSocket endpoint verfügbar. Melden Sie sich bei Ihrem Quicknode -Dashboard an, um loszulegen, oder erstellen Sie ein Quicknode -Konto, 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 solana@quicknode.com oder kontaktieren Sie uns auf Discord.