Am Rand des Determinismus: Transaktionslebenszyklus in Solana Sealevel und Sui Object Runtime

Was ist der Lebenszyklus einer Blockchain-Transaktion?

Blockchains verarbeiten Transaktionen. Transaktionen verändern den Zustand, also die aktualisierte Ansicht der Accounts auf einer Blockchain. Der Lebenszyklus einer Transaktion bringt die Designphilosophie einer Blockchain besonders klar zum Ausdruck. Er liefert technischen Stakeholdern wichtige Erkenntnisse darüber, wie die Chain Durchsatz und Sicherheit optimiert, welche Determinismusgarantien sie bietet, welche relativen Entwicklungskosten entstehen und welche potenziellen Probleme unter realen Bedingungen auftreten können.

In den folgenden Abschnitten betrachten wir die verschiedenen Phasen, die Transaktionen von der Einreichung bis zur Finalisierung durchlaufen, und wie sich dieser Prozess auf unterschiedlichen Ebenen dieser Chains auf die Ausführung auswirkt.

Lebenszyklus einer Solana-Transaktion

Die Solana-Blockchain basiert auf einem einzigartigen Design. Sie verwendet Proof-of-Stake (PoS) als Konsensmechanismus und Proof-of-History (PoH) als Zeitmechanismus, um Transaktionen effizient zu ordnen.

Solanas Designmodell ist Account-zentriert. Anders gesagt: „Alles auf Solana ist ein Account“.

Accounts speichern Daten, darunter Zustände und ausführbare Binärdateien, also Programmcode. Transaktionen enthalten Anweisungen, die den Zustand von Accounts verändern. Nodes, die am Konsens im Netzwerk teilnehmen und Transaktionen verarbeiten, heißen Validatoren. Der Prozess, durch den Transaktionen verarbeitet werden, um einen Account zu verändern, wird als Pipelining bezeichnet. Die einzelnen Punkte im Lebenszyklus einer Transaktion heißen Phasen.

Eine Solana-Transaktion

Auf Solana besteht eine Transaktion aus Signaturen serialisierter Nachrichten, die mit dem ersten Schlüssel des Account-Schlüssels von Message signiert wurden.

Die Nachricht einer Transaktion ist eine Datenstruktur mit Header, Account-Schlüsseln, aktuellem Blockhash und Anweisungen. Der Header enthält MessageHeader, das die Anordnung der Account-Schlüssel von Message beschreibt.

Jede Anweisung definiert ausdrücklich, auf welche Accounts sie zugreifen darf und welche Berechtigungen jeweils erforderlich sind. Diese Berechtigungen geben an, ob ein Account schreibgeschützt oder les- und beschreibbar ist und ob er die Transaktion mit dieser Anweisung signiert haben muss.

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

Einzelne Anweisungen enthalten eine Liste aller Accounts, auf die sie zugreifen können, sowie die jeweils erforderlichen Berechtigungen.

Ein Message enthält eine einzige gemeinsame, flache Liste aller Accounts, die sämtliche Anweisungen der Transaktion benötigen. Diese flache Liste wird beim Erstellen eines Message angelegt. Die Anweisungen werden dabei in einen Satz von CompiledInstructions umgewandelt. Diese CompiledInstructions verweisen dann per Index auf die benötigten Accounts in der gemeinsamen Account-Liste.

Die gemeinsame Account-Liste ist nach den erforderlichen Berechtigungen geordnet:

• Beschreibbare Accounts, die Signierer sind.
• Schreibgeschützte Accounts, die Signierer sind.
• Beschreibbare Accounts, die keine Signierer sind.
• Schreibgeschützte Accounts, die keine Signierer sind.

Auf Grundlage dieser Reihenfolge beschreiben die Felder von MessageHeader, welche Accounts einer Transaktion welche Berechtigungen benötigen.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

Wenn mehrere Transaktionen auf dieselben schreibgeschützten Accounts zugreifen, kann die Runtime sie parallel in einem einzigen PoH-Eintrag verarbeiten. Transaktionen, die auf dieselben les- und beschreibbaren Accounts zugreifen, werden nacheinander verarbeitet.

Transaktionen werden über Gulf Stream, Solanas Protokoll zur Weiterleitung von Transaktionen, an den Client übermittelt. Anschließend durchlaufen sie im Validator zwei mehrstufige Pipeline-Prozesse: die Transaction Processing Unit (TPU) und die Transaction Validation Unit (TVU).

Diese Prozesse arbeiten mit der Runtime zusammen. Dadurch werden Transaktionen, die unterschiedliche Account-Zustände verändern, parallel verarbeitet, während Transaktionen mit Änderungen am selben Account-Zustand nacheinander verarbeitet werden.

Die TPU läuft, wenn sich der Validator im Leader-Modus befindet, also Blöcke erzeugt. Die TVU läuft im Validator-Modus, also beim Validieren von Blöcken. In beiden Fällen ist die Pipeline-Hardware ähnlich: Netzwerkeingabe, Schreibvorgänge auf Datenträger, Netzwerkausgabe usw. Die Nutzung dieser Hardware unterscheidet sich jedoch. Vereinfacht gesagt erstellt die TPU Ledger-Einträge, während die TVU Einträge validiert.

Auf hoher Ebene werden Transaktionen über einen Client eingereicht und über Gulf Stream via QUIC an die TPU eines Leaders weitergeleitet. Die Transaktion wird geprüft und dann von der Banking Stage zur Ausführung eingeplant. Zustandsaktualisierungen werden in den In-Memory-Zustand der Bank zurückgeschrieben. Validatoren stimmen über Gossip über Blöcke ab. Die Blöcke werden mit Tower BFT finalisiert, einer PBFT-Variante mit Stake-gewichteten Lockout-Mechanismen.

Gulf Stream

