Solana v1-Transaktionen erklärt: Größenbeschränkungen und grundlegende Änderungen

Quicknode

1. September 2026 – 10 Minuten Lesezeit

Teilen

Als bevorzugte Quelle hinzufügen

Entwickler, die komplexe Anwendungen auf Solana erstellen, haben jahrelang daran gearbeitet, die Begrenzung der Transaktionsgröße zu umgehen. Mit v0 wurden Adressnachschlagetabellen eingeführt, wodurch eine Transaktion auf mehr Konten verweisen kann, ohne die Grenze von 1.232 Byte zu überschreiten. Das neueste Update führt v1-Transaktionen ein, wodurch die Begrenzung selbst um das 3,3-Fache angehoben wird.

Mit „Transaction v1“ wird die maximale Größe serialisierter Transaktionen von 1.232 Byte auf 4.096 Byte erhöht; diese Funktion wird Anfang September 2026 mit Agave v4.2 aktiviert. Für Teams, die Zero-Knowledge-Anwendungen (ZK), Multisig-Systeme und komplexe DeFi-Primitive entwickeln, macht der zusätzliche Speicherplatz eine ganze Reihe von Umgehungslösungen überflüssig.

Niemand muss v1 übernehmen, um davon betroffen zu sein. Alles, was Daten von Solana abruft, ist davon betroffen, unabhängig davon, ob es jemals eine v1-Transaktion sendet oder nicht.

Die Begrenzung auf 1.232 Byte stammte aus dem UDP-Protokoll. Solana hat die Transaktionserfassung bereits vor Jahren auf QUIC umgestellt, wodurch diese Einschränkung wegfiel. Die Begrenzung blieb jedoch bestehen. Die Teams teilten weiterhin Transaktionen auf, richteten Nachschlagetabellen ein und passten ihre Lösungen an eine Obergrenze an, die nicht mehr mit dem zugrunde liegenden Transportprotokoll übereinstimmte.

Die neue Obergrenze beruht nicht auf einer Netzwerkbeschränkung. 4.096 Byte entsprechen den Speicherseiten der Validatoren. Das schafft Platz für ZK-Beweise, BLS-Signaturschemata, vertrauliche Übertragungen, Oracle-Preisaktualisierungsanfragen und die Möglichkeit, mehr Befehle in eine einzelne Transaktion zu packen, ohne dass Bündelungsschemata erforderlich sind. Außerdem passt ein vollständiger Satz von 64 Konten inline hinein, weshalb v1 vollständig auf Adress-Lookup-Tabellen verzichtet.

Was ist eine „ Solana “-Transaktion der Version 1?

Eine v1-Transaktion ist ein neues Überweisungsformat der „ Solana “ mit einer Obergrenze von 4.096 Byte. Es handelt sich nicht um eine v0-Transaktion mit einer höheren Obergrenze; die beiden Formate unterscheiden sich in fünf Punkten:

• Versionsbyte 0x81 befindet sich am Offset Null, sodass jeder Empfänger das Format anhand eines einzigen Bytes identifizieren kann

• Signaturen werden an das Ende der Transaktion verschoben, anstatt der Nachricht vorangestellt zu werden

• Feste Breite u8 Zählwerte ersetzen die „compact-u16“-Kodierung

• Befehlsköpfe werden vor ihren Nutzdaten gruppiert, wodurch die Grenzen direkt berechnet werden können

• Ressourcenbeschränkungen werden in eine Kopfzeilenkonfigurationsmaske übernommen

Adress-Nachschlagetabellen sind nicht mehr vorhanden

Die Unterstützung für Adress-Nachschlagetabellen wurde in Version 1 entfernt. Jedes Konto wird nun inline als vollständiger 32-Byte-öffentlicher Schlüssel übertragen, und ein maximaler Satz von 64 Adressen belegt 2.048 Byte – die Hälfte des neuen Envelopes, bevor auch nur eine einzige Anweisung hinzugefügt wird.

Solana Die Kosten wurden für den gesamten mainnet -Datenverkehr gemessen. Etwa 62 % der v0-Transaktionen greifen auf mindestens eine Nachschlagetabelle zu. Umgerechnet auf v1 weisen die Hälfte davon einen Mehraufwand von weniger als 420 Byte und 90 % einen Mehraufwand von weniger als 1.400 Byte auf. Transaktionen, die auf mehrere Tabellen zugreifen, um jeweils eine Handvoll Adressen abzurufen, werden kleiner, da der Overhead der Tabellen den durch die Komprimierung erzielten Gewinn übersteigt.

