Agave 2.0 Zusammenfassung

Die Veröffentlichung des Agave-Validierungsclients v2.0 markiert einen bedeutenden Meilenstein in Solanas Reise zu einem robusteren, multiklientfähigen Ökosystem. Dieses Update bringt mehrere wichtige Verbesserungen mit, um die Netzwerkperformance, Zuverlässigkeit und Effizienz zu steigern. Zu den wichtigsten Änderungen in diesem Update gehören:

‍

• Umfangreiche Codebase-Refactorings und Optimierungen
• Partitionierte Epochenbelohnungen
• Vergütung der vollständigen Prioritätsgebühr an Validatoren
• Der neue zentrale Planer ist jetzt standardmäßig aktiviert
• Das ZK ElGamal Proof-Programm
• Get-Sysvar Syscall
• GetEpochStake Syscall
• MoveStake und MoveLamports
• Entfernung veralteter RPC-Methoden
• Kistenumbenennungen

‍

Egal, ob Sie einen Validator betreiben, auf der Plattform aufbauen oder Solana aktiv nutzen, dieser umfassende Überblick über das Agave 2.0-Update wird Sie mit den nötigen Einblicken ausstatten, um diese neuesten Innovationen zu verstehen und davon zu profitieren.

Was macht 2.0 zu einem großen Versionsupdate?

Es gibt nicht mehr einen einzigen 'Solana-Validator'. Agave 2.0 umarmt die neue multi-client Welt von Solana und markiert einen sauberen Schnitt vom Alten.Solana Labs GitHub-Repository. Das Solana Labs-Repository wird archiviert und neue Pull Requests oder Issues werden nicht mehr akzeptiert. Zuvor spiegelte dieses Repository die Aktivität aus dem Agave-Repository. Entwickler sollten alle Aktivitäten in dieAnza Agave GitHub-Repositoryfalls sie dies nicht bereits getan haben. DieSolana Labs zu Agave Migrationsprozessbegann am 1. März und wird öffentlich auf ihrem GitHub verfolgt.

‍

Mit der Weiterentwicklung des Ökosystems müssen Betreiber sich darauf einstellen, einen oder mehrere Clients auszuführen. Im Zuge dieser Veränderung werden mehrere Kisten umbenannt, um den Namensraum für die Unterstützung mehrerer Clients freizugeben - insbesondere Firedancer - die von unabhängigen Entwicklerteams verwaltet werden. Kisten, die von Anza verwaltet werden, werden nun mit „agave“ als Präfix versehen, um sie als anza-spezifische Abhängigkeiten in der Multi-Client-Umgebung leicht identifizierbar zu machen.

‍

‍

Betroffene Kisten sind:

‍

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

‍

Wie in unserem Detail beschriebenVorheriger Transitionsleitfaden, das 2.0-Update bringt mehrere Änderungen mit sich, insbesondere die Entfernung mehrerer veralteter und überholter Endpunkte - wichtige Updates, von denen alle Solana-Entwickler jetzt wissen sollten. Vollständige Details zu RPC-Änderungen sind am Ende dieses Artikels enthalten.

Funktionsbereitstellung

Zum Zeitpunkt des Schreibens laufen ~20,7% der Validatoren mit Version 2.0.14. Feature-Gate-Aktivierungen im Mainnet werden vorübergehend angehalten, damit die Einführung von v2.0 besser mit den Aktivierungen im Testnet und Devnet übereinstimmen kann. Sobald der Mainnet-Cluster v2.0 weitgehend angenommen hat, wird erwartet, dass die Feature-Gate-Aktivierungen gemäß dergeplante Aktivierungsbestellung.

‍

Die neuen vollständigen Funktionen, die in den folgenden Abschnitten erörtert werden, sind derzeit nicht aktiv und werden im Laufe des 2.0-Lebenszyklus langsam über ein Funktionsgate-System eingeführt. Funktionen werden zu bestimmten Epochen basierend auf relativer Priorität und der Reihenfolge, in der sie auf Testnet- und Devnet-Clustern aktiviert wurden, aktiviert.

