Solana im Überblick

Einführung

Solana ist eine leistungsstarke Blockchain mit geringer Latenz, die für ihre Geschwindigkeit, Effizienz und den Fokus auf die User Experience bekannt ist. Ihre einzigartige integrierte Architektur ermöglicht Tausende Transaktionen pro Sekunde in einem global dezentralisierten Netzwerk. Mit einer Blockzeit von 400 Millisekunden und Transaktionsgebühren von Bruchteilen eines Cents bietet sie sowohl Geschwindigkeit als auch Kosteneffizienz. Dieser Bericht beleuchtet die Details des Designs und Betriebs von Solana sowie die zentralen Mechanismen und die Netzwerktopologie, die diese Leistungsfähigkeit ermöglichen.

Solana verfolgt bei der Blockchain-Entwicklung einen integrierten Ansatz und nutzt die jahrzehntelange Erfahrung des Gründungsteams mit verteilten Systemen. Eines der Kernprinzipien von Solana lautet, dass Software die Hardware niemals ausbremsen darf. Die Software nutzt daher jede Hardware, auf der sie läuft, vollständig aus und skaliert mit ihr. Alle Anwendungen in diesem einheitlichen Ökosystem übernehmen die Komponierbarkeit der gemeinsamen Blockchain. So können sie nahtlos miteinander interagieren und aufeinander aufbauen. Diese Architektur sorgt außerdem für eine einfache und intuitive User Experience, ohne Bridges, separate Chain-IDs oder fragmentierte Liquidität.

Solana entwickelt sich schnell weiter. Zu den jüngsten Entwicklungen gehören SVM-Rollups und ZK Compression als wichtige Skalierungslösungen. Diese Projekte könnten unsere künftige Wahrnehmung von Solana prägen. Derzeit befinden sie sich jedoch noch in einer sehr frühen Entwicklungs- oder Einführungsphase und werden in diesem Bericht nicht behandelt.

Lebenszyklus einer Transaktion

Der Lebenszyklus einer typischen Transaktion dient uns in diesem Bericht als zentrale Perspektive auf Solana. Für ein grundlegendes Modell von Solana-Transaktionen lässt sich der Prozess wie folgt beschreiben: 

• Nutzer initiieren Transaktionen, die alle an den aktuellen führenden Blockproduzenten, den sogenannten Leader, gesendet werden. Der Leader fasst diese Transaktionen zu einem Block zusammen, führt sie aus und aktualisiert dadurch seinen lokalen Zustand.
• Dieser Transaktionsblock wird anschließend im gesamten Netzwerk verteilt, damit andere Validatoren ihn ausführen und bestätigen können.‍

Die folgenden Abschnitte dieses Berichts erweitern dieses Modell und beleuchten den Prozess deutlich detaillierter. Wir beginnen mit den wichtigsten Teilnehmern: den Nutzern.

Sechs Phasen

Wir beziehen uns im gesamten Bericht auf die oben gezeigte Darstellung der sechs Phasen. Sie bietet einen einheitlichen Rahmen, um die Beziehungen zwischen den Kernelementen von Solana zu verstehen.

Die ersten Kapitel orientieren sich an diesen sechs Phasen. Die letzten Kapitel – Gossip, Archiv, Ökonomie und Jito – führen die übrigen Themen zusammen. Einige Kapitel erstrecken sich über mehrere Phasen, und manche Phasen kommen in mehreren Kapiteln vor.

Diese Überschneidung ist unvermeidbar, da das Modell mit sechs Phasen Grenzen hat. Tatsächlich ist Solana ein komplexes verteiltes System mit vielen voneinander abhängigen Elementen.

Nutzer

Die Reise eines Nutzers beginnt normalerweise damit, eine Wallet-Anwendung einzurichten und aufzuladen. Für Solana gibt es mehrere beliebte Wallet-Anwendungen – entweder als native mobile Apps oder als Browsererweiterungen.

Wallets erzeugen kryptografisch Schlüsselpaare aus öffentlichen und privaten Schlüsseln. Der öffentliche Schlüssel dient als eindeutige Kennung für das Konto und ist allen Teilnehmern im Netzwerk bekannt. Ein Nutzerkonto auf Solana lässt sich als Datenstruktur betrachten, die Informationen und Zustände zu den Interaktionen mit der Solana-Blockchain enthält. Ein öffentlicher Schlüssel ähnelt somit einem Dateinamen: So wie ein Dateiname eine Datei innerhalb eines Dateisystems eindeutig identifiziert, identifiziert ein öffentlicher Solana-Schlüssel ein Konto auf der Solana-Blockchain. Öffentliche Schlüssel werden auf Solana als Base58-codierte Strings mit 32 Byte dargestellt.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Ein privater Schlüssel – auch geheimer Schlüssel genannt – lässt sich als Passwort oder Zugangsschlüssel betrachten, der den Zugriff auf das Konto und dessen Änderung erlaubt. Blockchains regeln die Autorisierung durch Signaturen mit privaten Schlüsseln. Wer den privaten Schlüssel kennt, hat uneingeschränkte Kontrolle über das Konto. Private Solana-Schlüssel sind ebenfalls 32 Byte lang. Schlüsselpaare sind 64-Byte-Kombinationen aus öffentlichen Schlüsseln in der ersten und privaten Schlüsseln in der zweiten Hälfte.

Beispiele:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Private Schlüssel können auch aus mnemonischen Seed-Phrasen abgeleitet werden, die üblicherweise 12 oder 24 Wörter lang sind. Wallets verwenden dieses Format häufig, um Backups und Wiederherstellungen zu vereinfachen. Aus einer einzelnen Seed-Phrase lassen sich mehrere Schlüssel deterministisch ableiten.

Solana nutzt Ed25519, einen weitverbreiteten digitalen Signaturalgorithmus auf Basis elliptischer Kurven, für seine Public-Key-Kryptografie. Ed25519 zeichnet sich durch kleine Schlüssel und Signaturen, schnelle Berechnungen und Widerstandsfähigkeit gegen viele gängige Angriffe aus. Jede Solana-Wallet-Adresse stellt einen Punkt auf der elliptischen Ed25519-Kurve dar.

Der Nutzer signiert Transaktionen mit seinem privaten Schlüssel. Diese Signatur wird in die Transaktionsdaten aufgenommen und kann von anderen Teilnehmern mit dem öffentlichen Schlüssel des Absenders verifiziert werden. Dieser Prozess stellt sicher, dass die Transaktion nicht manipuliert wurde und vom Eigentümer des zugehörigen privaten Schlüssels autorisiert ist. Die Signatur dient außerdem als eindeutige Kennung der Transaktion.

Solana-Transaktionen‍

