Agave-v2.0-Update: Alles, was du wissen musst

Zusammenfassung von Agave 2.0

Die Veröffentlichung des Agave-Validator-Clients v2.0 ist ein wichtiger Meilenstein auf Solanas Weg zu einem robusteren Multi-Client-Ökosystem. Dieses Update enthält mehrere entscheidende Verbesserungen für mehr Netzwerkleistung, Zuverlässigkeit und Effizienz. Zu den wichtigsten Änderungen gehören:

• Umfangreiche Refaktorierungen und Optimierungen der Codebasis
• Partitionierte Epochen-Rewards
• Auszahlung der vollständigen Priority Fee an Validatoren
• Der neue zentrale Scheduler ist jetzt standardmäßig aktiviert
• Das Programm ZK ElGamal Proof
• Get-Sysvar-Syscall
• GetEpochStake-Syscall
• MoveStake und MoveLamports
• Entfernung veralteter RPC-Methoden
• Umbenennung von Crates

Ganz gleich, ob du einen Validator betreibst, auf der Plattform entwickelst oder Solana aktiv nutzt: Dieser umfassende Überblick über das Agave-2.0-Update vermittelt dir alles, was du brauchst, um die neuesten Innovationen zu verstehen und zu nutzen.

Warum ist Agave 2.0 ein Major-Version-Update?

Es gibt nicht länger einen einzigen „Solana-Validator“. Agave 2.0 setzt auf Solanas neue Multi-Client-Welt und vollzieht einen klaren Bruch mit dem alten GitHub-Repository von Solana Labs. Das Repository von Solana Labs wird archiviert. Neue Pull Requests oder Issues werden nicht mehr akzeptiert. Zuvor spiegelte dieses Repository die Aktivitäten im Agave-Repository. Falls noch nicht geschehen, sollten Entwickler alle Aktivitäten in das Anza-Agave-Repository auf GitHub migrieren. Der Migrationsprozess von Solana Labs zu Agave begann am 1. März und wird öffentlich auf GitHub nachverfolgt.

Mit der Weiterentwicklung des Ökosystems müssen Betreiber den Betrieb eines oder mehrerer Clients unterstützen. Im Zuge dieser Umstellung werden mehrere Crates umbenannt. Dadurch wird der Namespace für mehrere Clients freigegeben – insbesondere für Firedancer, das von unabhängigen Entwicklerteams verwaltet wird. Von Anza gepflegte Crates erhalten künftig das Präfix "agave". So lassen sie sich in der Multi-Client-Umgebung leicht als Anza-spezifische Abhängigkeiten erkennen.

‍Betroffen sind folgende Crates: 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Wie in unserem früheren Migrationsleitfaden beschrieben, führt das 2.0-Update mehrere Breaking Changes ein. Besonders wichtig ist die Entfernung mehrerer überholter und veralteter Endpunkte. Alle Solana-Entwickler sollten diese Änderungen inzwischen kennen. Ausführliche Informationen zu den RPC-Änderungen findest du am Ende dieses Artikels.

Einführung der Funktionen

Zum Zeitpunkt der Erstellung dieses Artikels verwenden ~20,7 % der Validatoren Version 2.0.14. Die Aktivierung von Feature Gates im Mainnet wurde vorübergehend pausiert. So kann die Einführung von v2.0 besser mit den Aktivierungen im Testnet und Devnet abgestimmt werden. Sobald v2.0 im Mainnet-Cluster weitgehend eingeführt ist, werden die Aktivierungen der Feature Gates voraussichtlich gemäß der geplanten Aktivierungsreihenfolge fortgesetzt. 

Die neuen vollständigen Funktionen, die in den folgenden Abschnitten behandelt werden, sind derzeit noch nicht live. Sie werden über den Lebenszyklus von 2.0 hinweg mithilfe eines Feature-Gate-Systems schrittweise eingeführt. Die Funktionen werden in bestimmten Epochen aktiviert. Grundlage sind ihre relative Priorität und die Reihenfolge ihrer Aktivierung in den Testnet- und Devnet-Clustern.

Vollständige Priority Fee für Validatoren