‍

Belohnung volle Prioritätsgebühr an Validatoren

Dieses lang erwartete undviel diskutierte wirtschaftliche Aktualisierungwird nun nach dem Vorschlag umgesetzt,SIMD-0096, das im Mai einer Validator-Governance-Abstimmung unterzogen wurde. Die Abstimmung endete am Ende von Epoche 620, wobei 51,17 % des Einsatzes teilnahmen und 77,77 % dafür stimmten. Das feature-gated Update wird die Handhabung des Netzwerks grundlegend verändern.PrioritätsgebührenAnstelle des aktuellen Modells, bei dem die Gebühren zu 50% verbrannt und zu 50% an die Validatoren belohnt werden, wird das neue Modell 100% der Prioritätsgebühren direkt den Validatoren zuweisen.

Oben: Solana wöchentliche Prioritätsgebühren im USD-Wert (Quelle)

‍

Obwohl Prioritätsgebühren technisch gesehen optional sind, sind sie mit der Zunahme der wirtschaftlichen Aktivität auf Solana zur Standardpraxis geworden. Diese Gebühren werden in Mikrolamports (Millionstel eines Lamports) pro Recheneinheit nach folgender Formel berechnet:

‍

Priorisierungsgebühr = Berechnungseinheitspreis (Mikro-Lamports) x Berechnungseinheitslimit

‍

In Zukunft werden alle Prioritätsgebühren an Blockproduzenten vergeben. Dies schafft eine stärkere Ausrichtung der Anreize und verringert die Wahrscheinlichkeit, dass Validatoren sich auf außerprotokollarische Vereinbarungen zur Transaktionseingliederung einlassen, was in der Vergangenheit ein Problem war.

‍

Obwohl das Entfernen von Gebühren die Nettoinflationsrate von SOL leicht erhöht, hat die Ausgabe neuer Tokens durch Staking-Belohnungen eine weitreichendere Auswirkung. Leser können sich auf unseren früheren Helius-Blogbeitrag beziehen.Solanas Ausgabeverfahren und Inflationsplanfür eine detailliertere Aufschlüsselung dieser Dynamiken.

‍

Partitionierte Epochenbelohnungen

Belohnungen für geteilte EpochenZiel ist es, zu verteilenStake-Belohnungen Über mehrere Blöcke hinweg, wodurch die Leistungsprobleme gelindert werden, die mit der Konzentration der Belohnungsverteilung innerhalb des ersten Blocks jeder neuen Epoche verbunden sind. Der größte Engpass in diesem Prozess ist die Anforderung, Aktualisierungen auf die wachsende Anzahl aktiver Stake-Konten im Netzwerk zu schreiben, die sich derzeit auf etwa 1,4 Millionen belaufen. \

Unter diesem neuen Ansatz werden die Berechnung und Verteilung der Einsatzbelohnung an der Epochengrenze in zwei deutlich voneinander getrennte Phasen unterteilt:

‍

• Belohnungsberechnungsphase: In dieser Phase werden die Belohnungen für alle aktiven Stake-Konten berechnet, und die Verteilung wird in geplante Chunks aufgeteilt.
• Phasen der Belohnungsverteilung: Die vorberechneten Epochenbelohnungen für aktive Stake-Konten werden entsprechend verteilt.

‍

Um den Prozess zu erleichtern und zu überwachen, ein Sysvar-Konto,EpochRewards, wird die Belohnungsauszahlung während der Verteilungsphase verfolgen und verifizieren. Das Sysvar EpochRewards zeichnet auf, ob die Verteilungsphase der Belohnungen im Gange ist, und enthält die Informationen, die benötigt werden, um die Verteilung beim Starten aus einem Snapshot fortzusetzen.

Belohnungsberechnung

