ほとんどの人がBitcoin Coreをダウンロードするとき、そのビルドシステムとの関わりは数回クリックするだけで終わります。ソフトウェアの実行可能バイナリを取得し、署名を検証（できれば！）して、ビットコインノードを起動します。彼らが最初に目にするのは動作中のソフトウェアです。しかし、彼らが見ていないのは、そのソフトウェアを作り出したビルドシステムと広範なプロセスです。これは、ビットコインの分散化、透明性、検証性の原則を体現したビルドシステムです。そのダウンロードの背後には、単純な問いに答えるために長年にわたって行われてきたエンジニアリング作業があります：「_なぜ誰もこのソフトウェアを信頼すべきなのか？_」答えは：信頼する必要はないということです。検証できるはずです。ソフトウェア供給チェーン攻撃が世界的なニュースになる時代において、npmパッケージの改ざん、バックドアのあるライブラリ、 rogue CIサーバーなどに対抗する中、Bitcoin Coreのビルドプロセスは静かに規律を守るプロジェクトとして立ち上がっています。その方法は、「デプロイまでの推進」のような摩擦のない便利さと比べると遅く複雑に見えるかもしれませんが、それが狙いです。セキュリティは便利ではないのです。Bitcoin Coreのビルドシステムを理解するには、次の点を理解する必要があります：* Bitcoin Coreのビルドシステム哲学* 再現性のあるビルド* 依存関係の最小化* 自動更新なし* 継続的インテグレーション* 継続的な適応Bitcoin Coreのビルドシステム哲学----------------------------ビットコインの分散化に関して、多くの人はマイナー、ノード、開発者に焦点を当てます。しかし、分散化はプロトコルの参加者だけにとどまりません。ソフトウェア自体の構築と配布の方法にも及びます。ビットコインエコシステムの一つの原則は「信頼しない、検証せよ」です。自分のノードを運用することは検証行為であり、すべてのブロックとトランザクションを合意ルールに照らして確認します。しかし、ビルドシステム自体も、ソフトウェアレベルで検証の機会を提供します。ビットコインは信頼できる仲介者なしの通貨であり、Bitcoin Coreは信頼できるビルダーなしのソフトウェアを目指しています。ビルドシステムは、誰でもどこでも、bitcoincore.orgのウェブサイトに掲載されている正確なバイナリを独立して再現できるように細心の注意を払っています。この哲学は、1984年のケン・トンプソンのエッセイ『Reflections on Trusting Trust』にさかのぼります。そこでは、たとえ見た目がきれいなソースコードでも、そのソフトウェアをビルドしたコンパイラ自体が改ざんされている場合は信用できないと警告しています。Bitcoinの開発者たちはその教訓を心に刻みました。Bitcoin Coreの貢献者Michael Ford（fanquake）の言葉を借りれば：_「再現性のあるビルドは非常に重要です。なぜなら、私たちのソフトウェアの利用者は、内部に何が含まれているかを信頼しなくてよいからです。これは常に独立して検証可能でなければなりません。」_これは技術的な目標であると同時に、ビットコインの精神の一部でもあります。セキュリティの世界では、「攻撃面」という言葉が使われます。Bitcoin Coreのビルドシステムは、ビルドプロセス自体を最小化し、防御すべき攻撃面とみなしています。再現性のあるビルド：検証はすべての層で-----------------------------------Bitcoin Coreのリリースを作成するプロセスは、GitHubのオープンソースコードベースから始まります。すべての変更は公開され、すべてのプルリクエストはレビューされます。しかし、人間が読めるコードから実行可能なバイナリソフトウェアに至るまでの過程には、コンパイラやサードパーティのライブラリ、オペレーティングシステムなど、改ざんやバックドア、エラーの潜在的なベクトルが含まれています。「_信頼できる第三者はセキュリティホール_」 – Nick Szabo（2001）これらの懸念に対処するために、Bitcoin CoreはGuixというパッケージマネージャを用いて、再現性のある決定論的なソフトウェア環境を作り出すビルドパイプラインを構築しました。新しいBitcoin Coreのリリースがタグ付けされると、複数の独立した貢献者がGuixを使ってゼロからバイナリをビルドします。各ビルダーは、ツールチェーン、コンパイラのバージョン、システムライブラリが完全に一致する隔離された環境で作業します。すべてのビルダーが同じビット列の出力を生成できれば、そのビルドは決定論的であると確認できます。次に、貢献者は結果のバイナリに暗号署名を行い、その署名を別のGitHubリポジトリ「guix.sigs」に公開します。これには各リリースの証明書が記載されており、誰でも検証可能です。中にはBitcoin Coreの開発者もいますが、必須ではありません。公開されているため、多くの非コード貢献者も署名を提供しています。このプロセスは「再現性のあるビルド」と呼ばれ、Thompsonの「信頼できる信頼」への解毒剤です。誰でもオープンソースコードと同じGuix環境を使って、公式のバイナリが自分たちが作ったものと一致することを独立して確認できます。再現性のあるビルドは、ソフトウェアがソースコードの正当な表現であることを検証できますが、その正確性は徹底したテストとコードレビューのプロセスに委ねられています。ほとんどの人は完全なコンパイルやGuixのマニフェストの確認、ビルドハッシュの比較を行わないでしょう。それは必要ありません。そのインフラと、それを維持する人々の存在が、すべてのユーザーに信頼の土台を与えています。bitcoincore.orgの公式バイナリは、「Bitcoin Coreのメンテナが作っただけ」ではありません。複数の独立したビルダーの出力の交差点です。最終的にダウンロードするものは、皆が作り、検証して正当性を確認したものです。それは、すべての層で検証されているのです。依存関係の最小化：信頼すべきものを減らす-----------------------------------再現性は方程式の一側面です。もう一つは、再現すべきものを最小限に抑えることです。Bitcoin Coreのコードは、Bitcoin Coreを動かすときに唯一実行されるコードではありません。Bitcoin Coreはまた、開発と生産性を向上させるために外部のサードパーティコードやライブラリに依存しています。過去10年にわたり、Bitcoin Coreの開発者はこれらの不要で時には問題を引き起こすサードパーティ依存を着実に排除してきました。OpenSSLやMiniUPnPなどです。外部ライブラリやツールキットは、複雑さを増し、隠された前提を導入します。かつてCoreのコードベースの定番だったBoostやLibeventも、徐々に廃止またはよりシンプルで自己完結型の代替に置き換えられつつあります。なぜか？それは、あなたが継承する依存関係は潜在的な供給チェーンリスクだからです。自分で書いていないコード、監査していないコード、完全にコントロールできないコードです。依存関係を減らすことで、ビルドシステムはより軽量、安全、検証しやすくなります。Brinkは最近、「依存関係の最小化」についてのブログ記事[1]で、この努力を強調しています。それは単なるシンプルさの問題ではなく、プロジェクトのセキュリティと自律性を守るためのものです。削除された依存関係は、信頼すべき外部の関係者が少なくなることを意味し、バックドアの潜在リスクも減少します。最終的な目標は、完全に静的なバイナリを作ることです。必要なすべてを含み、動的またはランタイムの依存関係を持たない実行ファイルです。この自己完結型は、異なるOS間で異なる可能性のある外部ライブラリへの依存を排除します。ソフトウェアがますます重くなり、中央集権的なパッケージエコシステムに依存する世界の中で、Bitcoin Coreは逆方向に進んでいます：ミニマリズムと自立性を追求しています。自動更新なし-------------ほとんどの現代ソフトウェアでは、ユーザーはどのバージョンに更新するか、または更新するかどうかの決定から保護されています。アプリをインストールすると、静かに自動的に最新バージョンに更新されます。便利ではありますが、これはBitcoin Coreの哲学に反します。Bitcoin Coreは一度も自動更新を含んだことはなく、今後も含めるつもりはありません。自動更新は権力の集中を招きます。ネットワーク上のすべてのノードに（潜在的に悪意のある）コードをプッシュできる一つのグループを作り出します。これは、Bitcoinが避けるべき中央集権的コントロールそのものです。ユーザーが手動で新しいバージョンをダウンロード、検証、インストールすることを求めることで、Bitcoin Coreは個人の責任と検証可能な同意を強化します。ビルドシステムと自動更新の欠如は、同じ原則の二つの側面です。ノードの運用者だけが何を実行するかを決定し、そのソフトウェアが正当なものであることを検証できます。継続的インテグレーション：遅く進めて修正を--------------------------------------シリコンバレーでは、継続的インテグレーションと継続的デプロイ（CI/CD）がアジャイル開発の象徴です。迅速に出荷し、より早く反復し、自動化に任せる。しかし、Bitcoin Coreは異なるアプローチを取っています。彼らのCIシステムは、展開を加速させるためではなく、整合性を守るために存在します。自動ビルドは、プラットフォーム間の一貫性をテストします。Bitcoin Coreのビルドシステムは、ハードウェアやOSにできるだけ依存しないよう設計されています。Linux、macOS、Windows向けのバイナリや、x86_64、aarch64（ARM）、riscv64など複数のアーキテクチャ向けのビルドも可能です。継続的インテグレーションシステムは、これらの互換性とソフトウェアの整合性を確保するために、提案された変更ごとに何百ものテストを実施します。その結果、「継続的インテグレーション」とは、継続的なテスト、検証、セキュリティを意味し、絶え間ない革新ではないという文化が育まれています。遅く進めて修正を。継続的な適応：もう終わったのか？----------------------------ビルドシステムは静的ではありません。開発者は、依存関係の削減、クロスアーキテクチャビルドの改善、ゼロランタイム依存の完全静的ビルドの模索など、継続的に改良を続けています。Bitcoin Coreのビルドシステムは決定論性を追求していますが、それ自体は静的であり得ません。動作環境は常に変化しています。OS、コンパイラ、ライブラリ、ハードウェアアーキテクチャは変わり続けます。macOSやglibcの新リリース、コンパイラフラグの廃止、新しいCPUアーキテクチャの登場は、微妙な非互換性をもたらし、それに対応しなければなりません。静止したビルドシステムは、時間とともにビルドできなくなるでしょう。再現性のあるビルドのパラドックスは、それを維持するためには絶え間ない進化が必要だということです。開発者は、決定論性を保つために、ツールチェーンを固定し、パッチを当て、時には置き換える必要があります。このバランスを保つことが、ビットコインの継続的な耐性の一部です。今日の『The Core Issue』を手に入れよう！**『The Core Issue』を所有するチャンスをお見逃しなく** — 多くのコア開発者が自らの作業について解説した記事を掲載しています！_この文章は、Bitcoin Magazineの最新号『The Core Issue』の編集者からの手紙として掲載されたものです。全体のアイデアを早期に紹介するためにここに共有しています。_[1]
核心問題：二進法の下で、信頼性を検証する
ほとんどの人がBitcoin Coreをダウンロードするとき、そのビルドシステムとの関わりは数回クリックするだけで終わります。ソフトウェアの実行可能バイナリを取得し、署名を検証（できれば！）して、ビットコインノードを起動します。彼らが最初に目にするのは動作中のソフトウェアです。しかし、彼らが見ていないのは、そのソフトウェアを作り出したビルドシステムと広範なプロセスです。これは、ビットコインの分散化、透明性、検証性の原則を体現したビルドシステムです。
そのダウンロードの背後には、単純な問いに答えるために長年にわたって行われてきたエンジニアリング作業があります：「なぜ誰もこのソフトウェアを信頼すべきなのか？」答えは：信頼する必要はないということです。検証できるはずです。
ソフトウェア供給チェーン攻撃が世界的なニュースになる時代において、npmパッケージの改ざん、バックドアのあるライブラリ、 rogue CIサーバーなどに対抗する中、Bitcoin Coreのビルドプロセスは静かに規律を守るプロジェクトとして立ち上がっています。その方法は、「デプロイまでの推進」のような摩擦のない便利さと比べると遅く複雑に見えるかもしれませんが、それが狙いです。セキュリティは便利ではないのです。
Bitcoin Coreのビルドシステムを理解するには、次の点を理解する必要があります：
Bitcoin Coreのビルドシステム哲学
ビットコインの分散化に関して、多くの人はマイナー、ノード、開発者に焦点を当てます。しかし、分散化はプロトコルの参加者だけにとどまりません。ソフトウェア自体の構築と配布の方法にも及びます。
ビットコインエコシステムの一つの原則は「信頼しない、検証せよ」です。自分のノードを運用することは検証行為であり、すべてのブロックとトランザクションを合意ルールに照らして確認します。しかし、ビルドシステム自体も、ソフトウェアレベルで検証の機会を提供します。ビットコインは信頼できる仲介者なしの通貨であり、Bitcoin Coreは信頼できるビルダーなしのソフトウェアを目指しています。ビルドシステムは、誰でもどこでも、bitcoincore.orgのウェブサイトに掲載されている正確なバイナリを独立して再現できるように細心の注意を払っています。
この哲学は、1984年のケン・トンプソンのエッセイ『Reflections on Trusting Trust』にさかのぼります。そこでは、たとえ見た目がきれいなソースコードでも、そのソフトウェアをビルドしたコンパイラ自体が改ざんされている場合は信用できないと警告しています。Bitcoinの開発者たちはその教訓を心に刻みました。Bitcoin Coreの貢献者Michael Ford（fanquake）の言葉を借りれば：
「再現性のあるビルドは非常に重要です。なぜなら、私たちのソフトウェアの利用者は、内部に何が含まれているかを信頼しなくてよいからです。これは常に独立して検証可能でなければなりません。」
これは技術的な目標であると同時に、ビットコインの精神の一部でもあります。
セキュリティの世界では、「攻撃面」という言葉が使われます。Bitcoin Coreのビルドシステムは、ビルドプロセス自体を最小化し、防御すべき攻撃面とみなしています。
再現性のあるビルド：検証はすべての層で
Bitcoin Coreのリリースを作成するプロセスは、GitHubのオープンソースコードベースから始まります。すべての変更は公開され、すべてのプルリクエストはレビューされます。しかし、人間が読めるコードから実行可能なバイナリソフトウェアに至るまでの過程には、コンパイラやサードパーティのライブラリ、オペレーティングシステムなど、改ざんやバックドア、エラーの潜在的なベクトルが含まれています。
「信頼できる第三者はセキュリティホール」 – Nick Szabo（2001）
これらの懸念に対処するために、Bitcoin CoreはGuixというパッケージマネージャを用いて、再現性のある決定論的なソフトウェア環境を作り出すビルドパイプラインを構築しました。
新しいBitcoin Coreのリリースがタグ付けされると、複数の独立した貢献者がGuixを使ってゼロからバイナリをビルドします。各ビルダーは、ツールチェーン、コンパイラのバージョン、システムライブラリが完全に一致する隔離された環境で作業します。すべてのビルダーが同じビット列の出力を生成できれば、そのビルドは決定論的であると確認できます。
次に、貢献者は結果のバイナリに暗号署名を行い、その署名を別のGitHubリポジトリ「guix.sigs」に公開します。これには各リリースの証明書が記載されており、誰でも検証可能です。中にはBitcoin Coreの開発者もいますが、必須ではありません。公開されているため、多くの非コード貢献者も署名を提供しています。
このプロセスは「再現性のあるビルド」と呼ばれ、Thompsonの「信頼できる信頼」への解毒剤です。誰でもオープンソースコードと同じGuix環境を使って、公式のバイナリが自分たちが作ったものと一致することを独立して確認できます。再現性のあるビルドは、ソフトウェアがソースコードの正当な表現であることを検証できますが、その正確性は徹底したテストとコードレビューのプロセスに委ねられています。
ほとんどの人は完全なコンパイルやGuixのマニフェストの確認、ビルドハッシュの比較を行わないでしょう。それは必要ありません。そのインフラと、それを維持する人々の存在が、すべてのユーザーに信頼の土台を与えています。
bitcoincore.orgの公式バイナリは、「Bitcoin Coreのメンテナが作っただけ」ではありません。複数の独立したビルダーの出力の交差点です。最終的にダウンロードするものは、皆が作り、検証して正当性を確認したものです。
それは、すべての層で検証されているのです。
依存関係の最小化：信頼すべきものを減らす
再現性は方程式の一側面です。もう一つは、再現すべきものを最小限に抑えることです。Bitcoin Coreのコードは、Bitcoin Coreを動かすときに唯一実行されるコードではありません。Bitcoin Coreはまた、開発と生産性を向上させるために外部のサードパーティコードやライブラリに依存しています。
過去10年にわたり、Bitcoin Coreの開発者はこれらの不要で時には問題を引き起こすサードパーティ依存を着実に排除してきました。OpenSSLやMiniUPnPなどです。外部ライブラリやツールキットは、複雑さを増し、隠された前提を導入します。かつてCoreのコードベースの定番だったBoostやLibeventも、徐々に廃止またはよりシンプルで自己完結型の代替に置き換えられつつあります。
なぜか？それは、あなたが継承する依存関係は潜在的な供給チェーンリスクだからです。自分で書いていないコード、監査していないコード、完全にコントロールできないコードです。依存関係を減らすことで、ビルドシステムはより軽量、安全、検証しやすくなります。
Brinkは最近、「依存関係の最小化」についてのブログ記事[1]で、この努力を強調しています。それは単なるシンプルさの問題ではなく、プロジェクトのセキュリティと自律性を守るためのものです。削除された依存関係は、信頼すべき外部の関係者が少なくなることを意味し、バックドアの潜在リスクも減少します。
最終的な目標は、完全に静的なバイナリを作ることです。必要なすべてを含み、動的またはランタイムの依存関係を持たない実行ファイルです。この自己完結型は、異なるOS間で異なる可能性のある外部ライブラリへの依存を排除します。
ソフトウェアがますます重くなり、中央集権的なパッケージエコシステムに依存する世界の中で、Bitcoin Coreは逆方向に進んでいます：ミニマリズムと自立性を追求しています。
自動更新なし
ほとんどの現代ソフトウェアでは、ユーザーはどのバージョンに更新するか、または更新するかどうかの決定から保護されています。アプリをインストールすると、静かに自動的に最新バージョンに更新されます。便利ではありますが、これはBitcoin Coreの哲学に反します。
Bitcoin Coreは一度も自動更新を含んだことはなく、今後も含めるつもりはありません。自動更新は権力の集中を招きます。ネットワーク上のすべてのノードに（潜在的に悪意のある）コードをプッシュできる一つのグループを作り出します。これは、Bitcoinが避けるべき中央集権的コントロールそのものです。ユーザーが手動で新しいバージョンをダウンロード、検証、インストールすることを求めることで、Bitcoin Coreは個人の責任と検証可能な同意を強化します。
ビルドシステムと自動更新の欠如は、同じ原則の二つの側面です。ノードの運用者だけが何を実行するかを決定し、そのソフトウェアが正当なものであることを検証できます。
継続的インテグレーション：遅く進めて修正を
シリコンバレーでは、継続的インテグレーションと継続的デプロイ（CI/CD）がアジャイル開発の象徴です。迅速に出荷し、より早く反復し、自動化に任せる。
しかし、Bitcoin Coreは異なるアプローチを取っています。彼らのCIシステムは、展開を加速させるためではなく、整合性を守るために存在します。自動ビルドは、プラットフォーム間の一貫性をテストします。Bitcoin Coreのビルドシステムは、ハードウェアやOSにできるだけ依存しないよう設計されています。Linux、macOS、Windows向けのバイナリや、x86_64、aarch64（ARM）、riscv64など複数のアーキテクチャ向けのビルドも可能です。継続的インテグレーションシステムは、これらの互換性とソフトウェアの整合性を確保するために、提案された変更ごとに何百ものテストを実施します。
その結果、「継続的インテグレーション」とは、継続的なテスト、検証、セキュリティを意味し、絶え間ない革新ではないという文化が育まれています。
遅く進めて修正を。
継続的な適応：もう終わったのか？
ビルドシステムは静的ではありません。開発者は、依存関係の削減、クロスアーキテクチャビルドの改善、ゼロランタイム依存の完全静的ビルドの模索など、継続的に改良を続けています。
Bitcoin Coreのビルドシステムは決定論性を追求していますが、それ自体は静的であり得ません。動作環境は常に変化しています。OS、コンパイラ、ライブラリ、ハードウェアアーキテクチャは変わり続けます。macOSやglibcの新リリース、コンパイラフラグの廃止、新しいCPUアーキテクチャの登場は、微妙な非互換性をもたらし、それに対応しなければなりません。静止したビルドシステムは、時間とともにビルドできなくなるでしょう。
再現性のあるビルドのパラドックスは、それを維持するためには絶え間ない進化が必要だということです。開発者は、決定論性を保つために、ツールチェーンを固定し、パッチを当て、時には置き換える必要があります。このバランスを保つことが、ビットコインの継続的な耐性の一部です。
今日の『The Core Issue』を手に入れよう！
『The Core Issue』を所有するチャンスをお見逃しなく — 多くのコア開発者が自らの作業について解説した記事を掲載しています！
この文章は、Bitcoin Magazineの最新号『The Core Issue』の編集者からの手紙として掲載されたものです。全体のアイデアを早期に紹介するためにここに共有しています。
[1]