Das Entfernen von Nachschlagetabellen vereinfacht zudem die Einbindung von Validatoren. In v0 wird eine zustandsabhängige Tabellenauflösung erzwungen, noch bevor ein Validator überhaupt weiß, welche Konten von einer Transaktion betroffen sind. In v1 wird der vollständige Kontensatz direkt in der Transaktion selbst übergeben, sodass die Berechnung von Gebühren und Prioritäten früher erfolgt.

Was man mit den zusätzlichen Bytes bekommt

Anwendungen mit hohem Payload-Anteil gewinnen an Kapazität, da Nachweise und Befehlsdaten Bytes verbrauchen, ohne Kontoslots zu belegen. Anwendungen mit hohem Kontosupport, darunter Multi-Venue-Routing und umfassende Protokollzusammensetzung, nutzen den Großteil des neuen Speicherplatzes dafür, die Adressen wieder einzubinden, die zuvor durch Lookup-Tabellen komprimiert wurden. Für diese Teams stellt die Obergrenze von 64 Konten nun die einschränkende Bedingung dar, und der Verbleib bei v0 ist eine vernünftige Entscheidung.

Bytes sind die einzige Beschränkung, die v1 auferlegt. Die Anzahl der Accounts bleibt bei 64, die der Befehle bei 64 und die der Signaturen bei 12.

Was geht schief beim Auslesen von „ Solana “-Daten?

Anwendungen, die „ Solana “-Daten lesen oder indizieren, schlagen fehl, sobald zum ersten Mal eine v1-Transaktion in einem von ihnen abgefragten Block auftaucht. Code, der eine Transaktion von vorne liest, stößt auf Nachrichtendaten, in denen Legacy- und v0-Signaturen stehen; daher lässt sich ein Parser nicht durch eine Erhöhung der Längenprüfung beheben.

getBlock und getTransaction lehnen Transaktionen der Version 1 ab

Ein Aufruf, bei dem die Unterstützung für v1 nicht deklariert wurde, führt zu einem Fehler. -32015 sobald sie auf eine solche stößt, und der gesamte Lesevorgang für den Block schlägt fehl. Indexierer und Backfill-Jobs werden angehalten, anstatt die eine Transaktion zu überspringen, die sie nicht analysieren können. Set maxSupportedTransactionVersion: 1 bei beiden Aufrufen als JSON-Ganzzahl 1. Die Zeichenfolge "1" schlägt fehl, ebenso wie 0, daher ist Code, der sich während der Einführung von v0 für die Unterstützung von v0 entschieden hat, noch nicht abgedeckt. getSignaturesForAddress bleibt davon unberührt, da es Transaktionskörper niemals überprüft.

Der Aufruf, der fehlschlägt:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [402184291, { "encoding": "json" }]
}

Derselbe Aufruf, korrigiert. Neben dem Versionsparameter ist Base64 erforderlich, da Base58 keine Transaktionen mit mehr als 1.232 Byte kodieren kann:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [
        402184291,
        {
            "encoding": "base64",
            "maxSupportedTransactionVersion": 1
        }
    ]
}

blockSubscribe läuft nicht weiter

blockSubscribe stößt aus null und bleibt hängen, sobald es eine v1-Transaktion erreicht, ohne dass ein Fehler abgefangen werden kann. Die auf Fehlerraten basierende Überwachung wird nie ausgelöst, sodass das Abonnement beim ersten v1-Slot hängen bleibt und dort verbleibt. Set maxSupportedTransactionVersion: 1 im Abonnement, behandeln Sie block: null als Fehler statt als leeren Block behandeln und eine Verfallsprüfung hinzufügen, da sonst nichts anderes dies aufdecken wird.

Der ComputeBudget-Scan liefert Nullen als Ergebnis

In Version 1 wurden die Rechenlimit- und Prioritätsgebühren aus den Anweisungen herausgenommen und in eine Konfiguration auf Nachrichtenebene verlagert. Indexer, die nach „ComputeBudget“-Anweisungen suchen, finden keine Übereinstimmungen und schreiben Nullen in jeden nachgelagerten Datensatz, ohne dass auf irgendeiner Ebene ein Fehler auftritt. Lesen Sie die Limits stattdessen aus der Transaktionskonfiguration aus. Diese ist bei Antworten mit aktivierter Option in der Nachricht enthalten, fehlt jedoch vollständig bei Legacy- und v0-Antworten. Nicht festgelegte Felder werden zurückgegeben. null:

"message": {
    "instructions": ["… no ComputeBudget instruction here …"],
    "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
    "transactionConfig": {
        "computeUnitLimit": 30000,
        "heapSize": null,
        "loadedAccountsDataSizeLimit": 200000,
        "priorityFee": null
    }
}

