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

Einführung

Die Annahme von Solanas 1.18-Update durch eine Supermehrheit ist ein wichtiger Meilenstein. Das Update bringt zahlreiche Verbesserungen und neue Funktionen, die Performance, Zuverlässigkeit und Effizienz des Netzwerks steigern sollen. Eine der wichtigsten Änderungen ist die Einführung eines zentralen Schedulers. Dieser neue Scheduler soll die Verarbeitung von Transaktionen optimieren und genauere sowie effizientere Prioritätsberechnungen ermöglichen. Weitere Verbesserungen an der Laufzeitumgebung und an Programm-Deployments sorgen beispielsweise selbst bei Spitzenlasten für eine zuverlässigere Performance.

Dieser Artikel stellt die Neuerungen und Verbesserungen von Release 1.18 vor. Wir betrachten die Gründe für diese Änderungen, die Details der neuen Funktionen und ihre erwarteten Auswirkungen auf das Netzwerk. Ganz gleich, ob du einen Validator betreibst, entwickelst oder Solana einfach nur nutzt: Diese umfassende Übersicht über das 1.18-Update liefert dir alle Informationen, die du brauchst, um die Vorteile der neuen Verbesserungen zu verstehen und zu nutzen.

Zunächst müssen wir über Anza sprechen, ein neu gegründetes Entwicklungsunternehmen, das diese Änderungen vorantreibt und eine wichtige Rolle bei der fortlaufenden Entwicklung von Solana spielt.

Was ist Anza?

Anza ist ein neu gegründetes Softwareentwicklungsunternehmen, das von ehemaligen Führungskräften und Core Engineers von Solana Labs ins Leben gerufen wurde. Die Gründung ist ein strategischer Schritt zur Stärkung des Solana-Ökosystems und soll dessen Zuverlässigkeit, Dezentralisierung und Netzwerkstabilität verbessern. Anza will das Solana-Ökosystem durch die Entwicklung wichtiger Infrastruktur, Beiträge zu zentralen Protokollen und die Förderung innovativer neuer Tools voranbringen.

Zum Gründungsteam gehören Jeff Washington, Stephen Akridge, Jed Halfon, Amber Christiansen, Pankaj Garg, Jon Cinque und mehrere Core Engineers von Solana Labs.

Anza konzentriert sich mit der Entwicklung von Agave – einem Fork des Validator-Clients von Solana Labs – auf die Weiterentwicklung und Optimierung der Validator-Clients von Solana. Anzas Ambitionen gehen jedoch über die Entwicklung des eigenen Validator-Clients hinaus und umfassen Verbesserungen im gesamten Ökosystem. Dazu zählen die Entwicklung von Token Extensions und einer angepassten Rust-/Clang-Toolchain. Mit einem offenen, gemeinschaftlichen Entwicklungsansatz will Anza das Solana-Ökosystem schneller voranbringen und verbessern.

Was ist Agave?

Wie im vorherigen Abschnitt kurz erwähnt, ist Agave ein von Anza vorangetriebener Fork des Validator-Clients von Solana Labs. Der Begriff „Fork“ bedeutet in diesem Zusammenhang, dass Anzas Entwicklungsteam den vorhandenen Code aus dem Repository von Solana Labs übernommen und einen neuen, von der ursprünglichen Codebasis getrennten Entwicklungszweig gestartet hat. So kann Anza eigene Verbesserungen, Funktionen und Optimierungen am Client von Solana Labs umsetzen.

Der Migrationsprozess

Die Migration des Clients in Anzas GitHub-Organisation begann am 1. März. Zunächst wird Agave das Repository von Solana Labs spiegeln, damit die Community Zeit hat, sich umzustellen. Während dieser Phase schließt Anza Pull Requests (PRs) und migriert relevante Issues in das Repository von Agave. Agave und die Versionen 1.17 und 1.18 des Solana-Labs-Clients werden funktional identisch sein. Anza plant, Agave v2.0 diesen Sommer zu veröffentlichen, den Solana-Labs-Client zu archivieren und dem gesamten Netzwerk den Wechsel zum neuen Agave-Client zu empfehlen.