Nur durch das Senden einer Transaktion lässt sich der Zustand auf Solana ändern. Jede Schreiboperation erfolgt durch eine Transaktion. Transaktionen sind atomar: Entweder werden alle vorgesehenen Aktionen ausgeführt oder die Transaktion schlägt fehl. Eine Transaktion, formeller als „Transaktionsnachricht“ bezeichnet, besteht aus vier Abschnitten: einem Header, einer Liste mit Kontoadressen, einem aktuellen Blockhash und Anweisungen.

Header

Der Header enthält Verweise auf die Liste der Kontoadressen und gibt an, welche Konten die Transaktion signieren müssen.

Kontoadressen

Diese Liste enthält alle Konten, die während der Transaktion gelesen oder beschrieben werden. Eine solche Liste für jede Transaktion zu erstellen, ist eine Besonderheit von Solana und kann Entwickler vor Herausforderungen stellen. Wenn jedoch im Voraus bekannt ist, mit welchen Zustandselementen eine Transaktion interagiert, werden Optimierungen möglich, die viele andere Blockchains nicht bieten.

Aktueller Blockhash

Dieser verhindert doppelte und veraltete Transaktionen. Ein aktueller Blockhash läuft nach 150 Blöcken ab, also nach etwa einer Minute. Standardmäßig versuchen RPCs alle zwei Sekunden, Transaktionen weiterzuleiten, bis die Transaktion finalisiert ist oder der aktuelle Blockhash abläuft. Danach wird die Transaktion verworfen.

Anweisungen

Sie bilden den Kern der Transaktion. Jede Anweisung steht für eine bestimmte Operation, etwa Übertragen, Minting, Burning, Erstellen oder Schließen eines Kontos. Jede Anweisung legt das auszuführende Programm, die erforderlichen Konten und die zur Ausführung benötigten Daten fest.

Die Anzahl der Anweisungen in einer Transaktion wird zunächst durch ihre Größe begrenzt, die maximal 1.232 Byte betragen darf. Auch die Anzahl der referenzierten Konten ist begrenzt. Schließlich gibt es Grenzen für die Komplexität einer Transaktion, gemessen in Compute Units (CUs). CUs quantifizieren die Rechenressourcen, die für die Verarbeitung von Transaktionen aufgewendet werden.

Die Kosten für die Ausführung einer Transaktion in SOL bestehen aus zwei Teilen: einer Basisgebühr und einer Priorisierungsgebühr. Die Basisgebühr beträgt unabhängig von der Komplexität der Transaktion feste 5.000 Lamports pro Signatur. Üblicherweise gibt es eine Signatur pro Transaktion.

Priorisierungsgebühren sind technisch optional, werden aber bei hoher Nachfrage nach Blockspace notwendig. Diese Gebühren werden in Mikro-Lamports, also Millionsteln eines Lamports, pro Compute Unit berechnet. Sie dienen als Preissignal und schaffen für Validator-Nodes einen stärkeren wirtschaftlichen Anreiz, Transaktionen in ihre Blöcke aufzunehmen. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

Derzeit werden 50 % aller transaktionsbezogenen Gebühren verbrannt. Dadurch wird dieses SOL dauerhaft aus dem Umlauf genommen. Die übrigen 50 % gehen an den Blockproduzenten. Eine bevorstehende Änderung (SIMD 96) wird es ermöglichen, dass 100 % der Priorisierungsgebühren an den Blockproduzenten gehen. Die Basisgebühren bleiben unverändert.

Transaktionen senden

Ein Nutzer verbindet seine Wallet mit der Anwendung, sodass die App den öffentlichen Schlüssel des Nutzers lesen kann. Der private Schlüssel bleibt verschlüsselt und sicher in einer von der Anwendung getrennten Sandbox-Umgebung.

Die Anwendung erstellt anhand der Nutzerinteraktionen die Parameter der Transaktionsnachricht. Möchte ein Nutzer beispielsweise zwei Token tauschen, gibt er die Anzahl der zu kaufenden Token, die entsprechenden zu verkaufenden Token und eine akzeptable Slippage für die Transaktion an.

Sobald die Transaktionsnachricht bereit ist, wird sie an die Wallet gesendet und mit dem privaten Schlüssel des Nutzers signiert. Nun erscheint ein Pop-up, über das der Nutzer die Transaktion bestätigt. Dieses Pop-up kann eine Simulation der Transaktionsergebnisse enthalten. Nach der Signierung werden Transaktionsnachricht und Signatur an die App zurückgegeben. Diese kann die Transaktion anschließend an einen RPC-Anbieter der Wahl weiterleiten: einen eigenen oder den Anbieter der Wallet.

RPC-Anbieter (Remote Procedure Call) vermitteln zwischen Anwendungen und den Validatoren, die Blöcke erstellen. Dieser essenzielle Dienst ermöglicht es Anwendungen, signierte Transaktionen zu übermitteln oder zu simulieren und On-Chain-Daten effizient abzurufen. Anwendungen interagieren über einen JSON-RPC- oder WebSocket-Endpunkt mit dem Netzwerk (Dokumentation).

Gulf Stream

RPCs (Remote Procedure Calls) bezeichnen RPC-Nodes. Diese Nodes dienen als Gateways, über die du mit dem Netzwerk interagierst und Daten daraus liest. Sie führen dieselbe Software wie vollständige Validatoren aus, verwenden jedoch andere Einstellungen. Dadurch können sie Transaktionen präzise simulieren und eine aktuelle Ansicht des Zustands verwalten. Zum Zeitpunkt der Erstellung dieses Berichts gibt es im Solana-Netzwerk mehr als 4.000 RPC-Nodes.

Anders als vollständige Validator-Nodes halten RPC-Nodes keinen Stake im Netzwerk. Ohne Stake können sie weder abstimmen noch Blöcke erstellen. Dieses Modell unterscheidet sich von den meisten anderen Blockchains, bei denen Validator- und RPC-Nodes normalerweise identisch sind. Da RPC-Nodes keine Staking-Rewards erhalten, unterscheidet sich ihr Betriebsmodell von dem der Validatoren. Viele werden als kostenpflichtiger Dienst für Entwickler angeboten, die Solana-Anwendungen betreiben.

Solana hebt sich ab, weil es von Anfang an für den Betrieb ohne Mempool entwickelt wurde. Traditionelle Blockchains nutzen Gossip-Protokolle, um Transaktionen zufällig und breit im Netzwerk zu verteilen. Solana leitet dagegen alle Transaktionen für jeden Slot an einen vorab festgelegten führenden Validator weiter, den sogenannten Leader.

Sobald ein RPC eine Transaktionsnachricht zur Aufnahme in einen Block erhält, muss er sie an den Leader weiterleiten. Vor jeder Epoche, also ungefähr alle zwei Tage, wird ein Leader-Zeitplan erstellt. Die bevorstehende Epoche wird in Slots mit einer festen Dauer von jeweils 400 Millisekunden unterteilt. Für jeden Slot wird ein Leader ausgewählt. Validatoren mit höherem Stake werden in jeder Epoche häufiger als Leader ausgewählt. Während jedes Slots werden Transaktionsnachrichten an den Leader weitergeleitet, der einen Block erstellen kann. Ist ein Validator an der Reihe, wechselt er in den „Leader-Modus“, beginnt aktiv Transaktionen zu verarbeiten und überträgt Blöcke an den Rest des Netzwerks.