Die Belohnungsberechnungen werden im ersten Block der Epoche durchgeführt. Sobald berechnet, werden die Belohnungen in Verteilungsabschnitte aufgeteilt, die in der Bank gespeichert sind und während der Belohnungsverteilungsphase verteilt werden.

‍

Um die Auswirkungen auf die Blockverarbeitungszeit während der Belohnungsausschüttungsphase zu minimieren und sicherzustellen, dass jeder Block eine Teilmenge der Belohnungen auf deterministische Weise verteilt, werden pro Block 4.096 Stake-Belohnungen verteilt. Um ein dramatisches Wachstum der Anzahl von Stake-Konten zu verhindern, ist die Anzahl der Blöcke auf 10 % der Gesamt-Slots in einer Epoche begrenzt. Nur wenn diese Blockgrenze erreicht ist, dürfen die Konten pro Partition das Ziel von 4.096 überschreiten.

Belohnungsverteilung

Die Belohnungsauszahlung beginnt unmittelbar nach der Belohnungsberechnungsphase und beginnt mit dem zweiten Block des Epochs. Die Belohnungsauszahlungen erfolgen ganz oben im Block vor der normalen Transaktionsverarbeitung.

‍

Als Ergebnis sehen Benutzer möglicherweise Belohnungen, die ihrem Stake-Konto gutgeschrieben werden, einige Blöcke später als zuvor. Die Gesamterfahrung bleibt jedoch ähnlich, da die verlängerte erste Blockzeit an der Epochengrenze zuvor den Zugang des Benutzers zu Stake-Konten verzögerte. Ein zusätzlicher Vorteil dieses Ansatzes ist, dass Nicht-Staking-Transaktionen weiterhin reibungslos verarbeitet werden können, während sie zuvor während der Belohnungsauszahlung blockiert waren.

‍

Aufgrund der vergleichsweise geringen Anzahl von Stimmenkonten von ca. 1.500 bleibt der bestehende Mechanismus zur Verteilung der Stimmenbelohnungen am ersten Block der Epochengrenze unverändert. Nur Stake-Belohnungen werden auf mehrere Blöcke verteilt.

‍

Zentraler Scheduler ist jetzt standardmäßig aktiviert

Der zentrale Scheduler, der früher als "Scheduler" bekannt war, wurde erstmals als Feature-Release im Update v1.18 eingeführt und war standardmäßig nicht aktiviert und musste von Operatoren aktiviert werden, die beim Starten eines Validators das Flag —block-production-method central-scheduler verwendeten. Sie ist jetzt standardmäßig aktiviert. Bei der vorherigen Scheduler-Implementierung gab es mehrere Probleme, die sich negativ auf die Leistung auswirken konnten. Engpässe in der Transaktionsverarbeitung führen häufig zu Jitter oder Inkonsistenzen bei der Reihenfolge und Priorisierung von Transaktionen.

‍

Die neuere Implementierung ersetzt das bisherige Modell mit vier unabhängigen Banking-Threads, von denen jeder seine eigene Transaktionspriorisierung und -verarbeitung verwaltet. In dieser überarbeiteten Struktur ist der zentrale Scheduler der einzige Empfänger von Transaktionen aus der SigVerify-Phase der TPU. Es erstellt eine Prioritätswarteschlange und stellt ein Abhängigkeitsdiagramm bereit, das als Prio-Graph bezeichnet wird, um die Verarbeitung und Priorisierung widersprüchlicher Transaktionen besser zu verwalten. Dieses neue Scheduler-Design erhöht die Skalierbarkeit und Flexibilität und ermöglicht eine Erhöhung der Anzahl von Threads ohne die vorherigen Bedenken hinsichtlich erhöhter Sperrkonflikte. Es hat sich gezeigt, dass die anfängliche Einführung des zentralen Schedulers bessere Belohnungen generiert, was zu besseren Einnahmen für viele Betreiber führt. In unserem vorherigen Helius-Beitrag zum Solana v1.18-Update haben wir ausführlich behandeltwie der zentrale Planer funktioniert.