Bei den meisten Blockchains werden von Nutzern eingereichte Transaktionen in einem Mempool, wörtlich einem „Memory Pool“, in eine Warteschlange gestellt und warten dort auf die Verarbeitung durch das Netzwerk. Signierte Transaktionen können lange oder sogar unbegrenzt im Mempool verbleiben, wenn das Netzwerk nicht in optimalem Zustand ist oder die Ausführungsbedingungen nicht erfüllt sind. Dadurch werden solche Transaktionen unter Umständen nie in einen Block aufgenommen.

Solana macht einen globalen Mempool überflüssig. Stattdessen nutzt es einen deterministischen Leader-Zeitplan, der von einem Stake-gewichteten Algorithmus namens Stake-Weighted Quality of Service (SWQoS) beeinflusst wird. Dieser priorisiert Transaktionsnachrichten, die über Validatoren mit Stake weitergeleitet werden.

Da alle aktiven Nodes den Leader-Zeitplan im Voraus kennen, lassen sich Transaktionsnachrichten effizient verteilen. So haben kommende Leader bereits genügend Transaktionen zur Verarbeitung, bevor sie planmäßig einen Block erzeugen. Dieser Mechanismus ermöglicht es Validatoren, Transaktionen vorab zu verarbeiten, Signaturen zu prüfen und Duplikate oder fehlerhafte Transaktionen frühzeitig zu entfernen.

Ein weiterer Vorteil von Gulf Stream: Bei traditionellen Chains mit Mempool müssen Blockproduzenten dieselben Transaktionen in einem Block erneut übertragen. Jede Transaktion wird dadurch mindestens zweimal im Netzwerk verbreitet. Solana muss Gossip nicht überlasten, um ausstehende Transaktionen zu synchronisieren. Transaktionen müssen auch nicht über Gas-Auktionen um Blockspace konkurrieren, sondern werden auf Grundlage des Zeitplans verteilt.

Transaction Processing Unit (TPU)

Die TPU ist die zentrale Logik des Validators für die Blockproduktion. Transaktionen werden vom Client abgerufen und als Datenpakete über eine Komponente namens QUIC Streamer weitergeleitet. Diese weist Paketspeicher zu und liest die Daten vom QUIC-Endpunkt ein. Dieser Vorgang heißt „Fetch Stage“. Jeder Stream überträgt ein Paket innerhalb einer QUIC-Übertragungsbeschränkung, die durch den Client (IP-Adresse, Node-Pubkey) und den Server bestimmt wird.

Die Pakete werden dann an die Sigverify Stage übertragen. Dort entfernt ein spezieller Load-Shedding-Mechanismus Duplikate und überzählige Pakete. Anschließend werden Pakete mit ungültigen Signaturen herausgefiltert. Die übrigen Pakete gelangen zur Banking Stage.

Die Banking Stage ist eine zentrale Komponente der Runtime-Ausführung von Solana. Sie plant eingehende Pakete ein, filtert weitere Konflikte und prüft, ob Pakete in Batches verarbeitet, zurückgehalten oder weitergeleitet werden sollen. Erkennt sie, dass der Node der Blockproduzent ist, verarbeitet sie die zurückgehaltenen und neu empfangenen Pakete mit der Bank-Komponente. Die Bank ist eine In-Memory-Darstellung des vollständigen Ledger-Zustands in einem bestimmten Slot.

In der Banking Stage und der Scheduler-Komponente wird die Transaktion in zwei Zuständen verfolgt:

• Ein unverarbeiteter Zustand, in dem die Transaktion zur Einplanung bereitsteht
• Ein ausstehender Zustand, in dem die Transaktion gerade eingeplant oder verarbeitet wird

Nach Abschluss der Verarbeitung kann eine Transaktion erneut ausführbar sein. In diesem Fall wechselt sie zurück in den unverarbeiteten Zustand. Andernfalls wird der Zustand verworfen. Die gültigen verarbeiteten Transaktionen werden über PoH-Ticks zu einem „Entry“ zusammengefasst, in Blöcke gebündelt und als Shreds an Netzwerk-Peers übertragen. Dafür kommt Turbine, Solanas Protokoll zur Blockverteilung, zum Einsatz. Es erzeugt Erasure Codes, um verlorene Datenpakete zu „rekonstruieren“, bevor die Pakete in der Broadcast Stage an den zuständigen Netzwerk-Peer übertragen werden.

Transaction Validation Unit (TVU)

Die TVU ist die Logik in Validator-Nodes ohne Leader-Rolle, die Blöcke validiert und weiterverbreitet. In der TVU werden Datenpakete vor der Finalisierung in mehreren parallelen Phasen verarbeitet. Dazu gehören Shred Fetch, Signaturprüfung, erneute Übertragung und Replay.

In der Shred Fetch Stage und der Phase zur Prüfung der Leader-Signatur eines Shreds empfangen Nicht-Leader die Shreds anderer Nodes über UDP und prüfen Signaturen batchweise. Gültige Shreds werden in der Retransmit Stage erneut an Peer-Nodes übertragen. In der Replay Stage wird jede Transaktion der Reihe nach wiedergegeben.

In der Replay Stage ruft das System die Runtime auf, um alle Transaktionen deterministisch erneut auszuführen. So wird sichergestellt, dass sämtliche Zustandsänderungen, Programmattribute und Bank-Hashes exakt mit der Ausgabe des Leaders übereinstimmen.

Wird ein Block als gültig bewertet, signiert der Validator eine Abstimmungstransaktion und sendet diese Stimme an den Leader, damit sie in folgende Blöcke aufgenommen wird.

Runtime

Die Runtime ist Solanas nebenläufiger Transaktionsprozessor, den TPU und TVU gemeinsam verwenden. Transaktionen geben ihre Datenabhängigkeiten im Voraus an, also die Accounts, die sie lesen und/oder beschreiben möchten. Das ermöglicht eine explizite dynamische Speicherausführung. So lässt sich das Lesen von Zuständen gut von der Programmausführung isolieren und die Runtime kann nebenläufige Zugriffe koordinieren.

