Alles, was du über Solanas v1.17-Update wissen musst

Worum geht es in diesem Artikel?

Solanas Netzwerk hat mit der Annahme von Version 1.17 durch eine Supermehrheit einen wichtigen Meilenstein erreicht. Sie ist die neueste Version des Validator-Clients von Solana Labs. Nach dem jüngsten Netzwerkausfall führten die Validatoren mit Version 1.17.20 einen Neustart durch. Zum Zeitpunkt der Veröffentlichung verwenden ~68,6 % der Validatoren Version 1.17.21 und ~31,3 % Version 1.17.20.  Die neue Version umfasst zahlreiche Verbesserungen für mehr Effizienz und Skalierbarkeit sowie neue Anwendungsfälle im Netzwerk. Von bahnbrechenden Fortschritten bei Zero-Knowledge-Beweisen bis zur Optimierung des Gossip-Protokolls ist v1.17 ein entscheidender Schritt in Solanas kontinuierlicher Entwicklung.

Dieser Artikel enthält alles, was du über das Update des Validator-Clients von Solana Labs auf Version 1.17 wissen musst. Wir betrachten die umfangreichen Tests von v1.17, den jüngsten Netzwerkausfall und die neuen Funktionen dieses Updates.

Wie wurde v1.17 getestet?

v1.17 läuft seit dem 3. Oktober 2023 im Testnet. Die Version wurde regelmäßig Stresstests mit hoher Transaktionslast unterzogen. Solana Labs stellte außerdem einige Mainnet-Beta-Canary-Nodes mit v1.17 bereit, um die Stabilität der Version unter realen Bedingungen zu überwachen. Sie liefen in den vergangenen Monaten stabil. Die bisherigen Aktivitäten und Fortschritte dieser Canary-Nodes kannst du im Kanal #canaries-monitoring im Solana Tech Discord verfolgen. Ab dem 4. Dezember 2023 führte zudem eine kleine Gruppe freiwilliger Mainnet-Beta-Nodes ein Upgrade auf v1.17 durch. 

Mehrere Runtime-Fuzzer wurden entwickelt, um teilweise randomisierte Transaktionen auszuführen und so Grenzfälle oder seltene Race Conditions zu erkennen. Diese Transaktionen wurden über mehrere Versionen hinweg ausgeführt, um eine konsistente Leistung sicherzustellen. Externe Prüfer haben v1.17 mehrfach auditiert. Die Berichte werden nach ihrer Freigabe im GitHub-Repository für Solana-Sicherheitsaudits veröffentlicht.

Ausfall im Februar

Am 6. Februar 2024 kam es um 9:53 Uhr UTC im Mainnet-Beta zu einem Ausfall, der die Finalisierung von Blöcken vorübergehend stoppte. Die Netzwerkaktivität war etwa fünf Stunden lang unterbrochen, bis der Konsens um 14:55 Uhr UTC wiederhergestellt wurde. Der Ausfall geht auf einen Fehler bei der Kompilierung und Zwischenspeicherung des Programmcodes zur Ausführung zurück. Betroffen waren insbesondere ältere Versionen der Program Loader.

Die Ursache lag in der Verarbeitung der mit Just-in-time (JIT) kompilierten Ausgabe häufig verwendeter Programme durch die Validatoren. Ein neues Caching-System sollte diesen Prozess optimieren, führte jedoch unbeabsichtigt den fatalen Fehler ein. Bei bestimmten Legacy-Programmen konnte das neue System in eine Endlosschleife aus Neukompilierungen geraten. Dadurch kam Solanas Konsensmechanismus zum Stillstand, da die meisten Validatoren auf dieses Problem stießen und keine weiteren Transaktionen verarbeiten konnten.

Die Ursache wurde schnell gefunden, da der Fehler mehrere Ähnlichkeiten mit dem jüngsten Devnet-Ausfall aufwies. 1.17.20 wurde angepasst, um das Problem direkt zu beheben, und die Validatoren koordinierten einen Neustart des Netzwerks. Die Lösung bestand aus zwei Teilen: Kurzfristig wurden die zwei Legacy-Loader, die die Endlosschleife auslösen konnten, als veraltet markiert und damit die Auslösung verhindert. Zusätzlich wurde das neue Programm-Caching-System umfassender angepasst, um ähnliche Probleme künftig zu vermeiden. 