Stake-Weighted Quality of Service – SWQoS

Anfang 2024 führte Solana einen neuen Mechanismus ein, der Spam verhindern und die Sybil-Resistenz verbessern soll: Stake-Weighted Quality of Service (SWQoS). Mit diesem System können Leader Transaktionsnachrichten priorisieren, die über andere Validatoren mit Stake vermittelt werden. Validatoren mit einem höheren Stake erhalten proportional mehr Kapazität, um Pakete mit Transaktionsnachrichten an den Leader zu übertragen. Dieser Ansatz schwächt Sybil-Angriffe von Nodes ohne Stake im gesamten Netzwerk effektiv ab.

‍In diesem Modell können Validatoren außerdem Vereinbarungen treffen, um ihre nach Stake gewichtete Kapazität an RPC-Nodes zu vermieten. Im Gegenzug erhalten RPC-Nodes mehr Bandbreite und erreichen dadurch höhere Aufnahmeraten ihrer Transaktionen in Blöcke. 80 % der Kapazität eines Leaders, also 2.000 Verbindungen, sind für SWQoS reserviert. Die übrigen 20 %, also 500 Verbindungen, stehen Transaktionsnachrichten von Nodes ohne Stake zur Verfügung. Diese Aufteilung ähnelt gebührenpflichtigen Expressspuren auf Autobahnen, über die Fahrer Staus umgehen.

SWQoS hat das Solana-Ökosystem verändert: Die Anforderungen für das Weiterleiten von Transaktionen an den Leader sind gestiegen, während Spam-Angriffe weniger wirksam sind. Diese Änderung schafft für Anwendungen mit hohem Traffic einen Anreiz, ihren Betrieb vertikal zu integrieren. Indem sie eigene Validator-Nodes betreiben oder auf Staked Connections zugreifen, können Anwendungen einen privilegierten Zugang zum Leader sicherstellen und ihre Transaktionsverarbeitung verbessern.

Ein Hinweis zu QUIC

Ende 2022 führte Solana das Netzwerkprotokoll QUIC ein, um die Übertragung von Transaktionsnachrichten an den Leader zu steuern. Auslöser für den Wechsel waren Netzwerkstörungen durch Bots, die On-Chain-NFT-Mints mit Spam überlasteten. QUIC ermöglicht eine schnelle, asynchrone Kommunikation.

‍QUIC wurde ursprünglich 2012 von Google entwickelt und soll die Vorteile beider Welten vereinen. Es ermöglicht eine schnelle, asynchrone Kommunikation wie UDP, bietet aber zugleich die sicheren Sitzungen und erweiterten Datenflusskontrollen von TCP. Dadurch lässt sich der Traffic einzelner Quellen begrenzen, damit sich das Netzwerk auf die Verarbeitung echter Transaktionen konzentrieren kann. QUIC unterstützt außerdem separate Streams. Wird eine Transaktion verworfen, muss sie die übrigen Transaktionen daher nicht blockieren. Kurz gesagt versucht QUIC, die besten Eigenschaften von TCP und UDP zu kombinieren.

Blockerstellung

Viele Blockchain-Netzwerke erstellen vollständige Blöcke, bevor sie diese übertragen. Dieses Verfahren wird als diskrete Blockerstellung bezeichnet. Solana verwendet dagegen eine kontinuierliche Blockerstellung. Dabei werden Blöcke während des zugewiesenen Slots dynamisch zusammengesetzt und bereits bei ihrer Erstellung gestreamt, was die Latenz deutlich reduziert.

Jeder Slot dauert 400 Millisekunden. Jedem Leader werden vier aufeinanderfolgende Slots, also 1,6 Sekunden, zugewiesen, bevor der nächste Leader übernimmt. Damit ein Block akzeptiert wird, müssen alle darin enthaltenen Transaktionen gültig und von anderen Nodes reproduzierbar sein.

Zwei Slots vor der Übernahme der Leader-Rolle stoppt ein Validator das Weiterleiten von Transaktionen, um sich auf die bevorstehende Auslastung vorzubereiten. In diesem Zeitraum steigt der eingehende Traffic sprunghaft auf mehr als ein Gigabyte pro Sekunde, da das gesamte Netzwerk Pakete an den nächsten Leader sendet.

Nach dem Empfang gelangen die Transaktionsnachrichten in die Transaction Processing Unit (TPU), die Kernlogik des Validators für die Blockproduktion. Die Verarbeitung beginnt dort mit der Fetch Stage, in der Transaktionen über QUIC empfangen werden. Anschließend gelangen sie in die SigVerify Stage und durchlaufen strenge Validierungsprüfungen. Der Validator prüft die Gültigkeit und korrekte Anzahl der Signaturen und entfernt doppelte Transaktionen.

‍Banking Stage

Die Banking Stage lässt sich als Phase der Blockerstellung beschreiben. Sie ist die wichtigste Phase der TPU und nach der „Bank“ benannt. Eine Bank ist schlicht der Zustand bei einem bestimmten Block. Für jeden Block verfügt Solana über eine Bank, über die der Zustand dieses Blocks abgerufen wird. Sobald ein Block finalisiert ist, nachdem genügend Validatoren dafür gestimmt haben, schreiben sie die Kontoaktualisierungen aus der Bank dauerhaft auf den Datenträger. Der finale Zustand der Chain ergibt sich aus allen bestätigten Transaktionen. Dieser Zustand lässt sich jederzeit deterministisch aus dem Blockchain-Verlauf rekonstruieren.‍

Transaktionen werden parallel verarbeitet und zu „Einträgen“ im Ledger gebündelt. Diese bestehen aus jeweils 64 konfliktfreien Transaktionen. Die parallele Transaktionsverarbeitung ist auf Solana einfach möglich, da jede Transaktion eine vollständige Liste aller Konten enthalten muss, die sie liest oder beschreibt. Diese Designentscheidung erhöht den Aufwand für Entwickler, erlaubt dem Validator aber, Race Conditions zu vermeiden. Er wählt dafür einfach nur konfliktfreie Transaktionen zur Ausführung innerhalb eines Eintrags aus. Transaktionen stehen in Konflikt, wenn beide dasselbe Konto beschreiben wollen (zwei Schreibvorgänge) oder wenn eine dasselbe Konto liest, das die andere beschreibt (Lese- und Schreibvorgang). Konfliktbehaftete Transaktionen kommen daher in verschiedene Einträge und werden nacheinander ausgeführt. Konfliktfreie Transaktionen werden parallel ausgeführt.