Die Solana-Runtime nutzt eine Ausführungs-Engine namens Sealevel. Sie sorgt dafür, dass Transaktionen mit Zugriff auf schreibgeschützte Accounts parallel ausgeführt werden. Transaktionen, die auf dieselben beschreibbaren Accounts zugreifen, werden dagegen serialisiert und nacheinander ausgeführt.

Innerhalb der Runtime werden Transaktionen atomar ausgeführt. Alle Anweisungen einer Transaktion müssen erfolgreich ausgeführt werden, damit die Transaktion in die Bank übernommen wird. Andernfalls schlägt die Transaktion fehl.

Die Runtime interagiert mit einem Programm über einen Einstiegspunkt mit klar definierter Schnittstelle. Dieser Einstiegspunkt ist eine Rust-Funktion, die alle Onchain-Programme als Ausgangspunkt der Ausführung bereitstellen. Sie dient als Schnittstelle zwischen der Solana-Runtime und den Programmen. Die Ausführungs-Engine ordnet öffentliche Schlüssel Accounts zu und leitet sie an diesen Einstiegspunkt weiter. Dabei setzt sie einige wichtige Einschränkungen durch, welche die Ausführungslogik bestimmen und von der Befehlssatzarchitektur der virtuellen Maschine definiert werden:

• Nur das besitzende Programm darf den Inhalt eines Accounts verändern.
• Die Gesamtsalden aller Accounts sind vor und nach der Ausführung einer Transaktion gleich. Dies gilt jedoch nur aggregiert. Bei Systemübertragungen und Burns bleiben Lamports nicht erhalten.
• Nach Ausführung der Transaktion müssen die Salden schreibgeschützter Accounts den Salden vor der Transaktion entsprechen.
• Alle Anweisungen der Transaktion werden atomar ausgeführt. Schlägt eine davon fehl, werden sämtliche Account-Änderungen verworfen.

Die TPU- und TVU-Pipelines folgen bei der Interaktion mit der Runtime leicht unterschiedlichen Pfaden. Die TPU-Runtime stellt sicher, dass „Entries“ über PoH-Ticks aufgezeichnet werden, bevor der Speicher festgeschrieben wird. Die TVU-Runtime stellt dagegen sicher, dass „Entries“ geprüft werden, bevor die Runtime Transaktionen verarbeitet.

Konsens

Konsens ist einer der grundlegendsten Mechanismen komplexer verteilter Rechensysteme. Im Lebenszyklus einer Solana-Transaktion findet der Konsens statt, nachdem der Block ausgeführt und von der TVU validiert wurde, aber bevor er finalisiert wird. Die Kernidee des Konsenses ist eine einheitliche Einigung: Die Teilnehmer im Netzwerk einigen sich auf dasselbe Ergebnis und können ihre Entscheidung anschließend nicht mehr ändern.

Formal muss ein fehlertoleranter Konsensmechanismus die folgenden Eigenschaften erfüllen:

• Einheitliche Einigung: Keine zwei Nodes treffen unterschiedliche Entscheidungen.
• Integrität: Kein Node entscheidet mehr als einmal.
• Gültigkeit: Entscheidet ein Node einen Wert, muss dieser Wert von einem anderen Node vorgeschlagen worden sein.
• Terminierung: Jeder Node, der nicht ausfällt, entscheidet sich letztlich für einen Wert.

Oberflächlich betrachtet soll der Konsens Nodes dazu bringen, sich auf etwas zu einigen. Bei Solana gibt es mehrere Situationen, in denen sich Nodes einigen müssen. Drei Szenarien sind besonders relevant:

Leader-Rotation

Alle Nodes müssen sich darüber einig sein, wer der Leader ist. Netzwerkfehler können die Kommunikation stören und zu einem Split-Brain-Szenario führen, bei dem mehrere Nodes fälschlicherweise gleichzeitig glauben, der Leader zu sein.

Der Leader-Zeitplan wird mit einem vordefinierten Seed und folgendem Algorithmus erzeugt: Die Höhe des PoH-Ticks, also ein monoton steigender Zähler, dient regelmäßig als Seed für einen stabilen pseudozufälligen Algorithmus.

Bei dieser Höhe wird aus der Bank eine Stichprobe aller Accounts mit Stake und Leader-Identitäten entnommen, die innerhalb einer im Cluster konfigurierten Anzahl von Ticks abgestimmt haben. Diese Stichprobe heißt aktive Menge und wird nach Stake-Gewichtung sortiert. Anschließend wählt der Zufalls-Seed Nodes nach ihrem Stake gewichtet aus und erzeugt eine Stake-gewichtete Reihenfolge. Diese wird nach einer im Cluster konfigurierten Anzahl von Ticks gültig.

Synchronisierung

Ohne verlässliche Zeitstempel kann ein Validator die Reihenfolge eingehender Blöcke nicht bestimmen. Solana verwendet einen Mechanismus namens Proof-of-History als kryptografische Uhr, um Transaktionen vor dem Konsens zu ordnen. Laut der Anza-Dokumentation zur Synchronisierung:

„Leader-Nodes versehen Blöcke mithilfe kryptografischer Nachweise mit einem Zeitstempel. Diese belegen, dass seit dem letzten Nachweis eine bestimmte Zeit verstrichen ist. Alle in den Nachweis gehashten Daten sind mit Sicherheit entstanden, bevor der Nachweis erzeugt wurde. Der Node teilt den neuen Block anschließend mit den Validator-Nodes, die diese Nachweise prüfen können. Die Blöcke können in beliebiger Reihenfolge bei den Validatoren eintreffen oder sogar Jahre später erneut wiedergegeben werden. Dank solch verlässlicher Synchronisierungsgarantien kann Solana Blöcke in kleinere Transaktions-Batches unterteilen, die als Entries bezeichnet werden. Entries werden dann in Echtzeit an Validatoren gestreamt, noch bevor ein Blockkonsens besteht.“

