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

Worum geht es in diesem Artikel?

Solanas Validator-Netzwerk hat bei der Einführung von Version 1.16 erfolgreich eine Supermehrheit erreicht. Sie ist das neueste Upgrade des Validator-Clients von Solana Labs. Nach einer umfassenden Auditphase, unterstützt durch den engagierten Einsatz von Freiwilligen und Canary Nodes, bildet dieser Meilenstein den Abschluss von fast zehn Monaten intensiver Entwicklung.

In den folgenden Abschnitten sehen wir uns an, wie v1.16 getestet wurde und wie Solanas Feature-Gate-System funktioniert. Dieses Framework steuert die schrittweise Einführung neuer Funktionen im Netzwerk. Anschließend beschäftigen wir uns mit den neuen Funktionen, die in v1.16 implementiert wurden.

Wie wurde v1.16 getestet?

v1.16 wurde in den vergangenen Monaten intensiven Tests unterzogen. Das v1.16-Release läuft seit dem 7. Juni 2023 im Testnet und hat zahlreiche Stresstests durchlaufen. Außerdem aktualisierte ab dem 23. August 2023 eine kleine Gruppe freiwilliger Nodes auf v1.16. Diese Freiwilligen konnten verschiedene Probleme identifizieren und beheben, darunter langsame Startvorgänge bei RPC-Nodes und allgemeine Schutzverletzungen. Solana Labs stellte zudem mehrere Canary Nodes im Mainnet-Beta bereit. Damit wurde die Stabilität der v1.16-Nodes unter realen Bedingungen überwacht. Wenn du die bisherigen Aktivitäten und Fortschritte dieser Canary Nodes sehen möchtest, besuche den Kanal #canaries-monitoring im Solana Tech Discord.

Um Grenzfälle oder seltene Race Conditions zu erkennen, wurden mehrere Runtime-Fuzzer eingesetzt, die teilweise randomisierte Transaktionen ausführten. Diese Transaktionen wurden über verschiedene Runtime-Versionen hinweg ausgeführt, um eine konsistente Leistung sicherzustellen. v1.16 wurde außerdem umfassend von Halborn auditiert. Auditberichte werden nach und nach in diesem Repository veröffentlicht.

Feature-Gates

Wichtig: Einige der Funktionen, die wir in den folgenden Abschnitten behandeln, sind derzeit noch nicht live. Stattdessen werden Funktionen mithilfe eines Feature-Gate-Systems schrittweise eingeführt. Sie werden abhängig von ihrer relativen Priorität und der Reihenfolge ihrer Aktivierung in anderen Netzwerken zu bestimmten Epochen aktiviert. Die Aktivierung der Feature-Gates wurde bisher anhand einer Reihe von Kriterien ad hoc geplant. Du findest sie hier. Grundsätzlich sollten diese Gates zuerst im Testnet, danach im Devnet und schließlich im Mainnet-Beta aktiviert werden. Um eine Funktion zu aktivieren, sendet ein Engineer mit dem erforderlichen Aktivierungs-Keypair eine Transaktion. Nach ihrer Verarbeitung wird die Funktion in der nächsten Epoche live geschaltet. Pro Netzwerk darf jeweils nur ein Feature-Gate aktiviert werden, um die ordnungsgemäße Leistung sicherzustellen. Einige Funktionen können außerdem eine „Soak“-Phase benötigen, die die Aktivierung von Gates mit niedrigerer Priorität verzögern kann.

Dieses Feature-Gate-System verhindert, dass Änderungen, die den Konsens brechen, einen Validator mit einer neueren Version von der kanonischen Chain abspalten und weiter Blöcke produzieren lassen. Ein v1.14-Validator kennt beispielsweise die neuen Funktionen von v1.16 nicht und könnte bei Konflikten das Netzwerk zum Absturz bringen. Ein diese Woche in Solanas Codebasis aufgenommener Commit sieht für alle Änderungen, die den Konsens brechen, ein Solana Improvement Document (SIMD) vor. Die Issue-Vorlage für Feature-Gates enthält nun eine Anfrage nach dem SIMD des Issues. Das standardisiert den Entwicklungsprozess und schafft durch die Dokumentation neuer Änderungen mehr Transparenz.

Vertrauliche Transfers