Den offiziellen Bericht, der ursprünglich von Anza veröffentlicht wurde, findest du hier.

ZK Token Proof Program

Das ZK Token Proof Program sollte ursprünglich mit dem 1.16-Update veröffentlicht werden. Seine Aktivierung verzögerte sich jedoch aufgrund umfangreicher Audits. Im Zeitplan zur Aktivierung von Feature Gates ist das Programm ab Version 1.17.12 als Aktivierung im Testnet ausstehend gekennzeichnet. 

Vertrauliche Übertragungen

Mit der Aktivierung des ZK Token Proof Program werden vertrauliche Übertragungen endlich verfügbar. Vertrauliche Übertragungen verschlüsseln Token-Guthaben und Übertragungsbeträge für SPL-Token mithilfe von Zero-Knowledge-Beweisen. Das übergeordnete Ziel ist Vertraulichkeit statt Anonymität. Mit homomorpher Verschlüsselung lassen sich Berechnungen auf verschlüsselten Daten ausführen, ohne sie zu entschlüsseln. Guthaben können beispielsweise addiert oder subtrahiert werden, ohne die jeweiligen Beträge für diese Operationen zu ent- und erneut zu verschlüsseln. Die Berechnungen bleiben also verschlüsselt und funktionieren genauso, als würden sie auf Klartext angewendet.

Vertrauliche Übertragungen nutzen Twisted-ElGamal-Verschlüsselung und Sigma-Protokolle für sichere, private Transaktionen, ohne sensible Informationen offenzulegen. 

Nebenbei bemerkt:

• Die Twisted-ElGamal-Verschlüsselung ist eine einfache Variante des standardmäßigen ElGamal-Verschlüsselungsverfahrens. Dabei wird ein Chiffretext in ein Pedersen-Commitment der verschlüsselten Nachricht und einen Entschlüsselungs-Handle aufgeteilt, um verborgene mathematische Operationen auf dem Chiffretext ausführen zu können
• Sigma-Protokolle validieren vertrauliche Übertragungen. Sie sind eine spezielle Klasse von Zero-Knowledge-Beweisen, bei denen eine Partei, also der Beweisende, einer anderen Partei, also dem Prüfer, nachweisen kann, dass sie bestimmte Informationen kennt, ohne diese offenzulegen

Bei vertraulichen Übertragungen kann nur der Account mit dem Entschlüsselungsschlüssel sein verschlüsseltes Guthaben einsehen. Das Global Auditor System ist für Situationen vorgesehen, die eine Prüfung durch Dritte erfordern, etwa Compliance-Prüfungen oder Audits. Damit können Account-Inhaber über separate Entschlüsselungsschlüssel gezielt Lesezugriff auf bestimmte Accounts gewähren. Außerdem umfasst das System einen „Auditor-Verschlüsselungsschlüssel“ für Mints, der sichere Audits ermöglicht.

Transaktionen verwenden verschlüsselte Parameter für die Beträge von Absender, Empfänger und Auditor sowie Beweise, um Datenschutz und Integrität sicherzustellen. Account-Guthaben werden in „Ausstehend“ und „Verfügbar“ aufgeteilt, um Front-Running-Angriffe zu verhindern. Andernfalls könnte ein böswilliger Nutzer Token an einen Account senden und damit Beweise ungültig machen, die anhand des verschlüsselten Guthabens erstellt wurden.

Beachte, dass vertrauliche Übertragungen ein neues Schlüsselpaar erfordern. 

Befehlszeilenunterstützung

Auch die Unterstützung vertraulicher Übertragungen über das Command Line Interface (CLI) ist über die spl-token-Crate verfügbar. Nach der Aktivierung umfasst der Befehl create-token auch das Flag –enable-confidential-transfers auto. Damit können Nutzer Token minten, bei denen die Erweiterung für vertrauliche Übertragungen aktiviert ist. Daneben gibt es weitere nützliche Befehle:

• configure-confidential-transfer-account – konfiguriert einen bestehenden Account für vertrauliche Übertragungen. Nur der Account-Inhaber darf vertrauliche Übertragungen für den Account konfigurieren
• deposit-confidential-tokens – zahlt Token von einem nicht vertraulichen Account auf einen vertraulichen Account ein. Beachte, dass die eingezahlten Token anschließend nicht mehr im nicht vertraulichen Guthaben des Accounts vorhanden sind, da sie vollständig in das vertrauliche Guthaben verschoben wurden
• apply-pending-balance – verschiebt ein Guthaben von „Ausstehend“ nach „Verfügbar“. Das ist nötig, weil vertrauliche Token aus einer Übertragung oder Einzahlung zunächst im „ausstehenden“ Guthaben eines Accounts erscheinen. Nutzer können daher nicht sofort auf das Guthaben zugreifen und müssen das ausstehende Guthaben anwenden
• transfer (mit aktiviertem Flag –confidential) – überträgt Token an einen anderen Account, der für vertrauliche Übertragungen konfiguriert ist. Beachte, dass dieser Vorgang länger dauern kann als eine normale Token-Übertragung, da dafür mehrere voneinander abhängige Transaktionen erforderlich sind
• withdraw-confidential-tokens – überträgt Token vom vertraulichen Guthaben eines Accounts in sein nicht vertrauliches Guthaben. Stelle vor der Ausführung dieses Befehls sicher, dass alle ausstehenden Guthaben angewendet wurden, damit alle erwarteten Token abgehoben werden
• update-confidential-transfer-settings – aktualisiert die Konfiguration vertraulicher Übertragungen für einen bestimmten Token-Mint. Der Befehl bietet Optionen, um Richtlinien für die automatische Genehmigung vertraulicher Übertragungen festzulegen, also das Flag –aprove-policy, und den öffentlichen Schlüssel eines Auditors zu definieren, also das Flag –auditor-pubkey. Weitere Flags dienen zur Angabe eines Blockhashes, der Autorität für vertrauliche Übertragungen, von Konfigurationsdateien, Angaben zum Gebührenzahler, der JSON RPC URL, Angaben zum Nonce-Account, des Ausgabeformats und der Token-Programm-ID

Kompatibilität 

Beachte, dass die folgenden Erweiterungskombinationen mit vertraulichen Übertragungen entweder nicht funktionieren oder keinen Sinn ergeben:

• Vertrauliche Übertragung + nicht übertragbar
• Vertrauliche Übertragung + Gebühren (funktioniert erst ab 1.18)
• Vertrauliche Übertragung + Transfer Hooks (diese Übertragungen können nur Quell- oder Ziel-Accounts sehen und daher nicht auf den übertragenen Betrag reagieren)

Audits

Vertrauliche Übertragungen und das Token-2022-Programm insgesamt wurden umfassend von Unternehmen wie Halborn, Zellic, Trail of Bits, NCC Group und OtterSec auditiert. OtterSec führte zwei Audits durch: Das erste Audit konzentrierte sich auf Token-2022, während das zweite Audit speziell vertrauliche Übertragungen untersuchte.

Poseidon-Syscalls

Poseidon ist eine für Zero-Knowledge-Beweise optimierte Familie von Hashfunktionen. Die meisten ZK-basierten Blockchain-Projekte nutzen Poseidon-Hashfunktionen, darunter Zcash, Mina und Solanas Light Protocol. Derzeit ist die Berechnung von Poseidon-Hashes auf Solana zu aufwendig für eine einzelne Transaktion. Poseidon-Syscalls sollen das ändern. Ihre Veröffentlichung ist derzeit für v1.17.5 vorgesehen, die Aktivierung im Testnet steht noch aus.

Einfach erklärt

Stell dir einen modernen Taschenrechner vor, der bestimmte Rätsel für sichere Kommunikation effizient löst. Dieser Rechner nimmt Informationen auf, zerlegt sie und vermischt sie auf einzigartige Weise. Dadurch wird der ursprüngliche Inhalt vollständig verborgen, bleibt aber überprüfbar.

Dieser Mischvorgang verwendet eine spezielle Methode, die Zahlen addiert und mit bestimmten Exponenten potenziert. Diese gehören zu einer vorab definierten Zahlenmenge. So stellt die Methode sicher, dass der Mischvorgang jedes Mal gründlich und konsistent abläuft.

