Solana
Solana ist eine quelloffene Blockchain-Plattform für dezentrale Anwendungen. Sie verbindet Proof-of-Stake-Konsens mit einer kryptografischen Uhr namens Proof of History; ihr nativer Vermögenswert ist SOL. Anatoly Yakovenko beschrieb Proof of History 2017 in einem Whitepaper. Das öffentliche Mainnet Beta nahm im März 2020 den Betrieb auf.[1][2]
Geschichte
Yakovenkos Entwurf nutzte eine fortlaufende SHA-256-Berechnung als überprüfbare Ordnungsquelle. Mit Greg Fitzgerald entstand der erste Prototyp; Stephen Akridge und Raj Gokal wirkten am späteren Solana-Projekt mit. Testnetze und das Validatorprogramm Tour de SOL gingen dem Start im März 2020 voraus. Das Netz behielt die Bezeichnung „Beta“, während Protokoll und Validatorsoftware weiterentwickelt werden.
Solana Labs entwickelte große Teile der frühen Software. Die in der Schweiz ansässige Solana Foundation unterstützt Dezentralisierung, Förderprogramme und Ökosystementwicklung. Keine der beiden Organisationen validiert allein Transaktionen; das Hauptbuch entsteht durch die Validatoren des Netzwerks.
Architektur
Proof of History und Konsens
Proof of History (PoH) ist kein eigenes Abstimmungssystem. Eine fortlaufend berechnete Sequenz belegt die zeitliche Reihenfolge von Ereignissen. Validatoren verbinden diese Ordnungsquelle mit einem stake-gewichteten Konsensprotokoll, das meist Tower BFT genannt wird. Geplante Leader ordnen Transaktionen; Votes bestätigen Forks. Endgültigkeit beruht auf nachfolgenden Validatorstimmen, nicht allein auf der Uhr.[1]
Weitere Begriffe beschreiben Teile des Datenpfads: Turbine verteilt Blockdaten in kleineren Paketen, Gulf Stream leitet Transaktionen an kommende Leader, Pipelining verteilt Prüfungsschritte auf Hardwarestufen und Cloudbreak bezeichnet das Kontendatenbank-Design. Archivers wurden für verteilte Ledger-Speicherung vorgeschlagen. Es handelt sich nicht um separate Konsensmechanismen.
Konten, Programme und Ausführung
Zustand liegt in Konten mit 32-Byte-Adressen. Programme enthalten ausführbaren Code; veränderlicher Zustand liegt in getrennten Konten, die einer Instruktion übergeben werden. Mehrere Instruktionen können eine atomare Transaktion bilden. Sealevel führt nicht kollidierende Transaktionen parallel aus, sofern sich ihre schreibbaren Konten nicht überschneiden.[3]
Programme werden häufig in Rust geschrieben. Token verwenden gewöhnlich das Solana Program Library (SPL) Token Program oder Token-2022. „SPL“, nicht „SLP“, ist der einschlägige Solana-Standard.
Solana-Programme können als unveränderlicher Code oder über einen aktualisierbaren Loader bereitgestellt werden. Ein aktualisierbares Programm besitzt eine Upgrade Authority, die den ausführbaren Inhalt ersetzen kann. Diese Befugnis kann übertragen oder widerrufen werden; nach dem Widerruf ist das Programm unveränderlich. Bei einer Anwendung ist daher der Validator-Konsens von der engeren Kontrolle über ein einzelnes Programm zu unterscheiden.[4]
Transaktionen und Gebühren
Eine Transaktion enthält Signaturen und eine Nachricht mit Konten, aktuellem Blockhash und Instruktionen. Gebühren werden in SOL bezahlt und bestehen aus einer Basisgebühr je Signatur sowie einer optionalen Prioritätsgebühr. Rechen- und Kontendatenlimits begrenzen die Ausführung.[5]
Am 15. September 2026 wurde das Feature txv1 im Mainnet in Epoche 1035 aktiviert. Das Format Version 1 erhöhte die maximale serialisierte Transaktionsgröße von 1.232 auf 4.096 Byte. Legacy- und Version-0-Transaktionen bleiben gültig. Version 1 legt Ressourcenlimits in einer Transaktionskonfiguration ab, verwendet keine Address Lookup Tables und bietet mehr Platz für Beweise, Multisignaturen und Stapel. Leser und Indexer müssen Version 1 ausdrücklich unterstützen; das Senden bleibt optional.[6][7]
SOL
SOL dient für Gebühren und Staking; ein SOL besteht aus einer Milliarde Lamports. Validatoren und Delegierende können SOL einsetzen. Delegation überträgt Stimmgewicht, nicht die Verwahrung der Token. Protokollausgabe und Gebührenregeln verändern die umlaufende Menge, weshalb feste Enzyklopädie-Zahlen schnell veralten.
Zuverlässigkeit und Dezentralisierung
Das Hochdurchsatzdesign stellt hohe Anforderungen an Netzwerk und Hardware. Stake-Konzentration, wenige Client-Implementierungen und Betriebskosten sind wiederkehrende Dezentralisierungsfragen. Im September 2021 stand die Blockproduktion nach Überlastung etwa 17 Stunden still; weitere Vorfälle 2022 führten zu Änderungen bei Transaktionseingang, Gebührenmärkten und Software.[8] Historische Ausfälle sind mit Datum zu bewerten und belegen keine dauerhafte Nichtverfügbarkeit.
Auf die ursprüngliche Validator-Codebasis von Solana Labs folgte Anzas Agave-Client; Firedancer wurde als separate Hochleistungsimplementierung entwickelt. Veröffentlichungen und Feature-Aktivierungen erfolgen schrittweise, sodass der Stake-Anteil je Client eine datierte Betriebskennzahl und keine dauerhafte Eigenschaft ist. Unabhängige Clients können gemeinsame Implementierungsrisiken nur mindern, wenn sie produktionsreif und in relevantem Umfang eingesetzt sind.[9]
Ökosystem
Solana-Anwendungen umfassen Börsen, Kreditprotokolle, Zahlungen, Spiele und NFT-Märkte. Vermögenswerte wie USDT können als Solana-Token ausgegeben werden; Emittent und Verwaltungskontrollen bleiben jedoch vom Validator-Konsens getrennt.
Siehe auch
Weblinks
Einzelnachweise
- ↑ 1,0 1,1 Anatoly Yakovenko, „Solana: A new architecture for a high performance blockchain“, Version 0.8.13.
- ↑ Solana Foundation, „Year in Review 2020“, 2020.
- ↑ Solana-Dokumentation, „Core Concepts“, geprüft am 16. September 2026.
- ↑ Solana-Dokumentation, „Programs“, geprüft am 16. September 2026.
- ↑ Solana-Dokumentation, „Fees“, geprüft am 16. September 2026.
- ↑ Solana Foundation, „Larger Transaction Sizes“, aktualisiert im September 2026.
- ↑ CoinDesk, Bericht zu Solana Transaction V1, 15. September 2026.
- ↑ Solana Foundation, „9/14 Network Outage Initial Overview“, 2021.
- ↑ Solana-Changelog, geprüft am 16. September 2026.