Die Zusammenfassung der Prioritätsgebühren wird bei einer Änderung der Einheit unterbrochen

Bei Legacy und v0 wird die Gebühr in Mikro-Lamports pro Recheneinheit angegeben. Bei v1 wird sie als absoluter Gesamtbetrag in Lamports angegeben. Um beide Werte in einem Dashboard darzustellen, multiplizieren Sie den v0-Preis mit der von der Transaktion angeforderten Recheneinheitsgrenze und dividieren Sie das Ergebnis durch 1.000.000:

20.000 CU × 250.000 Mikro-Lamports/CU = 5.000 Lamports   // v0
                                        5.000 Lamports   // entspricht v1

Lässt man die Umrechnung weg, haben die Summen keine Aussagekraft.

Geyser- streams en unterliegen keinem Versionsbeschränkung

Für Streaming-Nutzer gibt es kein Äquivalent zu maxSupportedTransactionVersion und es gibt keine Möglichkeit, dies zu deaktivieren. Aktualisieren Sie das Geyser-Plugin „ Yellowstone “ auf Version 15.1.1 und generieren Sie die Protobuf-Stubs unter Version 12.6.0 oder höher neu, wodurch das Message.config Feld. Ein „stale“ Consumer gibt bei v1 keinen Fehler aus. Er liest die Transaktion als v0 mit einem leeren Rechenbudget.

Die Version strukturell erkennen anhand von Message.config, und überprüfen Sie dies in dieser Reihenfolge:

Die Reihenfolge ist wichtig, weil versionsverwaltet Dies gilt sowohl für v0 als auch für v1. Bei der Überprüfung wird zunächst jede v1-Transaktion stillschweigend als v0 klassifiziert, wobei das Rechenbudget auf Null gesetzt wird.

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
    if (message.config !== undefined) {
        return "v1";
    }
    return message.versioned ? "v0" : "legacy";
}

config ist eine Unternachricht, und Felder von Unternachrichten sind in proto3 immer explizit vorhanden, sodass diese Überprüfung unabhängig davon gilt, wie ein Decoder mit Standardwerten umgeht.

Ältere „ Yellowstone “-Builds: Downgrade von v1 auf v0

Yellowstone Geyser-Plugins aus Versionen vor 15.1.1 wandeln v1-Transaktionen in eine v0-Darstellung um, bevor sie an das Netzwerk gesendet werden. Der Stream funktioniert zwar weiterhin, aber die von ihm gelieferten Daten stimmen nicht mehr mit den auf der Blockchain ausgeführten Transaktionen überein. Führen Sie ein Upgrade auf Version 15.1.1 oder höher durch und berücksichtigen Sie diese Diskrepanz bei allen Vorgängen, bei denen während der Nutzung einer älteren Version Stream-Daten mit dem Blockchain-Status abgeglichen wurden.

Was geht beim Senden von v1-Transaktionen schief?

Die oben genannten Fehler treten unabhängig davon auf, ob ein „ equipe “ v1 übernimmt oder nicht. Diese hier hingegen nicht. Nichts von dem, was im Folgenden beschrieben wird, geschieht, bis eine Anwendung selbst eine v1-Transaktion erstellt und übermittelt, und jeder Punkt betrifft eine Änderung hinsichtlich der Art und Weise, wie eine Transaktion aufgebaut wird, und nicht, wie sie gelesen wird. Legacy- und v0-Transaktionen funktionieren weiterhin unverändert mit 1.232 Byte, sodass die Entscheidung, v1 zu senden, von der Kapazität abhängt. Eine Transaktion, die mehr als 1.232 Byte benötigt, hat keine andere Wahl.

Nicht festgelegte Ressourcengrenzen werden standardmäßig auf Null gesetzt

Bei den Versionen „Legacy“ und „v0“ wird auf 200.000 Recheneinheiten pro Befehl und 64 MiB geladener Kontodaten zurückgegriffen, wenn in einer Transaktion keine Angaben gemacht werden. Bei „v1“ wird auf null zurückgegriffen und die Transaktion wird abgebrochen. Jede v1-Transaktion legt explizit ein Limit für die Recheneinheiten und ein Limit für die Größe der geladenen Kontodaten fest. In @solana/kit 8.0 Diese werden aus den ComputeBudget-Anweisungen in die Nachrichtenkonfiguration verschoben:

import { setTransactionMessageConfig } from '@solana/kit';

const message = setTransactionMessageConfig(
    {
        computeUnitLimit: 20_000,
        loadedAccountsDataSizeLimit: 64 * 1024,
        priorityFeeLamports: 5_000n,
    },
    baseMessage,
);