Poseidon funktioniert genauso wie dieser moderne Taschenrechner. Solche Hashfunktionen eignen sich besonders gut zum Erstellen von Zero-Knowledge-Schaltkreisen. Schaltkreise sind im Wesentlichen Sammlungen mathematischer Operationen. Sie stellen mathematisch dar, wie eine Partei, der Beweisende, einer anderen Partei, dem Prüfer, nachweist, dass sie bestimmte Informationen kennt, ohne diese offenzulegen. Stell es dir grundsätzlich so vor, als würdest du beweisen, dass du weißt, was sich in einer versiegelten Kiste befindet, ohne sie tatsächlich zu öffnen. Du kannst das der Person, die die Kiste versiegelt hat, durch eine Reihe von Schlägen oder Schritten beweisen. Diese Schläge oder Schritte verraten weder Details über den Inhalt der Kiste noch darüber, wie sie sich öffnen lässt. Sie sind nur verständlich, wenn du die Kiste geöffnet hast.

Das ist für Blockchains nützlich, da es äußerst wichtig ist, Transaktionen privat zu halten und gleichzeitig ihre Echtheit verifizieren zu können. 

ZK-freundliche Eigenschaften

Poseidon-Hashfunktionen gelten aus mehreren Gründen als Zero-Knowledge-freundlich. Insbesondere gilt:

• Poseidon ist darauf ausgelegt, arithmetische Operationen, die bei Berechnungen für Zero-Knowledge-Beweise üblich sind, effizient auszuführen. Dazu gehören Addition, Multiplikation und Potenzierung
• Systeme für Zero-Knowledge-Beweise müssen Rechenlogik in einen kryptografischen Beweis umwandeln. Poseidons Design führt dank seiner arithmetischen Optimierung, der optimierten S-Box, anpassbarer Parameter und einer geringen Anzahl von Runden zu einer niedrigeren Schaltkreiskomplexität als andere Hashfunktionen. Eine Runde ist eine Abfolge von Operationen, die iterativ auf die Eingabedaten oder den internen Zustand der Hashfunktion angewendet wird. Dadurch sind weniger Schritte nötig, um einen Beweis für bestimmte Daten zu erstellen
• Poseidon-Hashfunktionen basieren auf einer Sponge-Konstruktion. Poseidon nutzt also eine Klasse von Algorithmen, die eine Bitfolge beliebiger Länge aufnehmen und eine Ausgabe beliebiger Länge erzeugen. Dadurch lassen sich Poseidon-Hashfunktionen besonders einfach in verschiedene Zero-Knowledge-Anwendungen integrieren.

Vergleich mit herkömmlichen Hashfunktionen

Poseidons auf Zero-Knowledge-Beweise zugeschnittene Recheneffizienz bietet einen klaren Vorteil gegenüber den allgemeineren und rechenintensiven Operationen herkömmlicher Hashfunktionen wie SHA-256. 

Herkömmliche Hashfunktionen sind zwar sicher und zuverlässig, führen innerhalb von Zero-Knowledge-Beweisen aber häufig zu größeren, komplexeren Schaltkreisen. Der Grund: Diese Hashfunktionen wurden ursprünglich nicht für die speziellen Einschränkungen von Systemen für Zero-Knowledge-Beweise entwickelt. Auf Blockchains führen Zero-Knowledge-Beweise ihre Berechnungen in endlichen Körpern aus. Ein endlicher Körper ist eine Zahlenmenge, in der alle arithmetischen Operationen, also Addition, Subtraktion, Multiplikation und Division, modulo einer Primzahl ausgeführt werden. Dadurch beginnen die Werte innerhalb der Menge nach Erreichen der Grenze wieder von vorn, und jede Operation bleibt in dieser Zahlenmenge. 

Herkömmliche Hashfunktionen wie SHA-256 stützen sich stark auf bitweise Operationen und vorgegebene Operationsfolgen. Diese Funktionen sind nicht direkt mit den arithmetischen Operationen in endlichen Körpern kompatibel. Ihre Implementierung in einem endlichen Körper würde zusätzliche Schritte erfordern und damit die Komplexität des Schaltkreises erhöhen.

Außerdem verwenden herkömmliche Hashfunktionen in der Regel modulare Arithmetik, die auf Zweierpotenzen basiert. Das unterscheidet sich von der modularen Arithmetik der endlichen Körper in Zero-Knowledge-Beweisen, die häufig auf Primzahlen beruht. Diese Inkompatibilität würde noch mehr Schritte erfordern und Größe sowie Komplexität des Schaltkreises erhöhen.