Vertrauliche Transfers sind eine von Token2022 eingeführte Funktion. Sie nutzen Zero-Knowledge-Beweise, um Guthaben und Transaktionsbeträge von SPL-Tokens zu verschlüsseln. Das Hauptziel besteht darin, die Privatsphäre der Nutzer zu verbessern. Dabei liegt der Schwerpunkt bewusst auf Vertraulichkeit statt auf Anonymität.

Vertrauliche Transfers nutzen die Twisted-ElGamal-Verschlüsselung für mathematische Operationen mit verschlüsselten Beträgen. Diese Transfers werden mithilfe von Sigma-Protokollen validiert. Das ist eine spezielle Kategorie von Zero-Knowledge-Beweisen, bei denen eine Partei, der Beweisende, einer anderen Partei, dem Verifizierenden, nachweisen kann, dass sie ein bestimmtes Geheimnis kennt, ohne das Geheimnis selbst offenzulegen. Lies auch unseren Artikel Was ist Token2022?, um die Funktionsweise vertraulicher Transfers genauer zu verstehen.

Eine nützliche Ergänzung für die Einführung vertraulicher Transfers ist die Unterstützung der Command Line Interface (CLI). Der Befehl create-token wurde um das Flag --enable-confidential-transfers erweitert. Damit können Nutzer Tokens prägen, für die vertrauliche Transfers aktiviert sind. Außerdem wurde der Befehl update-confidential-transfer-settings hinzugefügt, um die Konfiguration vertraulicher Transfers für einen bestimmten Mint dynamisch zu ändern. So lassen sich der Auditor-Schlüssel und die Genehmigungseinstellungen aktualisieren.

Bessere Runtime-Unterstützung für Zero-Knowledge-Beweise

Das v1.16-Release erweitert Solanas Zero-Knowledge-Funktionen durch eine verbesserte Runtime-Unterstützung für Zero-Knowledge-Berechnungen, insbesondere für 128-Bit-Operationen auf elliptischen Kurven. v1.16 führt alt_bn128-Syscalls ein, die für die effiziente Erzeugung von Beweisen entscheidend sind.

alt_bn128 bezeichnet eine spezielle Implementierung einer elliptischen Kurve für kryptografische Operationen, die als Barreto-Naehrig-Kurve (BN-128) bekannt ist. BN-128 ist eine spezielle Art pairing-freundlicher elliptischer Kurve, die eine effiziente Implementierung von zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) ermöglicht. Eine elliptische Kurve gilt als „pairing-freundlich“, wenn sich bestimmte Berechnungen damit effizienter ausführen lassen. In unserem Fall beschleunigt die BN-128-Kurve also die Arbeit mit Zero-Knowledge-Mathematik und -Beweisen erheblich.

Ein Syscall, also ein Systemaufruf, fordert Dienste vom Kernel des Betriebssystems an. Im Kontext von Solana ermöglicht ein Syscall Programmen, die in der Solana Virtual Machine (SVM) laufen, die Interaktion mit externen Ressourcen.

Ein alt_bn128-Syscall ist somit ein Aufruf, über den Solana-Programme mit der hocheffizienten BN-128-Kurve interagieren können. Das vereinfacht die Verifizierung von Zero-Knowledge-Beweisen und ermöglicht bessere Sicherheits- und Datenschutzfunktionen auf Solana. Kürzlich wurden außerdem alt_bn128-g1- und -g2-Syscalls hinzugefügt, mit denen sich Groth16-Beweise komprimieren lassen. Das ist wichtig, da diese Beweise jeweils 256 Byte Anweisungsdaten beanspruchen und private Solana-Programme (PSPs) derzeit zwei Groth16-Beweise verifizieren müssen. Durch die g1- und g2-Komprimierung lässt sich die benötigte Datenmenge pro Beweis auf 128 Byte halbieren. Das ist für die Speichereffizienz entscheidend.

Außerdem treten bei Solidity-basierten Contracts Kompatibilitätsprobleme mit Solana auf, wenn sie Aufrufe der folgenden vorkompilierten Contracts für Operationen auf elliptischen Kurven enthalten:

• bn256Add - Führt Additionen bei Operationen auf elliptischen Kurven aus
• bn256ScalarMult - Führt Skalarmultiplikationen bei Operationen auf elliptischen Kurven aus
• bn256Pairing - Führt Pairing-Operationen auf elliptischen Kurven aus, um zkSNARKs innerhalb des Block-Gaslimits zu verifizieren

Diese Operationen sind auf Ethereum durch EIP-196, EIP-197 und EIP-198 standardisiert. Die Einführung von alt_bn128-Syscalls ist ein wichtiger Schritt, um die Kompatibilitätslücke zu schließen. Solidity-Contracts, die auf diesen Operationen mit elliptischen Kurven basieren, können nun möglicherweise leichter zu Solana wechseln oder sogar mit Solana interagieren.

Die Aufnahme des alt_bn128-Syscalls in Solanas v1.16-Update verbessert Solanas Fähigkeit erheblich, Zero-Knowledge-Beweise effizient und sicher zu verarbeiten. Wenn du mehr über alt_bn128-Syscalls erfahren möchtest, sieh dir die folgenden Pull Requests an:

• alt_bn-Syscalls hinzugefügt
• Tests für alt_bn128-Syscalls hinzugefügt und zugehörige Probleme behoben
• Feat(syscall): g1- und g2-Komprimierung für altbn128 hinzufügen

Validatoren

Das v1.16-Update reduziert den RAM-Verbrauch von Validatoren drastisch. Solana nutzte zuvor RAM, um Accounts zu indexieren. Das System wurde nun so konfiguriert, dass Accounts standardmäßig auf dem Datenträger indexiert werden. Dadurch sinkt der RAM-Verbrauch erheblich. Yanshu von Luganodes berichtet, dass ihr Validator seit der Veröffentlichung von v1.16 mit nur ~39 GB RAM reibungslos läuft. Bei früheren Versionen waren es ~120 GB:

Das v1.16-Release führt außerdem ein überarbeitetes Peer-Sampling-System für Gossip-Pull-Requests ein. Dieses neue System reduziert die beim Start von Validatoren benötigte Bandbreite. In früheren Versionen konnten große Mengen an Gossip-Pull-Requests Bandbreitenengpässe verursachen. Dadurch konnte der Validator langsamer werden oder sogar überlasten. v1.16 behebt dieses Problem mit einer Variable für die Zeit seit dem letzten Request. Anhand dieser Variable wird das Volumen des eingehenden Traffics ermittelt und eine Ratenbegrenzung angewendet. So wird verhindert, dass der Validator beim Start überlastet.

Validatoren mit Stake, die hinter das Netzwerk zurückfallen, können den aktuellen Zustand dank der neuen, proportional zum eigenen Stake gewichteten Repair-Request-Funktion jetzt noch schneller erreichen. Wenn ein Validator mit hohem Stake vom Netzwerk abgespalten wird, stellt er einen Repair Request. Dieser Validator erhält Shreds nun schneller, weil er einen hohen Stake hält. So wird sichergestellt, dass der Validator nicht länger vom Netzwerk abgespalten ist und weiter beitragen kann. Bei Repair Requests haben Validatoren mit Stake eine höhere Priorität als RPC-Nodes, da RPC-Nodes keine Blöcke produzieren.

Der Verzögerungsschwellenwert für Shred-Reparaturen wurde ebenfalls von 100 ms auf 200 ms erhöht. Diese Änderung reduziert die Anzahl der Repair Requests für Shreds, die letztlich über Turbine bereitgestellt würden. Turbine bezeichnet den mehrschichtigen Mechanismus zur Blockverteilung, mit dem Solana Ledger-Einträge an alle Nodes überträgt. Dabei teilt sich der Solana-Cluster in mehrere Node-Schichten auf. Jede Node in einer bestimmten Schicht ist dafür verantwortlich, Daten an die nächste nachgelagerte Schicht weiterzugeben. Diese wichtige Anpassung minimiert unnötige Repair Requests und verbessert damit die Effizienz der Datenverteilung durch Turbine.

Noch nie war es so einfach, einen eigenen Validator zu betreiben. Wenn du deinen eigenen Validator betreiben möchtest, bietet Solana mit Solana Validator Education eine Reihe von Validator-Workshops auf dem eigenen YouTube-Kanal an.

Unterstützung für größenveränderbare Accounts