Sechs Threads verarbeiten Transaktionen parallel. Vier davon sind normalen Transaktionen und zwei ausschließlich Abstimmungstransaktionen vorbehalten, die einen wesentlichen Bestandteil des Solana-Konsensmechanismus bilden. Die gesamte Parallelisierung der Verarbeitung erfolgt über mehrere CPU-Kerne. Validatoren benötigen keine GPU (Dokumentation).‍

Sobald die Transaktionen zu Einträgen gruppiert wurden, können sie von der Solana Virtual Machine (SVM) ausgeführt werden. Die für die Transaktion erforderlichen Konten werden gesperrt. Prüfungen bestätigen, dass die Transaktion aktuell ist, aber noch nicht verarbeitet wurde. Die Konten werden geladen und die Transaktionslogik wird ausgeführt, wodurch sich die Kontozustände aktualisieren. Ein Hash des Eintrags wird zur Aufzeichnung an den Proof-of-History-Dienst gesendet. Mehr dazu folgt im nächsten Abschnitt. Ist die Aufzeichnung erfolgreich, werden alle Änderungen in der Bank festgeschrieben und die im ersten Schritt gesetzten Sperren der einzelnen Konten aufgehoben. Die Ausführung übernimmt die SVM. Diese virtuelle Maschine basiert auf dem Solana-Fork von rBPF, einer Bibliothek für JIT-Kompilierung und virtuelle Maschinen für eBPF-Programme. Solana schreibt Validatoren nicht vor, wie sie Transaktionen innerhalb eines Blocks anordnen. Diese Flexibilität ist entscheidend und wird später im Abschnitt „Ökonomie + Jito“ dieses Berichts erneut aufgegriffen.‍

Clients

Solana ist ein Netzwerk aus Tausenden unabhängig betriebenen Nodes, die gemeinsam ein einheitliches Ledger verwalten. Jeder Node ist eine Hochleistungsmaschine, auf der dieselbe Open-Source-Software läuft, die als „Client“ bezeichnet wird.

Solana startete mit einer einzigen Validator-Client-Software: dem ursprünglichen Solana-Labs-Client, der heute als Agave-Client bekannt und in Rust geschrieben ist. Seitdem hat die größere Vielfalt an Clients Priorität. Mit der Einführung des Firedancer-Clients wird dieses Ziel Realität. Firedancer ist eine vollständige Neuentwicklung des ursprünglichen Clients in der Programmiersprache C. Er wird von einem erfahrenen Team des Hochfrequenzhandelsunternehmens Jump entwickelt und soll der leistungsstärkste Validator-Client aller Blockchains werden.

Proof of History

Proof of History (PoH) ist Solanas Geheimrezept. Es funktioniert wie eine spezielle Uhr in jedem Validator und erleichtert die Synchronisierung im gesamten Netzwerk. PoH schafft eine verlässliche Referenz für die Reihenfolge von Ereignissen und den Zeitverlauf. Vor allem stellt es sicher, dass der Leader-Zeitplan eingehalten wird. Trotz des ähnlichen Namens ist Proof of History kein Konsensalgorithmus wie Proof of Work.

‍Der Kommunikationsaufwand zwischen Nodes steigt normalerweise mit der Größe eines Netzwerks, und die Koordination wird zunehmend komplex. Solana reduziert diesen Aufwand, indem es die Kommunikation zwischen Nodes durch eine lokale PoH-Berechnung ersetzt. Dadurch können sich Validatoren mit nur einer Abstimmungsrunde auf einen Block festlegen. Vertrauenswürdige Zeitstempel in Nachrichten verhindern, dass Validatoren einander zuvorkommen und ihre Blöcke vorzeitig beginnen.

PoH basiert auf den besonderen Eigenschaften von Hashing-Algorithmen, insbesondere SHA256:

• Deterministisch: Dieselbe Eingabe erzeugt immer denselben Hash.
• Feste Größe: Unabhängig von der Eingabegröße ist der ausgegebene Hash immer 256 Bit lang.
• Effizient: Der Hash lässt sich für jede Eingabe schnell berechnen.
• Präimage-Resistenz: Es ist rechnerisch nicht praktikabel, aus dem ausgegebenen Hash die ursprüngliche Eingabe zu ermitteln.
• Lawineneffekt: Eine kleine Änderung der Eingabe, selbst eines einzelnen Bits, erzeugt einen erheblich anderen Hash. Diese Eigenschaft wird als Lawineneffekt bezeichnet.
• Kollisionsresistenz: Es ist nicht praktikabel, zwei verschiedene Eingaben zu finden, die denselben Hash erzeugen.

In jedem Validator-Client führt ein eigener „Proof of History Service“ fortlaufend den SHA256-Hashing-Algorithmus aus und erzeugt eine Hash-Kette. Als Eingabe für jeden Hash dient die Ausgabe des vorherigen Hashes. Diese Kette funktioniert wie eine verifizierbare Verzögerungsfunktion, da die Hashing-Arbeit sequenziell erfolgen muss und die Ergebnisse zukünftiger Hashes nicht im Voraus bekannt sein können. Erzeugt der PoH-Service eine Kette aus tausend Hashes, wissen wir, dass Zeit vergangen sein muss, um jeden Hash nacheinander zu berechnen. Man kann dies als „Mikro-Proof-of-Work“ verstehen. Andere Validatoren können die Korrektheit der tausend Hashes jedoch parallel und wesentlich schneller überprüfen, als sie erzeugt wurden, da Ein- und Ausgabe jedes Hashes an das Netzwerk übertragen wurden. PoH ist daher schwer zu erzeugen, aber einfach zu verifizieren.

Die Leistungsunterschiede verschiedener CPUs bei der Berechnung von SHA-256 sind überraschend gering. Selbst zwischen den schnellsten Rechnern gibt es nur kleine Abweichungen. Eine allgemeine Obergrenze wurde bereits erreicht, obwohl viel Zeit und Aufwand in die Optimierung dieser Funktion geflossen sind – vor allem, weil Bitcoin auf sie angewiesen ist.

‍Während des Slots eines Leaders empfängt der PoH-Service neu verarbeitete Einträge aus der Banking-Phase. Der aktuelle PoH-Hash und ein Hash aller Transaktionen im Eintrag werden zum nächsten PoH-Hash kombiniert. Dieser dient als Zeitstempel, der den Eintrag in die Hash-Kette einfügt und die Reihenfolge beweist, in der die Transaktionen verarbeitet wurden. Der Prozess bestätigt nicht nur den Zeitverlauf, sondern erstellt auch einen kryptografischen Nachweis der Transaktionen.

Ein einzelner Block enthält 800.000 Hashes. Der PoH-Stream umfasst außerdem „Ticks“. Das sind leere Einträge, die anzeigen, dass der Leader aktiv ist, und den Zeitverlauf in kleinen Sekundenbruchteilen abbilden. Alle 6,25 Millisekunden erfolgt ein Tick. Das ergibt 64 Ticks pro Block und eine gesamte Blockzeit von 400 Millisekunden.

