SLV schließt Solana-v4-Unterstützung mit XDP und Alpenglow-bereitem BLS ab

ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki) und Validators DAO freuen sich bekannt zu geben, dass SLV, das Open-Source-Betriebswerkzeug für Solana, die Unterstützung für Solana v4 (Agave 4.x) abgeschlossen hat.

Mit diesem Update lassen sich die Optimierungen, auf die sich die leistungsstärksten Solana-Validatoren stützen — Anzas XDP-Turbine-Retransmit-Beschleunigung und der in SIMD-0387 definierte, Alpenglow-bereite Workflow zur Registrierung des öffentlichen BLS-Schlüssels — nun von jedem Betreiber über dieselbe bewährte Betriebsanleitung ausführen, über Gespräche mit einem KI-Agenten oder direkt per CLI. Die fortgeschrittene Abstimmung, die einst tiefgreifendes Linux- und Solana-Fachwissen erforderte, ist in SLV gebündelt, sodass selbst Betreiber ohne diesen spezialisierten Hintergrund sie allein durch Gespräche reproduzieren können.

SLV Offizielle Website: https://slv.dev/de SLV GitHub: https://github.com/validatorsDAO/slv

Den Betrieb von Spitzen-Validatoren demokratisieren — Weltklasse-Optimierung, von jedem reproduzierbar

SLV ist eine Open-Source-Initiative, um Solana-Validatoren gemeinsam mit KI-Agenten zu betreiben und die höchste Wartungsqualität kostengünstig und überall auf der Welt bereitzustellen.

Auf Solana ist die Kluft zwischen der reinen Leistung eines Validators und dem dahinterstehenden Betriebs-Know-how immer größer geworden. Netzwerk mit niedriger Latenz, Kernel- und NIC-Tuning, sorgfältige Vorbereitung auf Protokoll-Upgrades — der Betrieb, der zu erstklassiger Validator-Leistung führt, hat tiefgreifendes Fachwissen über Linux und Solana sowie kontinuierliche praktische Arbeit verlangt. Infolgedessen blieb das höchste Betriebsniveau tendenziell nur einer begrenzten Gruppe von Betreibern mit diesem Fachwissen zugänglich.

SLV existiert, um diese Kluft zu schließen. Indem das von Weltklasse-Validator-Betrieben aufgebaute Betriebs-Know-how in Fähigkeiten für einen KI-Agenten gebündelt wird, kann jeder dieselbe Betriebsanleitung allein durch Gespräche reproduzieren. Diese Solana-v4-Unterstützung bringt diese Idee unmittelbar auf die neuesten Optimierungen: XDP und BLS, genau die Technologien, die die leistungsstärksten Validatoren einsetzen, stehen nun jedem Betreiber zur Verfügung, der SLV nutzt — ohne die eigene Wahl von Client oder Umgebung aufzugeben.

Was die Solana-v4-Unterstützung bringt — XDP, BLS und Neustart-Sicherheit, alles für Sie erledigt

Solana v4 (Agave 4.x) ist die neueste Generation des Validator-Clients, die von Anza für das Mainnet empfohlen wird, und sie steigert die Kernleistung und bereitet das Netzwerk zugleich auf größere Blöcke und das bevorstehende Alpenglow-Konsens-Upgrade vor. Die v4-Unterstützung von SLV deckt die drei Bereiche ab, die für Betreiber beim Wechsel auf diese Grundlage am wichtigsten sind.

XDP-Turbine-Retransmit-Beschleunigung — schlüsselfertige Aktivierung des leistungsstarken Netzwerkpfads, der die Blockverbreitung beschleunigt.
Alpenglow-bereite Registrierung des öffentlichen BLS-Schlüssels (SIMD-0387) — Vorbereitung des Registrierungs-Workflows im Voraus, sodass Validatoren bereit sind, sich zu registrieren, sobald das Alpenglow-Feature-Gate aktiviert wird.
Neustart-Sicherheit für Agave 4.1+ — Anpassung des Portbereichs und Gating von Flags, die nur für Cluster-Neustarts gelten, sodass der Wechsel auf den neuen Client keine vermeidbaren Startfehler einführt.

