Wenn die meisten Leute Bitcoin Core herunterladen, ist ihre Interaktion mit dem Build-System mit wenigen Klicks beendet. Sie greifen auf die ausführbare Binärdatei der Software zurück, überprüfen (hoffentlich!) eine Signatur und starten den Betrieb eines Bitcoin-Knotens. Was sie sofort sehen, ist die Ausführung von Software. Was sie nicht sehen, ist das Build-System und die umfangreichen Prozesse, die diese Software erstellt haben. Ein Build-System, das die Bitcoin-Prinzipien der Dezentralisierung, Transparenz und Überprüfbarkeit repräsentiert.
Hinter diesem Download steckt jahrelange Ingenieursarbeit, die darauf abzielt, eine einfache Frage zu beantworten: „Warum sollte jemand dieser Software vertrauen?„Die Antwort lautet: Das sollte nicht sein. Sie sollten in der Lage sein, dies zu überprüfen.
In einer Zeit, in der Angriffe auf die Software-Lieferkette weltweit Schlagzeilen machen, angefangen bei kompromittierten NPM-Paketen über Backdoor-Bibliotheken bis hin zu betrügerischen CI-Servern, ist der Erstellungsprozess von Bitcoin Core ein stilles Projekt der Disziplin. Seine Methoden mögen im Vergleich zum reibungslosen Komfort von „Push-to-Deploy“ langsam und kompliziert erscheinen, aber genau darum geht es. Sicherheit ist nicht bequem.
Um das Build-System von Bitcoin Core zu verstehen, sollten wir Folgendes verstehen:
- Die Build-System-Philosophie von Bitcoin Core
- Reproduzierbare Builds
- Abhängigkeiten minimieren
- Keine automatischen Updates
- Kontinuierliche Integration
- Laufende Anpassung
Die Build-System-Philosophie von Bitcoin Core
Wenn es um die Dezentralisierung von Bitcoin geht, konzentrieren sich die meisten Menschen auf Miner, Knoten und Entwickler. Aber die Dezentralisierung hört nicht bei den Teilnehmern des Protokolls auf. Es erstreckt sich auf die Art und Weise, wie die Software selbst erstellt und verteilt wird.
Ein Grundsatz im Bitcoin-Ökosystem lautet „Nicht vertrauen, sondern überprüfen“. Das Betreiben eines eigenen Knotens ist ein Akt der Verifizierung, bei dem jeder Block und jede Transaktion anhand der Konsensregeln überprüft wird. Aber das Build-System selbst bietet Ihnen eine weitere Möglichkeit zur Überprüfung, auf Softwareebene. Bitcoin ist Geld ohne vertrauenswürdige Vermittler und Bitcoin Core funktioniert wie eine Software ohne vertrauenswürdige Entwickler. Das Build-System erfordert große Anstrengungen, um sicherzustellen, dass jeder unabhängig von jedem Ort genau dieselben Binärdateien neu erstellen kann, die auf dem Build-System angezeigt werden bitcoincore.org Webseite.
Diese Philosophie geht auf Ken Thompsons Essay aus dem Jahr 1984 zurück Überlegungen zum Vertrauender warnte, dass selbst einem sauber aussehenden Quellcode nicht vertraut werden kann, wenn der Compiler, der diese Software erstellt hat, selbst kompromittiert wurde. Die Entwickler von Bitcoin haben sich diese Lektion zu Herzen genommen. Mit den Worten des Bitcoin Core-Mitarbeiters Michael Ford (Fanquake):
„Reproduzierbare Builds sind von entscheidender Bedeutung, denn kein Benutzer unserer Software sollte darauf vertrauen müssen, dass das, was darin enthalten ist, das ist, was wir sagen. Dies muss immer unabhängig überprüfbar sein.“
Eine Aussage, die sowohl ein technisches Ziel als auch Teil des Bitcoin-Ethos ist.
In der Sicherheitswelt spricht man von „Angriffsflächen“. Das Build-System von Bitcoin Core behandelt den Build-Prozess selbst als Angriffsfläche, die es zu minimieren und zu verteidigen gilt.
Reproduzierbare Builds: Überprüfung bis zum Ende
Der Prozess der Erstellung einer Bitcoin Core-Version beginnt mit der Open-Source-Codebasis auf GitHub. Jede Änderung ist öffentlich. Jede Pull-Anfrage wird überprüft. Aber die Reise ist für Menschen lesbar Code zur ausführbaren Binärdatei Software Dabei handelt es sich um Compiler, Bibliotheken von Drittanbietern und Betriebssysteme, die selbst potenzielle Vektoren für Manipulationen, Hintertüren oder Fehler darstellen.
„Vertrauenswürdige Dritte sind Sicherheitslücken” – Nick Szabo (2001)
Um diese Bedenken auszuräumen, hat Bitcoin Core eine Build-Prozess-Pipeline mit Guix entwickelt, einem Paketmanager, der zum Erstellen reproduzierbarer, deterministischer Softwareumgebungen entwickelt wurde.
Wenn eine neue Bitcoin Core-Version markiert wird, erstellen mehrere unabhängige Mitwirkende die Binärdateien mit Guix von Grund auf neu. Jeder Builder arbeitet in einer isolierten Umgebung, die identische Toolchains, Compiler-Versionen und Systembibliotheken garantiert. Wenn alle Builder Ausgaben mit identischen Bits erzeugen, wissen sie, dass der Build deterministisch ist.
Anschließend signieren die Mitwirkenden die resultierenden Binärdateien kryptografisch und veröffentlichen diese Signaturen in einem separaten GitHub-Repository „guix.sigs“, das diese Attestierungen für jede Version von Bitcoin Core auflistet. Einige Builder sind Bitcoin Core-Entwickler, dies ist jedoch keine Voraussetzung, da der Zertifizierungsprozess für jedermann zugänglich ist. Tatsächlich tragen viele Nicht-Code-Mitwirkende regelmäßig Signaturen bei.
Dieser Prozess wird als reproduzierbare Builds bezeichnet und ist das Gegenmittel zu Thompsons „vertrauensvollem Vertrauen“. Dies bedeutet, dass jeder den Open-Source-Code und dieselbe Guix-Umgebung verwenden und unabhängig bestätigen kann, dass die offizielle Binärdatei mit dem übereinstimmt, was er selbst erstellt hat. Während reproduzierbare Builds verifizieren können, dass die Software eine echte Darstellung des Quellcodes der Software ist, wird die Korrektheit der Software Prozessen rund um gründliche Tests und Codeüberprüfung überlassen.
Die meisten Leute werden niemals eine vollständige Kompilierung durchführen oder die Guix-Manifeste überprüfen oder Build-Hashes vergleichen. Das ist nicht nötig. Die Existenz dieser Infrastruktur und die Menschen, die sie pflegen, geben jedem Benutzer eine Grundlage verdienten Vertrauens.
Die offiziellen Binärdateien auf bitcoincore.org werden nicht nur „von den Bitcoin Core-Betreuern produziert“. Sie sind die Schnittmenge von Dutzenden unabhängiger Bauträger. Was Sie schließlich herunterladen, ist das, was alle anderen erstellt und auf Echtheit überprüft haben.
Es ist eine Verifizierung bis ganz nach unten.
Abhängigkeiten minimieren: Weniger vertrauen
Reproduzierbarkeit ist eine Seite der Gleichung. Das andere ist die Minimierung dessen, was reproduziert werden muss. Der Code von Bitcoin Core ist nicht der einzige Code, der beim Ausführen von Bitcoin Core ausgeführt wird. Bitcoin Core setzt außerdem auf externen Code und Bibliotheken von Drittanbietern, um die Entwicklung und Produktivität zu beschleunigen.
Im letzten Jahrzehnt haben die Entwickler von Bitcoin Core diese unnötigen und manchmal problematischen Abhängigkeiten von Drittanbietern wie OpenSSL und MiniUPnP kontinuierlich beseitigt. Unabhängig davon, ob es sich um eine externe Bibliothek oder ein Toolkit handelt, erhöhen diese Abhängigkeiten die Komplexität oder führen zu versteckten Annahmen. Projekte wie Boost und Libevent, einst Grundbestandteile der Core-Codebasis, werden nach und nach eingestellt oder durch einfachere, eigenständige Alternativen ersetzt.
Warum? Denn jede Abhängigkeit, die Sie übernehmen, stellt ein potenzielles Risiko für die Lieferkette dar. Es ist mehr Code, den Sie nicht geschrieben haben, der nicht geprüft wird und den Sie nicht vollständig kontrollieren können. Durch die Reduzierung von Abhängigkeiten wird das Buildsystem schlanker, sicherer und einfacher zu überprüfen.
Brink hat diese Bemühungen kürzlich in seinem Bericht hervorgehoben Blogbeitrag „Abhängigkeiten minimieren“.[1]wobei er darauf hinweist, dass es nicht nur um Einfachheit geht, sondern auch darum, die Sicherheit und Autonomie des Projekts zu wahren. Jede entfernte Abhängigkeit bedeutet eine externe Partei weniger, der das Projekt vertrauen muss, und eine potenzielle Hintertür weniger.
Das letztendliche Ziel besteht darin, vollständig statische Binärdateien zu erstellen: ausführbare Dateien, die alles enthalten, was sie zum Ausführen benötigen, ohne dynamische oder Laufzeitabhängigkeiten. Diese Eigenständigkeit bedeutet, dass Sie nicht auf externe Bibliotheken angewiesen sind, die sich von Betriebssystem zu Betriebssystem unterscheiden können.
In einer Welt, in der die meiste Software immer umfangreicher und abhängiger von zentralisierten Paket-Ökosystemen wird, bewegt sich Bitcoin Core in die entgegengesetzte Richtung: hin zu Minimalismus und Unabhängigkeit.
Keine automatischen Updates
In den meisten modernen Softwareprogrammen sind Benutzer vor der Entscheidung geschützt, auf welche Softwareversion sie aktualisieren möchten, oder vor der Entscheidung, die Software überhaupt zu aktualisieren. Sie installieren eine App und diese aktualisiert sich im Hintergrund still und automatisch auf die neuesten Versionen. Das ist zwar praktisch, steht aber im Widerspruch zur Philosophie von Bitcoin Core.
Bitcoin Core hat nie automatische Updates integriert, und die Entwickler haben gesagt, dass dies auch nie der Fall sein wird. Automatische Updates bündeln die Leistung. Sie bilden eine einzelne Gruppe, die (potenziell bösartigen) Code an jeden Knoten im Netzwerk weiterleiten kann. Dies ist genau die Art zentraler Kontrolle, die Bitcoin vermeiden soll. Indem Benutzer neue Versionen manuell herunterladen, überprüfen und installieren müssen, stärkt Bitcoin Core die individuelle Verantwortung und die überprüfbare Zustimmung.
Das Build-System und das Fehlen automatischer Updates sind zwei Hälften desselben Prinzips. Nur der Node-Runner entscheidet, was ausgeführt werden soll, und kann überprüfen, ob die ausgeführte Software authentisch ist.
Kontinuierliche Integration: Gehen Sie langsam vor und beheben Sie Dinge
Im Silicon Valley sind Continuous Integration und Continuous Deployment (CI/CD) die Markenzeichen der agilen Softwareentwicklung. Schnell versenden. Iterieren Sie schneller. Lassen Sie die Automatisierung den Rest erledigen.
Bitcoin Core verfolgt einen anderen Ansatz. Seine CI-Systeme dienen nicht dazu, die Bereitstellung zu beschleunigen, sondern um die Integrität zu schützen. Automatisierte Builds sorgen für plattformübergreifende Testkonsistenz. Das Build-System von Bitcoin Core ist so konzipiert, dass es möglichst unabhängig von Hardware und Betriebssystemen ist. Das Projekt kann Binärdateien für Linux, macOS und Windows sowie für mehrere Architekturen erstellen, darunter x86_64, aarch64 (ARM) und sogar riscv64. Das kontinuierliche Integrationssystem stellt diese Kompatibilität sowie die Softwareintegrität sicher, indem es Hunderte von Tests für jede vorgeschlagene Änderung durchführt.
Das Ergebnis ist eine Kultur, in der „kontinuierliche Integration“ kontinuierliches Testen, Verifizieren und Sicherheit bedeutet, nicht kontinuierliche Innovation.
Gehen Sie langsam vor und reparieren Sie die Dinge.
Laufende Anpassung: Sind wir schon fertig?
Das Build-System ist nicht statisch. Entwickler verfeinern es weiter, indem sie Abhängigkeiten reduzieren, architekturübergreifende Builds verbessern und eine vollständig statische Build-Zukunft ohne Laufzeitabhängigkeiten erkunden.
Während das Build-System von Bitcoin Core nach Determinismus strebt, kann das Build-System selbst nicht statisch sein. Die Welt, in der es agiert, verändert sich ständig. Betriebssysteme, Compiler, Bibliotheken und Hardwarearchitekturen ändern sich alle. Jede neue Version von macOS oder Glibc, jede Abschaffung eines Compiler-Flags oder jede neue CPU-Architektur bringt subtile Inkompatibilitäten mit sich, die behoben werden müssen. Ein stillstehendes Build-System würde mit der Zeit überhaupt nicht mehr bauen.
Das Paradoxe an reproduzierbaren Builds besteht darin, dass sie einer kontinuierlichen Weiterentwicklung bedürfen, um reproduzierbar zu bleiben. Entwickler müssen Toolchains ständig fixieren, patchen und manchmal ersetzen, um den Determinismus vor dem Hintergrund des Wandels aufrechtzuerhalten. Die Aufrechterhaltung dieses Gleichgewichts zwischen Stabilität und Anpassungsfähigkeit ist Teil der anhaltenden Widerstandsfähigkeit von Bitcoin.
Verpassen Sie nicht Ihre Chance, es zu besitzen Das Kernproblem – mit Artikeln, die von vielen Kernentwicklern geschrieben wurden und die Projekte erläutern, an denen sie selbst arbeiten!
Bei diesem Stück handelt es sich um den Brief des Herausgebers, der in der neuesten Ausgabe vorgestellt wird Drucken Ausgabe des Bitcoin Magazine, The Core Issue. Wir teilen es hier als ersten Einblick in die Ideen, die in der gesamten Ausgabe untersucht wurden.
[1] https://brink.dev/blog/2025/09/19/minimizing-dependencies/