Der Migrationsprozess von Solana Labs zu Agave wird öffentlich auf GitHub dokumentiert.

Die Agave Runtime

Die grundlegende Architektur der Agave Runtime basiert auf der Solana Virtual Machine (SVM). Sie bildet das Rückgrat für die Ausführung der zentralen Funktionen, die von der Sealevel-Laufzeit definiert werden. 

Das Solana-Protokoll definiert die Laufzeit als zentrale Komponente zur Verarbeitung von Transaktionen und Aktualisierung des Zustands in der Account-Datenbank. Diese Spezifikation wurde von den Clients Agave und Firedancer übernommen und weiterentwickelt. Das Wesentliche an der SVM ist ihre Fähigkeit, alle Solana-Programme auszuführen und Account-Zustände parallel zu ändern.

Das Konzept einer Bank ist entscheidend, um die Verarbeitung von Transaktionen und die Änderungen in 1.18 zu verstehen. Eine Bank ist sowohl eine Logikkomponente als auch eine Darstellung des Zustands des Ledgers zu einem bestimmten Zeitpunkt. Sie fungiert als komplexe Steuereinheit, die die Account-Datenbank verwaltet, Client-Accounts verfolgt, die Programmausführung steuert und die Integrität sowie Fortschreibung von Solanas Ledger sicherstellt. Eine Bank kapselt den Zustand, der aus den Transaktionen eines bestimmten Blocks hervorgeht, und dient damit als Momentaufnahme des Ledgers zu diesem Zeitpunkt.

Jede Bank verfügt über die für die Transaktionsausführung nötigen Caches und Referenzen. Dadurch kann sie aus einem vorherigen Snapshot oder dem Genesis-Block initialisiert werden. Während der Banking Stage, in der der Validator Transaktionen verarbeitet, dienen Banks dazu, Blöcke zusammenzustellen und später deren Integrität zu prüfen. Dieser Lebenszyklus umfasst das Laden von Accounts, die Verarbeitung von Transaktionen, das Einfrieren der Bank zur Finalisierung des Zustands und schließlich ihre Verankerung als Root, wodurch sie dauerhaft wird.

Allgemein betrachtet lädt, kompiliert und führt die Engine zur Transaktionsverarbeitung innerhalb der Agave Runtime Programme aus. Sie verwendet Just-in-Time-Kompilierung (JIT) und speichert kompilierte Programme im Cache, um die Ausführung effizienter zu machen und unnötige Neukompilierungen zu vermeiden. Programme werden vor dem Deployment in das eBPF-Format kompiliert. Anschließend erstellt die Laufzeit mit dem rBPF-Toolkit eine virtuelle eBPF-Maschine. Diese führt die JIT-Kompilierung von eBPF in x86_64-Maschinencode-Anweisungen durch und nutzt dabei die verfügbare Hardware vollständig aus. Dadurch werden Programme effizient ausgeführt.

Das 1.18-Update führt einen zentralen Transaktions-Scheduler ein, der eng mit den Effizienzsteigerungen der Agave Runtime verknüpft ist. Indem das Update verbessert, wie Transaktionen kompiliert, ausgeführt und über Banks verwaltet werden, ermöglicht es einen schlankeren und effizienteren Scheduling-Prozess. Das führt wiederum zu kürzeren Verarbeitungszeiten und höherem Durchsatz. Die neue Agave Runtime und ihr Client bilden die Grundlage für diese Verbesserungen. Daher ist ein allgemeines Verständnis wichtig, bevor wir uns mit den Details des neuen Schedulers befassen. 

