R3E Network hat neox-rs v2.7.0 veröffentlicht, eine neue Version des auf Rust basierenden Neo-X-Full-Node-Clients, die 185 Commits aus dem Upstream Reth 2.7.0 übernimmt, neun cargo-audit-Schwachstellen behebt und den Lebenszyklus der Distributed-Key-Generation-Validatoren (DKG) härtet.

Jimmy Liao, ein Neo-Core-Entwickler und Gründer von R3E Network, gab die Veröffentlichung am 20. Oktober bekannt.

Seit seinem Debüt im Juli hat der Client drei frühere Releases durchlaufen: eine erste Pre-Release, eine erste stabile Version mit Konsenskorrekturen und ein Release zur Behebung von Audit-Findings, das 11 Findings schloss. Die Versionsnummer sprang von v2.5.2 direkt auf v2.7.0, um mit der Upstream-Nummerierung von Reth synchron zu bleiben – eine Konvention im Gleichschritt, die es Node-Betreibern ermöglicht, jeden neox-rs-Build genau auf die Upstream-Basis zurückzuverfolgen, von der er erbt.

Reth-2.7-Upstream-Merge

Das Update bringt neox-rs auf den Reth-2.7.0-Codebestand und übernimmt 185 Commits aus der vorherigen Basis, während die Neo-X-spezifischenokollschichten erhalten bleiben, darunter dBFT-Konsens, DKG-Threshold-Verschlüsselung, Anti-MEV-Envelope-Verarbeitung und benutzerdefinierte RPC-Endpunkte. Reth ist der von Paradigm entwickelte Rust-Execution-Client für Ethereum, und regelmäßige Upstream-Merges dieser Art ermöglichen es einem abgeleiteten Client, Korrekturen und Verbesserungen aus seiner Basis zu übernehmen, während sich der Upstream-Code weiterentwickelt, statt sich von ihr zu entfernen.

Zusammen mit dem Merge wurde das Neo-X-Geth-Oracle auf seine neueste Basis synchronisiert. Sowohl die MainNet- als auch die TestNet-Genesis-Dateien wurden verifiziert, dass sie mit den kanonischen Bytes übereinstimmen, wodurch die Genesis-Block-Hashes erhalten bleiben. Das Release wird mit Linux- und Windows-x86_64-Binaries ausgeliefert, jeweils mit SHA-256-Prüfsummen veröffentlicht; aarch64-Artefakte wurden für dieses Release nicht erstellt.

Sicherheitsbereinigung

Neun cargo-audit-Schwachstellen wurden durch Dependency-Updates auf quinn-proto 0.11.18 und rustls 0.23.46 behoben, und das Projekt weist nun null bekannte Schwachstellen aus cargo audit aus. Cargo audit prüft den Dependency-Baum eines Rust-Projekts gegen eine Datenbank veröffentlichter Hinweise, sodass ein Bericht ohne Findings bedeutet, dass im aktuellen Dependency-Set keine bekannten Schwachstellen-Flags mehr vorhanden sind.

Die Sicherheitsüberprüfung wurde durch einen agentenautorisierten Prozess statt durch ein unabhängiges Drittanbieter-Audit durchgeführt – ein Unterschied, der im Release als dokumentierte Risikoakzeptanz vermerkt ist.

Härtung des DKG-Lebenszyklus

Vier Änderungen zielen auf die Zuverlässigkeit im DKG-Validator-Lebenszyklus ab und behandeln Fehlermodi, die während langer Validierungsläufe beobachtet wurden:

• DKG-Vorbereitungen überstehen nun Fortschreitungen des kanonischen Heads und verhindern bisher gestrandete Zustände.
• Abgelehnte Submit-Operationen versetzen den Validator zurück in den Ready-Zustand, statt die vorbereitete Aufgabe verwaist zu lassen.
• Das Abgleichen von Shares verwendet nun Round und Aggregate Global Key gemeinsam und beseitigt falsche Epoch-Mismatch-Fehler während des normalen Blockfortschritts.
• Signer-Shares werden nicht mehr bei jedem Block neu installiert; das System hasht settle kanonische Eingaben statt des kanonischen Heads.

DKG ist das Threshold-Kryptografie-Verfahren, bei dem eine Validator-Menge gemeinsam Schlüsselmaterial erzeugt, sodass kein einzelner Teilnehmer den vollständigen Schlüssel besitzt – eine der Neo-X-spezifischen Schichten, die Upstream-Merge erhalten musste. Diese Korrekturen adressieren Randfälle, in denen der DKG-Zustand über Blockgrenzen hinweg inkonsistent werden könnte – Szenarien, die bei anhaltender Validierung über mehrere Runden zutage treten würden.

Validierung und Tests

Der Release-Kandidat wurde durch ein G8-Gate über 1.402 Blöcke validiert, das die Höhen 2.404 bis 3.805 umspannte. Das Gate bestätigte den DKG-Rundenfortschritt von Runde eins zu Runde zwei, hielt durchgehend ein identisches 128-Byte-Aggregate-Commitment bei und verzeichnete null Reorgs und null transiente RPC-Fehler.

Die Envelope-Entschlüsselung wurde sowohl in Current-Epoch- als auch in Cross-Epoch-Szenarien verifiziert, wobei ein gespeicherter Runde-eins-Envelope nach dem Fortschreiten der Kette zu Runde zwei erfolgreich entschlüsselt und gemined wurde. Fehlertests umfassten 60-Sekunden-Verzögerungen des Provers, erzwungene Prozessneustarts und den Ersatz fehlender Receipt-Shares.

Alle 427 Neo-X-Tests bestehen, ebenso die Clippy- und Formatierungsprüfungen. Die Datadir-Kompatibilität wurde ebenfalls bestätigt: Ein v2.7.0-Datenverzeichnis und ein DKG-Keystore öffneten sich erfolgreich unter v2.5.2, und die Release-Binary lud ein bestehendes MainNet-Archiv-Datadir – Prüfung, die für Betreiber relevant ist, da sie zeigen, dass bestehende Chain-Daten und DKG-Keystores über Versionsgrenzen hinweg nutzbar bleiben.

Ausblick

Der vollständige Clean-Datadir-MainNet-Sync ab dem Genesis-Block läuft nach der Veröffentlichung noch, obwohl Peer-Verbindung und Headers-Pipeline verifiziert wurden. Dieser Sync ist der ausstehende Meilenstein, dessen beiden Voraussetzungen – Peer-Konnektivität und Header-Abruf – bereits als funktionsfähig bestätigt sind.

neox-rs dient weiterhin als unabhängige Rust-Implementierung des Neo-X-Protokolls und bietet Client-Diversität neben dem von Bane Labs gepflegten Go-basierten Neo-X-Geth-Client. Client-Diversität – der Betrieb unabhängiger Implementierungen desselben Protokolls – ist eine langjährige Resilienz-Praxis in Blockchain-Netzwerken, da ein Fehler, der auf eine Codebasis beschränkt ist, nicht automatisch die andere betrifft.

Die Release-Seite ist verfügbar unter: https://github.com/R3E-Network/neox-rs/releases/tag/neox-v2.7.0