Wichtig ist: Proof-of-History ist zwar kein Konsensmechanismus, beeinflusst aber die Leistung von Solanas Proof-of-Stake-Konsens erheblich.

Atomares Commit

Ein weiterer notwendiger Prozess, über den sich Nodes einigen müssen, ist das atomare Commit. In einem Hochleistungssystem wie Solana kann eine Transaktion auf einigen Nodes fehlschlagen und auf anderen erfolgreich sein.

Um eine teilweise Ausführung zu verhindern, stellt Solana innerhalb der Runtime Atomarität im Sinne von ACID sicher. Zudem einigen sich alle Nodes auf das Ergebnis einer Transaktion: Entweder führen sie ein Rollback durch, wenn etwas fehlschlägt, oder sie führen ein Commit durch, wenn alles funktioniert.

Commitment misst bei Solana die Finalität eines Blocks beziehungsweise Slots. Grundlage sind die Anzahl der Validatoren, die dafür gestimmt haben, und die Tiefe ihrer Stimmen im Lockout-Mechanismus von Tower BFT. Es zeigt anhand der abgegebenen Validator-Stimmen, wie stark sich das Netzwerk auf einen bestimmten Slot geeinigt hat. Jeder Validator stimmt über Slots ab, genauer über Blockhöhen, und verpflichtet sich, nicht für widersprüchliche Forks zu stimmen. Die Lockouts in Tower BFT setzen diesen Mechanismus durch.

Solana hat drei Commitment-Status: verarbeitet, bestätigt und finalisiert. Ein Block gilt als bestätigt, wenn eine Supermehrheit der Validatoren mit Stake (≥66 %) dafür stimmt. Er gilt als finalisiert, sobald mindestens 32 bestätigte Blöcke darauf aufgebaut wurden.

Als direkte Folge der optimistischen parallelen Ausführung und des asynchronen Leader-Zeitplans folgt Solana dem Modell „zuerst ausführen, später abstimmen“: Das Protokoll wartet nicht darauf, dass sich alle Validatoren auf einen neu erzeugten Block einigen, bevor es den nächsten Block erzeugt. Dadurch können auch Forks entstehen, also mehrere konkurrierende Chains gleichzeitig. Sobald ein Slot finalisiert ist, werden alle konkurrierenden Forks aufgegeben und dieser Fork wird zur kanonischen Chain.

Alpenglow

Zum Zeitpunkt dieses Artikels verwendet Solana Tower BFT und das PoH-Ledger. So erreicht das Netzwerk auch dann einen Konsenszustand, wenn einige Teilnehmer ausfallen.

Kürzlich schlug das Forschungsteam von Anza ein neues Design für ein einfacheres und leistungsfähigeres Konsensprotokoll namens Alpenglow vor. Alpenglow soll die Legacy-Komponenten des aktuellen Konsensdesigns grundlegend überarbeiten, darunter Proof of History, Tower BFT und die Verwendung von Gossip zur Verbreitung von Stimmen.

Im Kern nutzt Alpenglow Votor und Rotor, um Solanas Konsens zu beschleunigen:

Votor ist ein zweistufiger Abstimmungsmechanismus. Er soll Blockfinalität in einer einzigen Runde erreichen, wenn 80 % des Stakes reagieren, und in zwei Runden, wenn mindestens 60 % des Stakes reagieren.

Rotor verbessert das bestehende Turbine-Protokoll. Eine einzelne Schicht von Relay-Nodes übernimmt dabei die Verteilung von Shreds. Rotor nutzt außerdem die Bandbreite der teilnehmenden Nodes proportional zu ihrem Stake, um die Anzahl der Hops zu senken und Solanas Durchsatz zu optimieren. 

Sui

Anders als Solana mit seinem Account-zentrierten Modell verwendet die Sui-Blockchain ein objektorientiertes Datenmodell. Zustandsdaten werden dabei als Objekte mit eindeutigen Bezeichnern, Eigenschaften und Methoden dargestellt.

Bei Sui ist auch ein Smart Contract ein Objekt. Es heißt Sui Move Package, besitzt einen eindeutigen Bezeichner und verändert Objekte. Diese Sui Move Packages bestehen aus mehreren Sui-Move-Bytecode-Modulen. Jedes Modul ist durch seinen Namen und die Kombination aus der Onchain-ID eines Packages und dem Modulnamen eindeutig bestimmt.

Die Feinheiten des Objektdesigns und der Metadaten liegen außerhalb des Rahmens dieses Artikels. Wichtig ist jedoch, dass jedes Objekt einen Besitzer hat, der bestimmt, wie dieses Objekt in Transaktionen verwendet werden kann.

Objekte können folgende Besitzmodelle haben:

• Adressgebundene Objekte: Ein adressgebundenes Objekt gehört einer bestimmten 32-Byte-Adresse, entweder einer Account-Adresse oder einer Objekt-ID. Nur sein Besitzer kann darauf zugreifen.
• Unveränderliche Objekte: Ein unveränderliches Objekt kann nicht verändert, übertragen oder gelöscht werden. Diese Objekte haben keinen Besitzer und sind global für jeden zugänglich.
• Gemeinsame Objekte: Ein gemeinsames Objekt wird geteilt und ist ebenfalls für jeden zugänglich.
• Eingebettete Objekte: Dabei wird ein Objekt in ein anderes Objekt eingebettet. Eingebettete Objekte sind nicht unabhängig und lassen sich nur über das umgebende Objekt aufrufen.

Eine Sui-Transaktion