Wenn du mehr über die Agave Runtime erfahren möchtest, empfehle ich den Artikel von Joe Caulfield zu diesem Thema. Er geht ausführlich darauf ein und enthält viele hilfreiche Codebeispiele.

Ein effizienterer Transaktions-Scheduler

Die aktuelle Implementierung

In der Pipeline zur Transaktionsverarbeitung gelangen Transaktionspakete zunächst über den Paket-Ingress in das System. Anschließend werden ihre Signaturen in der SigVerify-Phase geprüft. Dieser Schritt stellt sicher, dass jede Transaktion gültig und vom Absender autorisiert ist.

Nach der Signaturprüfung werden die Transaktionen an die Banking Stage gesendet. Die Banking Stage hat sechs Threads: Zwei verarbeiten Vote-Transaktionen aus der Transaction Processing Unit (TPU) oder aus Gossip, vier weitere verarbeiten Non-Vote-Transaktionen. Jeder Thread arbeitet unabhängig und empfängt Pakete aus einem gemeinsamen Kanal. SigVerify sendet Pakete also in Batches. Jeder Thread zieht Transaktionen aus dem gemeinsamen Kanal und speichert sie in einem lokalen Puffer. 

Der lokale Puffer empfängt die Transaktionen, bestimmt ihre Priorität und sortiert sie entsprechend. Diese Queue ist dynamisch und wird laufend aktualisiert, um Änderungen am Transaktionsstatus und an der Netzwerkauslastung in Echtzeit abzubilden. Wenn Transaktionen zur Queue hinzukommen, wird ihre Reihenfolge neu bewertet. So stehen die Transaktionen mit der höchsten Priorität zuerst zur Verarbeitung bereit.

Dieser Prozess läuft kontinuierlich. Was mit den Transaktionspaketen geschieht, hängt von der Position des Validators im Leader-Zeitplan ab. Ist der Validator in naher Zukunft nicht als Leader eingeplant, leitet er die Pakete an den nächsten Leader weiter und verwirft sie anschließend. Nähert sich der Validator seinem vorgesehenen Leader-Slot (~20 Slots entfernt), leitet er Pakete weiterhin weiter, verwirft sie aber nicht mehr. So können sie in einen seiner eigenen Blöcke aufgenommen werden, falls andere Leader sie nicht verarbeiten. Zwei Slots bevor ein Validator zum Leader wird, hält er Pakete zurück: Er nimmt sie an, tut aber zunächst nichts damit, damit er sie verarbeiten kann, sobald er Leader ist.

Während der Blockproduktion nimmt jeder Thread die obersten 128 Transaktionen aus seiner lokalen Queue, versucht Locks zu setzen und prüft, lädt, verarbeitet, erfasst und bestätigt die Transaktionen anschließend. Schlägt das Setzen eines Locks fehl, wird die Transaktion später erneut versucht. Sehen wir uns die einzelnen Schritte genauer an:

• Lock: Dieser Schritt prüft, für welche Transaktionen der Thread Locks setzen kann. Jede dieser Transaktionen liest und schreibt eine bestimmte Anzahl von Accounts. Der Validator muss daher sicherstellen, dass keine Konflikte bestehen
• Prüfen: Dieser Schritt prüft, ob die Transaktion zu alt ist oder bereits verarbeitet wurde. Beachte, dass Banks über einen Status-Cache verfügen, der die Transaktionen der letzten 150–300 Slots erfasst
• Laden: Dieser Schritt lädt die Accounts, die zur Ausführung einer bestimmten Transaktion erforderlich sind. Außerdem wird geprüft, ob der Gebührenzahler die Gebühren tatsächlich bezahlen kann und ob das aufgerufene Programm gültig ist. Im Wesentlichen lädt dieser Schritt die Accounts und führt erste Vorbereitungen durch
• Ausführen: Dieser Schritt führt jede Transaktion aus
• Erfassen: Die Ergebnisse der ausgeführten Transaktionen werden zum Hashen an den Proof of History Service gesendet. Hier wird die Transaktionssignatur ausgegeben
• Bestätigen: Ist der Erfassungsschritt erfolgreich, werden die Transaktionen bestätigt. Dieser Schritt überträgt die Änderungen außerdem zurück in das Account-System, damit spätere Transaktionen in diesem oder nachfolgenden Slots die aktualisierte Ansicht jedes Accounts verwenden‍
• Unlock: Die im ersten Schritt gesetzten Locks für die einzelnen Accounts werden aufgehoben

