- Helius-Produkte und -Plattform
- Solana-Grundlagen
- Transaktionsmechanik
- Token und Assets
- Konnektivität und Streaming
- Ökosystem
Helius-Produkte und -Plattform
Autoscaling
Der automatische Mechanismus von Helius zum Aufladen von Credits für Fiat-Tarife. Wenn das monatliche Credit-Kontingent aufgebraucht ist, kauft Autoscaling bis zu einem vom Benutzer festgelegten Limit zusätzliche Credits. So unterbrechen429-Fehler nicht den Produktionsverkehr. Krypto-Tarife bieten kein Autoscaling. Stattdessen verwenden sie Prepaid-Credits, die du manuell kaufst.
Weitere Informationen findest du unter Autoscaling.
Credit
Die Einheit, in der Helius die Nutzung von API und Streaming abrechnet. RPC-Methoden, DAS-Aufrufe und der Streaming-Durchsatz haben jeweils bestimmte Credit-Kosten. Jeder Tarif enthält ein monatliches Credit-Kontingent, das zu Beginn jedes Abrechnungszeitraums zurückgesetzt wird. Nicht genutzte Credits werden nicht übertragen. Die vollständige Kostentabelle findest du unter Credits.DAS API
Digital Asset Standard — eine offene Spezifikation für eine einheitliche Schnittstelle zu digitalen Solana-Assets wie NFTs, komprimierten NFTs und fungiblen Token. Die DAS API-Implementierung von Helius gibt angereicherte Metadaten, Eigentumsinformationen und Preise in einer einzigen strukturierten response zurück. Dadurch brauchst du keine eigenen Parser für Onchain-Asset-Daten. Weitere Informationen findest du unter DAS API.Dedicated Nodes
Private Helius-RPC-nodes ohne rate limits oder Credit-Messung, die zu einem festen monatlichen Preis abgerechnet werden. Sie eignen sich für spezielle Anwendungsfälle, die unbegrenzten Durchsatz benötigen. Für die meisten Anwendungen ist das reguläre Helius RPC dank besserer Leistung, Ausfallsicherheit und Funktionsabdeckung die bessere Wahl. Weitere Informationen findest du unter Dedicated Nodes.Enhanced Transactions
Die API von Helius für geparste Transaktionen. Sie decodiert rohe Solana-Transaktionen in menschenlesbare Ereignisse wie Token-Übertragungen, NFT-Verkäufe, Swaps und Staking-Vorgänge. Dafür sind keine eigenen Instruction-Parser für einzelne Programme nötig. Weitere Informationen findest du unter Enhanced Transactions.Fehlercodes
Standardmäßige HTTP-Statuscodes, die Helius APIs mit Helius-spezifischem Kontext zurückgeben:400 Bad Request— ungültige Parameter oder fehlerhafter request (z. B. ungültiges Adressformat, fehlende Pflichtfelder oder fehlerhaftes JSON)401 Unauthorized— fehlender oder ungültiger API key403 Forbidden— Zugriff verweigert, meist aufgrund von IP-Beschränkungen, eines Abonnements ohne den betreffenden endpoint oder unzureichender Berechtigungen des API key404 Not Found— für die angeforderte Ressource sind keine Daten verfügbar (bei Identitätsabfragen für unbekannte Wallets normal)429 Too Many Requests— Credit-Kontingent aufgebraucht, rate limit überschritten oder Limit für gleichzeitige requests erreicht5xx— Probleme aufseiten von Helius; wiederhole den request mit exponentiellem Backoff
Gatekeeper
Das Edge-Gateway von Helius bietet deutlich geringere Latenz als standardmäßige RPC-Aufrufe. Dazu leitet es requests über eine global verteilte Proxy-Flotte weiter. Ersetze in der RPC-URLmainnet.helius-rpc.com durch beta.helius-rpc.com, um darauf zuzugreifen.
Weitere Informationen zur Architektur findest du unter Gatekeeper und im Blogbeitrag Introducing Gatekeeper.
LaserStream
Der leistungsstarke gRPC-Streaming-Dienst von Helius für Solana-Onchain-Daten. Er bietet historische Wiedergabe, regionsübergreifende Ausfallsicherheit und den größten Funktionsumfang unter den Streaming-Produkten von Helius. Offizielle SDKs sind für JavaScript/TypeScript, Rust und Go verfügbar. LaserStream WebSocket läuft auf derselben Infrastruktur. Weitere Informationen findest du unter LaserStream. Eine ausführliche Analyse der SDK-Benchmarks bietet der Blogbeitrag zur Leistung der LaserStream SDKs.LaserStream WebSocket
Der persistente WebSocket-Streaming-Dienst von Helius. Er stellt sowohl die standardmäßigen Solana-WebSocket-Methoden als auch Helius-spezifische Erweiterungen (transactionSubscribe und ein erweitertes accountSubscribe mit umfangreicheren Filtern) über einen einzigen einheitlichen endpoint bereit. LaserStream WebSocket nutzt dasselbe Backend wie LaserStream gRPC.
Weitere Informationen findest du unter LaserStream WebSocket.
Preconfirmations
Helius’ Transaktionssignal mit der niedrigsten Latenz. Es liefert Transaktionen, bevor sie zu Einträgen zusammengefasst und in shred zerlegt werden: Helius Preconfirmations in dem Moment, in dem der Leader sie ausführt, einschließlich ihres Ausführungsstatus, sowie BAM Preconfirmations, wenn sich der Validator zu ihrer Ausführung verpflichtet, noch bevor sie ausgeführt werden. Früher als Shred Delivery und früher als Streams mit processed commitment. Die Bereitstellung erfolgt über einpreconfSubscribe WebSocket-Abonnement. Verfügbar in allen kostenpflichtigen Tarifen für 10 Credits pro zugestellter Nachricht. Für slot ohne Nachrichten fallen keine Kosten an. Für slot mit mindestens einer zugestellten Nachricht gilt pro Abonnement ein Mindestpreis von 300 Credits. Die Abdeckung hängt davon ab, welche Validatoren ihren stream an Helius weiterleiten. Daher ist der Datenfluss nicht kontinuierlich.
Weitere Informationen findest du unter Preconfirmations und preconfSubscribe.
Priority Fee API
Der endpoint von Helius zur Gebührenschätzung gibt empfohlene Priority-Fee-Werte auf Basis der Onchain-Gebührenmärkte in Echtzeit zurück. So kannst du wettbewerbsfähige Gebühren festlegen, ohne zu raten oder bei hoher Auslastung zu viel zu bezahlen. Weitere Informationen findest du unter Priority Fee API.Rate Limit
Die maximale Anzahl von requests pro Sekunde, die ein bestimmter Helius-Tarif zulässt. Rate limits unterscheiden sich je nach Tarifstufe und API-Familie (standardmäßiges RPC, Enhanced APIs und Streaming). Bei einer Überschreitung wird429 Too Many Requests zurückgegeben.
Weitere Informationen findest du unter Rate Limits.
Sender
Der spezialisierte Dienst von Helius für die zuverlässige Aufnahme von Transaktionen wurde für Händler entwickelt, die niedrige Latenzen benötigen. Er kombiniert Priority Fees, Jito-Tipps und Routing über Staked Connections, um die Aufnahmerate zu maximieren. Verfügbar unterhttps://sender.helius-rpc.com/fast.
Weitere Informationen findest du unter Sender.
Shred Delivery
Der Service von Helius streamt rohe Solana-shred über UDP und stellt sie noch vor der endgültigen Block-Zusammenstellung bereit. Helius aggregiert shred aus einem verteilten Netzwerk regional verteilter Validatoren, um geografisch bedingte Latenzschwankungen einzelner Validatoren zu minimieren. Der Service eignet sich für den Hochfrequenzhandel und andere Anwendungen mit niedriger Latenz. Rohe shred sind direkt über das Helius Dashboard verfügbar – für $1.000 USD pro Monat und IP-Adresse ($800 USD pro Monat und IP-Adresse mit Pro-Tarifen). Weitere Informationen findest du unter Shred Delivery. Eine ausführliche Erklärung der Funktionsweise von shreds bietet der Blogbeitrag Winning the Millisecond Game: Shreds, LaserStream, and the Edge of Solana.Staked Connections
Der standardmäßige Pfad zum Übermitteln von Transaktionen bei kostenpflichtigen Helius-Tarifen. Staked Connections leiten Transaktionen über Solanas protokollbasierten Mechanismus Stake-Weighted Quality of Service (SWQoS) an die nächsten Block-Leader weiter. Dieser weist bevorzugte Verbindungsplätze anhand des Validator-Stakes zu und reduziert Paketverluste bei hoher Auslastung. Kostenpflichtige Helius-Tarife erhalten diesen Vorteil bei der Aufnahmerate, ohne dass Aufrufer selbst einen Validator mit hohem Stake betreiben müssen. Weitere Informationen findest du unter Transaktionen optimieren und im Blogbeitrag Stake-Weighted Quality of Service: Everything You Need to Know.Wallet API
Die REST API von Helius zum Abfragen von Guthaben, Transaktionsverlauf, Übertragungen, Identität und Finanzierungsquelle eines Solana-Wallets. Statt roher RPC-Ausgaben liefert sie strukturierte responses mit USD-Preisen. Zusätzlich zu Adressen akzeptiert sie SNS-.sol- und ANS-Domainnamen.
Weitere Informationen findest du unter Wallet API.
Solana-Grundlagen
Account
Ein Container, der Daten dauerhaft auf Solana speichert und durch einen öffentlichen 32-Byte-Schlüssel identifiziert wird. Der gesamte Onchain-Zustand — Benutzerguthaben, Programmcode und Token-Metadaten — befindet sich in Accounts, einschließlich der Programme selbst. Jeder Account hat einen Eigentümer. Das ist ein Programm, das seine Daten ändern oder Lamports abheben darf. Damit der Account bestehen bleibt, muss er außerdem ein SOL-Mindestguthaben halten und von der Miete befreit sein. Eine ausführliche Erklärung findest du im Blogbeitrag The Solana Programming Model: An Introduction to Developing on Solana.Agave
Der aktuelle kanonische Solana-Validator-Client, der von Anza gepflegt wird. Er ist der umbenannte Nachfolger des ursprünglichen Clients von Solana Labs. Verweise auf bestimmte Agave-Versionen, etwa den Mindest-Stake-Schwellenwert für SWQoS in v1.17.31, binden ein Verhalten normalerweise an eine bestimmte Client-Version. Jito-Solana ist ein Fork von Agave mit integrierter Block Engine. Firedancer ist eine unabhängige, C-basierte Alternative von Jump Crypto. Weitere Informationen zum von Agave implementierten SVM-Modell findest du im Blogbeitrag Solana Virtual Machine.Airdrop
Eine Zuteilung von SOL oder SPL-Token an eine Adresse. Auf Devnet und Testnet bezeichnet ein Airdrop normalerweise eine kleine Menge Test-SOL aus einem Faucet, mit der Entwicklungs-Wallets finanziert werden. Auf Mainnet bezeichnet der Begriff die umfangreiche Verteilung von Token an bestehende Inhaber. Devnet-Airdrops sind über den Devnet-Faucet verfügbar.Associated Token Account (ATA)
Ein deterministisch abgeleiteter Token-Account, der für eine bestimmte Wallet-Adresse einen bestimmten SPL-Token hält. Jedes Wallet hat höchstens einen ATA pro Token-Mint. ATAs sind daher der kanonische Ort, um das Token-Guthaben eines Benutzers abzufragen. Die Ableitung verwendet die Wallet-Adresse und den Token-Mint als Seeds.Block
Eine Datenstruktur, die eine Gruppe von Transaktionen sowie wichtige Metadaten enthält. Dazu gehören der Hash des Blocks und der Hash des vorherigen Blocks, die zusammen eine unveränderliche Kette bilden. Blöcke werden während slots erzeugt: Der einem slot zugewiesene Leader validiert eingehende Transaktionen, bündelt sie in einem Block und verteilt ihn über Turbine an das Netzwerk. Nicht jeder slot erzeugt einen Block. Wenn der Leader nicht rechtzeitig einen Block erzeugt, wird der slot übersprungen und das Netzwerk fährt fort. Sobald ein Block eine Supermehrheit Stake-gewichteter Stimmen von Validatoren erhalten hat, gilt er als bestätigt. Siehe Commitment-Stufe. Eine ausführliche Erklärung findest du im Blogbeitrag Understanding Slots, Blocks, and Epochs on Solana.Commitment-Stufe
Der Grad der Gewissheit, dass eine Transaktion Onchain aufgenommen wurde:processed— vom aktuellen Leader gesehen, aber noch nicht abgestimmt; kann weiterhin verworfen werden, wenn der Block den Konsens verliert (~0,4 s)confirmed— ≥66 % der Stake-gewichteten Validator-Stimmen entfallen auf den Block; bisher wurde noch kein bestätigter Block rückgängig gemacht (~0,6 s)finalized— der Block hat ≥66 % der Stimmen und 31 nachfolgende Blöcke wurden darauf aufgebaut (d. h. der maximale Lockout von Tower BFT); dadurch ist er praktisch unumkehrbar (~13 s)
confirmed ist der empfohlene Standardwert. Verwende processed für UI-Feedback und finalized für hochwertige Vorgänge wie Börseneinzahlungen oder Cross-Chain-Bridges. Mit finalized abgerufene Blockhashes laufen früher ab als mit confirmed abgerufene. Dadurch verkürzt sich das Zeitfenster bis zum Ablauf der Transaktion.
Eine ausführliche Erklärung findest du im Blogbeitrag What are Solana Commitment Levels?.
Compute Units (CU)
Solanas Maßeinheit für die Rechenarbeit einer Transaktion, vergleichbar mit Gas auf Ethereum. Jede Transaktion gibt ein Compute-Unit-Limit und einen Compute-Unit-Preis an, also die Priority Fee in Mikrolamports pro CU. Das Produkt daraus bestimmt die gesamten Priority-Fee-Kosten. Wenn die Transaktion das Limit überschreitet, schlägt sie fehl.CPI (Cross-Program Invocation)
Ein Solana-Mechanismus, mit dem ein Onchain-Programm ein anderes aufrufen und dabei Accounts sowie Instruction-Daten übergeben kann. Dieser Grundbaustein ermöglicht die Zusammensetzbarkeit von Solana. CPIs werden über den Syscallsol_invoke_signed bereitgestellt. Dieser prüft, ob der Aufrufer die erforderlichen Berechtigungen für die übergebenen Accounts besitzt. Mit PDAs können Programme im Namen ihrer eigenen Accounts signieren.
Ein aufgerufenes Programm arbeitet innerhalb des verbleibenden Compute-Budgets des aufrufenden Programms. Wenn es das Budget aufbraucht oder ein festgelegtes Limit überschreitet, schlägt die gesamte Aufrufkette einschließlich der ursprünglichen Transaktion fehl.
Eine ausführliche Erklärung findest du im Blogbeitrag Solana Virtual Machine.
Epoche
Eine Gruppe von ungefähr 432.000 Solana-slots. In diesem übergeordneten Organisationsintervall aktualisiert Solana seinen Validator-Satz, den Leader-Zeitplan, Stake-Delegationen und die Verteilung von Belohnungen. Beim aktuellen slot-Ziel dauert jede Epoche ungefähr zwei Tage. Eine ausführliche Erklärung findest du im Blogbeitrag Understanding Slots, Blocks, and Epochs on Solana.Firedancer
Ein zweiter unabhängiger Solana-Validator-Client, den Jump Crypto von Grund auf in C entwickelt hat. Firedancer verfolgt drei erklärte Ziele: (1) das Solana-Protokoll durch eine unabhängige Implementierung zu dokumentieren und zu standardisieren, (2) die Client-Vielfalt zu erhöhen, sodass kein einzelner Client mehr als 33 % des Stakes kontrolliert, und (3) die Leistung des Ökosystems zu steigern. Die Architektur ist modular. Viele Linux-Prozesse mit jeweils einer Aufgabe, sogenannte „Tiles“ wie QUIC Tile und Verify Tile, kommunizieren über gemeinsamen Speicher. Das unterscheidet sich vom Einprozess-Design von Agave. Frankendancer ist die hybride Zwischenlösung. Sie kombiniert den leistungsstarken C-Netzwerkcode von Firedancer mit dem Rust-Laufzeit- und Konsenscode von Agave. Eine ausführliche Erklärung findest du im Blogbeitrag What is Firedancer?.Instruction
Die kleinste Arbeitseinheit innerhalb einer Solana-Transaktion: ein einzelner Programmaufruf mit den relevanten Accounts und Daten. Eine Transaktion bündelt eine oder mehrere Instructions, die atomar ausgeführt werden. Entweder sind alle erfolgreich oder alle werden gemeinsam rückgängig gemacht. Eine ausführliche Erklärung findest du im Blogbeitrag The Solana Programming Model: An Introduction to Developing on Solana.Lamport
Die kleinste Einheit von SOL: 1 SOL = 1.000.000.000 Lamports (10⁻⁹ SOL). Sie ist nach Leslie Lamport benannt, dem Turing-Award-Gewinner für grundlegende Arbeiten an verteilten Systemen. Rohe Solana-RPC-Methoden geben Guthaben und Gebühren in Lamports zurück. Die Wallet API von Helius übernimmt die Umrechnung automatisch. Priority Fees werden in Mikrolamports angegeben — einem Millionstel Lamport (10⁻¹⁵ SOL).Leader / Leader-Zeitplan
Der Leader ist der Validator, der während eines bestimmten slot einen neuen Block vorschlagen soll. Die Leader werden anhand eines Stake-gewichteten Zufallszeitplans ausgewählt, der zu Beginn jeder Epoche berechnet wird. Daher kann jeder Validator unabhängig ermitteln, wer jeden slot im kommenden Zeitfenster von etwa zwei bis drei Tagen leitet. Jedem Leader werden vier aufeinanderfolgende slots zugewiesen, also ungefähr 1,6 Sekunden bei rund 400 ms pro slot. Das gibt ihm ein kurzes Zeitfenster für die fortlaufende Blockerzeugung. Wenn ein Leader in seinem slot keinen Block erzeugt, wird der slot übersprungen. Das Netzwerk wartet nicht auf den fehlenden Block, sondern fährt fort. Dienste zum Senden von Transaktionen wie Sender leiten signierte Transaktionen an den aktuellen und die beiden nächsten Leader weiter, um die Wahrscheinlichkeit der Aufnahme zu maximieren. Eine ausführliche Erklärung findest du im Blogbeitrag Consensus on Solana: Tower BFT and Proof of History.Merkle-Baum
Eine kryptografische Baumstruktur, in der jeder Nicht-Blatt-Knoten ein Hash seiner Kinder ist. Dadurch bindet sich der einzelne Root-Hash an den gesamten Datensatz. Um zu prüfen, ob ein Datenelement zum Baum gehört, werden nur die Hashes der Geschwisterknoten entlang des Pfads vom Blatt zur Wurzel benötigt. Dieser Merkle-Beweis benötigt unabhängig von der Baumgröße O(log n) Daten. Bei einem Baum der Tiefe 26 besteht der Beweis aus 26 Geschwister-Hashes (~832 Byte). Das ist klein, gilt aber weiterhin pro Blatt. Diese Beweisform verwenden komprimierte NFTs. ZK Compression ersetzt sie durch einen einzelnen Gültigkeitsbeweis mit konstanter Größe, die nicht mit dem Datensatz wächst. Weitere Informationen findest du im Blogbeitrag Cryptographic Tools 101: Hash Functions and Merkle Trees Explained.Programm
Ein ausführbarer Account mit kompiliertem sBPF-Bytecode, also ein Smart Contract auf Solana. Programme sind zustandslos. Sie lesen und schreiben eigene Daten-Accounts und werden durch eine Programm-ID identifiziert, ihre 32-Byte-Adresse. Solana enthält eine Reihe nativer Programme wie System, Stake und Vote, die in die Laufzeit integriert sind. Alles andere ist ein von einem Benutzer bereitgestelltes Programm. Eine ausführliche Erklärung findest du im Blogbeitrag The Solana Programming Model: An Introduction to Developing on Solana.Program Derived Address (PDA)
Eine deterministische Adresse, die aus einer Programm-ID und mehreren Seeds abgeleitet wird. Mit PDAs können Programme für die von ihnen kontrollierten Accounts signieren. Sie sind daher für den Entwurf zustandsbehafteter Programme unerlässlich. PDAs liegen absichtlich nicht auf der Kurve, sodass für sie kein privater Schlüssel existiert.Proof of History (PoH)
Solanas Grundbaustein für die Synchronisierung, nicht sein Konsensalgorithmus. PoH stellt eine kryptografische Zeitstempelfunktion bereit. Damit können sich Validatoren auf die Reihenfolge von Ereignissen einigen, ohne miteinander zu kommunizieren. Die Implementierung besteht aus einer sequenziellen SHA-256-Hash-Kette, die pro Validator kontinuierlich auf einem einzelnen CPU-Kern läuft und die Ausgabe jeder Iteration als Eingabe der nächsten verwendet. Die Erzeugung erfolgt sequenziell und in einem Thread, die Verifizierung lässt sich parallelisieren. PoH liefert die „Ticks“, die bestimmen, wann ein Block gültig ist. Leader müssen Blöcke innerhalb eines bestimmten PoH-Tick-Bereichs veröffentlichen. Ein Block außerhalb dieses Bereichs gilt als übersprungen. PoH läuft zusammen mit Tower BFT, dem eigentlichen Konsensmechanismus. Eine ausführliche Erklärung findest du im Blogbeitrag Proof of History, Proof of Stake, and Proof of Work Explained.Miete / Mietbefreiung
Das SOL-Guthaben, das jeder Solana-Account halten muss, um Onchain bestehen zu bleiben. Die Höhe richtet sich nach der Speichergröße des Accounts. Accounts müssen von der Miete befreit erstellt werden. Transaktionen schlagen fehl, wenn das Guthaben eines Accounts dadurch unter den Mindestwert fallen würde. Nach der Mietbefreiung bleibt der Account ohne weitere Zahlungen unbegrenzt bestehen.Sealevel
Solanas Engine für die parallele Ausführung von Transaktionen. Im Gegensatz zu sequenziellen VMs wie der EVM führt Sealevel mehrere Transaktionen gleichzeitig auf verschiedenen CPU-Kernen aus. Das ist möglich, weil jede Solana-Transaktion vor Beginn der Ausführung explizit angibt, aus welchen Accounts sie liest und in welche sie schreibt. So kann der Scheduler konfliktfreie Gruppen ohne Laufzeitanalyse erkennen. Die Planungsregeln sind einfach: Transaktionen, die unterschiedliche Accounts betreffen, werden parallel ausgeführt. Transaktionen, die dieselben Accounts nur lesen, werden ebenfalls parallel ausgeführt, da Lesezugriffe nicht kollidieren. Transaktionen, die in dieselben Accounts schreiben, werden sequenziell ausgeführt, um Race Conditions zu verhindern. Eine ausführliche Erklärung findest du im Blogbeitrag Solana Virtual Machine.Slot
Solanas grundlegende Zeiteinheit. Währenddessen kann ein bestimmter Leader-Validator einen Block erzeugen. Das aktuelle Ziel für slots beträgt 400 ms. Die tatsächliche Dauer kann je nach Netzwerkbedingungen abweichen. Wenn ein Leader während seines slot keinen Block erzeugt, wird der slot übersprungen. Das Netzwerk wartet nicht, sondern fährt mit dem nächsten slot fort. Daher entsteht nicht in jedem slot ein Block. Eine ausführliche Erklärung findest du im Blogbeitrag Understanding Slots, Blocks, and Epochs on Solana.SVM (Solana Virtual Machine)
Solanas vollständiger Stack zur Transaktionsausführung, nicht nur ein Bytecode-Interpreter. Die SVM umfasst die Bank-Komponente zur Steuerung der Ausführung, den Banking-Stage-Scheduler, BPF-Loader und die virtuelle sBPF-Maschine selbst. Letztere ist eine registerbasierte VM mit 11 Universalregistern und ungefähr 100 Opcodes, die für hohe Leistung JIT-kompiliert wird. Das unterscheidet sie von der EVM, die eindeutig einen einzelnen Bytecode-Executor bezeichnet. Solana-Programme werden zu sBPF kompiliert, Solanas Fork von Linux eBPF. Jede Sprache mit einem LLVM-Frontend wie C, C++, Rust oder Zig kann sBPF als Ziel verwenden. Weil Transaktionen ihre Account-Zugriffe vorab deklarieren müssen, werden die parallele Ausführung von Sealevel und Solanas lokale Gebührenmärkte möglich. Eine ausführliche Erklärung findest du im Blogbeitrag Solana Virtual Machine.Tower BFT
Solanas Konsensmechanismus. Tower BFT ist ein pBFT-ähnlicher Algorithmus, der die synchronisierte Uhr von Proof of History nutzt. Dadurch ist nicht für jeden slot eine synchrone Konsensrunde erforderlich. Validatoren bauen einen „Vote Tower“ auf, einen sequenziellen Stapel von Stimmen. Jede neue Stimme verdoppelt die Lockout-Dauer aller vorherigen Stimmen. Dadurch steigen die Kosten eines Fork-Wechsels durch Stake-Verluste exponentiell. Bestätigungsschwellenwerte: Ein Block gilt als bestätigt, sobald ≥2/3 der Stake-gewichteten Stimmen auf ihn entfallen. Um die Endgültigkeit zu verletzen, müssten ≥4,6 % des gesamten Stakes gekürzt werden. Ein Block gilt als finalisiert, sobald er Stimmen erhalten hat und 31 weitere Blöcke darauf aufgebaut wurden. Das ist der maximale Lockout von Tower BFT. Hinweise zur Verwendung findest du unter Commitment-Stufe. Eine ausführliche Erklärung findest du im Blogbeitrag Consensus on Solana: Tower BFT and Proof of History.Turbine
Solanas Protokoll zur Blockverteilung. Der Leader zerlegt jeden Block in MTU-große shreds und mit Reed-Solomon-Löschcodes versehene Wiederherstellungs-shreds. Mit der FEC-Rate, normalerweise 32:32, kann das Netzwerk einen Block selbst bei etwa 33 % Paketverlust rekonstruieren. Anschließend leitet der Leader die shreds über einen deterministischen, Stake-gewichteten Baum gleichrangiger Validatoren weiter, der pro shred-Gruppe durch(leader id, slot, shred index, shred type) initialisiert wird. Er überträgt also nicht den vollständigen Block direkt an jeden Validator. Der Baum (DATA_PLANE_FANOUT = 200) hält die ausgehende Bandbreite des Leaders unabhängig von der Anzahl der Validatoren ungefähr konstant. Außerdem erreichen Blöcke das Netzwerk in zwei bis drei Hops statt in O(n).
Weitere Informationen findest du im Blogbeitrag Turbine: Block Propagation on Solana.
Validator
Ein node im Solana-Netzwerk, der am Konsens teilnimmt. Er erzeugt während der ihm zugewiesenen Leader-slots Blöcke und stimmt über Blöcke anderer Validatoren ab. Validatoren werden proportional zu ihrem aktiven Stake für Leader-slots ausgewählt.Transaktionsmechanik
Address Lookup Table (ALT)
Eine Onchain-Tabelle mit Solana-Adressen, auf die eine versionierte Transaktion über einen 1-Byte-Index statt über einen vollständigen 32-Byte-Pubkey verweisen kann. Dadurch kann eine einzelne Transaktion auf bis zu 256 Accounts verweisen. ALTs sind für komplexe DeFi-Vorgänge unerlässlich, die andernfalls die Größenbeschränkung für Transaktionen überschreiten würden.Blockhash
Ein 32-Byte-Hash, der einen aktuellen Block identifiziert und in jeder Solana-Transaktion enthalten ist, um ihre Aktualität nachzuweisen. Blockhashes laufen nach ungefähr 150 slots, also etwa einer Minute, ab. Transaktionen mit abgelaufenen Blockhashes werden abgelehnt. Clients rufen unmittelbar vor dem Signieren übergetLatestBlockhash einen aktuellen Blockhash ab.
Priority Fee
Ein an Validatoren gezahltes Trinkgeld pro Compute Unit, das einer Transaktion Vorrang vor anderen gibt und ihre Aufnahme beschleunigt. Priority Fees werden in Mikrolamports pro Compute Unit (µLamports/CU) festgelegt. Die Priority Fee API von Helius liefert Echtzeitschätzungen auf Basis aktueller Onchain-Gebührenmärkte.Shred
Die kleinste Einheit eines Solana-Blocks. Blöcke werden für die parallele Verteilung über das Validator-Netzwerk mittels Turbine in shreds zerlegt. Der Zugriff auf shred-Ebene liefert Händlern Onchain-Signale mit extrem niedriger Latenz, noch bevor der Block zusammengesetzt ist. Preconfirmations treffen allerdings noch früher ein, bevor Einträge in shreds zerlegt werden. Weitere Informationen findest du unter Rohe shreds (UDP) und in der Übersicht zu Shred Delivery.Stake-Weighted Quality of Service (SWQoS)
Ein Mechanismus auf Solana-Protokollebene, der eingehende Transaktionen anhand des Stakes des Absenders für den aktuellen und die nächsten Leader priorisiert. SWQoS wurde nach dem Solana-Ausfall vom 30. April 2022 als Schutzmaßnahme gegen Sybil-Angriffe eingeführt. Es verhindert, dass Peers mit geringem oder ohne Stake bei hoher Auslastung die Bandbreite des Leaders monopolisieren. Der Leader stellt zwei Pools für eingehende Verbindungen bereit: ungefähr 500 offene Verbindungen, die sich alle Peers ohne Stake teilen, und ungefähr 2.000 Stake-gewichtete Verbindungen, die proportional auf Validatoren mit Stake verteilt werden. Ein Validator mit X % des gesamten aktiven Stakes kann bis zu X % der Pakete an den Leader senden. Validatoren mit weniger als ungefähr 15.000 SOL aktivem Stake, also etwa 1/25.000 des gesamten Netzwerk-Stakes, gelten als Validatoren ohne Stake. Der Mindest-Stake-Schwellenwert wurde mit Agave v1.17.31 eingeführt. Die Staked Connections von Helius übernehmen diesen Vorteil bei der Aufnahmerate, indem sie Kundentransaktionen über Solanas größten Validator weiterleiten. So profitieren Aufrufer von SWQoS, ohne selbst einen Validator mit hohem Stake zu betreiben. Weitere Informationen findest du im Blogbeitrag Stake-Weighted Quality of Service: Everything You Need to Know.Versionierte Transaktion
Ein Solana-Transaktionsformat, das durch ein Versionsbyte am Anfang der serialisierten Transaktion identifiziert wird. Version 0 (v0) führte Address Lookup Tables ein. Dadurch kann eine Transaktion auf bis zu 256 Accounts verweisen, verglichen mit ungefähr 35 bei Legacy-Transaktionen. Version 1 (v1, SIMD-0385, Agave 4.2) verschiebt Signaturen an das Ende der Transaktion und überträgt das Compute-Budget in einemtransactionConfig-Headerfeld statt in ComputeBudget-Instructions. Lege für RPC-requests maxSupportedTransactionVersion: 1 fest, um jede Version zu empfangen. Siehe Unterstützung für Transaction v1.
Token und Assets
Komprimierter Account
Ein komprimierter Account ist ein Solana-Account, dessen Daten über Transaktionsprotokolle an das Ledger gebunden werden. Im Validator-Zustand wird nur ein Hash-Fingerabdruck gespeichert, statt die vollständigen Daten in einem herkömmlichen Account-Platz auf den Datenträgern der Validatoren abzulegen. Entwickler können komprimierte Accounts wie normale Accounts behandeln. Indexer wie Photon parsen Transaktionsprotokolle, um den aktuellen Zustand zu rekonstruieren. Ein Groth16-Zero-Knowledge-Beweis mit konstanter Größe verifiziert die Integrität, wenn Accounts über ZK Compression gelesen oder geändert werden. Dieses Modell eignet sich am besten für Accounts mit kleinen Datenmengen. Bei größeren Datenmengen über ungefähr 100 Byte ist die Komprimierung unpraktisch.Komprimiertes NFT (cNFT)
Ein Solana-NFT, das als Blatt in einem nebenläufigen Onchain-Merkle-Baum statt in einem eigenen Account dargestellt wird. Der Baum befindet sich in einem Solana-Account, und das Ledger sichert seine Zustandsübergänge. Indexer leiten den aktuellen Zustand des NFT aus dem Transaktionsverlauf ab und erzeugen Merkle-Beweise, die sich anhand der Onchain-Wurzel des Baums verifizieren lassen. Zum Lesen eines cNFT ist daher ein Indexer wie die DAS API erforderlich. Das standardmäßige Solana RPC kann cNFT-Daten nicht direkt zurückgeben. Dieses Modell reduziert die Minting-Kosten gegenüber standardmäßigen NFTs um bis zu 99 %.Nebenläufiger Merkle-Baum
Eine Solana-spezifische Variante eines Merkle-Baums, bei der mehrere Schreiber den Baum im selben slot aktualisieren können, ohne die Beweise der jeweils anderen ungültig zu machen. Der Onchain-Account speichert nicht nur die aktuelle Wurzel, sondern auch einen Änderungsprotokoll-Puffer mit kürzlich gültigen Wurzeln und eine Canopy, also eine zwischengespeicherte Teilmenge der oberen Baumknoten. Dadurch können Validatoren Beweise verifizieren, die anhand einer beliebigen Wurzel erstellt wurden, die sich noch im Pufferfenster befindet. Drei Parameter definieren einen Baum: die maximale Tiefe, die die Blattanzahl auf 2^Tiefe begrenzt, die Puffergröße oder Tiefe des Änderungsprotokolls, die bestimmt, wie viele Schreibvorgänge erfolgen können, bevor ältere laufende Beweise ungültig werden, und die Canopy-Tiefe, die Onchain-Miete gegen kleinere Beweise innerhalb von Transaktionen eintauscht. Gültige Paare aus Tiefe und Puffer reichen von (3, 8) bis (30, 2048). Behalte für praktische ZusammensetzbarkeitmaxDepth − canopyDepth ≤ 10 bei.
Nebenläufige Merkle-Bäume werden vom Programm SPL Account Compression implementiert. Sie bilden die Grundlage für komprimierte NFTs, die über Metaplex Bubblegum als Blätter gemintet werden.
Weitere Informationen findest du im Blogbeitrag All You Need to Know About Compression on Solana.
Groth16
Ein zk-SNARK-Beweissystem, das unabhängig von der Komplexität der Aussage Zero-Knowledge-Beweise konstanter Größe erzeugt: 128 Byte auf der BN254-Kurve bei Verwendung von Punktkomprimierung. Die Verifizierung benötigt O(1). ZK Compression verwendet Groth16, um Gültigkeitsbeweise dafür zu erzeugen, dass ein komprimierter Account an einer bekannten Wurzel zu einem bekannten Zustand gehörte. Die geringe Beweisgröße hält Transaktionen mit komprimierten Accounts kostengünstig. Weitere Informationen findest du im Blogbeitrag Solana Builders: ZK Compression.Mint-Account
Der Onchain-Account, der die Eigenschaften eines SPL-Tokens definiert: Angebot, Dezimalstellen sowie Mint- und Freeze-Autoritäten. Die Adresse des Mint-Accounts ist der kanonische Bezeichner des Tokens, vergleichbar mit seiner „Contract-Adresse“ bei Ethereum.SPL-Token
Ein Token auf Solana, der über das Token Program der Solana Program Library (SPL) ausgegeben wird. Fungible Token wie USDC, BONK und JUP sind SPL-Token. Standardmäßige, nicht komprimierte NFTs sind ebenfalls SPL-Token und werden mit einem Angebot von 1 und 0 Dezimalstellen gemintet. SPL-Token entsprechen ungefähr ERC-20 und ERC-721 auf Ethereum. Token-2022 ist ein neueres Programm, das diese Schnittstelle um optionale Funktionen wie Übertragungsgebühren und vertrauliche Übertragungen erweitert.Zustandsbaum
Der Merkle-Baum, in dem ZK Compression die Hashes komprimierter Accounts speichert. Der Onchain-Account enthält nur die aktuelle Wurzel und minimale Metadaten. Die eigentlichen komprimierten Daten befinden sich in Transaktionsprotokollen und werden von Indexern wie Photon rekonstruiert. Programme lesen oder ändern den komprimierten Zustand, indem sie einen Gültigkeitsbeweis übergeben, der zeigt, dass der Hash des beanspruchten Account-Inhalts einem Blatt unter der aktuellen Wurzel entspricht. Weitere Informationen findest du unter ZK Compression.Token-Account
Ein Onchain-Account, der für einen bestimmten Eigentümer ein Guthaben eines bestimmten SPL-Tokens hält. Ein Wallet kann beliebige Token-Accounts besitzen. Üblicherweise wird jedoch ein Associated Token Account (ATA) verwendet, also ein vom Associated Token Account Program deterministisch abgeleiteter Token-Account für jedes Paar aus Wallet und Mint.Token-2022 (Token-Erweiterungen)
Eine Variante des SPL Token Program, die optionale Erweiterungen unterstützt, etwa Übertragungsgebühren, vertrauliche Übertragungen, verzinsliche Token und nicht übertragbare Token. Token-2022 läuft als separates Onchain-Programm mit eigener Programm-ID. Es wurde jedoch als kompatibler Nachfolger des klassischen Token Program entwickelt, sodass SDKs normalerweise beide verarbeiten können. Mints müssen unter dem Token-2022-Programm erstellt werden, um Erweiterungen zu verwenden. Weitere Informationen findest du im Blogbeitrag What are Token Extensions?.Gültigkeitsbeweis
Ein Groth16-Zero-Knowledge-Beweis konstanter Größe, der zeigt, dass der beanspruchte Inhalt eines komprimierten Accounts an einer bestimmten Wurzel im Zustandsbaum existierte. ZK Compression-Programme verlangen bei jedem Lesen oder Ändern komprimierter Accounts einen Gültigkeitsbeweis. Damit kann das Programm einen Offchain-Zustand verifizieren, ohne dass der Validator die Daten Onchain speichern muss. Photon stellt Aufrufern Gültigkeitsbeweise über seine RPC-MethodegetValidityProof bereit.
Gültigkeitsbeweise unterscheiden ZK Compression von komprimierten NFTs. cNFTs verwenden einfache Merkle-Beweise, also eine Liste von Geschwister-Hashes vom Blatt bis zur Wurzel, die mit der Baumtiefe wächst. Der ZK-Beweis konstanter Größe von ZK Compression legt dagegen weder den Pfad noch den umgebenden Baumzustand offen.
Weitere Informationen findest du im Blogbeitrag Solana Builders: ZK Compression.
ZK Compression
ZK Compression ist ein von Helius und Light Protocol entwickelter Solana-Grundbaustein, der die Onchain-Speicherkosten drastisch reduziert. Er bindet Account-Daten an Transaktionsprotokolle im Ledger und speichert nur einen Hash-Fingerabdruck im Validator-Zustand. Zero-Knowledge-Beweise mit konstanter Größe, die Groth16 aus indexierten Transaktionsdaten erzeugt, bewahren die kryptografische Integrität. Dieser Grundbaustein unterscheidet sich von komprimierten NFTs, die nebenläufige Merkle-Bäume ohne Zero-Knowledge-Beweise verwenden. Weitere Informationen findest du unter ZK Compression und im Blogbeitrag Solana Builders: ZK Compression.Konnektivität und Streaming
Geyser
Solanas Plugin-System streamt Zustandsänderungen von Validatoren — Accounts, Transaktionen, slots und Blöcke — in Echtzeit an externe Systeme. Validatoren laden Geyser-Plugins als dynamische Bibliotheken. Das Plugin empfängt Zustandsaktualisierungen, während der Validator sie verarbeitet. Dadurch musst du RPC nicht auf Änderungen abfragen. Yellowstone gRPC — das vorherrschende Geyser-Plugin — stellt diese Aktualisierungen über gRPC bereit. Helius’ LaserStream implementiert die Yellowstone-gRPC-Schnittstelle und bietet zusätzliche Funktionen wie die historische Wiedergabe (bis zu ~48 Stunden, ~691.200 slots bei aktueller Netzwerkgeschwindigkeit) und regionsübergreifendes Failover.gRPC
gRPC ist ein universelles, leistungsstarkes binäres RPC-Protokoll. Der Name ist ein rekursives Akronym für „gRPC Remote Procedure Call“. Im Solana-Kontext bezeichnet „gRPC“ normalerweise Yellowstone gRPC, eine Streaming-Schnittstelle auf Basis des Geyser-Plugin-Systems von Solana, die Aktualisierungen zu Accounts und Transaktionen über gRPC bereitstellt. Der Dienst LaserStream von Helius basiert auf einer Yellowstone-Schnittstelle und ergänzt Funktionen wie historische Wiedergabe, regionsübergreifende Ausfallsicherheit und verwaltete Infrastruktur.RPC
RPC steht für Remote Procedure Call. Das ist ein allgemeines Muster, um eine Servermethode wie eine lokale Funktion aufzurufen. Bei Solana bezeichnet „RPC“ meistens einen RPC node. Dieser node verfolgt den Zustand von Solana, nimmt aber nicht am Konsens teil. Er ist darauf spezialisiert, Daten-requests wie Account-Zustände, Transaktionsverläufe und Transaktionsübermittlungen über eine JSON-RPC-Schnittstelle zu verarbeiten. Validatoren erzeugen dagegen Blöcke und stimmen über sie ab. Der RPC-Dienst von Helius ist eine global verteilte Flotte von RPC nodes, die für Produktionsworkloads optimiert ist. Eine ausführliche Erklärung findest du im Blogbeitrag Solana Nodes — A Primer on Solana RPCs, Validators, and RPC Providers.Webhook
Ein webhook ist ein HTTP-POST-request, den ein Server beim Eintreten eines abonnierten Ereignisses an eine Empfänger-URL sendet. Es handelt sich um „umgekehrtes“ HTTP, bei dem der Server den Aufruf initiiert. Helius Webhooks senden Solana-Onchain-Ereignisse wie Übertragungen, NFT-Verkäufe und benutzerdefinierte Programmaktivitäten an einen registrierten endpoint. Dadurch entfällt wiederholtes Abfragen.WebSocket (WSS)
Ein WebSocket ist eine persistente bidirektionale TCP-Verbindung, die aus HTTP aktualisiert wurde. Sie dient dem Push-basierten Streaming von Solana-Daten ohne wiederholte HTTP-requests. WSS (WebSocket Secure) ist dasselbe Protokoll über TLS und wird für Solana-Produktionsverbindungen verwendet. LaserStream WebSocket, das WebSocket-Streaming-Produkt von Helius mit den standardmäßigen Solana-Methoden und Helius-Erweiterungen wietransactionSubscribe, verwendet WSS.
Ökosystem
Anchor
Anchor ist ein Rust-Framework zum schnellen und sicheren Erstellen von Solana-Programmen. Es verarbeitet mit prozeduralen Makros Standardcode für Account-Serialisierung, Validierung und Instruction-Dispatch. So können sich Entwickler auf die Programmlogik statt auf Details auf niedriger Ebene konzentrieren. Die meisten Solana-Entwickler verwenden Anchor, statt Programme in nativem Rust zu schreiben. Eine ausführliche Erklärung findest du im Blogbeitrag An Introduction to Anchor: A Beginner’s Guide to Building Solana Programs.IDL
IDL steht für Interface Definition Language. Eine IDL ist ein JSON-Schema, das die Instructions, Accounts und Datentypen eines Solana-Programms beschreibt. Clients verwenden es, um Transaktionen zu erstellen und Programmdaten zu decodieren, ohne Instruction-Layouts manuell zu implementieren. Anchor erzeugt IDLs automatisch und veröffentlicht sie standardmäßig Onchain in einem eigenen Account, damit sie öffentlich auffindbar sind.Jito
Ein Unternehmen im Solana-Ökosystem, das die führende Block Engine des Netzwerks betreibt. Diese MEV-Infrastrukturschicht für maximal extrahierbaren Wert akzeptiert Transaktionspakete, also atomare Gruppen von Transaktionen, die entweder gemeinsam oder gar nicht ausgeführt werden. Suchende können Validatoren Trinkgelder zahlen, um die Aufnahme dieser Pakete zu priorisieren. Der Validator-Client Jito-Solana ist ein Fork von Agave mit integrierter Block Engine. Für die Aufnahme eines Pakets ist ein Trinkgeld von mindestens 10.000 Lamports erforderlich. Der Jito-Relayer hält eingehenden Datenverkehr ungefähr 200 ms zurück, um die Offchain-Auktion der Pakete zu ermöglichen. Sender von Helius übermittelt Transaktionen gleichzeitig über Staked Connections und die Block Engine von Jito. Verwendet wird der Pfad, über den die Transaktion zuerst aufgenommen wird. Weitere Informationen findest du im Blogbeitrag Solana MEV: An Introduction.Light Protocol
Das Solana-Protokollteam, das ZK Compression gemeinsam mit Helius entwickelt hat. Helius entwickelte den kanonischen Indexer Photon und betreibt das öffentliche RPC. Light Protocol entwickelt die Onchain-Programme und den Beweis-Stack, von denen der Indexer abhängt. Siehe github.com/Lightprotocol/light-protocol.Photon
Der von Helius entwickelte Open-Source-Indexer für ZK Compression. Daten komprimierter Accounts befinden sich in Solana-Transaktionsprotokollen statt im Account-Zustand. Validatoren stellen sie daher nicht über das standardmäßige RPC bereit. Photon parst Solana-Transaktionen, rekonstruiert den Zustand komprimierter Accounts und stellt ihn über eine JSON-RPC-Schnittstelle bereit. Diese bildet Solanas natives RPC ab und ergänzt ZK-Compression-spezifische Methoden wiegetCompressedAccount und getValidityProof. Entwickler können Photon über github.com/helius-labs/photon selbst hosten oder den gehosteten Helius-endpoint verwenden.
Weitere Informationen findest du unter ZK Compression.