- Helius-Produkte & Plattform
- Solana-Grundlagen
- Transaktionsmechanik
- Token & Assets
- Konnektivität & Streaming
- Ökosystem
Helius-Produkte und Plattform
Autoscaling
Helius’ automatische Mechanismus zur Guthaben-Aufstockung für Fiat-Pläne. Wenn das monatliche Guthaben aufgebraucht ist, kauft das Autoscaling zusätzliche Guthaben bis zu einem benutzerdefinierten Limit, um429 Fehler zu vermeiden, die den Produktionsverkehr unterbrechen. Kryptoplanen haben kein Autoscaling. Stattdessen verwenden sie Vorausbezahlte Guthaben, die manuell gekauft werden.
Siehe Autoscaling.
Credit
Die Einheit, in der Helius die Nutzung von API und Streaming berechnet. RPC-Methoden, DAS-Aufrufe und der Streaming-Durchsatz haben jeweils einen spezifischen Guthabenkosten. Jeder Plan beinhaltet ein monatliches Guthaben, das bei jedem Abrechnungszyklus zurückgesetzt wird (nicht genutztes Guthaben wird nicht übertragen). Siehe Credits für die vollständige Kostentabelle.DAS API
Digital Asset Standard — eine offene Spezifikation für eine einheitliche Schnittstelle für Solana-Digital-Assets (NFTs, komprimierte NFTs, fungible Tokens). Die DAS-API-Implementierung von Helius liefert angereicherte Metadaten, Eigentum und Preise in einer einzigen strukturierten Antwort, was die Notwendigkeit benutzerdefinierter Parser über Onchain-Asset-Daten eliminiert. Siehe DAS API.Dedizierte Nodes
Private Helius-RPC-Nodes ohne Geschwindigkeitsbegrenzungen oder Guthabenmessung, die zu einem festen monatlichen Preis abgerechnet werden. Sie eignen sich für spezielle Anwendungsfälle, die unbegrenzten Durchsatz benötigen; die meisten Anwendungen sind mit regulären Helius-RPCs besser bedient, aufgrund überlegener Leistung, Ausfallsicherheit und Funktionsabdeckung. Siehe Dedizierte Nodes.Verbesserte Transaktionen
Die analysierte Transaktions-API von Helius, die rohe Solana-Transaktionen in lesbare Ereignisse dekodiert — Token-Übertragungen, NFT-Verkäufe, Swaps, Staking-Operationen und mehr — ohne die Notwendigkeit von per-Programm-Befehl-Parser. Siehe Verbesserte Transaktionen.Fehlercodes
Standard-HTTP-Statuscodes, die von Helius-APIs zurückgegeben werden, mit Helius-spezifischem Kontext:400 Bad Request— ungültige Parameter oder fehlerhafte Anfrage (z. B. ungültiges Adressformat, fehlende erforderliche Felder, fehlerhaftes JSON)401 Unauthorized— fehlender oder ungültiger API-Schlüssel403 Forbidden— Zugriff verweigert, typischerweise aufgrund von IP-Einschränkungen, einem Abonnement, das den Endpunkt nicht enthält, oder unzureichenden API-Schlüsselberechtigungen404 Not Found— keine Daten verfügbar für die angeforderte Ressource (normal bei Identitätssuchen unbekannter Wallets)429 Too Many Requests— Guthaben aufgebraucht, Geschwindigkeitsbegrenzung überschritten oder gleichzeitiges Anfrage-Limit erreicht5xx— Probleme auf Helius-Seite; erneuter Versuch mit exponentiellem Backoff
Gatekeeper
Helius’ Edge-Gateway, das erheblich niedrigere Latenz als Standard-RPC-Aufrufe bietet, indem Anfragen durch eine weltweit verteilte Proxy-Flotte geleitet werden. Zugriff durch Ersetzen vonmainnet.helius-rpc.com durch beta.helius-rpc.com in der RPC-URL.
Siehe Gatekeeper und den Einführung Gatekeeper Blogbeitrag für architektonischen Hintergrund.
LaserStream
Helius’ hochleistungsfähiger gRPC-Streaming-Service für Solana-Onchain-Daten mit historischem Replay, Multi-Region-Ausfallsicherheit und dem umfangreichsten Funktionsumfang unter den Helius-Streaming-Produkten. Offizielle SDKs sind für JavaScript/TypeScript, Rust und Go verfügbar. LaserStream WebSocket läuft auf derselben Infrastruktur. Siehe LaserStream und den LaserStream SDK-Performance-Blogbeitrag für einen tiefen Einblick in SDK-Benchmarks.LaserStream WebSocket
Helius’ persistenter WebSocket-Streaming-Service. Er bedient sowohl die Standard-Solana-WebSocket-Methoden als auch Helius-spezifische Erweiterungen (transactionSubscribe und ein erweiterter accountSubscribe mit reichhaltigerem Filtern) an einem einzigen, einheitlichen Endpunkt. LaserStream WebSocket teilt sein Backend mit LaserStream gRPC.
Siehe LaserStream WebSocket.
Prekonfirmationen
Das Transaktionssignal von Helius mit der niedrigsten Latenz. Streams Transaktionen, bevor sie in Einträge gesammelt und zerfetzt werden: Helius Prekonfirmationen im Moment, in dem sie vom Leader ausgeführt werden, zusammen mit ihrem Ausführungsstatus, und BAM Prekonfirmationen, wenn der Validator sich verpflichtet, sie auszuführen, bevor sie ausgeführt werden. Früher als Shred Delivery und früher als verarbeitete Verpflichtungsstreams. Geliefert über einpreconfSubscribe WebSocket-Abonnement. Erfordert einen Professional-Plan oder höher; abgerechnet mit 10 Credits pro Nachricht. Die Abdeckung hängt davon ab, welche Validatoren ihren Stream an Helius weiterleiten, sodass der Feed nicht kontinuierlich ist.
Siehe Prekonfirmationen und preconfSubscribe.
Prioritätsgebühren-API
Helius’ Gebührenschätzendpunkt, der empfohlene Prioritätsgebührenwerte basierend auf Echtzeit-Onchain-Gebührmärkten zurückgibt. Ermöglicht wettbewerbsfähige Gebühren, ohne während der Überlastung zu raten oder zu überzahlen. Siehe Prioritätsgebühren-API.Geschwindigkeitsbegrenzung
Die maximal erlaubten Anfragen pro Sekunde unter einem bestimmten Helius-Plan. Geschwindigkeitsbegrenzungen variieren je nach Planstufe und API-Familie (Standard-RPC, erweiterte APIs, Streaming). Bei Überschreitung wird429 Too Many Requests zurückgegeben.
Siehe Geschwindigkeitsbegrenzungen.
Sender
Helius’ spezialisierter Transaktionsabwicklungsdienst für Händler mit niedriger Latenz, der Prioritätsgebühren, Jito-Tipps und geroutete Verbindungen nutzt, um die Transaktionsraten zu maximieren. Verfügbar unterhttps://sender.helius-rpc.com/fast.
Siehe Sender.
Shred Delivery
Helius’ Dienst zum Streaming roher Solana-Shreds über UDP, geliefert vor der finalen Blockzusammenstellung. Helius aggregiert Shreds aus einem verteilten Netzwerk von Validatoren über Regionen, um die geographische Latenzvarianz eines einzelnen Validators zu minimieren. Nützlich für Hochfrequenzhandel, Arbitrage und andere Anwendungen mit niedriger Latenz. Roh-Shreds sind selbstbedienbar im Helius Dashboard verfügbar - 800/Monat pro IP auf Pro-Plänen). Siehe Shred Delivery und den Blogbeitrag Gewinnen im Millisekundenspiel: Shreds, LaserStream und der Rand von Solana für einen tiefen Einblick, wie Shreds funktionieren.Gestakete Verbindungen
Der Standard-Transaktionseinreichungsweg für bezahlte Helius-Pläne. Gestakete Verbindungen leiten Transaktionen zu den kommenden Blockleadern über Solanas Protokoll-Level Stake-Weighted Quality of Service (SWQoS), das bevorzugte Verbindungsslots basierend auf dem Validator-Stake gewährt und Paketverluste während der Überlastung reduziert. Helius’ bezahlte Pläne erben diesen Eingangsratevorteil, ohne dass Anrufer selbst einen stark gestaketen Validator betreiben müssen. Siehe Transaktionen optimieren und den Blogbeitrag Stake-Weighted Quality of Service: Alles, was Sie wissen müssen.Wallet API
Helius’ REST-API zum Abfragen des Guthabens, der Transaktionshistorie, der Übertragungen, der Identität und der Finanzierungsquelle einer Solana-Wallet — strukturierte, USD-bepreiste Antworten statt rohe RPC-Ausgabe. Es akzeptiert SNS.sol und ANS Domain-Namen zusätzlich zu Adressen.
Siehe Wallet API.
Solana-Grundlagen
Konto
Ein Container, der Daten dauerhaft auf Solana speichert und durch einen 32-Byte-öffentlichen Schlüssel identifiziert wird. Alle Onchain-Zustände — Benutzerkonten, Programmcodes, Token-Metadaten — befinden sich in Konten, einschließlich der Programme selbst. Jedes Konto hat einen Eigentümer, der ein Programm ist, das seine Daten ändern oder Lamports abziehen kann, und muss ein Mindest-SOL-Guthaben (mietfrei) aufrechterhalten, um zu bestehen. Siehe den Blogbeitrag Das Solana-Programmiermodell: Eine Einführung in die Entwicklung auf Solana für einen tieferen Einblick.Agave
Der aktuelle kanonische Solana-Validator-Client, gepflegt von Anza — der umbenannte Nachfolger des ursprünglichen Solana Labs-Clients. Referenzen auf spezifische Agave-Veröffentlichungen (z. B. die v1.17.31 SWQoS Mindeststakethresholf) binden typischerweise das Verhalten an eine bestimmte Version des Clients. Jito-Solana ist ein Fork von Agave mit ihrem Block-Engine integriert; Firedancer ist eine unabhängige C-basierte Alternative, die von Jump Crypto entwickelt wurde. Siehe den Blogbeitrag Solana Virtual Machine für das SVM-Modell, das Agave implementiert.Airdrop
Eine Zuwendung von SOL- oder SPL-Tokens an eine Adresse. Auf Devnet und Testnet bezieht sich ein Airdrop typischerweise auf eine kleine Menge Test-SOL von einem Wasserhahn, das zur Finanzierung von Entwicklungskonten verwendet wird; auf Mainnet bezieht es sich auf Massenverteilungen von Token an bestehende Inhaber. Devnet-Airdrops sind über den Devnet-Wasserhahn verfügbar.Zugewiesenes Token-Konto (ATA)
Ein deterministisch abgeleitetes Token-Konto, das ein bestimmtes SPL-Token für eine gegebene Wallet-Adresse hält. Jede Wallet hat höchstens ein ATA pro Token-Mint, was ATAs zum kanonischen Ort macht, um das Token-Guthaben eines Nutzers nachzuschlagen. Es wird mithilfe der Wallet-Adresse und des Token-Mints als Seeds abgeleitet.Block
Eine Datenstruktur, die eine Menge von Transaktionen plus essenziellen Metadaten enthält — einschließlich des Hashs des Blocks und des vorherigen Blocks, der eine unveränderliche Kette bildet. Blöcke werden während Slots produziert: Der zugewiesene Leader für einen Slot validiert eingehende Transaktionen, verpackt sie in einen Block und sendet den Block über Turbine über das Netzwerk. Nicht jeder Slot produziert einen Block — wenn der Leader es nicht rechtzeitig schafft, wird der Slot übersprungen und das Netzwerk geht weiter. Sobald ein Block eine Supermehrheit der stake-gewichteten Validator-Stimmen erreicht hat, gilt er als bestätigt (siehe Verpflichtungslevel). Siehe den Blogbeitrag Verstehen von Slots, Blöcken und Epochen auf Solana für einen tieferen Einblick.Verpflichtungslevel
Das Maß an Vertrauen, dass eine Transaktion in die Blockchain aufgenommen wurde:processed— vom aktuellen Leader gesehen, aber noch nicht abgestimmt; kann noch verworfen werden, wenn der Block den Konsens verliert (~0,4s)confirmed— ≥66% stake-gewichtete Validierungsstimmen zum Block; historisch wurde kein bestätigter Block zurückgezogen (~0,6s)finalized— der Block hat ≥66% Stimmen plus 31 nachfolgende Blöcke, die darauf gebaut werden (d. h. die Tower BFT maximale Sperrung), was ihn effektiv irreversibel macht (~13s)
confirmed wird als Standardeinstellung empfohlen. Verwenden Sie processed für UI-Feedback, finalized für hochkarätige Operationen wie Umtausch-Einzahlungen oder Kettenübergreifende Brücken. Blockhashes, die bei finalized abgerufen werden, laufen schneller ab als solche bei confirmed, wodurch das Fenster vor dem Ablauf der Transaktion verkleinert wird.
Siehe den Blogbeitrag Was sind Solana-Verpflichtungslevel? für einen tieferen Einblick.
Recheneinheiten (CU)
Solas Messgröße für die von einer Transaktion erbrachte Rechenarbeit, analog zum Gas auf Ethereum. Jede Transaktion gibt ein Limit für Recheneinheiten und einen Preis pro Recheneinheit an (Prioritätsgebühr in Mikrolamports pro CU); das Produkt bestimmt die Gesamtkosten der Prioritätsgebühr. Überschreitung des Limits führt zum Fehlschlagen der Transaktion.CPI (Cross-Program Invocation)
Ein Mechanismus von Solana, der es einem Onchain-Programm ermöglicht, ein anderes aufzurufen, indem es Konten und Befehl-Daten übergibt — das Grundprinzip, das Solanas Komponierbarkeit ermöglicht. CPIs werden über dassol_invoke_signed Syscall bereitgestellt, das überprüft, ob der Anrufer die entsprechenden Berechtigungen für die übergebenen Konten hat; PDAs lassen Programme im Namen der von ihnen kontrollierten Konten unterschreiben.
Ein aufgerufenes Programm arbeitet innerhalb des verbleibenden Recheneinheitenkontingents des aufrufenden Programms: Wenn es das Kontingent überschreitet oder ein festgelegtes Limit überschreitet, schlägt die gesamte Kette von Aufrufen fehl — einschließlich der ursprünglichen Transaktion.
Siehe den Blogbeitrag Solana Virtual Machine für einen tieferen Einblick.
Epoche
Ein Cluster von etwa 432.000 Solana-Slots — das übergeordnete organisatorische Intervall, in dem Solana sein Validatorenset, den Führungzeitplan, die Stake-Delegationen und die Belohnungsverteilungen aktualisiert. Jede Epoche dauert ~2 Tage beim aktuellen Slot-Ziel. Siehe den Blogbeitrag Verstehen von Slots, Blöcken und Epochen auf Solana für einen tieferen Einblick.Firedancer
Ein zweiter unabhängiger Solana-Validator-Client, der von Grund auf in C von Jump Crypto geschrieben wurde. Die erklärten Ziele von Firedancer sind (1) die Dokumentation und Standardisierung des Solana-Protokolls durch eine unabhängige Implementierung, (2) die Verbesserung der Client-Diversität (kein einzelner Client kontrolliert >33% des Stakes) und (3) die Steigerung der Leistung des Ökosystems. Die Architektur ist modular: viele spezialisierte Linux-Prozesse, die als “Tiles” bezeichnet werden (QUIC Tile, Verify Tile usw.), kommunizieren über gemeinsam genutzten Arbeitsspeicher, im Gegensatz zu Agaves Ein-Prozess-Design. Frankendancer ist ihre hybride Zwischenlösung — Firedancers leistungsstarke C-Netzwerkcode gepaart mit Agaves Rust-Laufzeit und Konsenscode. Siehe den Blogbeitrag Was ist Firedancer? für einen tieferen Einblick.Befehl
Die kleinste Arbeitseinheit innerhalb einer Solana-Transaktion — ein einzelner Programmaufruf mit den relevanten Konten und Daten. Eine Transaktion bündelt ein oder mehrere Befehle, die atomar ausgeführt werden (alle gelingen oder alle werden zusammen rückgängig gemacht). Siehe den Blogbeitrag Das Solana-Programmiermodell: Eine Einführung in die Entwicklung auf Solana für einen tieferen Einblick.Lamport
Die kleinste Einheit von SOL: 1 SOL = 1.000.000.000 Lamports (10⁻⁹ SOL), benannt nach Leslie Lamport, dem Turing Award-Gewinner für grundlegende Arbeiten in verteilten Systemen. Rohe Solana-RPC-Methoden geben Guthaben und Gebühren in Lamports zurück; Helius’ Wallet API behandelt die Umrechnung automatisch. Prioritätsgebühren werden in Mikrolamports angegeben — ein Millionstel eines Lamports (10⁻¹⁵ SOL).Leader / Leader Zeitplan
Der Leader ist der Validator, der während eines bestimmten Slots dazu bestimmt ist, einen neuen Block vorzuschlagen. Leaders werden durch einen stake-gewichteten zufälligen Zeitplan ausgewählt, der zu Beginn jeder Epoche berechnet wird, sodass jeder Validator unabhängig ableiten kann, wer während des kommenden ~2-3 Tage Fensters führen wird. Jeder Leader wird vier aufeinanderfolgende Slots zugewiesen (~1,6 Sekunden bei ~400 ms pro Slot), was ihnen ein kurzes Zeitfenster für aufeinanderfolgende Blockproduktionen gibt. Wenn ein Leader es versäumt, einen Block in seinem Slot zu produzieren, wird der Slot übersprungen — das Netzwerk geht weiter, anstatt auf den fehlenden Block zu warten. Dienste zum Senden von Transaktionen wie Sender leiten signierte Transaktionen an den aktuellen Leader und die nächsten beiden Leader, um die Wahrscheinlichkeit der Landung zu maximieren. Siehe den Blogbeitrag Konsens auf Solana: Tower BFT und Proof of History für einen tieferen Einblick.Merklebaum
Eine kryptografische Baumstruktur, bei der jeder Nicht-Blatt-Knoten ein Hash seiner Kinder ist, sodass der einzelne Wurzel-Hash das gesamte Dataset bindet. Die Überprüfung, dass ein Datenstück zum Baum gehört, erfordert nur die Sibling-Hashes entlang des Pfades vom Blatt zur Wurzel — ein Merkle-Nachweis — der O(log n) Daten unabhängig von der Baumgröße enthält. Für einen Baum der Tiefe 26 ist dieser Nachweis 26 Sibling-Hashes (~832 Byte), der klein, aber dennoch pro Blatt ist: dies ist die Nachweisform, die von komprimierten NFTs verwendet wird. ZK-Komprimierung ersetzt ihn durch einen einzigen Konstanten-Größen-Nachweis Validity Proof, der nicht mit dem Dataset wächst. Siehe den Blogbeitrag Kryptografische Werkzeuge 101: Hash-Funktionen und Merkle-Bäume erklärt.Programm
Ein ausführbares Konto, das kompilierten sBPF-Bytecode enthält (d. h. ein Smart Contract auf Solana). Programme sind zustandslos — sie lesen und schreiben auf Datenkonten, die sie besitzen, und werden durch eine Programm-ID identifiziert (ihre 32-Byte-Adresse). Solana wird mit einer Reihe von nativen Programmen geliefert (System, Stake, Vote usw.), die in die Laufzeit integriert sind; alles andere ist ein benutzerbereitgestelltes Programm. Siehe den Blogbeitrag Das Solana-Programmiermodell: Eine Einführung in die Entwicklung auf Solana für einen tieferen Einblick.Program Derived Address (PDA)
Eine deterministische Adresse, die von einer Programm-ID und einer Reihe von Seeds abgeleitet wird. PDAs lassen Programme im Namen der von ihnen kontrollierten Konten unterschreiben, was sie für den Entwurf zustandsbehafteter Programme unerlässlich macht. PDAs sind absichtlich außerhalb der Kurve, sodass kein privater Schlüssel für sie existiert.Proof of History (PoH)
Solanas Synchronisationsprimitive — kein Konsensalgorithmus. PoH bietet eine kryptografische Zeitstempelfunktion, die es Validatoren ermöglicht, sich auf die Reihenfolge der Ereignisse zu einigen, ohne miteinander kommunizieren zu müssen. Implementierung: eine sequentielle SHA-256-Hash-Kette, die kontinuierlich auf einem einzigen CPU-Kern pro Validator läuft, wobei jede Iteration ihre Ausgabe als Eingabe der nächsten Iteration verwendet. Die Erzeugung ist sequenziell und einkernig; die Überprüfung ist parallelisierbar. PoH bietet die “Ticks”, die definieren, wann ein Block gültig ist. Leaders müssen Blöcke innerhalb eines bestimmten PoH-Tickbereichs veröffentlichen — ein Block außerhalb des Bereichs gilt als übersprungen. PoH läuft parallel zu Tower BFT, dem eigentlichen Konsensmechanismus. Siehe den Blogbeitrag Proof of History, Proof of Stake, und Proof of Work erklärt für einen tieferen Einblick.Miete / Mietfrei
Das SOL-Guthaben, das jedes Solana-Konto halten muss, um dauerhaft onchain zu bleiben, skalierte auf die Größe des Kontospeichers. Konten müssen mietfrei erstellt werden: Transaktionen, die das Konto unter dem Mindestbetrag lassen würden, schlagen fehl. Einmal mietfrei, bleibt das Konto auf unbestimmte Zeit ohne weitere Zahlungen bestehen.Sealevel
Solas parallele Transaktionsausführungsengine. Im Gegensatz zu sequentiellen VMs wie der EVM führt Sealevel mehrere Transaktionen gleichzeitig über CPU-Kerne aus. Dies ist möglich, da jede Solana-Transaktion explizit deklariert, welche Konten sie lesen und schreiben wird, bevor die Ausführung beginnt, sodass der Scheduler nicht-konfliktierende Chargen ohne Laufzeitanalyse identifizieren kann. Die Scheduling-Regeln sind einfach: Transaktionen, die verschiedene Konten berühren, werden parallel ausgeführt; Transaktionen, die nur dieselben Konten lesen, werden ebenfalls parallel ausgeführt (Lesen verursacht keine Konflikte); Transaktionen, die auf dieselben Konten schreiben, werden sequentiell ausgeführt, um Wettlaufsituationen zu vermeiden. Siehe den Blogbeitrag Solana Virtual Machine für einen tieferen Einblick.Slot
Solanas grundlegende Zeiteinheit, während der ein zugewiesener führender Validator die Möglichkeit hat, einen Block zu produzieren. Slots zielen derzeit auf 400 ms ab, obwohl die tatsächlichen Dauer aufgrund der Netzwerkbedingungen variieren kann. Wenn ein Leader es versäumt, während seines Slots einen Block zu produzieren, wird der Slot übersprungen — das Netzwerk geht weiter zum nächsten Slot, anstatt zu warten, sodass nicht jeder Slot zu einem Block führt. Siehe den Blogbeitrag Verstehen von Slots, Blöcken und Epochen auf Solana für einen tieferen Einblick.SVM (Solana Virtual Machine)
Solas vollständiger Transaktionsausführungsstack — kein enger Bytecode-Interpreter. Die SVM umfasst die Bankkomponente, die die Ausführung orchestriert, den Scheduler der Banking Stage, BPF-Loader und die sBPF virtuelle Maschine selbst (eine registerbasierte VM mit 11 Generalzweck-Registern und ~100 Opcodes, JIT-kompiliert für Leistung). Dies ist unverwechselbar vom EVM, der unzweideutig auf einen einzigen Bytecode-Executor verweist. Solana-Programme kompilieren zu sBPF, Solanas Fork von Linux eBPF. Jede Sprache mit einem LLVM-Frontend (C, C++, Rust, Zig) kann sBPF anvisieren. Transaktionen müssen vorab deklarieren, auf welche Konten sie zugreifen, was die parallele Ausführung von Sealevel und Solanas lokalisierte Gebührenmärkte freischaltet. Siehe den Blogbeitrag Solana Virtual Machine für einen tieferen Einblick.Tower BFT
Solas Konsensmechanismus. Tower BFT ist ein pBFT-ähnlicher Algorithmus, der Proof of Historys synchronisierte Uhr nutzt und die Notwendigkeit für synchrone Konsensrunden in jedem Slot eliminiert. Validatoren bauen einen “Abstimmungsturm” — einen sequentiellen Stapel von Abstimmungen, bei dem jede neue Abstimmung die Sperrzeit aller vorherigen Abstimmungen verdoppelt, um die stake-Verlustkosten des Fork-Wechsels exponentiell zu erhöhen. Bestätigungsschwellen: Ein Block ist bestätigt, sobald ≥2/3 der stake-gewichteten Stimmen auf ihn abgegeben wurden (≥4,6% der gesamten Stakes müssten abgeschrieben werden, um die Finalität zu verletzen). Ein Block ist finalisiert, sobald er Stimmen plus 31 nachfolgende Blöcke darauf hat, die Tower BFT maximale Sperrung. Siehe Verpflichtungslevel für Nutzungsempfehlungen. Siehe den Blogbeitrag Konsens auf Solana: Tower BFT und Proof of History für einen tieferen Einblick.Turbine
Solanas Block-Propagationsprotokoll. Der Leader teilt jeden Block in MTU-große Shreds plus Reed-Solomon-Erasure-codierte Wiederherstellungs-Shreds — die FEC-Rate (normalerweise 32:32) ermöglicht es dem Netzwerk, einen Block selbst bei ~33% Paketverlust wiederherzustellen. Der Leader leitet dann Shreds über einen deterministischen stake-gewichteten Baum von Peer-Validatoren weiter (pro Shred-Gruppe basierend auf(leader id, slot, shred index, shred type) gesät), anstatt den vollständigen Block direkt an jeden Validator zu senden. Der Baum (DATA_PLANE_FANOUT = 200) hält die ausgehende Bandbreite des Leaders ungefähr konstant, unabhängig von der Anzahl der Validatoren, und lässt Blöcke das Netzwerk in 2–3 Hops erreichen, anstatt O(n).
Siehe den Blogbeitrag Turbine: Block-Propagation auf Solana.
Validator
Ein Node im Solana-Netzwerk, der am Konsens teilnimmt, indem er während seiner zugewiesenen Leader-Slots Blöcke produziert und über Blöcke anderer Validatoren abstimmt. Validatoren werden für Leader-Slots proportional zu ihrem aktiven Stake ausgewählt.Transaktionsmechanik
Address Lookup Table (ALT)
Eine Onchain-Tabelle von Solana-Adressen, auf die eine versionierte Transaktion mit einem 1-Byte-Index anstelle eines vollständigen 32-Byte-Pubkeys verweisen kann, sodass eine einzelne Transaktion bis zu 256 Konten referenzieren kann. ALTs sind unerlässlich für komplexe DeFi-Operationen, die ansonsten die Transaktionsgrößenlimits überschreiten würden.Blockhash
Ein 32-Byte-Hash, der einen kürzlich erfolgten Block identifiziert und in jeder Solana-Transaktion enthalten ist, um Frische zu beweisen. Blockhashes laufen nach ~150 Slots ab (~1 Minute); Transaktionen mit abgelaufenen Blockhashes werden abgelehnt. Clients rufen einen aktuellen Blockhash übergetLatestBlockhash ab, kurz bevor sie signieren.
Prioritätsgebühr
Ein pro-Recheneinheit-Trinkgeld, das an Validatoren gezahlt wird, um einer Transaktion Vorrang vor anderen zu geben und ihre Zeit bis zur Inklusion zu verbessern. Prioritätsgebühren werden in Mikrolamports pro Recheneinheit (µLamports/CU) festgelegt. Helius’ Prioritätsgebühren-API gibt Echtzeitschätzungen basierend auf den jüngsten Onchain-Gebührmärkten zurück.Shred
Die kleinste Einheit eines Solana-Blocks. Blöcke werden (d. h. geschreddert) in Shreds aufgeteilt, um parallel über das Validatornetzwerk via Turbine propagiert zu werden. Zugriff auf Shred-Ebene gibt Händlern ultra-niedrige Latenz-Onchain-Signale, vor der Blockzusammenstellung — obwohl Prekonfirmationen noch früher ankommen, bevor die Einträge zerfetzt werden. Siehe Roh-Shreds (UDP) und die Shred Delivery Übersicht.Stake-Weighted Quality of Service (SWQoS)
Ein Protokoll-Level-Mechanismus von Solana, der eingehende Transaktionen zu den aktuellen und kommenden Leadern basierend auf dem Stake des Senders priorisiert. Eingeführt nach dem Ausfall von Solana am 30. April 2022, um eine Sybil-Resistance-Maßnahme zu sein, verhindert SWQoS, dass Peers mit niedrigem Stake oder ungestakete Peers während der Überlastung die Bandbreite des Leaders monopolisieren. Der Leader stellt zwei eingehende Verbindungspools bereit: ~500 offene Verbindungen, die über alle ungestaketen Peers geteilt werden, und ~2.000 stake-gewichtete Verbindungen, die proportional zu den gestaketen Validatoren verteilt sind — ein Validator, der X% des gesamten aktiven Stakes hält, kann bis zu X% der Pakete an den Leader senden. Validatoren unter ~15.000 SOL aktivem Stake (~1/25.000 des gesamten Netzwerk-Stakes) werden als ungestaket behandelt. Der Mindeststakethreshold wurde in Agave v1.17.31 festgelegt. Helius’ Gestakete Verbindungen erben diesen Eingangsratevorteil, indem sie Kunden-Transaktionen durch Solanas größten Validator leiten, sodass Anrufer von SWQoS profitieren, ohne selbst einen stark gestaketen Validator zu betreiben. Siehe den Blogbeitrag Stake-Weighted Quality of Service: Alles, was Sie wissen müssen.Versionierte Transaktion
Ein Solana-Transaktionsformat, das durch ein Versionsbyte am Beginn der serialisierten Transaktion identifiziert wird. Version 0 (v0) fügte Adressensuchtabellen hinzu, die es einer Transaktion ermöglichen, bis zu 256 Konten zu referenzieren (vs. ~35 in Legacy-Transaktionen). Version 1 (v1, SIMD-0385, Agave 4.2) verschiebt Signaturen ans Ende der Transaktion und trägt das Recheneinheitenbudget in einemtransactionConfig Kopfzeilenfeld anstelle von ComputeBudget-Befehlen. Setzen Sie maxSupportedTransactionVersion: 1 auf RPC-Anfragen, um jede Version zu empfangen. Siehe Transaktion v1 Unterstützung.
Token und Assets
Komprimiertes Konto
Ein komprimiertes Konto ist ein Solana-Konto, dessen Daten über Transaktionslogs in die Ledger eingetragen werden, wobei nur ein Hash-Fingerabdruck im Validatorzustand gespeichert wird — anstelle der vollständigen Daten, die einen traditionellen Kontenslot auf den Validatordisks beanspruchen. Entwickler können komprimierte Konten wie normale Konten behandeln; Indexer (wie Photon) analysieren Transaktionslogs, um den aktuellen Zustand zu rekonstruieren, und ein konstanter Größennachweis Groth16 überprüft die Integrität, wenn Konten über ZK-Komprimierung gelesen oder modifiziert werden. Dieses Modell eignet sich am besten für Konten mit kleinen Daten — größere Daten (über ~100 Bytes) machen die Komprimierung unpraktisch.Komprimiertes NFT (cNFT)
Ein Solana NFT, das als Blatt in einem Onchain-konkurrierenden Merklebaum dargestellt wird, anstatt ein eigenes Konto zu haben. Der Baum lebt in einem Solana-Konto, und seine Zustandsübergänge werden durch das Ledger gesichert; der aktuelle Zustand des NFTs wird aus der Transaktionshistorie abgeleitet durch Indexer, die Merkle-Nachweise erzeugen, die gegen den Onchain-Wurzel des Baums überprüft werden können. Das Lesen eines cNFT erfordert daher einen Indexer wie die DAS API — standardmäßiges Solana-RPC kann cNFT-Daten nicht direkt zurückgeben. Dieses Modell reduziert die Prägekosten um bis zu 99 % im Vergleich zu Standard-NFTs.Concurrent Merkle Tree
Eine Solana-spezifische Variante eines Merkle Tree, die es mehreren Schreibern ermöglicht, den Baum im gleichen Slot zu aktualisieren, ohne die Nachweise anderer zu ungültig machen. Der Onchain-Account speichert nicht nur die aktuelle Wurzel, sondern auch einen Änderungsprotokollpuffer von kürzlich gültigen Wurzeln und ein Vordach (einen zwischengespeicherten Teil der oberen Baumknoten), sodass Validatoren Nachweise überprüfen können, die gegen jede Wurzel im Pufferfenster generiert wurden. Drei Parameter definieren einen Baum: maximale Tiefe (begrenzt die Blattanzahl auf 2^Tiefe), Puffergröße (Änderungsprotokolllänge — wie viele Schreibvorgänge vor dem Ungültigwerden älterer ausstehender Nachweise auftreten können), und Vordachtiefe (die Onchain-Miete gegen kleinere In-Transaktions-Nachweise austauscht). Gültige (Tiefe, Puffer)-Paare reichen von (3, 8) bis (30, 2048); für praktische Komponierbarkeit halten SiemaxDepth − canopyDepth ≤ 10.
Concurrent Merkle Trees sind im SPL-Account-Komprimierungsprogramm implementiert und bilden das Substrat für komprimierte NFTs, die als Blätter über Metaplex Bubblegum gemintet werden.
Siehe den Blogbeitrag Alles, was Sie über Komprimierung auf Solana wissen müssen.
Groth16
Ein zk-SNARK-beweisendes System, das konstanze Größen-Nachweise (128 Byte auf der BN254-Kurve mit Punktkompression) unabhängig von der Komplexität der Aussage erzeugt und eine O(1)-Verifizierung bietet. ZK-Komprimierung verwendet Groth16, um Validity Proofs zu erzeugen, die zeigen, dass ein komprimiertes Konto einem bekannten Zustand an einer bekannten Wurzel angehörte — die kleine Nachweisgröße ist es, die komprimierte Kontotransaktionen günstig hält. Siehe den Blogbeitrag Solana Builders: ZK-Komprimierung.Mint-Konto
Das Onchain-Konto, das die Eigenschaften eines SPL-Tokens definiert — Angebot, Dezimalstellen und Präge-/Einfachautoren. Die Adresse des Mint-Kontos ist die kanonische Kennung des Tokens (seine “Vertragsadresse” in Ethereum-Begriffen).SPL-Token
Ein Token auf Solana, das über das Token-Programm der Solana Program Library (SPL) ausgegeben wird. Fungible Tokens (USDC, BONK, JUP usw.) sind SPL-Tokens; Standard (nicht komprimierte) NFTs sind ebenfalls SPL-Tokens, die mit dem Angebot 1 und 0 Dezimalstellen gemintet werden. SPL-Tokens entsprechen ungefähr den ERC-20 und ERC-721 auf Ethereum. Token-2022 ist ein neueres Programm, das diese Schnittstelle mit optionalen Funktionen wie Übertragungsgebühren und vertraulichen Übertragungen erweitert.Zustandsbaum
Der Merklebaum, den die ZK-Komprimierung verwendet, um die Hashes komprimierter Konten zu speichern. Das Onchain-Konto hält nur die aktuelle Wurzel plus minimalen Metadaten; die tatsächlichen komprimierten Daten befinden sich in den Transaktionsprotokollen und werden von Indexern wie Photon rekonstruiert. Programme lesen oder ändern komprimierten Zustand, indem sie einen Validity Proof übergeben, der zeigt, dass die behaupteten Inhalte des Kontos zu einem Blatt unter der aktuellen Wurzel hashieren. Siehe ZK-Komprimierung.Token-Konto
Ein Onchain-Konto, das ein Guthaben eines bestimmten SPL-Tokens für einen bestimmten Besitzer hält. Ein Wallet kann beliebige Token-Konten besitzen, aber die Konvention ist, ein Zugewiesenes Token-Konto (ATA) zu verwenden — ein deterministisch abgeleitetes Token-Konto pro (Wallet, Mint)-Paar, das durch das Zugewiesene Token-Konto-Programm erstellt wird.Token-2022 (Token-Erweiterungen)
Eine Variante des SPL-Token-Programms, die optionale Erweiterungen unterstützt (z. B. Übertragungsgebühren, vertrauliche Übertragungen, zinsbringende Token, nicht übertragbare Token). Token-2022 läuft als ein separates Onchain-Programm mit seiner eigenen Programm-ID, ist jedoch als kompatibler Nachfolger des klassischen Token-Programms konzipiert, sodass SDKs normalerweise in der Lage sind, beide zu handhaben. Mints müssen unter dem Token-2022-Programm erstellt werden, um Erweiterungen zu verwenden. Siehe den Blogbeitrag Was sind Token-Erweiterungen?.Validity Proof
Ein konstant großer Groth16 Nullwissen-Beweis, dass die behaupteten Inhalte eines komprimierten Kontos im Zustandsbaum an einer bestimmten Wurzel existierten. ZK-Komprimierung Programme erfordern einen Gültigkeitsnachweis, wann immer komprimierte Konten gelesen oder geändert werden; Der Nachweis ermöglicht es dem Programm, den Off-Chain-Zustand zu überprüfen, ohne dass der Validator die Daten Onchain speichert. Photon stellt über seinegetValidityProof RPC-Methode Gültigkeitsnachweise zur Verfügung.
Gültigkeitsnachweise sind es, die ZK-Komprimierung von komprimierten NFTs unterscheiden: cNFTs verwenden einfache Merkle-Nachweise (eine Liste von Sibling-Hashes von Blatt zur Wurzel, die mit der Baumtiefe wächst), während ZK-Komprimierungen kontinuierliche Größe von ZK Nachweis enthüllen nicht den Pfad oder den umgebenden Baumzustand.
Siehe den Blogbeitrag Solana Builders: ZK-Komprimierung.
ZK-Komprimierung
ZK-Komprimierung ist eine Solana-Primitiv, die von Helius und Light Protocol entwickelt wurde und die Onchain-Speicherkosten drastisch reduziert, indem Kontendaten in Transaktionsprotokollen im Ledger eingetragen und nur ein Hash-Fingerabdruck im Validatorzustand gespeichert wird. Die kryptografische Integrität wird durch konstant große Groth16 Nullwissen-Beweise erhalten, die aus indizierten Transaktionsdaten erzeugt werden. Dieses Primitiv unterscheidet sich von komprimierten NFTs, die konkurrierende Merkle-Bäume ohne Nullwissen-Beweise verwenden. Siehe ZK-Komprimierung und den Blogbeitrag Solana Builders: ZK-Komprimierung für einen tieferen Einblick.Konnektivität und Streaming
Geyser
Solanas Plugin-System zum Streamen von Validatorzustandsänderungen — Konten, Transaktionen, Slots, Blöcke — zu externen Verbrauchern in Echtzeit. Validatoren laden Geyser-Plugins als dynamische Bibliotheken; das Plugin empfängt Zustandsaktualisierungen, während der Validator sie verarbeitet, wodurch die Notwendigkeit entfällt, RPC für Änderungen zu pollen. Yellowstone gRPC — das dominierende Geyser-Plugin — stellt diese Updates über gRPC bereit. Helius’ LaserStream implementiert die Yellowstone gRPC-Schnittstelle mit zusätzlichen Funktionen wie historischem Replay (bis zu ~216.000 Slots / ~24 Stunden) und Multi-Region-Ausfallsicherheit.gRPC
gRPC ist ein allgemeiner, leistungsfähiger binärer RPC-Protokoll (ein rekursives Akronym für “gRPC Remote Procedure Call”). In Solana-Kontexten bezieht sich “gRPC” typischerweise auf Yellowstone gRPC — eine Streaming-Schnittstelle, die auf Solanas Geyser-Plugin-System basiert und Konto- und Transaktionsupdates über gRPC bereitstellt. Helius’ LaserStream Dienst basiert auf einer Yellowstone-basierten Schnittstelle mit zusätzlichen Funktionen wie historischem Replay, Multi-Region-Ausfallsicherheit und verwalteter Infrastruktur.RPC
RPC steht für Remote Procedure Call, ein allgemeines Muster zum Aufrufen einer Server-Methode, als wäre sie eine lokale Funktion. In Solana bezieht sich “RPC” meistens auf einen RPC-Node — ein Node, der Solanas Zustand verfolgt, aber nicht am Konsens teilnimmt und sich auf das Bedienen von Datenanfragen (d. h. Kontostand, Transaktionshistorie, Transaktionseinreichung) über eine JSON-RPC-Schnittstelle spezialisiert. Validatoren hingegen produzieren Blöcke und stimmen darüber ab. Helius’ RPC-Dienst ist eine weltweit verteilte Flotte von RPC-Nodes, die für Produktionsarbeitslasten optimiert sind. Siehe den Blogbeitrag Solana-Nodes — Eine Einführung in Solana-RPCs, Validatoren und RPC-Anbieter für einen tieferen Einblick.Webhook
Ein Webhook ist eine HTTP-POST-Anfrage, die von einem Server an eine Empfangs-URL gesendet wird, wenn ein abonniertes Ereignis eintritt — „umgekehrtes“ HTTP, bei dem der Server den Anruf initiiert. Helius Webhooks senden Solana Onchain-Ereignisse (Transfers, NFT-Verkäufe, benutzerdefinierte Programmaktionen) an einen registrierten Endpunkt und beseitigen die Notwendigkeit von Polling.WebSocket (WSS)
Ein WebSocket ist eine persistente bidirektionale TCP-Verbindung, die von HTTP aufgerüstet wird und für das Push-basierte Streaming von Solana-Daten ohne wiederholte HTTP-Anfragen verwendet wird. WSS (WebSocket Secure) ist das gleiche Protokoll, das über TLS läuft, und die Variante, die für Produktionen Solana-Verbindungen verwendet wird. LaserStream WebSocket — Helius’ WebSocket-Streamingprodukt, einschließlich der Standard-Solana-Methoden und Helius-Erweiterungen wietransactionSubscribe — verwendet WSS.
Ökosystem
Anchor
Anchor ist ein Rust-Framework zum schnellen und sicheren Erstellen von Solana-Programmen. Es behandelt Boilerplate wie Konto-Serialisierung, Validierung und Anweisungsversand durch Prozedurmakros, sodass Entwickler sich auf die Programmlogik konzentrieren können, anstatt auf niedrige Details. Die meisten Solana-Entwickler verwenden Anchor, anstatt Programme in nativem Rust zu schreiben. Siehe den Blogbeitrag Eine Einführung in Anchor: Ein Anfängerleitfaden zum Entwickeln von Solana-Programmen für einen tieferen Einblick.IDL
IDL steht für Interface Definition Language. Eine IDL ist ein JSON-Schema, das die Anweisungen, Konten und Datentypen eines Solana-Programms beschreibt; Clients verwenden sie, um Transaktionen zu konstruieren und Programmdaten zu dekodieren, ohne manuell Anweisungslayouts zu erstellen. Anchor generiert IDLs automatisch und veröffentlicht sie standardmäßig Onchain in einem dedizierten Konto zur öffentlichen Auffindbarkeit.Jito
Ein Solana-Ökosystemunternehmen, das die dominierende Blockengine des Netzwerks betreibt — eine MEV (maximal extrahierbare Wert)-Infrastruktur-Schicht, die Transaktionsbündel akzeptiert (atomare Gruppen von Transaktionen, die zusammen oder gar nicht ausgeführt werden) und es Suchern ermöglicht, Trinkgelder an Validatoren zu zahlen, um sie prioritär zu landen. Der Jito-Solana-Validator-Client ist ein Fork von Agave, mit integriertem Block-Engine. Die Bündeleinschluss erfordert ein Mindesttrinkgeld von 10.000 Lamports und der Jito-Relayer hält eingehenden Traffic für ~200 ms, um die Off-Chain-Bündel-Auktion zu ermöglichen. Helius’ Sender gibt Transaktionen sowohl über gestakete Verbindungen als auch Jitos Block-Engine gleichzeitig ab und wählt den Weg, der zuerst landet. Siehe den Blogbeitrag Solana MEV: Eine Einführung.Light Protocol
Das Solana-Protokollteam, das zusammen mit Helius ZK-Komprimierung entwickelt hat. Helius baute den kanonischen Indexer (Photon) und betreibt den öffentlichen RPC; Light Protocol erstellt die Onchain-Programme und Beweisstapel, auf die der Indexer angewiesen ist. Siehe github.com/Lightprotocol/light-protocol.Photon
Der von Helius erstellte Open-Source-ZK-Komprimierungs-Indexer. Komprimierte Kontodaten befinden sich in Solana-Transaktionsprotokollen anstatt im Kontozustand, sodass Validatoren sie nicht über Standard-RPC bereitstellen — Photon analysiert Solana-Transaktionen, rekonstruiert komprimierten Kontostand und stellt ihn über eine JSON-RPC-Schnittstelle zur Verfügung, die Solanas nativen RPC plus ZK-Komprimierung-spezifische Methoden wiegetCompressedAccount und getValidityProof widerspiegelt. Entwickler können entweder selbst hosten mit github.com/helius-labs/photon oder den gehosteten Helius-Endpunkt nutzen.
Siehe ZK-Komprimierung.