Die Banking Stage erstellt diese Transaktions-Batches mit einem Multi-Iterator-Ansatz. Ein Multi-Iterator ist ein Programmiermuster, mit dem sich ein Datensatz gleichzeitig in mehreren Sequenzen durchlaufen lässt. Stell dir mehrere Leser vor, die dasselbe Buch lesen und jeweils in unterschiedlichen Kapiteln beginnen. Sie stimmen sich ab, damit sie nicht gleichzeitig dieselbe Seite lesen, falls ihr Verständnis des Inhalts sich gegenseitig beeinflussen könnte. In der Banking Stage sind diese „Leser“ Iteratoren und das „Buch“ ist die Sammlung der Transaktionen, die auf ihre Verarbeitung warten. Der Multi-Iterator soll Transaktionen effizient durchsuchen und sie in Batches gruppieren, die ohne Lock-Konflikte verarbeitet werden können.

Zunächst werden die Transaktionen anhand ihrer Priorität in einen Vektor serialisiert. Dadurch erhält der Multi-Iterator eine strukturierte Sequenz, die er in konfliktfreie Batches unterteilen kann. Der Multi-Iterator beginnt am Anfang des serialisierten Vektors und platziert Iteratoren an Stellen, an denen Transaktionen nicht miteinander in Konflikt stehen. So erstellt er Batches aus 128 Transaktionen ohne Lese-Schreib- oder Schreib-Schreib-Konflikte. Steht eine Transaktion mit dem gerade entstehenden Batch in Konflikt, wird sie übersprungen und nicht markiert. So kann sie in einen späteren Batch aufgenommen werden, in dem der Konflikt nicht mehr besteht. Dieser iterative Prozess passt sich dynamisch an, während weitere Transaktionen verarbeitet werden. 

Nachdem ein Batch erfolgreich erstellt wurde, werden die Transaktionen ausgeführt. Bei erfolgreicher Ausführung werden sie im Proof of History Service erfasst und an das Netzwerk übertragen.

Probleme der aktuellen Implementierung

Die aktuelle Implementierung hat mehrere Schwachstellen, die die Performance beeinträchtigen können. Dadurch drohen Engpässe bei der Transaktionsverarbeitung und eine inkonsistente Priorisierung. Diese Probleme ergeben sich hauptsächlich aus der Architektur der Banking Stage und der Art, wie das System Transaktionen verarbeitet.

Ein grundlegendes Problem besteht darin, dass die vier unabhängigen Threads zur Verarbeitung von Non-Vote-Transaktionen jeweils eine eigene Sicht auf die Priorität der Transaktionen in ihrem Thread haben. Diese Abweichung kann zu Schwankungen oder Inkonsistenzen bei der Reihenfolge der Transaktionen führen. Besonders deutlich werden sie, wenn alle Transaktionen mit hoher Priorität miteinander in Konflikt stehen. Da jeder Thread Pakete im Wesentlichen zufällig aus dem gemeinsamen SigVerify-Kanal zieht, enthält jeder Thread eine zufällige Auswahl aller Transaktionen. Bei stark umkämpften Ereignissen, etwa einem beliebten NFT-Mint, befinden sich wahrscheinlich viele Transaktionen mit hoher Priorität gleichzeitig in mehreren Threads der Banking Stage. Das ist problematisch, weil es zu Lock-Konflikten zwischen den Threads kommen kann. Da die Threads mit unterschiedlichen Prioritäten arbeiten, konkurrieren sie möglicherweise um die Verarbeitung dieser Transaktionen. Erfolglose Lock-Versuche verschwenden dabei unbeabsichtigt Rechenzeit.