Validatoren führen die PoH-Uhr auch dann kontinuierlich aus, wenn sie nicht der Leader sind, da sie bei der Synchronisierung zwischen Nodes eine zentrale Rolle spielt.

Account-Modell

In einem Solana-Validator wird der globale Zustand in der Account-Datenbank AccountsDB verwaltet. Diese Datenbank speichert alle Accounts, sowohl im Arbeitsspeicher als auch auf der Festplatte. Die primäre Datenstruktur im Account-Index ist eine Hashmap. Damit ist AccountsDB im Wesentlichen ein großer Key-Value-Speicher. Der Schlüssel ist die Account-Adresse und der Wert sind die Account-Daten.

Im Laufe der Zeit ist die Zahl der Solana-Accounts auf mehrere Hundert Millionen gestiegen. Das liegt zum Teil daran, dass Solana-Entwickler gern sagen: „Alles auf Solana ist ein Account!“

Solana-Accounts

Ein Account ist ein Container, der Daten dauerhaft speichert, ähnlich einer Datei auf einem Computer. Es gibt verschiedene Arten:

• Benutzer-Accounts: Diese Accounts besitzen einen privaten Schlüssel und werden normalerweise von einer Wallet-Software für einen Benutzer erstellt.
• Daten-Accounts: Diese Accounts speichern Zustandsinformationen, etwa die Menge eines bestimmten Tokens, die ein Benutzer hält.
• Programm-Accounts: Das sind größere Accounts mit ausführbarem Bytecode, ungefähr vergleichbar mit einer .exe-Datei unter Windows oder einer .app-Datei auf einem Mac.
• Native Programm-Accounts: Das sind spezielle, vorab bereitgestellte Programm-Accounts, die verschiedene Kernfunktionen des Netzwerks ausführen. Zu den Beispielen gehören das Vote Program und der BPF Loader.

Alle Accounts haben die folgenden Felder:

Programme‍

Solana-Programm-Accounts enthalten ausschließlich ausführbare Logik. Wenn ein Programm ausgeführt wird, verändert es also den Zustand anderer Accounts, bleibt selbst jedoch unverändert. Diese Trennung von Code und Zustand unterscheidet Solana von anderen Blockchains und ermöglicht viele seiner Optimierungen. Entwickler schreiben diese Programme hauptsächlich in Rust, einer universellen Programmiersprache mit starkem Fokus auf Sicherheit und Leistung. Zusätzlich stehen mehrere SDKs in TypeScript und Python zur Verfügung. Sie erleichtern die Entwicklung von Anwendungs-Frontends und ermöglichen die programmgesteuerte Interaktion mit dem Netzwerk.

Native Programme bieten viele gängige Funktionen direkt an. Solana verlangt beispielsweise nicht, dass Entwickler Code bereitstellen, um einen Token zu erstellen. Stattdessen senden sie Anweisungen an ein vorab bereitgestelltes natives Programm. Dieses richtet einen Account ein, der die Metadaten des Tokens speichert, und erstellt damit einen neuen Token.

Rent

Rent ist ein Mechanismus, der Benutzer dazu anregen soll, Accounts zu schließen und die Aufblähung des Zustands zu reduzieren. Um einen neuen Account zu erstellen, muss der Account ein Mindestguthaben in SOL halten, den sogenannten „rent-exempt“-Betrag. Dieser Betrag lässt sich als Speicherkosten betrachten, die anfallen, um den Account im Arbeitsspeicher eines Validators aktiv zu halten. Steigt die Größe der Account-Daten, erhöht sich das erforderliche Mindestguthaben proportional. Wird ein Account nicht mehr benötigt, kann er geschlossen werden. Die Rent wird dann an den Account-Inhaber zurückgezahlt. 

Hält ein Benutzer beispielsweise einen an den Dollar gekoppelten Stablecoin, wird dieser Zustand in einem Token-Account gespeichert. Der „rent-exempt“-Betrag für einen Token-Account liegt derzeit bei 0,002 SOL. Überträgt der Benutzer sein gesamtes Stablecoin-Guthaben an einen Freund, kann der Token-Account geschlossen werden und der Benutzer erhält seine 0,002 SOL zurück. Programme schließen Accounts für Benutzer häufig automatisch. Mehrere Anwendungen helfen Benutzern dabei, alte, nicht mehr verwendete Accounts zu bereinigen und die darin gespeicherten kleinen SOL-Beträge zurückzuerhalten.

Inhaberschaft

Account-Daten dürfen von jedem gelesen werden. Das Inhaberschaftsmodell von Solana erhöht jedoch die Sicherheit, indem es genau festlegt, wer die Daten eines Accounts ändern, also schreiben, darf. Dieses Konzept ist entscheidend, um Regeln und Berechtigungen auf der Solana-Blockchain durchzusetzen. Jeder Account hat ein Programm als „Inhaber“. Der Inhaber eines Accounts verwaltet ihn und stellt sicher, dass nur autorisierte Programme die Account-Daten ändern können. Eine wichtige Ausnahme ist die Übertragung von Lamports, der kleinsten Einheit von SOL: Das Lamports-Guthaben eines Accounts darf unabhängig von der Inhaberschaft von jedem erhöht werden.

Speicherung des Zustands

Solana-Programme sind schreibgeschützte ausführbare Dateien und müssen ihren Zustand daher über „Program Derived Addresses“ (PDAs) speichern. PDAs sind spezielle Account-Typen, die einem Programm statt einem bestimmten Benutzer zugeordnet sind und diesem gehören. Normale Solana-Benutzeradressen werden aus dem öffentlichen Schlüssel eines Ed25519-Schlüsselpaars abgeleitet. PDAs besitzen dagegen keinen privaten Schlüssel. Ihr öffentlicher Schlüssel wird stattdessen aus einer Kombination von Parametern – häufig Schlüsselwörtern oder anderen Account-Adressen – und der Programm-ID (Adresse) des besitzenden Programms abgeleitet.

PDA-Adressen liegen „off-curve“. Anders als normale Adressen befinden sie sich also nicht auf der Ed25519-Kurve. Nur das Programm, dem die PDA gehört, kann programmgesteuert Signaturen für sie erzeugen. Dadurch ist sichergestellt, dass ausschließlich dieses Programm den Zustand der PDA ändern kann.

Turbine

In der Banking-Phase werden Transaktionen zu Einträgen zusammengefasst und zur Zeitstempelung an den Proof-of-History-Stream gesendet. Die Bank des Blocks wird aktualisiert. Anschließend sind die Einträge für die nächste Phase bereit: Turbine.

Über Turbine verteilt der Leader seinen Block an den Rest des Netzwerks. Das von BitTorrent inspirierte Verfahren ist auf Geschwindigkeit und Effizienz ausgelegt. Es reduziert den Kommunikationsaufwand und minimiert die Datenmenge, die ein Leader senden muss.