Auf Sui bestehen Transaktionen aus einer Gruppe von Befehlen. Diese werden auf Eingaben ausgeführt und bestimmen das Ergebnis der Transaktion. Solche Befehlsgruppen heißen Programmable Transaction Blocks (PTB) und definieren alle Nutzertransaktionen auf Sui. Mit PTBs kann ein Nutzer in einer einzigen Transaktion mehrere Move-Funktionen aufrufen sowie seine Objekte und „Coins“ verwalten, ohne ein neues Move Package veröffentlichen zu müssen.

Die Struktur eines PTB ist wie folgt definiert:

{
    inputs: [Input],
    commands: [Command],
}

inputs ist ein Vektor aus Argumenten, die entweder Objekte oder reine Werte sind. Diese Objekte können dem Absender gehören, gemeinsam genutzt oder unveränderlich sein. Das Feld commands ist ein Vektor aus übergeordneten Transaktionsanweisungen.

Bei der Ausführung von PTBs wird der Eingabevektor mit den Eingabeobjekten oder den Bytes reiner Werte befüllt. Anschließend werden die Transaktionsbefehle der Reihe nach ausgeführt. Die Ergebnisse werden in einem Ergebnisvektor gespeichert. Dieser ist ein Array aus Werten, wobei jeder Wert einem beliebigen und für den jeweiligen Befehl spezifischen Move-Typ entsprechen kann. Anders als bei Eingaben sind die Werte nicht auf Objekte oder reine Werte beschränkt. Abschließend werden die Auswirkungen der Transaktion atomar angewendet. 

Wir behandeln die Interna der Sui-PTBs nicht, da sie ein eigenes komplexes Thema darstellen. Wichtig ist jedoch: Zu Beginn der Ausführung übernimmt die PTB-Runtime die bereits geladenen Eingabeobjekte und lädt sie in das Eingabe-Array. Das Netzwerk hat die Objekte bereits anhand von Regeln wie Existenz und gültigem Besitz geprüft. Die Bytes reiner Werte werden ebenfalls in das Array geladen, aber erst bei ihrer Verwendung validiert.

In dieser Phase sind die Auswirkungen auf den Gas Coin besonders wichtig. Das maximale Gas-Budget wird vom Gas Coin abgezogen. Dieses maximale Gas-Budget wird üblicherweise beim Einreichen einer Transaktion vom Absender festgelegt und gibt an, wie viel Gas die Transaktion höchstens verbrauchen darf. Nicht verbrauchtes Gas wird am Ende der Ausführung an den Gas Coin zurückgegeben, selbst wenn der Coin inzwischen den Besitzer gewechselt hat. Danach wird jeder Transaktionsbefehl der Reihe nach ausgeführt.

Nach der Einreichung zertifiziert der Full Node alle bereitgestellten Metadaten, indem er die Transaktion an einen Validator-Node sendet. Dies ist die Zertifizierungsphase. Der Validator-Node führt alle erforderlichen Gültigkeitsprüfungen der Transaktion durch und signiert sie, wenn sie diese Prüfungen besteht. Damit ein Validator-Node die Transaktion als gültig betrachtet, muss sie:

• Eine gültige Nutzersignatur besitzen.
• Sicherstellen, dass der Initiator der Transaktion auf alle verwendeten Eingabeobjekte in seinem Besitz zugreifen kann.
• Sicherstellen, dass die von der Transaktion verwendeten gemeinsamen Eingabeobjekte vorhanden sind.
• Mindestens so viel Gas enthalten, wie im Gas-Budget der Transaktion angegeben ist.

Wenn alle Prüfungen erfolgreich sind, versucht der Validator, alle im Besitz befindlichen inputs-Objekte für den angegebenen „Transaktions-Digest“ zu sperren. So kann jede Eingabe im Besitz eines Nutzers jeweils nur einmal verwendet werden.

Wenn die Sperrung erfolgreich ist, signiert der Validator die Transaktion und gibt die Signatur an den Full Node zurück.

Ein Sui Full Node ist im Wesentlichen eine schreibgeschützte Ansicht des Netzwerkzustands. Anders als Validator-Nodes können Full Nodes keine Transaktionen signieren. Sie können jedoch die Integrität der Chain prüfen, indem sie Transaktionen erneut ausführen, die zuvor von einem Quorum der Validatoren übernommen wurden. Der Full Node sammelt nicht nur eine einzelne Validator-Signatur, sondern parallel so viele wie möglich. Für ein Transaktionszertifikat ist jedoch nur eine Supermehrheit erforderlich, also ⅔+ des Stakes.

Ausführung und Checkpoints

Sobald Transaktionen ein Zertifikat erhalten haben, werden sie zur Ausführung an ein Validator-Komitee gesendet, also an eine Gruppe unabhängiger Validatoren, die für jede Epoche feststeht. Der Validator muss die Transaktionen nicht erneut prüfen. Er muss lediglich die Signaturen des Zertifikats verifizieren. Ist die Signatur des Zertifikats gültig, kann der Validator sicher sein, dass auch die Transaktion gültig ist.

Bei der Ausführung werden Transaktionen in zwei Kategorien unterteilt: Transaktionen mit Objekten im Besitz eines Nutzers und Transaktionen mit gemeinsamen Objekten:

Transaktionen mit Objekten im Besitz eines Nutzers

Transaktionen mit Objekten im Besitz eines Nutzers greifen auf keine gemeinsamen Eingabeobjekte zu und werden sofort ausgeführt. Sie werden auch als Fast-Path-Transaktionen bezeichnet. Das heißt, sie werden nach der Validierung ausgeführt und in die kanonische Chain übernommen. Diese Transaktionen „durchlaufen“ keinen Konsens. Letztlich gelangen Fast-Path-Transaktionen zwar in den Konsens, aber nur, um eine kanonische Reihenfolge für die Aufnahme in Checkpoints zu erzeugen. Technisch ist das möglich, weil kein Risiko widersprüchlicher Schreibvorgänge besteht: Nur der Besitzer kann das Objekt verändern. 