Jeder dieser Punkte wird über denselben SLV-Workflow erledigt — Gespräch mit dem KI-Agenten oder CLI — sodass der Wechsel auf Solana v4 nicht zu einem manuellen, fehleranfälligen Projekt wird. Das neueste SLV-Release trägt alle oben genannten Punkte als Teil der Serie v2026.6.6 — BLS, XDP und die Korrekturen zur Neustart-Sicherheit kommen zuerst, gefolgt von der Robustheit für Firedancer und RPC in derselben Serie.

Was XDP ist — Ein schneller Pfad im Linux-Kernel, der Turbine beschleunigt

XDP (eXpress Data Path) ist eine Linux-Kernel-Technologie, die es leistungsstarkem Netzwerkcode ermöglicht, einen großen Teil des üblichen Paketverarbeitungspfads des Kernels zu umgehen. Indem Datenkopien und Kontextwechsel reduziert werden, verarbeitet sie Pakete mit weit weniger Overhead als der Standard-Netzwerkstack.

In Agave wird XDP auf Turbine angewendet, das Protokoll, das Blöcke über das Validator-Netzwerk verbreitet. Eingehende Shreds werden von einem eBPF-Programm verarbeitet, das nahe an der Netzwerkkarte (NIC) angebunden ist, und über AF_XDP in Userspace-Puffer abgebildet, während ausgehende Shreds direkt mittels XDP_TX gesendet werden — wodurch Syscalls und Kopien auf dem Hot Path entfallen. Anza führte XDP für Turbine in der Agave-3.x-Serie (ab v3.0.9) ein und übernimmt es in die Agave-4.0-Grundlage.

Laut Anzas Setup-Leitfaden können große Validatoren mit XDP an 150,000 ausgehende Pakete pro Sekunde herankommen. Anza positioniert XDP als Teil des Spielraums, der Validatoren auf 100M-CU-Blöcke vorbereitet und die IBRL-Roadmap (Increase Bandwidth, Reduce Latency) voranbringt, und hat einen offiziellen Setup-Leitfaden für Betreiber veröffentlicht, die es einführen.

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

SLV macht XDP schlüsselfertig — Aktivieren mit einem Gespräch und einigen Inventar-Variablen

XDP von Hand einzuführen ist nicht trivial. Es erfordert einen aktuellen Kernel (6.14+ für den igb-Treiber, 6.8+ für andere), eine XDP-fähige NIC, die richtigen systemd-Capabilities für den Validator-Prozess und die korrekten Startup-Flags — und das CPU-Core-Pinning (einschließlich des PoH-Cores) muss korrekt gewählt werden, damit der Pfad performant arbeitet. Genau das ist die Art von Spezialarbeit, die fortgeschrittene Optimierung für viele Betreiber unerreichbar gehalten hat.

SLV verwandelt dies in einen schlüsselfertigen Schritt. Die XDP-Retransmit-Beschleunigung wird per Opt-in über Inventar-Variablen pro Host aktiviert — xdp_enabled, xdp_interface, xdp_cpu_cores, xdp_zero_copy und xdp_poh_pinned_cpu_core. Bei Aktivierung wendet SLV die für die jeweilige Agave-/Jito-Version passenden XDP-Startup-Flags an und gewährt automatisch die erforderlichen systemd-Capabilities (CAP_NET_RAW, CAP_NET_ADMIN, CAP_BPF, CAP_PERFMON). Diese Variablen gelten für Agave- und Jito-Validatoren; Firedancer nutzt XDP nativ und benötigt keine separate Aktivierung. (XDP ist über die Agave-Releases hinweg gereift — seit Agave 4.1 ist es nicht mehr experimentell, und die zugehörigen Flag-Namen haben sich auf diesem Weg geändert — daher verfolgt SLV die korrekten Flags für jede Version, und Betreiber müssen es nicht tun.)

Aus Sicht des Betreibers lässt sich dies vollständig per Gespräch steuern. Starten Sie die AI Console und sagen Sie etwa „Aktiviere die XDP-Retransmit-Beschleunigung auf diesem Validator", und der KI-Agent wählt die nötige Konfiguration aus und wendet sie an. Auch für CLI-orientierte Nutzer werden entsprechende Befehle bereitgestellt, sodass Workflows ohne KI-Agenten vollständig unterstützt werden. Dieselbe Netzwerk-Optimierung, die die leistungsstärksten Validatoren verwenden, wird zu etwas, das jeder SLV-Betreiber einschalten kann.