‍

ZK ElGamal Proof Programm

Das ZK Token Proof-Programm, das ursprünglich für die Version 1.17 vorgesehen war, ist jetzt veraltet und wird durch ein flexibleres, anwendungsunabhängiges Programm ersetzt.ZK ElGamal-Beweisprogramm. Das neue ZK ElGamal Proof-Programm behält die Teile des ZK Token Proof-Programms bei, die allgemein auf Anwendungen zutreffen, wie die Überprüfung der Gültigkeit eines öffentlichen Schlüssels oder des Wertebereichs, der in einem ElGamal-Chiffre verschlüsselt ist. Es lässt jedoch anwendungsspezifische Elemente wie die für SPL Token-Transferanweisungen erforderliche Überprüfung des Zero-Knowledge-Beweises aus. Das neue ZK ElGamal Proof-Programm wird in die Liste der integrierten Programme an der Adresse eingefügt.ZkE1Gama1Proof11111111111111111111111111111.

‍

Um mehr über das ZK Token Proof-Programm zu erfahren, lesen Sie unserenUrsprünglicher Beitrag im Helius-Blog.

Get-Sysvar-Syscall

Syscalls oder Systemaufrufe fordern Dienste vom Betriebssystemkern an. Im Kontext von Solana ermöglicht ein Syscall Programmen, die innerhalb der Solana Virtual Machine (SVM) ausgeführt werden, mit externen Ressourcen und Diensten zu interagieren.

‍

Sysvars machen Clusterstatusinformationen verfügbar, z. B. den letzten Blockhash und Epochenbelohnungen. Diese Konten werden unter bekannten Adressen aufgefüllt. Programme können über ein Sysvar-Konto auf Sysvars zugreifen oder diese über einen Syscall abfragen. On-Chain-Programme verwenden viele Sysvars für eine Vielzahl von Anwendungsfällen, und bestimmte Sysvars sind für den Betrieb des Netzwerks unerlässlich.

‍

Der Get-Sysvar Syscall, der ursprünglich vorgeschlagen wurde,SIMD-127 von Anza-Ingenieur Joe Caulfieldführt eine einheitliche Syscall-Schnittstelle für den Zugriff auf Sysvar-Daten ein. Dieses Upgrade ermöglicht den Abruf zuvor nicht zugänglicher Sysvar-Daten, einschließlich SlotHashes und StakeHistory. Mit dieser neuen Schnittstelle können Entwickler auf spezifische Fragmente von Sysvar-Daten zugreifen - wie z. B. Aufruf von SlotHashes::get_slot(slot)undStakeHistory::get_entry(Epoche)—ohne ganze Datenstrukturen duplizieren zu müssen.

‍

Das Update minimiert auch den Overhead beim Ändern der Sysvar-Datenlayouts oder beim Hinzufügen neuer Sysvars. Zuvor erforderte jeder neue Sysvar die Hinzufügung eines entsprechenden Syscalls, was zu einer engen Beziehung führte, die die Syscall-Schnittstelle im Laufe der Zeit aufblähte und die Wartung kompliziert machte. Jetzt wird ein einzelner sol_get_Sysvar Syscall alle Sysvar-Schnittstellen bedienen, was eine konsistente und effiziente Datenabfrage von jedem Sysvar ermöglicht.

‍

Die Einführung des neuen Syscall vereinfacht den Prozess der Modifikation und Hinzufügung neuer Sysvars. Es reduziert signifikant die Komplexität und Wartungsanforderungen der Syscall-Schnittstelle. Darüber hinaus ebnet dieses Update den Weg für eine Erweiterung des BPF-Programmzugriffs auf Sysvar-Daten, sodass On-Chain-Programme mehr Sysvar-Informationen lesen können, ohne die Transaktionsgröße zu beeinflussen.

‍

GetEpochStake-Systemaufruf