Transaktionen mit gemeinsamen Objekten

Transaktionen mit gemeinsamen Objekten greifen auf gemeinsam genutzte Objekte zu. Daher müssen sie über den Konsens in Bezug auf andere Transaktionen geordnet werden, die dieselben gemeinsamen Objekte verwenden und ausführen. Sie werden auch als Slow-Path-Transaktionen bezeichnet. Sie müssen den vollständigen Konsensprozess durchlaufen, um Konsistenz zu gewährleisten, da mehrere Nutzer auf die beteiligten Objekte zugreifen und sie verändern können. 

Früher vermied Suis Mempool Narwhal typische Überlastung, indem er die Verteilung und Ordnung von Transaktionen voneinander trennte. Zertifizierte, signierte Transaktionen wurden in einem gerichteten azyklischen Graphen (DAG) gehalten, ohne dass Narwhal sie selbst ordnete. Bullshark legte anschließend die Konsensreihenfolge fest.

Um Leistung und Resilienz weiter zu verbessern, wurde das Protokoll HammerHead als Erweiterung von Bullshark eingeführt. Es implementiert eine dynamische, bewertungsbasierte Leader-Auswahl. Dadurch sank die Latenz erheblich und der Durchsatz stieg, insbesondere bei fehlerhaften oder ausgefallenen Leadern.

Aufbauend auf diesen Fortschritten ersetzt Mysticeti nun sowohl Narwhal als auch Bullshark und vereint die Verteilung und Ordnung von Transaktionen in einem einzigen Protokoll. Mysticeti sequenziert Transaktionen in einer vollständigen Reihenfolge. Das strafft den Prozess weiter und erzielt eine noch geringere Latenz sowie einen höheren Durchsatz. Dank Suis objektzentriertem Besitzmodell bleiben die meisten Transaktionen zudem unabhängig und müssen nicht um einen globalen Ordnungsplatz konkurrieren.

Nach der Ausführung der Transaktionen signiert der Validator die Transaktionsauswirkungen und gibt sie an den Full Node zurück. Transaktionsauswirkungen sind im Wesentlichen eine Liste aller durch die Transaktion vorgenommenen Aktionen. Dazu gehören alle veränderten Objekte, das verbrauchte Gas und der Ausführungsstatus der Transaktion.

Die Signaturen der Auswirkungen bilden eine Sammlung von Wirkungszertifikaten, die der Full Node von einer Supermehrheit der Validatoren erhält. Sie garantieren, dass eine Transaktion finalisiert wurde.

Wenn eine Transaktion in einen Checkpoint aufgenommen wird und damit die letzte Phase ihres Lebenszyklus erreicht, sind die daraus resultierenden Zustandsänderungen bereits finalisiert und im Netzwerk angewendet.

Transaktionen, die ausschließlich Eingabeobjekte im Besitz eines Nutzers betreffen, werden von Validatoren ausgeführt und finalisiert, bevor sie zur Ordnung an die Konsensschicht übermittelt werden.

Transaktionen mit gemeinsamen Eingabeobjekten werden dagegen vor der Ausführung zur Ordnung an den Konsens übermittelt und nicht erneut zur Aufnahme in einen Checkpoint eingereicht.

Der Validator sammelt kausal geordnete und vollständige Transaktionsblöcke aus der Konsensschicht und erstellt daraus einen Checkpoint. Dieser enthält sowohl die Liste der Transaktions-Digests als auch die entsprechenden Digests der Auswirkungen jeder Transaktion. Checkpoints dienen daher als unveränderlicher Datensatz aller finalisierten Zustandsübergänge im Netzwerk.

Finalität

Eine Transaktion auf Sui erreicht Finalität, sobald eine Supermehrheit (2𝑓 + 1) der Validatoren ein Transaktionszertifikat akzeptiert und gegenzeichnet. Das gilt bereits, bevor das Zertifikat vom Konsens sequenziert oder ausgeführt wird. Ab diesem Zeitpunkt kann keine widersprüchliche Transaktion mehr auftreten und die Transaktion lässt sich nicht widerrufen. Bei Transaktionen, die nur Objekte im Besitz eines Nutzers betreffen, ist das Ausführungsergebnis unmittelbar bei Erreichen der Finalität bekannt. Bei Transaktionen mit gemeinsamen Objekten steht das Ergebnis erst fest, nachdem das Zertifikat vom Konsens sequenziert wurde. Die Transaktionsfinalität wird innerhalb von zwei Netzwerk-Roundtrips erreicht.

Die Abwicklung erfolgt, wenn eine Supermehrheit der Validatoren die Transaktion ausführt und ein Wirkungszertifikat gebildet wird. Bei Transaktionen mit Objekten im Besitz eines Nutzers erfolgt diese Ausführung sofort, ohne auf den Konsens zu warten. Bei Transaktionen mit gemeinsamen Objekten erfolgen Ausführung und Abwicklung unmittelbar nachdem der Konsens das Zertifikat geordnet hat. In beiden Fällen verzögert die Erstellung des Checkpoints die Abwicklung nicht. Dadurch ist die Latenz niedriger als beim Checkpoint-Prozess.

Ein Transaktionszertifikat ist ein starkes Indiz für Finalität. Eine absolute Garantie bietet jedoch nur ein Wirkungszertifikat oder die Aufnahme in einen zertifizierten Checkpoint. Dafür muss eine Supermehrheit der Validatoren die Transaktion ausführen und ihre Auswirkungen übernehmen.