Alpenglow-bereite BLS-Registrierung — Vorausschauende Unterstützung für SIMD-0387

Alpenglow ist Solanas Konsensprotokoll der nächsten Generation. Um Validator-Stimmen effizient zu aggregieren — zum Beispiel, um knapp zu beweisen, dass 60% der Validatoren für das Überspringen eines Slots gestimmt haben — ersetzt Alpenglow die aktuellen ed25519-Signaturen durch das BLS-Aggregatsignaturverfahren (Boneh–Lynn–Shacham) für Stimmen. SIMD-0387 definiert, wie Validatoren einen öffentlichen BLS-Schlüssel in ihrem Vote Account registrieren, damit sie bereit sind abzustimmen, sobald Alpenglow aktiviert ist.

Unter SIMD-0387 wird die Registrierung eines öffentlichen BLS-Schlüssels möglich, sobald das Feature-Gate des Vorschlags aktiv ist, und jeder Validator muss vor dem Live-Gang von Alpenglow einen solchen in seinem Vote Account haben, um weiter abstimmen zu können. Das BLS-Schlüsselpaar wird aus dem Vote-Authority-Schlüsselpaar abgeleitet (oder aus dem Identity-Schlüsselpaar, falls dieses fehlt), und die Registrierung erfolgt on-chain zusammen mit einem Proof of Possession (PoP) — einem kryptografischen Nachweis, der den Schlüssel an den Vote Account bindet und Rogue-Key-Angriffe verhindert. Derzeit befindet sich SIMD-0387 in der Review-Phase und sein Feature-Gate ist auf dem Mainnet noch nicht aktiv (es ist für die Aktivierung auf dem Devnet vorgesehen), sodass auf dem Mainnet noch kein BLS-Schlüssel registriert werden kann; worauf es heute ankommt, ist, den Workflow bereit zu haben, wenn das Gate öffnet.

Genau hier zahlt es sich aus, frühzeitig bereit zu sein. Sobald Alpenglow live ist, würde sich ein Vote Account ohne registrierten BLS-Schlüssel so verhalten, als wäre er unstaked. Den Registrierungs-Workflow im Voraus bereitzuhaben, statt zu hetzen, wenn das Gate öffnet, ist es, was einen Betrieb über den Übergang hinweg sicher hält.

SLVs register:bls — Automatisch zur Deploy-Zeit vorbereitet

SLV richtet diese Vorbereitung für Sie ein. Der neue Befehl slv v register:bls ist der Workflow, der den öffentlichen BLS-Schlüssel — abgeleitet aus dem Authorized-Voter- oder dem Identity-Schlüsselpaar — auf jedem Vote Account registriert, sobald das Feature-Gate aktiv ist. Er läuft außerdem automatisch am Ende von slv v deploy, sodass ein über SLV erstellter oder aktualisierter Validator diesen Schritt als Teil des normalen Ablaufs durchläuft.

Die Operation ist so konzipiert, dass sie zu jedem Zeitpunkt sicher ausgeführt werden kann. Auf einem Cluster, auf dem das Feature-Gate noch nicht aktiviert ist, läuft sie sicher als No-op durch; sobald das Gate aktiviert wird, registriert derselbe Workflow den Schlüssel. Sie ist idempotent, sodass eine frühe Ausführung kein Risiko birgt und es nicht nötig ist, sie präzise auf das Upgrade abzustimmen. Wie bei XDP lässt sich derselbe Schritt über das Gespräch mit dem KI-Agenten oder über die CLI steuern. Die Grundlage, die darüber entscheidet, ob ein Validator über den Alpenglow-Übergang hinweg weiter abstimmen kann, ist im Voraus eingerichtet, ohne manuelle Schlüsselverwaltung.

Verstärkte Neustart-Sicherheit für Agave 4.1+

Der Wechsel auf eine neue Client-Generation kann subtile Startfehler zutage fördern, und die v4-Unterstützung von SLV geht diese direkt an. Für Agave 4.1+ (und Jito-Validatoren auf derselben Basis) wird der dynamic_port_range auf mindestens 27 Ports (8000–8030 / 8900–8930) erweitert, was einen Fall behebt, in dem Agave/Jito 4.1.0+ einen engeren Bereich beim Start mit „Port range is too small" ablehnt — ein Fehler, der Validatoren und RPC-Knoten in eine Crash-Loop gebracht hat. Die Korrektur deckt alle Start-Skripte für Validator, RPC und pythnet ab, ebenso die init- und Inventar-Standardwerte.