Dieses mit Spannung erwartete und intensiv diskutierte wirtschaftliche Update wird nun gemäß dem Vorschlag SIMD-0096 umgesetzt. Im Mai stimmten die Validatoren im Rahmen der Governance darüber ab. Die Abstimmung endete zum Ende der Epoche 620. 51,17 % des Stakes nahmen teil, davon stimmten 77,77 % dafür. Das per Feature Gate aktivierte Update wird die Handhabung von Priority Fees im Netzwerk grundlegend ändern. Im aktuellen Modell werden 50 % der Gebühren verbrannt und 50 % an Validatoren ausgezahlt. Im neuen Modell gehen 100 % der Priority Fees direkt an die Validatoren.

Priority Fees sind technisch gesehen optional. Mit der zunehmenden wirtschaftlichen Aktivität auf Solana haben sie sich jedoch als Standard etabliert. Diese Gebühren werden anhand der folgenden Formel in Mikro-Lamports (Millionstel eines Lamports) pro Compute Unit berechnet:

‍Priorisierungsgebühr = Preis pro Compute Unit (Mikro-Lamports) x Compute-Unit-Limit

Künftig erhalten Blockproduzenten alle Priority Fees. Dadurch werden die Anreize besser aufeinander abgestimmt. Zugleich sinkt die Wahrscheinlichkeit, dass Validatoren für die Aufnahme von Transaktionen Vereinbarungen außerhalb des Protokolls treffen, was in der Vergangenheit problematisch war.

Die Abschaffung der Gebührenverbrennung erhöht zwar die Nettoinflationsrate von SOL leicht, die Ausgabe neuer Token durch Staking-Rewards wirkt sich jedoch deutlich stärker aus. Eine detailliertere Aufschlüsselung dieser Dynamik findest du in unserem früheren Helius-Blogbeitrag über den Ausgabe- und Inflationsplan von Solana.

Partitionierte Epochen-Rewards

Partitionierte Epochen-Rewards sollen Stake-Rewards über mehrere Blöcke verteilen. Das reduziert Leistungsprobleme, die entstehen, wenn die Rewards im ersten Block jeder neuen Epoche verteilt werden. Der größte Engpass besteht darin, Updates in die wachsende Zahl aktiver Stake-Accounts im Netzwerk zurückzuschreiben. Mittlerweile gibt es davon etwa 1,4 Millionen.

Beim neuen Ansatz werden die Berechnung und Verteilung der Stake-Rewards an der Epochengrenze in zwei getrennte Phasen aufgeteilt:

• Phase zur Berechnung der Rewards: In dieser Phase werden die Epochen-Rewards für alle aktiven Stake-Accounts berechnet und zur Verteilung in geplante Abschnitte aufgeteilt.
• Phase zur Verteilung der Rewards: Die vorberechneten Epochen-Rewards werden entsprechend an die aktiven Stake-Accounts verteilt.

Ein Sysvar-Account namens EpochRewards unterstützt und überwacht den Prozess. Er verfolgt und verifiziert die Reward-Verteilung während der gesamten Verteilungsphase. Die EpochRewards-Sysvar zeichnet auf, ob die Verteilungsphase läuft, und speichert die Informationen, die zum Fortsetzen der Verteilung aus einem Snapshot benötigt werden. 

Berechnung der Rewards

Die Rewards werden im ersten Block der Epoche berechnet. Anschließend werden sie in Verteilungsabschnitte aufgeteilt und in der Bank gespeichert. Die Verteilung erfolgt während der Verteilungsphase.

Um die Auswirkungen auf die Blockverarbeitungszeit während der Verteilungsphase zu minimieren und sicherzustellen, dass jeder Block eine Teilmenge der Rewards deterministisch verteilt, sollen pro Block 4.096 Stake-Rewards verteilt werden. Damit ein starkes Wachstum der Anzahl an Stake-Accounts keine Probleme verursacht, ist die Anzahl der Blöcke auf 10 % aller Slots einer Epoche begrenzt. Nur wenn dieses Blocklimit erreicht wird, darf die Anzahl der Accounts pro Partition das Ziel von 4.096 überschreiten.

Verteilung der Rewards

Die Verteilung der Rewards beginnt direkt nach der Berechnungsphase mit dem zweiten Block der Epoche. Die Rewards werden am Anfang des Blocks verteilt, bevor die normale Transaktionsverarbeitung beginnt.