Auf hoher Ebene nutzt der Lebenszyklus einer Sui-Transaktion ein objektzentriertes Modell, um Parallelität und Effizienz zu maximieren. Wenn eine Transaktion zur Zertifizierung eingereicht wird, versuchen Validatoren, die spezifischen Versionen der referenzierten Eingabeobjekte zu sperren.

Bei Objekten im Besitz eines Nutzers werden diese Sperren sofort während der Zertifizierung gesetzt. Das gewährleistet exklusiven Zugriff und verhindert Double-Spending. Bei gemeinsamen Objekten werden Sperren erst eingerichtet, nachdem Suis Konsensprotokoll die Transaktion geordnet hat.

Sobald alle erforderlichen Sperren vorliegen, wird die Transaktion zur Ausführung eingeplant. Dadurch können Transaktionen, die mit disjunkten Objektmengen arbeiten, unabhängig und parallel ausgeführt werden. Das reduziert Konkurrenz und Überlastung in nicht zusammenhängenden Bereichen des Zustands erheblich.

Nach erfolgreicher Ausführung signieren Validatoren die Auswirkungen der Transaktion. Sobald eine Supermehrheit der Signaturen vorliegt, wird ein Wirkungszertifikat gebildet. Dieses Zertifikat garantiert die Abwicklungsfinalität: Die Transaktion ist nun unumkehrbar und ihre Auswirkungen sind dauerhaft.

Checkpoints sind kein Teil des kritischen Pfads für die Ausführung oder Finalität von Transaktionen. Sie werden stattdessen nach der Ausführung erstellt, um eine kanonische Reihenfolge der Transaktionen bereitzustellen und die Zustandssynchronisierung für Nodes zu erleichtern, die nicht direkt an der Ausführung beteiligt waren.

Suis Objektmodell ermöglicht eine präzise Verfolgung von Abhängigkeiten auf Objektebene und macht eine globale Zustandssynchronisierung überflüssig. Diese Architektur unterstützt eine skalierbare, verteilte Ausführung auf handelsüblicher Hardware, statt für höheren Durchsatz auf Fortschritte bei der Hardwareleistung angewiesen zu sein.

Erkenntnisse zu Ausführung, Skalierbarkeit und Designkompromissen

Wie bereits erwähnt, bringt der Lebenszyklus einer Transaktion die Designphilosophie einer Blockchain besonders klar zum Ausdruck. Die Unterschiede zwischen den Transaktionslebenszyklen von Solana und Sui zeigen tiefgreifende Philosophien der Ausführungsmodelle in drei entscheidenden Bereichen: Ausführungseffizienz, Skalierbarkeitsgrenzen und Designkompromisse.

Ausführung

Als Account-zentrierte Chain erkennt Solana Account-Konflikte dynamisch, indem Accounts während der Banking Stage gesperrt werden. So werden Transaktionen, die nicht denselben Account verändern, parallel verarbeitet. Transaktionen mit Konflikten werden dagegen nacheinander verarbeitet.

Ein solcher Mechanismus zur Erkennung von Accounts kann in stark ausgelasteten DeFi-Szenarien zusätzliche Runtime-Kosten verursachen. Das gilt besonders, wenn Programme Logik aus anderen Programmen ausführen müssen, ein Mechanismus namens Cross-Program Invocation. Solanas Ausführungs-Engine erreicht durch ihre dynamische Konflikterkennung dennoch eine enorme Parallelität. So kann die Chain Transaktionen nahezu sofort und zu äußerst niedrigen Gebühren ausführen.

Sui muss sich dagegen weniger mit widersprüchlichen Transaktionen befassen. Aufgrund des objektzentrierten Besitzmodells wird die Parallelität bereits zur Compile-Zeit abgeleitet. Das Modell aus gemeinsamen Objekten und Objekten im Besitz eines Nutzers ermöglicht es, Konflikte statisch abzuleiten und für Transaktionen mit eigenen Objekten nahezu keine Runtime-Kosten zu verursachen.

Skalierbarkeitsgrenzen

Bei der Skalierung erreicht Sui horizontale Skalierbarkeit und kann mit Objektpartitionen linear wachsen. Dafür verarbeitet es Transaktionen mit Objekten im Besitz eines Nutzers ohne globalen Konsens. Das ermöglicht nahezu sofortige Finalität unter einer Sekunde sowie einen Durchsatz, der nur durch die verfügbare Hardware begrenzt ist. Transaktionen mit gemeinsamen Objekten erfordern einen Konsens. Seit dem Mysticeti-Upgrade erreichen aber auch sie Finalität unter einer Sekunde und hohen Durchsatz. Suis Architektur kann sowohl die Blockverteilung als auch die Ausführung durch zusätzliche Ressourcen elastisch skalieren. Dadurch verarbeitet das System steigende Lasten effizient. Der Konsenspfad ist jedoch nicht so unbegrenzt wie der Fast Path für Objekte im Besitz eines Nutzers.

Solana scheint aufgrund seines Single-Leader-Ansatzes und der durch Account-Konkurrenz begrenzten Auffächerung der Ausführung an eine horizontale Skalierungsgrenze zu stoßen. Gründe dafür sind das globale, nicht geshardete Zustandsmodell und die Leader-zentrierte Aufnahme von Transaktionen pro Slot. Innerhalb dieser Grenze optimiert Solana jedoch aggressiv durch klar definiertes Pipelining, ergänzt durch PoH. Transaktionen lassen sich präzise ordnen, in weniger als 400 ms verarbeiten und in weniger als einer Sekunde optimistisch bestätigen. Bei der vertikalen Skalierung wächst Solana massiv mit der Validator-Hardware, insbesondere mit CPU-Kernen und RAM. Das passt perfekt zum zugrunde liegenden Design.

Solana entscheidet sich bewusst für vertikale statt horizontale Skalierung. Die daraus entstehende Obergrenze beruht auf Designkompromissen, nicht auf einem Architekturfehler. Einige horizontale Ansätze befinden sich derzeit in Entwicklung, etwa lokale Gebührenmärkte, virtuelle Subnetze und die Zustandsminimierung über CMTs.