Die neueGetEpochStake Syscall wird eine stark nachgefragte Funktion zum Abrufen des delegierten Einsatzes eines Abstimmungskontos für die aktuelle Epoche einführen, die eine effizientere, direktere Methode zum Abrufen dieser Informationen auf der Kette bietet.

‍

Derzeit können Programme keine Echtzeitdaten zu den an bestimmte Abstimmungskonten delegierten Einsätzen für die aktuelle Epoche abrufen, was eine Hürde für Anwendungsfälle wie Validator-Governance und sekundäre Konsensmechanismen darstellt. Die Aktivierung der Abfrage dieser Daten auf der Chain wird diese Anwendungen freischalten und den Weg für zukünftige Anwendungsfälle ebnen.

‍

Mit GetEpochStake geben Entwickler eine 32-Byte-Abstimmungskontoadresse an, und der Systemaufruf gibt eine u64-Ganzzahl zurück, die den gesamten aktiven Einsatz darstellt, der derzeit an dieses Abstimmungskonto delegiert wurde. Wenn die angegebene Adresse keinem gültigen Abstimmungskonto entspricht oder nicht existiert, gibt der Syscall einfach 0 zurück.

‍

MoveStake und MoveLamports

Zwei neue Anweisungen für das Staking-Programm,MoveStake und MoveLamportswerden eingeführt, um Wertübertragungen zwischen Stake-Konten zu erleichtern. Diese Anweisungen, die erstmals in derSIMD-0148, unterstützen Entwickler, indem sie den Transfer von Geldern zwischen Konten mit übereinstimmenden Berechtigungen ohne Kontrolle der Abheberberechtigung ermöglichen.

‍

Bisher haben Protokolle, die Benutzereinsätze verwalten, Schwierigkeiten gehabt, Einsätze auf mehrere Validatoren aufzuteilen und regelmäßig zwischen ihnen umzuleiten. Wenn ein Protokoll den Einsatz eines Benutzers zur Deaktivierung aufteilt, muss es die Rentenbefreiungslamports für das neue Konto finanzieren. Das Protokoll kann die Rentenbefreiungslamports nicht zurückfordern, wenn diese aufgeteilten Konten zusammengeführt werden.

MoveStake: Diese Anweisung ermöglicht es, einen aktiven Einsatz zwischen Konten zu verschieben, indem er von einem aktiven Konto auf ein anderes oder von einem aktiven Konto auf ein inaktives Konto übertragen wird, wodurch das Konto reaktiviert wird. Wenn die gesamte Quellkontodelegierung verschoben wird, wird das Quellkonto inaktiv. Der mietfreie Saldo bleibt in allen Szenarien unangetastet, und für aktive Konten werden Mindestdelegationsregeln beibehalten.

‍

MoveLamports: Verschieben Sie überschüssige Lamports von einem aktiven oder inaktiven Konto auf ein anderes aktives oder inaktives Konto, wobei sich "überschüssige Lamports" auf Lamports bezieht, die weder delegiert sind noch für die Mietbefreiung erforderlich sind. MoveLamports ermöglicht Housekeeping-Aufgaben wie die Rückforderung von Lamports von zusammengeführten Konten und die Konsolidierung ungenutzter Gelder.

‍

Um die Implementierung zu optimieren, unterstützen diese Änderungen nicht die Aktivierung oder Deaktivierung von Konten und wirken sich auch nicht auf teilweise aktive Stake-Konten aus. Diese neuen Programmanweisungen ändern nicht die bestehende Funktionalität.

‍

Bonus: Die Solana-SVM-Kiste

Mit der Veröffentlichung von Agave 2.0 kommt einbrandneue Solana-SVM-Kistebietet Entwicklern einen direkten Zugang zu den Kernkomponenten von SVM über eine optimierte API, die unabhängig vom vollständigen Validator-Framework ist. Dadurch wird die hochleistungsfähige Transaktionsverarbeitung von Solana für Anwendungen außerhalb des Validators geöffnet, wie z.B. Off-Chain-Services, leichte Clients, Zustandskanäle und Rollups.