Wenn du ein Programm auf Solana bereitstellst, wird dafür immer das Doppelte seiner Größe reserviert. Mit v1.16 kannst du Programme mit größenveränderbaren Daten-Accounts bereitstellen. Du kannst dein Programm also zunächst mit einem kleineren Account bereitstellen und dessen Größe später erweitern. Dabei zahlst du nur für den zusätzlichen Speicher. Die Unterstützung größenveränderbarer Accounts bietet Entwicklern, die Anwendungen auf Solana bereitstellen, mehr Flexibilität und eine bessere Ressourcenzuweisung.

Epoch Accounts Hash

In früheren Versionen gab es Probleme mit Blöcken und der Verifizierung aller Accounts im Zustand. Wenn ein Validator längere Zeit nicht mit einem bestimmten Account interagierte, konnte er eine beschädigte Version dieses Accounts besitzen, ohne es zu bemerken. Das lag daran, dass der Zustand des Accounts nicht mit dem Zustand anderer Validator-Nodes abgeglichen wurde, solange keine Transaktionen seinen Zustand änderten.

v1.16 behebt dieses Problem mit dem Epoch Accounts Hash. Dabei handelt es sich um einen Hash aller Accounts, der am Ende jeder Epoche erzeugt wird, selbst wenn mit diesen Accounts nicht interagiert wurde. Mit dem Epoch Accounts Hash kann das Netzwerk Nodes mit beschädigten Daten identifizieren und abspalten. Das erhöht die Integrität und Sicherheit von Solana.

Systemoptimierung

Bei der Systemoptimierung werden das Betriebssystem und die Hardwarekonfiguration eines Validators für eine optimale Leistung angepasst. Mit dem v1.16-Release wurde solana-sys-tuner entfernt. Stattdessen werden jetzt manuelle Tests empfohlen. Die Funktion wurde entfernt, weil die Spalten TransactionStatus und AddressSignature der RocksDB in früheren Versionen nicht ordnungsgemäß bereinigt wurden. Außerdem war die regelmäßige Komprimierung, die Speicherplatz zurückgewinnt, standardmäßig deaktiviert. Dadurch wuchsen diese Spalten bei Nodes mit dem Flag --enable-rpc-transaction-history unbegrenzt. Dank des folgenden Commits wird der Speicherplatz bei Validatoren mit diesem Flag nun effizienter verwaltet. Das vereinfacht die Speicheranforderungen von Validatoren erheblich, da unnötige Transaktionsstatus und Adresssignaturen nicht mehr gespeichert werden müssen.

Fazit

Solanas v1.16-Release ist ein bedeutender Meilenstein und das Ergebnis von zehn Monaten Entwicklungsarbeit. Die langsame Veröffentlichung ist auf die Priorisierung von QUIC zurückzuführen. Daher waren diese Fortschritte bei vertraulichen Transfers, der Zero-Knowledge-Unterstützung und der Optimierung von Validatoren längst überfällig. Dennoch sind diese Verbesserungen bahnbrechend. Dieses Release hebt Effizienz und Datenschutz auf Solana auf ein neues Niveau.

Solana Labs stellt künftig auf einen agileren Release-Zyklus um und plant ungefähr alle drei Monate ein neues Release. Diese künftigen Releases sollen deutlich kleiner als v1.16 ausfallen. Das ermöglicht schnellere Iterationen und reduziert das Risiko bei der Bereitstellung. Den Release-Zeitplan für v1.17 findest du hier. Auch dieses mit Spannung erwartete Release soll eine noch bessere Zero-Knowledge-Unterstützung und die mögliche Einführung von Posidon-Syscalls bieten.

Wenn du bis hierher gelesen hast, Anon: Danke! Mit einem agileren Release-Zyklus und zahlreichen neuen Funktionen und Verbesserungen sieht Solanas Zukunft besser aus als je zuvor. Ob du Entwickler, Investor, Validator oder Solana-Enthusiast bist: Behalte die kommenden Releases im Blick! Deine Reise mit Solana fängt gerade erst an.

Zusätzliche Ressourcen und weiterführende Literatur

• Zeitplan für die Aktivierung von Feature-Gates
• Prozess zur Aktivierung von Feature-Gates
• Sicherheitsaudits von Solana
• Solana Beach – Validator-Seite

‍