Dadurch sehen Nutzer die Gutschrift der Rewards auf ihren Stake-Accounts möglicherweise einige Blöcke später als zuvor. Das Nutzungserlebnis bleibt jedoch weitgehend gleich, da die längere Verarbeitungszeit des ersten Blocks an der Epochengrenze den Zugriff auf Stake-Accounts zuvor ebenfalls verzögerte. Ein weiterer Vorteil: Transaktionen ohne Staking können ohne Unterbrechung weiterverarbeitet werden. Zuvor waren sie während der Reward-Verteilung blockiert.‍

Da es mit etwa 1.500 vergleichsweise wenige Vote-Accounts gibt, bleibt der bestehende Mechanismus zur Verteilung von Vote-Rewards im ersten Block an der Epochengrenze unverändert. Nur Stake-Rewards werden über mehrere Blöcke verteilt.

Zentraler Scheduler jetzt standardmäßig aktiviert

Der zentrale Scheduler wurde erstmals mit dem v1.18-Update als Funktion veröffentlicht und war zuvor als „der Scheduler“ bekannt. Er war nicht standardmäßig aktiviert. Betreiber mussten ihn beim Start eines Validators mit dem Flag --block-production-method central-scheduler aktivieren. Jetzt ist er standardmäßig eingeschaltet. Die vorherige Scheduler-Implementierung hatte mehrere Probleme, die die Leistung beeinträchtigen konnten. Engpässe bei der Transaktionsverarbeitung führten häufig zu Schwankungen oder Inkonsistenzen bei der Reihenfolge und Priorisierung von Transaktionen.

Die neuere Implementierung ersetzt das bisherige Modell mit vier unabhängigen Banking-Threads, die jeweils ihre eigene Priorisierung und Verarbeitung von Transaktionen verwalteten. In der neuen Struktur empfängt ausschließlich der zentrale Scheduler die Transaktionen aus der SigVerify-Phase der TPU. Er erstellt eine Prioritätswarteschlange und verwendet einen Abhängigkeitsgraphen, den sogenannten Prio-Graph. So lassen sich die Verarbeitung und Priorisierung kollidierender Transaktionen besser steuern. Das neue Scheduler-Design erhöht Skalierbarkeit und Flexibilität. Die Anzahl der Threads kann steigen, ohne dass dabei wie zuvor zusätzliche Lock-Konflikte befürchtet werden müssen. Die erste Einführung des zentralen Schedulers hat nachweislich bessere Rewards erzeugt und damit die Einnahmen vieler Betreiber erhöht. In unserem früheren Helius-Beitrag zum Solana-v1.18-Update haben wir ausführlich erklärt, wie der zentrale Scheduler funktioniert.

ZK ElGamal Proof Program

Das ZK Token Proof Program, das ursprünglich für Version 1.17 vorgesehen war, ist jetzt veraltet und wird durch ein vielseitigeres, anwendungsunabhängiges ZK ElGamal Proof Program ersetzt. Das neue ZK ElGamal Proof Program übernimmt die anwendungsübergreifend nutzbaren Teile des ZK Token Proof Program. Dazu gehören die Überprüfung der Gültigkeit eines öffentlichen Schlüssels und des Wertebereichs, der in einem ElGamal-Chiffretext verschlüsselt ist. Anwendungsspezifische Elemente lässt es dagegen aus, etwa die für SPL-Token-Transferanweisungen erforderliche Validierung von Zero-Knowledge-Proofs. Das neue ZK ElGamal Proof Program wird unter der Adresse ZkE1Gama1Proof11111111111111111111111111111 in die Liste der integrierten Programme aufgenommen.

Weitere Informationen zum ZK Token Proof Program findest du in unserem ursprünglichen Beitrag im Helius-Blog.

Get-Sysvar-Syscall

Syscalls oder Systemaufrufe fordern Dienste vom Betriebssystem-Kernel an. Im Kontext von Solana ermöglicht ein Syscall den in der Solana Virtual Machine (SVM) ausgeführten Programmen, mit externen Ressourcen und Diensten zu interagieren. 

Sysvars stellen Informationen über den Zustand des Clusters bereit, etwa den aktuellen Block-Hash und Epochen-Rewards. Diese Accounts werden unter bekannten Adressen befüllt. Programme können über einen Sysvar-Account auf Sysvars zugreifen oder sie per Syscall abfragen. On-Chain-Programme verwenden zahlreiche Sysvars für verschiedenste Anwendungsfälle. Bestimmte Sysvars sind für den Betrieb des Netzwerks unerlässlich.