‍

Durch die Entkopplung der API vom Rest der Laufzeit macht diese Kiste Komponenten wie Bankinstanzen überflüssig und reduziert den Betriebsaufwand. Entwickler können jetzt die gleichen robusten Komponenten nutzen, die die Mainnet-Beta von Solana unterstützen, um benutzerdefinierte SVM-Projekte wie Light Clients, State Channels, Rollups und Off-Chain-Dienste zu erstellen. Der Kern dieser API ist die TransactionBatchProcessor-Struktur, die es Anwendungen ermöglicht, Batches bereinigter Solana-Transaktionen mit der vollständigen Suite nachgelagerter Agave-Komponenten zu verarbeiten, einschließlich des BPF-Loaders, des eBPF und der virtuellen Maschine.

‍

Oben: der Transaktions-Batch-Prozessor (Bildquelle: Anza)

‍

Lesen Sie die tiefgehende Analyse vonAnzas Neue SVM APIfür weitere Informationen zu dieser aufregenden Entwicklung.

‍

Entfernte RPC-Endpunkte

Mehrere veraltete und veraltete v1 Agave RPC-Endpunkte wurden entfernt. Das Helius Devrel-Team hat alle Kunden kontaktiert, die diese Endpunkte verwenden. Durch interne Analyse haben wir zuvor eine kleine Gruppe von Kunden identifiziert, die aktiv die folgenden Endpunkte verwenden, die entfernt werden sollen:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Wir empfehlen allen Entwicklern dringend, Verweise auf diese Aufrufe zu überprüfen und sie entsprechend mit den vorgeschlagenen Ersetzungen zu aktualisieren.

‍

Oben: eine vollständige Liste veralteter und veralteter v1 Agave RPC-Endpunkte, die entfernt werden sollen

‍

N.B. Der alternative Ansatz für getAccountInfo im Bild gezeigt werden kannhier gefunden.

‍

Zu den wichtigsten Änderungen des SDK gehören:

‍

• Unterstützung für Borsh v0.9 entfernt, bitte verwenden Sie v1 oder v0.10 (#1440)
• Die Kopierfunktion wird nicht mehr abgeleitet. auf Rent und EpochSchedule; Wechseln Sie zur Verwendung von clone()
• solana-sdk: veraltete Symbole) entfernt
• solana-program: veraltete Symbole entfernt

‍

Für Validator-Betreiber werden bei der Veröffentlichung von Agave v2.0 mehrere veraltete Validator-Argumente entfernt. Eine vollständige Liste dieser Argumente finden Siehier.

‍

Schlussfolgerung

Das Agave 2.0-Update markiert einen bedeutenden Fortschritt für Solana und umfasst zahlreiche Funktionsimplementierungen und Laufzeitoptimierungen. Mit dieser Version werden die Grenzen weiter ausgereizt und es gibt leistungsstarke neue Syscalls, erweiterte Funktionalitäten und umfassende Hausarbeiten, einschließlich Umbenennungen von Kisten, Entfernung veralteter RPC-Methoden und optimierte Validator-Argumente. Agave 2.0 erweitert die Fähigkeiten von Solana und verbessert Leistung und Benutzerfreundlichkeit. Egal, ob Sie Entwickler, Validator oder aktiver Benutzer sind, das Agave 2.0-Update eröffnet spannende neue Möglichkeiten für alle im Solana-Ökosystem.

‍

Weitere Ressourcen / Weiterführende Lektüre

• Agave v2.0 Veröffentlichungsplan
• Agave v2.0 Änderungsprotokoll
• Agave-Freigabe-Versionen

Haftungsausschluss:

1. Dieser Artikel ist abgedruckt von [helius)]. Alle Urheberrechte gehören dem Originalautor [Lostin]. Wenn es Einwände gegen diesen Nachdruck gibt, kontaktieren Sie bitte die Gate LearnTeam, und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Die Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.