Stell dir die Banking Stage als Orchester vor, in dem jeder Thread eine andere Instrumentengruppe bildet: Streicher, Blechbläser, Holzbläser und Schlagzeug. Im Idealfall koordiniert ein Dirigent diese Gruppen und sorgt für ein harmonisches Zusammenspiel. Das aktuelle System ähnelt jedoch einem Orchester, das ein komplexes Stück ohne Dirigenten aufführen will. Jede Gruppe spielt ihre eigene Melodie und gerät regelmäßig mit den anderen in Konflikt. Die Transaktionen mit hoher Priorität sind die Solopassagen, die alle Gruppen gleichzeitig spielen wollen. Das sorgt für Chaos. Diese fehlende Koordination zeigt, dass Solanas Transaktionsverarbeitung einen zentralen „Dirigenten“ braucht, der wie in einem Orchester für Effizienz und Harmonie sorgt.

Der neue Transaktions-Scheduler

Das 1.18-Update führt einen zentralen Scheduling-Thread ein. Er ersetzt das bisherige Modell mit vier unabhängigen Banking-Threads, die ihre Priorisierung und Verarbeitung von Transaktionen jeweils selbst verwalten. In der neuen Struktur empfängt nur noch der zentrale Scheduler die Transaktionen aus der SigVerify-Phase. Er erstellt eine Priority Queue und verwaltet die Priorisierung und Verarbeitung der Transaktionen mithilfe eines Abhängigkeitsgraphen.

Dieser Abhängigkeitsgraph wird als Prio-Graph bezeichnet. Es handelt sich um einen gerichteten azyklischen Graphen, der beim Hinzufügen neuer Transaktionen verzögert ausgewertet wird. Transaktionen werden in den Graphen eingefügt, um Ausführungsketten zu bilden, und anschließend nach Zeit und Priorität entnommen. Bei Transaktionen mit Konflikten hat die zuerst eingefügte Transaktion immer die höhere Priorität. Im obigen Beispiel gibt es die Transaktionen A bis H. Die Transaktionen A und E haben innerhalb ihrer jeweiligen Ketten die höchste Priorität und stehen nicht miteinander in Konflikt. Der Scheduler arbeitet von links nach rechts und verarbeitet die Transaktionen in Batches:

Transaktionen A und E werden als erster Batch verarbeitet, dann B und F, danach C, D und G und schließlich H als letzter Batch. Wie du siehst, stehen die Transaktionen mit der höchsten Priorität ganz oben im Graphen, also ganz links. Während der Scheduler die Transaktionen in absteigender Reihenfolge prüft, erkennt er Konflikte. Wenn eine Transaktion mit einer höher priorisierten Transaktion in Konflikt steht, wird im Graphen eine Kante erstellt, die diese Abhängigkeit darstellt. Beispielsweise stehen C und D mit B in Konflikt.

Das neue Scheduler-Modell löst mehrere zentrale Probleme des Multi-Iterator-Ansatzes:

• Konsistente Priorisierung: Das neue System zentralisiert den Empfang und das Scheduling von Transaktionen. Dadurch werden alle Transaktionen in einer einheitlichen Prioritätsreihenfolge verarbeitet. Die zuvor durch unterschiedliche Ansichten der Threads auf die Transaktionsprioritäten verursachten Schwankungen entfallen
• Weniger Verzögerungen bei der Verarbeitung: Der Prio-Graph sorgt dafür, dass zur Ausführung vorbereitete Batches mit hoher Wahrscheinlichkeit ohne Lock-Konflikte erfolgreich sind. Das verkürzt die Verarbeitungszeit und vermeidet Verzögerungen durch Lock-Contention. Beachte die Formulierung „mit hoher Wahrscheinlichkeit erfolgreich“: Streng genommen erstellt der Prio-Graph keine Batches, bei denen Lock-Fehler unmöglich sind. Konflikte mit Vote-Threads können weiterhin auftreten, auch wenn dies ein sehr seltener Grenzfall ist
• Skalierbarkeit und Flexibilität: Mit dem neuen Scheduler-Design lässt sich die Zahl der Threads erhöhen, ohne dass dadurch wie bisher mehr Lock-Konflikte zu erwarten sind. Möglich machen das die zentrale Sicht auf Locks und die kontrolliertere Verteilung von Transaktionen auf Worker 

Der zentrale Scheduler in 1.18 dürfte die Transaktionsverarbeitung deutlich verbessern und die Komplexität sowie den Overhead des bisherigen Systems reduzieren. Das wird voraussichtlich zu kürzeren Verarbeitungszeiten, höherem Durchsatz und einem stabileren Netzwerk führen. Wegen der Verzögerungen bei der Veröffentlichung von 1.18 wurde der Scheduler seit seiner Einführung weiter verbessert. Beispielsweise wurde die Precompile-Verifizierung von Transaktionen für mehr Effizienz in Worker-Threads verschoben. Außerdem sind die CU-Limits jetzt sinnvoller und die Verhältnisse zwischen geschätzten und tatsächlichen Werten deutlich niedriger als beim alten Scheduler. Der neue Scheduler kann nun CUs verwenden, um geplante Arbeits-Queues zu drosseln. So verhindert er, dass aufgrund von Account-Konflikten übermäßig viele Aufgaben in die Queue gelangen.

Beachte, dass der zentrale Scheduler nicht standardmäßig aktiviert ist und beim Start eines Validators mit dem neuen Flag --block-production-method central-scheduler aktiviert werden muss. Derzeit ist er optional, wird in zukünftigen Releases aber zum Standard-Scheduler. Der alte Scheduler lässt sich außerdem mit dem Flag --block-production-method thread-local-multi-iterator aktivieren. Dieses ist standardmäßig aktiviert. Nutze es in zukünftigen Releases aber bitte nicht mehr: Der zentrale Scheduler ist deutlich effizienter und behebt die Probleme des alten Schedulers.

Effektivere Prioritätsberechnung 

1.18 verbessert außerdem die Ermittlung der Transaktionspriorität. Dadurch wird der Prozess im Hinblick auf Ressourcennutzung und Kostendeckung fairer und effizienter. Zuvor basierte die Priorisierung von Transaktionen hauptsächlich auf der Priorität des Compute-Budgets. Das führte mitunter zu einer suboptimalen Bepreisung von Compute Units. Der Grund: Die Priorisierung berücksichtigte die eingenommenen Grundgebühren nicht ausreichend. Dadurch konnten Ressourcen zu niedrig bepreist werden, was die operative Effizienz des Netzwerks beeinträchtigte.

Der neue Ansatz passt die Berechnung der Transaktionspriorität so an, dass Transaktionsgebühren und zugehörige Kosten anhand der Formel Priorität = Gebühren / (Kosten + 1) berücksichtigt werden. Die Gebühren stehen dabei für die mit einer bestimmten Transaktion verbundenen Transaktionsgebühren. Die Kosten entsprechen dem Rechen- und Ressourcenverbrauch, den Solanas Kostenmodell ermittelt. Die zusätzliche „1“ im Nenner verhindert eine Division durch null. 

Wir können die Formel weiter aufschlüsseln, um Gebühren und Kosten genauer darzustellen:

Die Kosten einer Transaktion werden nun umfassend berechnet und berücksichtigen alle damit verbundenen Rechen- und Betriebskosten. Dadurch spiegeln Prioritätsberechnungen den tatsächlichen Ressourcenverbrauch einer Transaktion wider. Entwickler und Nutzer erhalten also eine höhere Priorität, wenn sie weniger Compute Units anfordern. Außerdem erhalten einfache Übertragungen auch ohne Prioritätsgebühren eine gewisse Priorität in der Queue.

Verbesserte Programm-Deployments

1.18 verbessert Programm-Deployments auch deutlich im Hinblick auf Deployment-Zuverlässigkeit und Ausführungseffizienz. 

Das neue Update behebt ein Problem, bei dem Programme, die im letzten Slot einer Epoche bereitgestellt wurden, die für die folgende Epoche geplanten Änderungen an der Laufzeitumgebung nicht korrekt übernahmen. Ein in dieser Übergangsphase bereitgestelltes Programm verwendete daher fälschlicherweise die alte Laufzeitumgebung. 1.18 passt den Deployment-Prozess so an, dass die Laufzeitumgebung jedes am Ende einer Epoche bereitgestellten Programms mit der Umgebung der kommenden Epoche übereinstimmt.

1.18 behebt auch das Problem, dass sich für Deployment-Transaktionen kein Preis oder Limit für Compute Units festlegen ließ. Dazu wird das Flag --with-compute-unit-price zu den CLI-Befehlen für Programm-Deployments hinzugefügt. Das Flag kann mit den Befehlen solana program deploy und solana program write-buffer verwendet werden. Das Limit für Compute Units wird festgelegt, indem jeder Typ von Deployment-Transaktion simuliert und das Limit auf die Anzahl der verbrauchten Compute Units gesetzt wird.  

Eine weitere wichtige Verbesserung betrifft den Umgang mit Blockhashes bei großen Programm-Deployments. Vor 1.18 wurden Transaktionen, die mit sign_all_messages_and_send gesendet wurden, auf 100 TPS gedrosselt. Bei größeren Programmen kann die Zahl der Deployment-Transaktionen in die Tausende gehen. Dadurch konnten Transaktionen verzögert werden und abgelaufene Blockhashes verwenden, da viele von ihnen jeweils mehr als zehn Sekunden warten mussten. 1.18 verzögert das Signieren von Deployment-Transaktionen mit einem aktuellen Blockhash bis nach der Drosselungsverzögerung. Blockhashes werden jetzt alle fünf Sekunden aktualisiert. Deployments mit mehr als 500 Transaktionen profitieren dadurch von einem aktuelleren Blockhash.

Außerdem verbessert 1.18 die Verarbeitung von Programm-Deployments und die Verifizierung von Transaktionen im Netzwerk. Zuvor wurden einige Programme aufgrund von Fehlern bei der Ermittlung des Account-Status fälschlicherweise als FailedVerification markiert. Dadurch konnten Programme falsch gekennzeichnet werden, obwohl sie keine Prüfung tatsächlich nicht bestanden hatten. Diese Programme werden nun korrekt als Closed erkannt, wenn sie nicht aktiv sein sollen. So werden nur problematische Programme für eine erneute Prüfung markiert und unnötige Neuverifizierungen vermieden.

Auch der Prozess zur Aktualisierung von Programmzuständen wurde verbessert. Programme können jetzt innerhalb desselben Slots, in dem sie bereitgestellt werden, vom Status Closed in einen aktiven Zustand wechseln. Dadurch werden Programme schneller und zuverlässiger betriebsbereit, was in Zeiten hoher Nachfrage entscheidend ist. Beachte jedoch, dass diese Verbesserung weiterhin der Abkühlphase von einem Slot für Aufhebung, erneutes Deployment und Deployment sowie der Sichtbarkeitsverzögerung von einem Slot unterliegt. Die Anpassungen helfen also, die Netzwerklast effektiver zu steuern und bestimmte Arten von Überlastung zu verhindern. Den Workflow für dApp-Entwickler verändern sie jedoch nicht wesentlich.

