bitcoin-rs, ein unabhängiger Full Node in Rust, bittet um externe Prüfung
Serguey Asael Shinder1 Min. LesezeitEin neuer, unabhängiger Bitcoin-Full-Node in Rust, bitcoin-rs, wurde am 28. September im Forum Delving Bitcoin vorgestellt. Sein Autor bezeichnet ihn als frühe Arbeit und, wie btcd, als eigenständige Implementierung, mit der sich Änderungen an Architektur und Leistung erproben lassen, die innerhalb von Bitcoin Core schwer umzusetzen sind, ohne die externe Überprüfbarkeit aufzugeben.
Der Beitrag nennt vier Hauptunterschiede. Der Node verwaltet das maßgebliche UTXO-Set, gegen das er prüft, und bietet zusätzlich einen schreibgeschützten, Esplora-kompatiblen Skriptindex, sodass übliche Abfragen von Wallets und Explorern keinen separaten Indexer im Electrum-Stil brauchen. Seine Komponenten, Konsens, Chainstate, Speicher, Netzwerk, Mempool, Indexierung und Steuerung, sind klein und getrennt gehalten, damit Fehler eingegrenzt bleiben. Synchronisation, Speicher, Arbeitsspeicher, Nebenläufigkeit und Ein- und Ausgabe werden gemeinsam optimiert, mit dem erklärten Ziel einer wettbewerbsfähigen Gesamtleistung gegenüber Bitcoin Core. Und Skripte lassen sich entweder mit dem eigenen Rust-Code prüfen oder über libbitcoinkernel, die Bibliothek mit dem Konsenscode von Bitcoin Core; der Kernel-Pfad kann als Orakel dienen, um den nativen Pfad gegenzuprüfen.
Laut den Autoren entsteht ein Prüfrahmen aus mehreren unabhängigen Referenzen: libbitcoinkernel als Konsensreferenz, bitcoinfuzz für differenzielle und gezielt feindliche Tests, das qa-assets-Korpus von Bitcoin Core für bekannte Grenzfälle sowie eigene Regressionstests und Benchmarks für Synchronisation, Reorgs, Wiederherstellung und Speicher. Sie bitten um Rückmeldungen und unabhängige Prüfung, vor allem dieses Ansatzes.
Was das bedeutet
Jeder alternative Node steht vor derselben Frage: Wie zeigt man, dass man genau die Regeln durchsetzt, die Bitcoin Core durchsetzt, einschließlich seiner Fehler? libbitcoinkernel als laufende Gegenprüfung beantwortet einen Teil davon, weil Abweichungen als fehlgeschlagene Tests sichtbar werden statt als Kettenspaltung. Die Leistungsversprechen sind Ziele, keine Messungen, und das Projekt selbst stellt sie als etwas dar, das andere nachprüfen sollen.