‍Turbine erreicht dies, indem es Transaktionsdaten durch einen als „Shredding“ bezeichneten Prozess in „Shreds“ zerlegt. Shreds sind kleine Datenpakete von bis zu 1280 Byte, ähnlich einzelnen Frames in einem Videostream. Nach dem erneuten Zusammensetzen können Validatoren mit diesen Shreds den gesamten Block wiedergeben. Die Shreds werden über UDP zwischen Validatoren durch das Internet gesendet. Sie nutzen Erasure Coding, um Paketverluste oder das böswillige Verwerfen von Paketen auszugleichen. Erasure Coding ist ein auf Polynomen basierendes Verfahren zur Fehlererkennung und -korrektur, das die Datenintegrität sicherstellt. Selbst wenn einige Shreds verloren gehen, lässt sich der Block rekonstruieren.

Shreds werden in Gruppen zusammengefasst, die als Forward-Error-Correction-Batches (FEC-Batches) bezeichnet werden. Standardmäßig bestehen diese Batches aus 64 Shreds (32 Daten-Shreds + 32 Wiederherstellungs-Shreds). Die Datenwiederherstellung erfolgt pro FEC-Batch. Dadurch kann bis zur Hälfte der Pakete eines Batches verloren gehen oder beschädigt werden, ohne dass Daten verloren gehen. Jeder Batch aus 64 Shreds wird in einen Merkle-Baum überführt, dessen Root der Leader signiert und mit dem vorherigen Batch verkettet. Dadurch können Shreds sicher von jedem Node im Netzwerk bezogen werden, der sie besitzt. Die Kette der Merkle-Roots bietet einen überprüfbaren Nachweis ihrer Authentizität und Integrität.

Der Leader sendet zunächst an einen einzelnen Root-Node, der die Shreds an alle anderen Validator-Nodes verteilt. Dieser Root-Node wechselt mit jedem Shred. Die Validatoren sind in Schichten angeordnet und bilden den „Turbine-Baum“. Validatoren mit einem größeren Stake befinden sich normalerweise weiter oben im Baum, während Validatoren mit einem kleineren Stake weiter unten platziert werden.

‍Der Baum umfasst je nach Anzahl aktiver Validatoren normalerweise zwei oder drei Hops. Zur übersichtlichen Darstellung ist oben ein Fanout von 3 abgebildet. Der tatsächliche Fanout-Wert von Solana liegt derzeit jedoch bei 200. Aus Sicherheitsgründen wird die Reihenfolge des Baums für jeden neuen Shred-Batch rotiert.

Das Hauptziel eines solchen Systems besteht darin, den ausgehenden Datenverkehr der Leader- und Root-Nodes zu entlasten. Ein System aus Übertragung und erneuter Übertragung verteilt die Last zwischen dem Leader und den weiterleitenden Nodes. Dadurch sinkt die Belastung jedes einzelnen Nodes.

Konsens

Sobald ein Validator über Turbine einen neuen Block vom Leader erhält, muss er alle Transaktionen in jedem Eintrag validieren. Dazu gibt er den gesamten Block wieder, validiert die PoH-Hashes parallel, rekonstruiert die Transaktionen in der von PoH vorgegebenen Reihenfolge und aktualisiert seine lokale Bank. 

‍Diesen Prozess übernimmt die Transaction Validation Unit (TVU). Sie entspricht der Transaction Processing Unit (TPU) des Leaders und enthält die Kernlogik für die Verarbeitung von Shreds und die Blockvalidierung. Wie der TPU-Ablauf besteht auch der TVU-Ablauf aus mehreren Phasen. Er beginnt mit der Shred Fetch Stage, in der Shreds über Turbine empfangen werden. In der anschließenden Shred Verify Leader Signature Stage durchlaufen die Shreds mehrere Plausibilitätsprüfungen. Besonders wichtig ist die Prüfung der Leader-Signatur, die sicherstellt, dass die empfangenen Shreds vom Leader stammen. ‍

In der Retransmit Stage leitet der Validator die Shreds entsprechend seiner Position im Turbine-Baum an die richtigen nachgelagerten Validatoren weiter. In der Replay Stage rekonstruiert der Validator jede Transaktion exakt und in der richtigen Reihenfolge. Gleichzeitig aktualisiert er seine lokale Version der Bank.

Die Replay Stage entspricht der Banking-Phase in der TPU. Sie ist die wichtigste Phase und lässt sich direkter als Blockvalidierungsphase beschreiben. Replay ist eine Single-Thread-Prozessschleife, die viele zentrale Vorgänge koordiniert, darunter Abstimmungen, das Zurücksetzen der PoH-Uhr und den Wechsel zwischen Banken. 

Konsens

Um einen Konsens zu erzielen, verwendet Solana Tower BFT (TBFT), eine eigene Implementierung des bekannten Practical-Byzantine-Fault-Tolerance-Algorithmus (PBFT). Die meisten Blockchains nutzen ihn, um sich auf den Zustand der Chain zu einigen. Wie alle Blockchains geht Solana davon aus, dass sich böswillige Nodes im Netzwerk befinden. Das System muss daher nicht nur Node-Ausfälle, sondern auch bestimmte Angriffe verkraften.

Tower BFT unterscheidet sich von anderen Chains, weil es die von Proof of History bereitgestellte synchronisierte Uhr nutzt. Traditionelles PBFT benötigt mehrere Kommunikationsrunden, um sich auf die Reihenfolge der Transaktionen zu einigen. Solana-Nodes verwenden dagegen die bereits festgelegte Reihenfolge der Ereignisse und reduzieren damit den Nachrichtenaufwand erheblich.

Abstimmungen

‍Um am Konsens teilzunehmen und Belohnungen zu verdienen, stimmen Validatoren für Blöcke, die sie für gültig halten, also beispielsweise frei von Double Spends oder fehlerhaften Signaturen, und die als kanonisch gelten sollten. Validatoren zahlen für diese Stimmen eine Transaktionsgebühr. Der Leader verarbeitet sie und nimmt sie zusammen mit regulären Benutzertransaktionen in einen Block auf. Deshalb werden Solana-Transaktionen häufig in Abstimmungs- und Nicht-Abstimmungstransaktionen unterteilt. Gibt ein Validator eine korrekte und erfolgreiche Stimme ab, erhält er einen Credit. Dieser Mechanismus motiviert Validatoren, für den Fork zu stimmen, der ihrer Ansicht nach die besten Chancen auf eine Aufnahme hat, also für den „schwersten“ Fork.

Forks

Ein Teil des Designs, das Solana so schnell macht, besteht darin, dass das Netzwerk nicht auf die Zustimmung aller Validatoren zu einem neu erzeugten Block wartet, bevor der nächste Block erzeugt wird. Daher ist es nicht ungewöhnlich, dass zwei verschiedene Blöcke mit demselben übergeordneten Block verknüpft sind und Forks entstehen.