Bestimmen Sie beide Grenzwerte in einem Simulationsdurchlauf, wobei jeweils der maximale Wert eingestellt ist, und schreiben Sie dann den zurückgegebenen Wert verbrauchte Einheiten und Größe der geladenen Kontodaten Zurück zur Konfiguration. Runden Sie die Datengröße auf die nächste 32-KiB-Seite auf. Das Blockkostenmodell berechnet die Kosten in 32-KiB-Seiten, daher ist der Spielraum unterhalb der nächsten Grenze kostenlos.

Planen Sie mehr Speicherplatz ein, als in der Simulation angegeben wird. Das Laden eines noch nicht vorhandenen Kontos kostet keinen Speicherplatz, aber sobald es angelegt ist, benötigt es 64 Byte plus seine Daten. Daher schlägt eine Begrenzung, die exakt auf die Simulationsangaben abgestimmt ist, fehl mit Maximale Datengröße für geladene Konten überschritten wenn das Konto angezeigt wird, bevor die Transaktion verbucht wird.

ComputeBudget-Anweisungen werden zu No-Ops

v1 akzeptiert sie, berechnet jeweils 150 Recheneinheiten und ignoriert sie bei der Konfiguration. Eine Transaktion, die ComputeBudget-Anweisungen enthält, aber keine Nachrichtenkonfiguration aufweist, durchläuft die Validierung und wird anschließend ohne Beschränkungen ausgeführt. Entfernen Sie sie vollständig aus den v1-Buildern. Die Nachrichtenkonfiguration ersetzt sie, und jede zurückbleibende Anweisung belegt einen der 64 verfügbaren Befehlsslots sowie 150 Recheneinheiten, ohne etwas zu bewirken.

Prioritätsgebühren

In Version 1 wird die Prioritätsgebühr als absolute Lamport-Summe festgelegt. Die Berechnung der Mikro-Lamports pro Recheneinheit aus Version 0 wird nicht übernommen. Der Wert ist ein „bigint“, und der Setter wird bei der Kompilierung für Legacy- und v0-Nachrichten abgelehnt:

import { setTransactionMessagePriorityFeeLamports } from '@solana/kit';

const message = setTransactionMessagePriorityFeeLamports(5_000n, baseMessage);

Die Base58-Kodierung ist auf 1.232 Byte begrenzt

Transaktionen, die diesen Betrag übersteigen, erfordern Kodierung: „base64“ bei der Übermittlung. Anträge, in denen „base58“ fest codiert ist, schlagen bei den von Version 1 ermöglichten großen Transaktionen fehl.

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
        "<base64-encoded transaction>",
        { "encoding": "base64" }
    ]
}

Doppelte Adressen werden abgelehnt

Legacy und v0 lassen wiederholte Kontoadressen innerhalb einer Transaktion zu. v1 lehnt diese ab.

Welche Client-Versionen unterstützen Version 1?

Die Unterstützung für v1 beginnt bei @solana/kit 8.0.0, die Rust-Crates der Version 4.2.x, Solders 0.29.0 und „ solana-go“ 1.23.0.

Das v1-Format läuft derzeit auf einem lokalen Validator, ohne dass ein Feature-Gate erforderlich ist. solana-Test-Validator wird ab Version 4.2 unterstützt, Surfpool ab Version 1.5 und ein Ephemeral Surfnet, konfiguriert für SIMD-0296 bietet eine gehostete Option an.

Quicknode Unterstützung für Version 1

Quicknode RPC-Endpunkte und APIs unterstützen v1-Transaktionen bereits bei der Aktivierung. Es ist keine Migration von „ endpoint “, keine Planänderung, kein Konfigurationsflag und kein Support-Ticket erforderlich.

Quicknode Der Alpenglow-Cluster wickelt bereits heute Transaktionen der Version 1 ab, sodass das Format anhand eines Live- endpoint s getestet werden kann, bevor es auf testnet verfügbar ist. Testnet steht noch unter dem Vorbehalt der Aktivierung von SIMD-0385 Transaction V1, die für Mittwoch, den 2. September 2026, um 10:30 Uhr UTC vorgesehen ist.

Der verbleibende Teil der Arbeit betrifft den Anwendungscode. Weiter maxSupportedTransactionVersion: 1 auf getTransaction und getBlock, führen Sie ein Upgrade auf eine der oben aufgeführten Client-Versionen durch, ersetzen Sie das Scannen von ComputeBudget-Befehlen durch die Nachrichtenkonfiguration, vereinheitlichen Sie die Prioritätsgebühreneinheiten über alle Formate hinweg und wechseln Sie bei Transaktionen mit mehr als 1.232 Byte zur Base64-Kodierung.