Beim Erstellen eines Zero-Knowledge-Beweises soll eine mathematische Darstellung von Rechenlogik entstehen, die das Wissen über bestimmte Informationen beweist, ohne sie offenzulegen. Eine effiziente und einfache Darstellung dieses Wissens ist entscheidend für die Skalierbarkeit dieser Beweise. Die Poseidon-Familie von Hashfunktionen erfüllt diese Anforderungen direkt durch effiziente Operationen in endlichen Körpern und reduziert die nötigen Schritte zur Erstellung eines Schaltkreises erheblich. Das Ergebnis ist ein kleinerer, weniger komplexer Schaltkreis. Herkömmliche Hashfunktionen sind nicht direkt auf die Anforderungen beim Aufbau von Schaltkreisen zugeschnitten, sondern für allgemeine Zwecke konzipiert. 

Die Integration von Poseidon-Syscalls in v1.17 markiert den Übergang zu spezialisierten kryptografischen Werkzeugen, die das Erstellen und Validieren von Zero-Knowledge-Beweisen auf Solana optimieren. Das beschleunigt die Transaktionsverarbeitung, senkt die Kosten und verbessert die Skalierbarkeit von Zero-Knowledge-Berechnungen. Zusammen mit Poseidons Flexibilität und Anpassbarkeit wird das Erstellen und Validieren von Zero-Knowledge-Beweisen auf Solana deutlich einfacher.

Konkrete Implementierung

v1.17 führt den Syscall sol_poseidon ein. Dieser Systemaufruf nimmt einen zweidimensionalen Byte-Slice als Eingabe und berechnet daraus den entsprechenden Poseidon-Hash. Er verwendet die BN254-Kurve und akzeptiert die folgenden Poseidon-Parameter:

• x^5-S-Boxen, also Substitutionsboxen
• Eingaben mit 1 ≤ n ≤ 12
• Breite mit 2 ≤ t ≤ 13
• 8 vollständige Runden und von t abhängige Teilrunden: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Diese Poseidon-Hashes werden mit der light-posiedon-Crate berechnet. Sie wurde auditiert und ist mit Circom kompatibel. 

Beachte, dass wir im folgenden Abschnitt die Ergänzung von alt_bn128-Syscalls behandeln. BN254 wird umgangssprachlich auch BN128 genannt, bezogen auf die Sicherheitsbits, sowie alt_bn128 oder alt_bn_128. Gemeint ist jeweils dieselbe Kurve.

alt_bn128-Syscalls

v1.16 schlug eine verbesserte Runtime-Unterstützung für Zero-Knowledge-Berechnungen vor, insbesondere für Operationen auf elliptischen 128-Bit-Kurven. alt_bn128-Syscalls sind für die effiziente Erstellung von Beweisen entscheidend und sollten mit v1.16 veröffentlicht werden. Die Veröffentlichung verzögerte sich jedoch. Laut dem Zeitplan zur Aktivierung von Feature Gates sind alt_bn128-Syscalls derzeit für v1.17.15 vorgesehen, wobei die Aktivierung im Mainnet-Beta noch aussteht. Die alt_bn128-Komprimierung ist ebenfalls für v1.17.15 vorgesehen, die Aktivierung im Testnet steht noch aus.

Für alle, die tiefer einsteigen möchten: alt_bn128 bezeichnet die Implementierung der elliptischen Barreto-Naehrig-Kurve (BN-128). Diese spezielle, pairing-freundliche elliptische Kurve ermöglicht effiziente zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge). Sie gilt als „pairing-freundlich“, da sich damit bestimmte Zero-Knowledge-Berechnungen und -Beweise effizienter ausführen lassen. Auf Solana ermöglichen alt_bn128-Syscalls Programmen, diese Kurve zur optimierten Verifizierung von Zero-Knowledge-Beweisen zu nutzen. Das verbessert Sicherheit und Datenschutz. Die Ergänzung von alt_bn128-g1- und g2-Syscalls erleichtert die Komprimierung von Groth16-Beweisen. Dadurch sinkt der Platzbedarf pro Beweis erheblich, was den Speicherplatz für Solana-Programme effizienter nutzt.