Darüber hinaus werden Flags, die nur für Cluster-Neustarts gelten, nun gegated: --wait-for-supermajority und --expected-bank-hash werden nur ausgegeben, wenn sie explizit gesetzt sind, sodass ein veralteter Slot oder Bank-Hash bei einem gewöhnlichen Neustart einen Knoten nicht mehr hängen lassen oder ihn mit einer Bank-Hash-Diskrepanz in einen Panic versetzen kann. Das sind die Arten von Details, die ein Routine-Upgrade, wenn man sie von Hand handhabt, in einen Vorfall verwandeln — und um die SLV sich nun als Teil der Standard-Anleitung kümmert.

Diese Härtung setzt sich über die gesamte Anleitung fort. Ein Folge-Release dehnt dieselbe betriebliche Robustheit auf die Firedancer- und RPC-Pfade aus — netzwerkbewusste Handhabung der Firedancer-Version, eine Bereinigung von Jito-Build-Konflikten und Korrekturen am RPC-Start-Skript — sodass der Wechsel auf die neueste Grundlage reibungslos bleibt, unabhängig davon, welchen Client ein Betreiber ausführt.

Das Rad nicht neu erfinden — Spitzen-Know-how im KI-Agenten bündeln

Im Solana-Ökosystem verbringen viele Projekte Zeit mit der gemeinsamen Arbeit des Betriebs von Validatoren und Knoten, getrennt von der Entwicklung ihres eigentlichen Produkts. Bauen, Deployen, Überwachen, Aktualisieren und Migrieren von Clients — für jedes Projekt sind dies ähnliche Wiederholungen derselben Aufgaben, eine Art Neuerfindung des Rades.

Die Aktivierung von XDP und die Alpenglow-bereite BLS-Registrierung sind perfekte Beispiele dafür. Sie sind fortgeschritten, leicht falsch zu machen, und jeder Betreiber muss sie andernfalls selbstständig recherchieren und neu herleiten. Indem dieses Betriebs-Know-how in SLV-Fähigkeiten für den KI-Agenten gebündelt wird, kann dieselbe bewährte Anleitung von jedem allein durch Gespräche reproduziert werden — und der menschliche Aufwand des Betriebs sinkt strukturell. Mit diesem Release wurde die SLV-Validator-Fähigkeit — das Wissen, auf das der KI-Agent zurückgreift — für BLS (SIMD-0387) und XDP aktualisiert, sodass der Agent die aktuelle, korrekte Vorgehensweise anwendet statt einer veralteten. Das ist es, was „die höchste Wartungsqualität, kostengünstig" in der Praxis bedeutet.

SLV wird die betrieblichen Lasten, die über Solana-Projekte hinweg gemeinsam sind, weiterhin eine nach der anderen lösen, gemeinsam mit SLV AI — damit sich jedes Projekt auf die wesentliche Entwicklung seines eigenen Produkts konzentrieren kann.

Sowohl CLI als auch KI-Agent — Stabilität trägt beide

SLV läuft stabil nicht nur als KI-Agent, sondern auch als CLI. Für Nutzer, die sich nicht auf KI-Agenten verlassen möchten oder SLV in skriptgesteuerte Automatisierungsabläufe integrieren wollen, bleibt SLV eine praxistaugliche Betriebsgrundlage.

Genau diese Stabilität auf CLI-Ebene ist es, die die Zuverlässigkeit des Betriebs per KI-Agent untermauert. Jede SLV-Funktion ist MCP-kompatibel (Model Context Protocol), und der KI-Agent ruft über MCP dieselben Schnittstellen auf wie die CLI. Wenn die CLI stabil ist, ist der KI-Agent stabil — dieses Designprinzip untermauert die Zuverlässigkeit des KI-Agent-Betriebs von SLV. Auch die XDP-Aktivierung und register:bls lassen sich auf dieselbe Weise sowohl von der CLI als auch vom KI-Agenten handhaben, auf derselben MCP-Grundlage.