Designkompromisse

Solana garantiert Determinismus durch strenge Runtime-Beschränkungen, Account-Isolierung und eine deterministische Leader-Planung. Seine dynamische Auflösung von Account-Konkurrenz und das klar definierte Pipelining fördern tiefe Interaktionen zwischen Programmen und ermöglichen starke Komponierbarkeit.

Sui garantiert Determinismus durch integrierte Ausführungspfade, die anhand einer Analyse der Objektbesitzverhältnisse bestimmt werden. Gleichzeitig ermöglicht Suis objektzentriertes Modell Komponierbarkeit über gemeinsame Objekte und Programmable Transaction Blocks (PTBs). Dadurch sind komplexe Interaktionen und atomare Vorgänge über mehrere Contracts und Nutzer hinweg möglich. Das funktioniert, weil der Besitzer eines Objekts selbst ein anderes Objekt sein kann. So werden Interoperabilität auf Objektebene und die Anordnung von Objekten in Besitzbäumen möglich. Solche Strukturen sind besonders nützlich, wenn Objekte häufig gemeinsam verwendet werden oder Runtime-Lookups nötig sind, um während der Ausführung das zu bearbeitende Objekt zu bestimmen.

Zusammenfassung

Der Mechanismus, mit dem Transaktionen von der Einreichung bis zur Finalität verarbeitet werden, bildet die Grundlage für die außergewöhnlich hohe Leistung von Solana und Sui. Die Untersuchung des Transaktionslebenszyklus gibt Einblick in die sorgfältig entwickelten Pipelines, die bei beiden Chains für niedrige Latenz und hohen Durchsatz sorgen.

Solana basiert auf einem Account-zentrierten Modell. Transaktionen durchlaufen mehrere parallele Prozesse und Pipelines, um ihre Gültigkeit sicherzustellen. Sie werden an den Leader übermittelt, der die TPU-Pipeline ausführt, damit Transaktionen geprüft und entsprechend eingeplant werden: parallel, wenn keine Konflikte bestehen, andernfalls nacheinander. Wenn ein Validator keine Blöcke produziert, führt er die TVU-Pipeline aus, um Transaktionen zu replizieren und zu validieren. Sowohl TPU als auch TVU nutzen die Runtime. Dadurch verarbeitet Solana Tausende Transaktionen in sehr kurzer Zeit. Die Runtime kann nicht überlappende Accounts im Voraus und deterministisch erkennen und konfliktfreie Transaktionen parallel ausführen. Das macht Solana ideal für reale Anwendungsfälle wie Hochfrequenzhandel, stark komponierbares DeFi, infrastrukturintensive dApps und verbraucherorientierte dApps mit niedriger Latenz.

Sui verwendet dagegen ein objektzentriertes Modell, in dem jedes Objekt über einen eindeutigen Bezeichner verfolgt wird. Durch Ableitung der Besitzverhältnisse kann das System statisch bestimmen, ob eine Transaktion parallel ausgeführt werden kann, wenn sie disjunkte Objektmengen betrifft. Sein Modell mit zwei Ausführungspfaden trennt Transaktionen mit Objekten im Besitz eines Nutzers von Transaktionen mit gemeinsamen Objekten und nutzt signierte Checkpoints, um Full Nodes zu synchronisieren. So kann Sui einfache Transaktionen verarbeiten, ohne die Konsensschicht zu belasten, und erreicht dennoch verlässliche, schnelle Finalität sowie effiziente Synchronisierung für neue Nodes. Dadurch kann das System bei steigender Last horizontal skalieren. Das ist besonders nützlich für Anwendungen mit umfangreichen Objektinteraktionen, etwa DeFi, Gaming, Asset-zentrierte Börsen und programmierbare Assets.

Quellen

• Offizielle Solana-Dokumentation
• Offizielle Anza-Dokumentation
• Offizielle Sui-Dokumentation
• Gulf Stream: Solanas Protokoll zur Transaktionsweiterleitung ohne Mempool
• Sealevel — Parallele Verarbeitung Tausender Smart Contracts
• Cross-Program Invocations und PDAs – die Kombination zweier leistungsstarker Mechanismen auf Anchor
• Narwhal und Tusk: Ein DAG-basierter Mempool und effizienter BFT-Konsens
• Sui-Ausführung mit Pilotfish horizontal skalieren
• SUI vs. Solana - TrustWallet
• Tower BFT: Solanas leistungsstarke Implementierung von PBFT
• David J DeWitt und Jim N Gray: „Parallele Datenbanksysteme: Die Zukunft leistungsstarker Datenbanksysteme,“ Communications of the ACM, Band 35, Nummer 6, Seiten 85–98, Juni 1992. doi:10.1145/129888.129894
• Jim N Gray und Leslie Lamport: „Konsens beim Transaktions-Commit,“ ACM Transactions on Database Systems (TODS), Band 31, Nummer 1, Seiten 133–160, März 2006. doi:10.1145/1132863.1132867
• Leslie Lamport: „Zeit, Uhren und die Ordnung von Ereignissen in einem verteilten System“, Communications of the ACM, Band 21, Nummer 7, Seiten 558–565, Juli 1978.
• Michael J Fischer, Nancy Lynch und Michael S Paterson: „Unmöglichkeit eines verteilten Konsenses mit einem fehlerhaften Prozess“, Journal of the ACM, Band 32, Nummer 2, Seiten 374–382, April 1985. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: „MYSTICETI: Die Latenzgrenzen mit nicht zertifizierten DAGs erreichen“, [cs.DC], Juli 2024.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: „HammerHead: Leader-Reputation für dynamische Planung“, [cs.CR], September 2023.