Der Syscall Get-Sysvar, der ursprünglich in SIMD-127 vom Anza-Entwickler Joe Caulfield vorgeschlagen wurde, führt eine einheitliche Syscall-Schnittstelle für den Zugriff auf Sysvar-Daten ein. Mit diesem Upgrade lassen sich zuvor nicht zugängliche Sysvar-Daten abrufen, darunter SlotHashes und StakeHistory. Über die neue Schnittstelle können Entwickler gezielt auf bestimmte Fragmente von Sysvar-Daten zugreifen – etwa durch Aufrufe von SlotHashes::get_slot(slot) und StakeHistory::get_entry(epoch) – ohne vollständige Datenstrukturen duplizieren zu müssen.

Das Update reduziert außerdem den Aufwand beim Ändern von Sysvar-Datenlayouts und beim Hinzufügen neuer Sysvars. Zuvor war für jede neue Sysvar ein entsprechender Syscall erforderlich. Diese enge Kopplung blähte die Syscall-Schnittstelle mit der Zeit auf und erschwerte die Wartung. Jetzt bedient ein einzelner sol_get_Sysvar-Syscall alle Sysvar-Schnittstellen. So können Daten aus jeder Sysvar einheitlich und effizient abgerufen werden.

Der neue Syscall vereinfacht das Ändern und Hinzufügen von Sysvars. Er reduziert die Komplexität und den Wartungsaufwand der Syscall-Schnittstelle erheblich. Außerdem schafft dieses Update die Grundlage dafür, den Zugriff von BPF-Programmen auf Sysvar-Daten zu erweitern. On-Chain-Programme können dadurch mehr Sysvar-Informationen lesen, ohne die Transaktionsgröße zu erhöhen.

GetEpochStake-Syscall

Der neue GetEpochStake-Syscall führt eine häufig gewünschte Funktion ein. Damit lässt sich der an einen Vote-Account delegierte Stake für die aktuelle Epoche effizienter und direkt on-chain abrufen.

Derzeit können Programme nicht auf Echtzeitdaten über den Stake zugreifen, der bestimmten Vote-Accounts für die aktuelle Epoche delegiert wurde. Das behindert Anwendungsfälle wie Validator-Governance und sekundäre Konsensmechanismen. Wenn diese Daten on-chain abgefragt werden können, ermöglicht das solche Anwendungen und schafft die Grundlage für künftige Anwendungsfälle.

Bei GetEpochStake geben Entwickler eine 32 Byte lange Vote-Account-Adresse an. Der Syscall gibt eine u64-Ganzzahl zurück, die den gesamten derzeit an diesen Vote-Account delegierten aktiven Stake darstellt. Falls die angegebene Adresse keinem gültigen Vote-Account entspricht oder nicht existiert, gibt der Syscall einfach 0 zurück.

MoveStake und MoveLamports

Zwei neue Anweisungen des Stake-Programms, MoveStake und MoveLamports, erleichtern Wertübertragungen zwischen Stake-Accounts. Diese erstmals in SIMD-0148 vorgeschlagenen Anweisungen unterstützen Entwickler dabei, Mittel ohne Kontrolle durch die Auszahlungsautorität zwischen Accounts mit übereinstimmenden Autoritäten zu verschieben.

Protokolle, die Stakes von Nutzern verwalten, hatten bisher Schwierigkeiten, Stakes auf mehrere Validatoren aufzuteilen und regelmäßig neu zwischen ihnen zu delegieren. Wenn ein Protokoll den Stake eines Nutzers zur Deaktivierung aufteilt, muss es die Lamports für die Mietbefreiung des neuen Accounts bereitstellen. Beim Zusammenführen dieser aufgeteilten Accounts kann das Protokoll die Lamports für die Mietbefreiung nicht zurückfordern.

MoveStake

MoveStake: Mit dieser Anweisung kann aktiver Stake zwischen Accounts verschoben werden – von einem aktiven Account zu einem anderen aktiven Account oder von einem aktiven zu einem inaktiven Account, wodurch dieser reaktiviert wird. Wird die gesamte Delegation des Quell-Accounts verschoben, wird der Quell-Account inaktiv. Das mietbefreite Guthaben bleibt in allen Szenarien unberührt. Für aktive Accounts gelten weiterhin die Regeln zur Mindestdelegation.