Eine Betriebsgrundlage, die ein Bekenntnis zur Leistung trägt — Der Epics-DAO-Validator erreichte weltweit Platz 3

Der Epics-DAO-Validator, der als Quelle des SWQoS-Endpunkts von ERPC und von Epic Shreds betrieben wird, hat im Shinobi Performance Pool unter allen Solana-Validatoren weltweit Rang 3 (Score 99.93) erreicht, mit stimmbezogenen Scores von über 99%.

Dieses Ergebnis ist das kumulative Resultat mehrerer Verbesserungen: Hardware-Auswahl, Optimierung von Kernel-Parametern, Tuning des Netzwerkstacks, Anpassung der IRQ-Affinität, die Einführung von DoubleZero und Netzwerk-Optimierungen genau jener Art, die XDP verkörpert. SLV bündelt dieses Betriebs-Know-how im KI-Agenten und liefert es in einer Form, die jeder als dieselbe Betriebsanleitung reproduzieren kann. Die hier beschriebenen Optimierungen sind nicht theoretisch — sie stammen aus einem Betrieb, der die Spitze des Netzwerks erreicht hat.

In Kombination mit der ERPC-Plattform

Die Solana-v4-Unterstützung von SLV funktioniert in jeder Umgebung und harmoniert besonders gut mit der ERPC-Plattform. ELSOUL LABO betreibt als Teil der ERPC-Plattform ein Solana-dediziertes Rechenzentrum unter seinem eigenen, von RIPE NCC gewährten ASN (AS200261) — und dort können Sie die v4-Optimierungen, die Betriebsautomatisierung von SLV und die ERPC-Plattform gemeinsam nutzen.

ERPC unterdrückt distanzbedingte Latenz bereits in der Entwurfsphase, indem es Quell-Validatoren, empfangende Endpunkte und Verarbeitungsknoten innerhalb von Premium-Rechenzentren platziert, in denen Solana-Validatoren dicht konzentriert sind. Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, Bare-Metal-Server, SWQoS, die Pyth-kompatible Price API sowie Jet Analytics & Indexed RPC lassen sich allesamt auf derselben Plattform kombinieren. Wenn Sie einen mit SLV erstellten v4-Validator auf der ERPC-Plattform betreiben, können Sie die Optimierungen von SLV mit der Geschwindigkeit auf Entwurfsebene von ERPC in derselben Umgebung kombinieren.

ERPC Offizielle Website: https://erpc.global/de

Jetzt mit SLV-AI-Tokens loslegen

Der KI-Agent von SLV läuft mit SLV-AI-Tokens. Sie können kostenlos starten — eine Autorisierung über EUR 5 stellt 100,000 Tokens bereit, ein Volumen, das ausreicht, um die Aktivierung von XDP, die Vorbereitung der BLS-Registrierung und den Betrieb eines Solana-v4-Validators über Gespräche mit dem KI-Agenten zu erleben.

ERPC SLV AI Plans: https://erpc.global/de/price/

Verbindungen über ChatGPT- und Claude-API-Tokens werden ebenfalls unterstützt, sodass Sie SLV AI mit Ihren eigenen API-Schlüsseln betreiben können.

Ihr Feedback formt SLV

SLV entwickelt sich jeden Tag durch Ihr Feedback weiter. Auch diese Solana-v4-Unterstützung nahm durch die im offiziellen Discord von Validators DAO geteilten Stimmen und durch den Betrieb von Validatoren an der Spitze des Netzwerks Gestalt an. Bitte probieren Sie sie aus und teilen Sie uns Ihre Gedanken und Wünsche im offiziellen Discord von Validators DAO mit.

Vielen Dank wie immer. Wir schätzen Ihre fortwährende Unterstützung von SLV und ERPC.

Kontakt

Für Anfragen zu SLV und ERPC eröffnen Sie bitte ein Support-Ticket im offiziellen Discord von Validators DAO.

Validators DAO Offizielles Discord: https://discord.gg/C7ZQSrCkYR

SLV schließt die Solana-v4-Unterstützung ab — XDP-Turbine-Beschleunigung und Alpenglow-bereite BLS-Registrierung, von jedem Validator über Gespräche mit einem KI-Agenten reproduzierbar