Solana-Validatoren müssen über diese Forks abstimmen und mithilfe eines Konsensalgorithmus bestimmen, welchen sie übernehmen. Bei konkurrierenden Forks finalisiert das Netzwerk letztlich nur einen Fork. Blöcke in verworfenen Forks werden aufgegeben.

Für jeden Slot ist ein Leader vorgegeben, und nur der Block dieses Leaders wird akzeptiert. Für einen einzelnen Slot kann es daher nicht zwei vorgeschlagene Blöcke geben. Die Anzahl möglicher Forks ist somit auf eine „vorhanden/nicht vorhanden“-Skip-Liste von Forks begrenzt, die an den Grenzen der Leader-Rotations-Slots entstehen können. Sobald ein Validator einen Fork auswählt, bleibt er diesem bis zum Ablauf einer Sperrfrist verpflichtet. Er muss seine Wahl also für einen Mindestzeitraum beibehalten.

‍Die „Skip Rate“ von Solana – der Prozentsatz der Slots, in denen kein Block erzeugt wurde – liegt zwischen 2 % und 10 %. Forks sind der Hauptgrund für diese übersprungenen Slots. Weitere mögliche Ursachen sind der Beginn einer neuen Epoche, ein offline befindlicher Leader oder die Erzeugung eines ungültigen Blocks.

Denk daran:

Der Status einer Transaktion auf Solana hängt von ihrer aktuellen Phase im Konsensprozess ab:

• Verarbeitet: Die Transaktion wurde in einen Block aufgenommen.
• Bestätigt: Eine Zweidrittelmehrheit hat für den Block der Transaktion gestimmt.
• Finalisiert: Auf dem Block der Transaktion wurden mehr als 31 weitere Blöcke aufgebaut.

Bis heute gab es in der Geschichte von Solana keinen Fall, in dem ein optimistisch bestätigter Block nicht finalisiert wurde.‍

Solana verwendet für jeden Block eine Bank, um auf den Zustand bei diesem Block zuzugreifen. Wenn eine Bank finalisiert wird, werden die Account-Aktualisierungen dieser Bank und ihrer Vorgänger auf die Festplatte geschrieben. Zusätzlich werden alle Account-Aktualisierungen früherer Banken entfernt, die keine Vorgänger der finalisierten Bank sind. Mit diesem Prozess kann Solana mehrere potenzielle Zustände effizient verwalten.

Gossip + Archiv

Gossip

Das Gossip-Netzwerk lässt sich als Kontrollebene des Solana-Netzwerks verstehen. Anders als die Datenebene, die Transaktionsflüsse verarbeitet, verteilt die Kontrollebene wichtige Metadaten über den Zustand der Blockchain. Dazu gehören Kontaktinformationen, die Ledger-Höhe und Abstimmungsinformationen. Ohne Gossip wüssten Validatoren und RPCs nicht, welche Adressen und Ports für die Kommunikation mit verschiedenen Diensten geöffnet sind. Auch neue Nodes benötigen Gossip, um dem Netzwerk beizutreten.

Das Gossip-Protokoll von Solana nutzt informelle Peer-to-Peer-Kommunikation mit einem von einem modifizierten PlumTree-Algorithmus inspirierten Baum-Broadcast-Verfahren. Diese Methode verteilt Informationen effizient, ohne von einer zentralen Quelle abhängig zu sein.

Gossip arbeitet weitgehend als isoliertes System und unabhängig von den meisten anderen Validator-Komponenten. Validatoren und RPCs teilen über Gossip alle 0,1 Sekunden signierte Datenobjekte per UDP. Dadurch bleiben die Informationen im gesamten Netzwerk verfügbar. Alle Gossip-Nachrichten dürfen höchstens so groß wie die maximale Übertragungseinheit (MTU) von 1280 Byte sein, die in der Codebasis als „packet struct“ bezeichnet wird.

Gossip-Datensätze sind die eigentlichen Datenobjekte, die Nodes miteinander teilen. Es gibt ungefähr 10 verschiedene Arten von Datensätzen, die jeweils unterschiedlichen Zwecken dienen. Gossip-Datensätze werden signiert, versioniert und mit einem Zeitstempel versehen, um ihre Integrität und Aktualität sicherzustellen.

Es gibt vier Arten von Gossip-Nachrichten:‍

1. Push: Die häufigsten Nachrichten. Sie teilen Informationen mit einer Teilmenge von „Push-Peers“.
2. Pull & Pull Response: Prüft regelmäßig, ob Nachrichten fehlen. Pull Responses senden Informationen zurück, die den Nodes fehlen.
3. Prune: Ermöglicht Nodes, die Anzahl ihrer bestehenden Verbindungen gezielt zu reduzieren.
4. Ping & Pong: Integritätsprüfungen für Nodes. Wird ein Ping gesendet, wird ein Pong als Antwort erwartet. Dieser zeigt an, dass der Peer-Node noch aktiv ist.

Gossip-Daten werden in einem Cluster Replicated Data Store (CrdsTable) gespeichert. Diese Datenstruktur kann sehr groß werden und muss regelmäßig bereinigt werden.

Archiv

Solana unterscheidet sich von anderen Blockchains, weil nicht der gesamte Verlauf benötigt wird, um den aktuellen Zustand eines Accounts zu bestimmen. Das Account-Modell von Solana stellt sicher, dass der Zustand für jeden Slot bekannt ist. Validatoren können daher den aktuellen Zustand jedes Accounts speichern, ohne alle historischen Blöcke zu verarbeiten. RPCs und Validatoren bewahren absichtlich nicht das gesamte historische Ledger auf. Stattdessen speichern sie normalerweise nur Transaktionsdaten aus 1 oder 2 Epochen, also 2 bis 4 Tagen. Das reicht aus, um die Spitze der Chain zu validieren.

Archive werden derzeit von „Warehouse-Nodes“ verwaltet. Diese werden von professionellen RPC-Dienstleistern, der Solana Foundation und anderen Teilnehmern des Ökosystems betrieben, die den Transaktionsverlauf verfügbar halten möchten. Warehouse-Nodes verwalten normalerweise eine oder beide der folgenden Ressourcen:

1. Ledger-Archiv: Lädt das rohe Ledger und AccountsDB-Snapshots hoch, die sich für eine vollständige Wiedergabe eignen.
2. Google-Bigtable-Instanz: Speichert Blockdaten ab dem Genesis-Block in einem Format, das RPC-Anfragen bedienen kann.

Ökonomie + Jito

Solana nutzt Inflation, um Staking-Belohnungen auszuschütten, indem in jeder Epoche neue SOL-Token erzeugt werden. Dadurch sinkt der Netzwerkanteil von Nicht-Stakern im Verhältnis zu Stakern. Vermögen wird also von Nicht-Stakern zu Stakern übertragen. Die Inflation begann Anfang 2021 mit einer anfänglichen Rate von 8 %. Sie sinkt jährlich um 15 %, bis sie sich langfristig bei 1,5 % stabilisiert.