Die Einführung von alt_bn128-Syscalls verringert die Kompatibilitätslücke zwischen Solana und Solidity-basierten Contracts, die für die in EIP-196, EIP-197 und EIP-198 beschriebenen Operationen auf elliptischen Kurven vorkompilierte Contracts verwenden. Diese Operationen (bn256Add, bn256ScalarMult, bn256Pairing) ermöglichen die Verifizierung von zk-SNARKs innerhalb der Gas-Limits von Ethereum. Solidity-Contracts, die diese Operationen auf elliptischen Kurven nutzen, lassen sich nun möglicherweise leichter zu Solana migrieren oder mit Solana interoperabel machen.

Verbesserungen an Gossip

v1.17 verbessert die Effizienz der Gossip-Nachrichtenverteilung, indem Push-Nachrichten besser verbreitet werden und die Abhängigkeit von Pull-Anfragen sinkt. Die optimierten Abläufe des Gossip-Protokolls reduzieren den Ressourcenverbrauch von Konsens-Validatoren.

Zum Kontext: Solanas Gossip Service ist für den Informationsaustausch zwischen Validatoren entscheidend. Dazu gehören Informationen wie Ledger-Höhen, Kontaktdaten und Konsensabstimmungen. Der Dienst nutzt „Push“- und „Pull“-Nachrichten, um Informationen im Netzwerk zu teilen und zu verifizieren. Dieses Nachrichtensystem stellt sicher, dass alle Nodes synchron bleiben. 

Bisher überträgt AccountsHashVerifier seine Account-Hashes per Push an Gossip. Da jedoch keine Netzwerkkomponente diese Daten jemals abruft, ist der Vorgang überflüssig. Frühere Abläufe wie der Vergleich von Account-Hashes aus Gossip mit den Werten bekannter Validatoren wurden mit der Einführung von EpochAccountsHash entfernt.  Auch die RPC-Methode getHealth wurde so überarbeitet, dass sie nicht mehr von Account-Hashes aus Gossip abhängt. Darauf gehen wir im nächsten Abschnitt näher ein. Seit v1.17 ruft daher keine Komponente mehr Account-Hashes aus Gossip ab. AccountsHashVerifier wurde so geändert, dass keine Accounts mehr an Gossip übertragen werden. Außerdem wurden die Funktionen zum Übertragen und Abrufen von Account-Hashes über Gossip entfernt.

getHealth 

Früher konnte der RPC-Aufruf getHealth für einen bestimmten Node den falschen Zustand melden. Ursache war eine Abweichung zwischen dem CLI-Befehl solana catchup und dem RPC-Aufruf getHealth. Ein Node konnte dadurch gleichzeitig als synchronisiert und im Rückstand erscheinen. Infolgedessen konnten fehlerfrei laufende Nodes fälschlicherweise als fehlerhaft markiert und möglicherweise aus RPC-Pools entfernt werden.

Der Zustand wurde ursprünglich bestimmt, indem ein lokaler, in Gossip veröffentlichter Account-Hash-Slot mit denen anderer Nodes verglichen wurde. Als Standardvergleichswert dienten 100 Slots. Das konnte ungenau sein, insbesondere bei Nodes, die mit Werten von mehr als 100 Slots konfiguriert waren. getHealth wurde so überarbeitet, dass es den neuesten optimistisch bestätigten Slot des Clusters verwendet. Das ist der letzte Slot, den alle Validatoren verarbeitet und eine Supermehrheit bestätigt hat, der aber noch nicht finalisiert ist. Dies ermöglicht einen genaueren Vergleich: Der bestätigte Slot des Clusters lässt sich mit der neuesten optimistisch bestätigten Bank vergleichen, um zu bestimmen, wie weit der Node zurückliegt. Die Änderung ermöglicht eine präzisere Prüfung, reduziert falsch negative Ergebnisse, bei denen fehlerfreie Nodes als fehlerhaft markiert werden, und schützt vor Dominoeffekten durch Probleme bei bekannten Validatoren. 

Außerdem wurde das Flag –skip-health-check für die Befehle wait-for-restart-window und exit hinzugefügt, um die Probleme mit getHealth zu beheben. Damit können Validatoren die Prüfung überspringen, ob ein Node fehlerfrei läuft.

QUIC