„Der Congestion Patch“ – bessere Überlastungsbewältigung

Testnet-Version 1.18.11, angekündigt als „The Congestion Patch“, schlug Änderungen vor, um Solanas jüngste Überlastung zu beheben. Dieses Release ist nicht spezifisch für 1.18 und wurde auf 1.17.31 zurückportiert. Dennoch müssen wir darüber sprechen.

Die große Änderung besteht darin, dass QUIC Peers mit äußerst geringem Stake in Stake-Weighted Quality of Service (SWQoS) nun wie Peers ohne Stake behandelt. Damit wird verhindert, dass Nodes mit einem sehr geringen Stake das System ausnutzen, um unverhältnismäßig viel Bandbreite zu erhalten. Außerdem konnten die bisherigen Metriken nicht zeigen, welche Anteile der gesendeten und gedrosselten Pakete von Nodes mit beziehungsweise ohne Stake stammten. Daher wurden diese Metriken ergänzt, um mehr Transparenz zu schaffen. Auch die Verarbeitung von Paketabschnitten wurde optimiert. Dazu wurden Instanzen von vec durch smallvec ersetzt, um eine Allokation pro Paket einzusparen. Das ist möglich, weil Streams die Größe eines Pakets haben und daher nur wenige erwartet werden. 

Zuvor wurden in der Banking Stage alle Pakete an den nächsten Node weitergeleitet. 1.18 ändert dies, sodass nur Pakete von Nodes mit Stake weitergeleitet werden. Damit werden Verbindungen mit Stake künftig wichtiger denn je, da sie bei der Berechnung der Priorität und der Weiterleitung von Transaktionen stärker gewichtet werden.

Verbesserte Dokumentation

Das 1.18-Update verbessert auch die Übersetzungsunterstützung für die offizielle Solana-Dokumentation erheblich, damit sie einem weltweiten Publikum besser zugänglich ist. Zu den Neuerungen gehören ein Upgrade der Crowdin-CLI und ihrer Konfiguration, was die sprachübergreifende Synchronisierung von Dokumenten vereinfacht, sowie ein neuer Befehl serve für bessere lokale Tests mit Docusaurus. Die Dokumentation verbessert außerdem die Verarbeitung statischer Inhalte. PDF-Dateien werden direkt mit GitHub-Blobs verknüpft, um Probleme mit relativen Pfaden in übersetzten Builds zu vermeiden.

Ein aktualisiertes README erklärt Entwicklern den Prozess für Übersetzungsbeiträge und den Umgang mit häufigen Problemen wie erforderlichen Umgebungsvariablen und typischen Build-Fehlern. Hinzu kommen Verbesserungen am Continuous-Integration-Ablauf, der Übersetzungen jetzt nur noch in Builds des stabilen Kanals einbezieht. Dadurch erreichen nur geprüfte und stabile Dokumentationen die Endnutzer. Diese Änderungen sollen Beiträge vereinfachen, die Qualität der offiziellen Dokumentation verbessern und allen Nutzern Zugang zu zuverlässigen und präzisen Informationen geben.

Fazit

Das von Anza vorangetriebene 1.18-Update verbessert die Transaktionsverarbeitung, Prioritätsberechnungen, Programm-Deployments, offizielle Dokumentation und allgemeine Netzwerk-Performance erheblich. Dank des zentralen Schedulers und verschiedener Korrekturen gegen die jüngsten Überlastungen kann Solana Spitzenlasten besser bewältigen und ein effizientes, zuverlässiges Netzwerkverhalten sicherstellen. Solana bietet die beste Chance auf eine skalierbare Blockchain. Dieses Update bestätigt das Potenzial.

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

Zusätzliche Ressourcen

• Agave-Client
• Zeitplan für die Umstellung auf Agave
• Anza
• Prio-Graph-Crate
• Solana Banking Stage und Scheduler
• Im Fokus: Solanas Scheduler