MoveLamports

MoveLamports: Verschiebt überschüssige Lamports von einem aktiven oder inaktiven Account zu einem anderen aktiven oder inaktiven Account. „Überschüssige Lamports“ bezeichnet Lamports, die weder delegierter Stake sind noch für die Mietbefreiung benötigt werden. MoveLamports ermöglicht Verwaltungsaufgaben wie das Zurückfordern von Lamports aus zusammengeführten Accounts und das Konsolidieren ungenutzter Mittel.

Um die Implementierung zu vereinfachen, unterstützen diese Änderungen weder die Aktivierung noch die Deaktivierung von Accounts und wirken sich nicht auf teilweise aktive Stake-Accounts aus. Die neuen Programmanweisungen ändern keine vorhandenen Funktionen.

Bonus: Das Solana-SVM-Crate

Mit Agave 2.0 erscheint ein brandneues solana-svm-Crate. Es bietet Entwicklern über eine schlanke API direkten Zugriff auf zentrale SVM-Komponenten und ist unabhängig vom vollständigen Validator-Framework. Dadurch wird Solanas leistungsstarke Transaktionsverarbeitung auch für Anwendungen außerhalb des Validators verfügbar, etwa für Off-Chain-Dienste, schlanke Clients, State Channels und Rollups.

Da die API vom restlichen Runtime-System entkoppelt ist, benötigt dieses Crate keine Komponenten wie Bank-Instanzen und reduziert so den Betriebsaufwand. Entwickler können jetzt dieselben robusten Komponenten nutzen, die Solanas Mainnet-Beta unterstützen, um individuelle SVM-Projekte wie Light Clients, State Channels, Rollups und Off-Chain-Dienste zu entwickeln. Den Kern dieser API bildet das Struct TransactionBatchProcessor. Damit können Anwendungen Batches bereinigter Solana-Transaktionen mit der vollständigen Suite nachgelagerter Agave-Komponenten verarbeiten, darunter BPF Loader, eBPF und die virtuelle Maschine.

Eine vollständige Beschreibung dieser spannenden Entwicklung findest du in der ausführlichen Analyse zu Anzas neuer SVM API.

Entfernte RPC-Endpunkte 

Mehrere überholte und veraltete v1-Agave-RPC-Endpunkte wurden entfernt. Das DevRel-Team von Helius hat alle Kunden kontaktiert, die diese Endpunkte verwenden. Durch interne Analysen hatten wir zuvor eine kleine Gruppe von Kunden identifiziert, die folgende zur Entfernung vorgesehene Endpunkte aktiv nutzen:

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

Hinweis: Der im Bild gezeigte alternative Ansatz für getAccountInfo ist hier zu finden.

Zu den Breaking Changes im SDK gehören:

• Unterstützung für Borsh v0.9 entfernt, bitte verwende v1 oder v0.10 (#1440)
• Copy-Trait wird nicht mehr abgeleitet für Rent und EpochSchedule; verwende stattdessen clone()
• solana-sdk: veraltete Symbole) entfernt 
• solana-program: veraltete Symbole entfernt

Für Validator-Betreiber werden mit der Veröffentlichung von Agave v2.0 mehrere veraltete Validator-Argumente entfernt. Eine vollständige Liste findest du hier.‍

Fazit

Das Agave-2.0-Update ist ein wichtiger Fortschritt für Solana und umfasst zahlreiche neue Funktionen und Runtime-Optimierungen. Diese Version verschiebt die Grenzen mit leistungsstarken neuen Syscalls, erweiterten Funktionen und umfassender Bereinigung weiter. Dazu gehören die Umbenennung von Crates, die Entfernung veralteter RPC-Methoden und vereinfachte Validator-Argumente. Agave 2.0 erweitert die Möglichkeiten von Solana und verbessert Leistung und Benutzerfreundlichkeit. Ganz gleich, ob du Entwickler, Validator oder aktiver Nutzer bist: Das Agave-2.0-Update eröffnet allen im Solana-Ökosystem spannende neue Möglichkeiten.

Weitere Ressourcen

• Veröffentlichungsplan für Agave v2.0
• Änderungsprotokoll für Agave v2.0
• Agave-Versionen