v1.17 ermöglicht es, Shreds über QUIC zu übertragen und Reparaturen durchzuführen. Die Turbine- und Reparatur-QUIC-Endpunkte sind derzeit deaktiviert, da sie erst nach der vollständigen Migration des Testnets zu QUIC benötigt werden. Damit ist jedoch die Grundlage für die Migration dieser Protokolle zu QUIC geschaffen. Mehrere PRs wurden zusammengeführt, um die zugrunde liegende Funktionalität einzuführen, darunter:

• Hinzufügen einer verzögerten Bereinigung für QUIC-Reparaturverbindungen, damit die Anzahl offener Verbindungen nicht unbegrenzt wächst
• Hinzufügen von Metriken zur Überwachung des Turbine-QUIC-Endpunkts
• Hinzufügen von Metriken zur Überwachung der Reparatur des QUIC-Endpunkts
• Verhindern von Zeitüberschreitungen bei QUIC-Verbindungen aufgrund seltener Reparaturanfragen

Asynchrone TPU-Verbindungen

v1.17 führt asynchrone TPU-Client-Verbindungen ein und verbessert damit den Connection-Cache-Mechanismus erheblich. Das Update soll die Transaktionslatenz verringern, indem Verbindungen im Hintergrund mit einer standardmäßigen Connection-Pool-Größe von vier aufgebaut werden. Asynchrone TPU-Client-Verbindungen ermöglichen eine reibungslosere Transaktionsverarbeitung ohne die bei synchronen Verbindungen erforderlichen Wartezeiten. 

Optimierter Validator-Start und aktualisiertes Snapshot-Format

v1.17 optimiert den Startvorgang von Validatoren durch ein neues Flag und aktualisierte unterstützte Snapshot-Dateiformate. Dadurch starten Validatoren schneller. Das ist wichtig, weil kürzere Ausfallzeiten die Widerstandsfähigkeit des Netzwerks erhöhen.

v1.17 führt das neue Flag –use-snapshot-archives-at-startup ein. Damit können Validatoren den Start beschleunigen, indem sie zwischen lokalen Snapshots und dem lokalen Zustand auf dem Datenträger wählen oder automatisch die neuere der beiden Optionen verwenden. Wenn der Zustand auf dem Datenträger neuer ist, müssen dank dieses Flags keine Snapshots verarbeitet werden. Das verkürzt die Neustartzeit.

Bisher unterstützte Solana verschiedene Komprimierungsformate für Snapshots. Zu den Archivformaten gehörten bz2, gzip, zstd, lz4, tar und unkomprimierte Archive. Das neueste Update beschränkt die Auswahl jedoch auf zstd und lz4, um die Effizienz zu optimieren und den Support-Aufwand zu reduzieren. Die anderen Formate gelten für das Argument –snapshot-archive-format als veraltet. Validatoren können vorhandene Snapshots in diesen Formaten aber weiterhin lesen, um Abwärtskompatibilität sicherzustellen. Dadurch wird das Command Line Interface für solana-validator und solana-ledger-tool einfacher. 

Fazit

Dank zahlreicher neuer Funktionen und der schnellen Behebung des jüngsten Netzwerkausfalls ist Solanas v1.17-Update ein großer Fortschritt. Mit der Veröffentlichung des ZK Token Program, der Poseidon-Syscalls und der alt_bn128-Syscalls bietet das Update ein bislang unerreichtes Maß an Zero-Knowledge-Unterstützung und neuen Funktionen. Zusammen mit Verbesserungen an Validatoren und der Netzwerkeffizienz schafft dieses Update eine solide Grundlage für die nächste Version. Es ist kleiner als v1.16 und entspricht dem Ziel, alle drei Monate eine neue Version zu veröffentlichen. Den Veröffentlichungsplan für 1.18 findest du hier.

Wenn du bis hierher gelesen hast: Danke, Anon! Gib unten deine E-Mail-Adresse ein, damit du keine Neuigkeiten zu Solana verpasst. Möchtest du noch tiefer einsteigen? Entdecke die neuesten Artikel im Helius-Blog und setze deine Reise durch Solana noch heute fort.

Weitere Ressourcen

• Bericht zum Ausfall des Solana Mainnet Beta am 06.02.24
• Veröffentlichungsplan für v1.17
• Poseidon: ZK-freundliches Hashing
• Twitter-Account zum Solana-Status
• Solana-Validatoren übernehmen das v1.17-Update