‍Jeder Inhaber von SOL-Token kann Belohnungen verdienen und das Netzwerk absichern, indem er Token bei einem oder mehreren Validatoren stakt. Das Zuweisen von Token an einen Validator wird als Delegieren bezeichnet. Wer Token an einen Validator delegiert, bringt ihm Vertrauen entgegen. Der Validator erhält dadurch jedoch weder das Eigentum noch die Kontrolle über die Token. Alle Staking-, Unstaking- und Delegationsaktionen werden zu Beginn der nächsten neuen Epoche ausgeführt.

Abstimmungsbelohnungen

‍Wenn ein Validator eine Stimme abgibt, erhält er einen Credit, sofern die Stimme korrekt und erfolgreich ist. Abstimmungstransaktionen kosten 0,000005 SOL und sind von Priority Fees befreit. Die Abstimmungskosten betragen ungefähr 1 SOL pro Tag und Validator. Damit sind sie die wichtigsten Betriebskosten eines Validators. Im Laufe einer Epoche sammeln Validatoren durch Abstimmungen Credits. Am Ende der Epoche können sie diese gegen einen Anteil an der Inflation eintauschen.

Die leistungsstärksten Validatoren stimmen bei ungefähr 90 % der Slots erfolgreich ab. Beachte, dass der Anteil der Slots ohne Blöcke (Skipped Slot Rate) zwischen 2 % und über 10 % liegt. Über diese Slots kann nicht abgestimmt werden. Ein durchschnittlicher Validator stimmt bei etwa 80 % der Slots erfolgreich ab und verdient in einer Epoche mit 432.000 Slots 345.600 Credits.

Der gesamte Inflationstopf wird zunächst anhand der in der Epoche verdienten Credits aufgeteilt. Der Anteil eines Validators an allen Credits – seine Credits geteilt durch die Summe der Credits aller Validatoren – bestimmt seine anteilige Belohnung. Diese wird zusätzlich nach Stake gewichtet.

Ein Validator mit 1 % des gesamten Stakes sollte daher ungefähr 1 % der gesamten Inflation verdienen, sofern er eine durchschnittliche Anzahl an Credits besitzt. Liegt seine Credit-Anzahl über oder unter dem Durchschnitt, schwanken seine Belohnungen entsprechend.‍

Unterschiede bei der Abstimmungsleistung sind ein Grund dafür, dass die von Validatoren angebotenen Renditen für Staker, gemessen als APY, variieren. Ein weiterer Faktor ist der Provisionssatz des Validators. Dabei handelt es sich um einen Prozentsatz der gesamten Inflationsbelohnungen, der an den Validator fließt. Auch ein offline befindlicher oder nicht mit der Blockchain synchronisierter Validator – als Delinquency bezeichnet – beeinträchtigt die Rendite erheblich.

Blockbelohnungen

Validatoren, die als Leader für einen bestimmten Block ausgewählt wurden, erhalten zusätzliche Blockbelohnungen. Diese umfassen 50 % der Basisgebühren und 50 % der Priority Fees aller Transaktionen im Block. Die übrigen Gebühren werden verbrannt. Nur der Validator, der den Block erzeugt hat, erhält diese Belohnungen. Anders als Staking-Belohnungen, die pro Epoche ausgeschüttet werden, werden Blockbelohnungen bei der Erzeugung des Blocks sofort dem Identitäts-Account des Validators gutgeschrieben.

Liquid Staking

Liquid Staking ist zu einer beliebten Alternative zum nativen Staking geworden. Teilnehmer erhalten einen Token, den sogenannten Liquid Staking Token (LST) oder ein Liquid Staking Derivative (LSD), wenn sie ihre SOL staken. Dies geschieht normalerweise in einem Stake-Pool, der ihre Token auf mehrere Validatoren verteilt. Die neu erhaltenen LST-Token repräsentieren den Anteil des Benutzers an den gestakten SOL. Diese Token können gehandelt, in verschiedenen Anwendungen verwendet oder an andere übertragen werden, während sie weiterhin Staking-Belohnungen verdienen. Der größte Vorteil dieses Systems ist die erheblich höhere Kapitaleffizienz.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

Beim traditionellen nativen Staking sammelt der Staker im Laufe der Zeit direkt mehr SOL an. Beim Liquid Staking werden die Belohnungen dagegen wieder in den Pool investiert und erhöhen den fairen Wert des LST. Solange es einen Mechanismus gibt, um LSTs gegen die zugrunde liegenden gestakten SOL einzulösen, sorgen Arbitrage-Händler dafür, dass der Token-Preis rational bleibt.

Jito

Zum Zeitpunkt der Erstellung verwenden über 80 % (Quelle) des Stakes auf Solana die Jito-Validator-Client-Software. Dieser Client ist ein Fork des ursprünglichen Agave-Clients. Er führt eine protokollexterne Blockspace-Auktion ein, die Validatoren durch Trinkgelder zusätzliche wirtschaftliche Anreize bietet. Dieser zusätzliche Anreiz ist ein wichtiger Grund für die weite Verbreitung des Jito-Clients unter Validatoren.

Wenn Leader den Jito-Validator-Client verwenden, werden ihre Transaktionen zunächst an den Jito-Relayer geleitet. Diese Open-Source-Software dient als Proxy-Router für Transaktionen. Andere Nodes im Netzwerk wissen nichts von der Existenz des Jito-Relayers. Sie senden Transaktionen einfach an die Adress- und Portkonfiguration, die der Leader im Gossip-Netzwerk als seinen ingress_socket veröffentlicht hat, und nehmen an, dass sie dem Leader gehört.

‍Der Relayer hält alle Transaktionen 200 Millisekunden lang zurück, bevor er sie an den Leader weiterleitet. Dieser „Speed-Bump“-Mechanismus verzögert eingehende Transaktionsnachrichten und schafft ein kurzes Zeitfenster für Auktionen. Nach 200 Millisekunden gibt der Relayer die Transaktionen unabhängig vom Auktionsergebnis optimistisch frei.

Blockspace-Auktionen finden außerhalb der Chain über die Jito Block Engine statt. Searcher und Anwendungen können dabei Gruppen atomar ausgeführter Transaktionen einreichen, die als Bundles bezeichnet werden. Diese Bundles enthalten normalerweise zeitkritische Transaktionen wie Arbitragen oder Liquidationen. Jito berechnet eine Gebühr von 5 % auf alle Trinkgelder. Das Mindesttrinkgeld beträgt 10.000 Lamports. Trinkgelder werden vollständig außerhalb des Protokolls abgewickelt und sind von den protokollinternen Priority Fees und Basisgebühren getrennt. Früher betrieb Jito einen kanonischen protokollexternen Mempool-Dienst, der inzwischen eingestellt wurde.