ほとんどの人がBitcoin Coreをダウンロードするとき、ビルドシステムとのやり取りは数回のクリックで終わってしまいます。彼らはソフトウェアの実行可能バイナリを手に入れ、（できれば！）署名を検証し、Bitcoinノードの実行を開始します。彼らがすぐに目にするのは、動いているソフトウェアです。見えていないのは、そのソフトウェアを生み出したビルドシステムと、膨大なプロセスです。つまり、ビットコインの分散化、透明性、検証可能性という原則を体現するビルドシステムです。 そのダウンロードの背後には、「_なぜ誰かがこのソフトウェアを信じるべきなのか？_」という単純な問いに答えるために設計された何年ものエンジニアリング作業があります。答えは、「信じる必要はない」です。検証できるべきなのです。 ソフトウェア・サプライチェーン攻撃が世界的な見出しを賑わせる時代において、侵害されたnpmパッケージ、バックドア付きのライブラリ、ならず者のCIサーバなどが取り沙汰される一方で、Bitcoin Coreのビルドプロセスは規律の静かなプロジェクトとして存在しています。「push to deploy」の、摩擦のない便利さと比べて、その手法は遅くて複雑に見えるかもしれません。しかしそれがポイントです。セキュリティは便利ではありません。 Bitcoin Coreのビルドシステムを理解するには、まず理解すべきことがあります： * Bitcoin Coreのビルドシステムの哲学 * 再現可能なビルド * 依存関係の最小化 * 自動アップデートなし * 継続的インテグレーション * 継続的な適応 Bitcoin Coreのビルドシステムの哲学-------------------------------------- ビットコインの分散化となると、多くの人はマイナー、ノード、開発者に注目します。しかし分散化はプロトコルの参加者にとどまりません。ソフトウェアそのものが、どのように作られ、どのように配布されるかにも広がっています。 ビットコイン・エコシステムの一つの原則が「信じるな、検証せよ」です。自分自身でノードを動かすことは、検証の行為であり、合意ルールに照らしてすべてのブロックとトランザクションをチェックします。しかし、ビルドシステム自体が、ソフトウェアのレベルでもう一つの検証の機会をあなたに与えます。ビットコインは信頼できる仲介者のないお金であり、Bitcoin Coreは信頼できるビルダーのないソフトウェアとして機能するように努めています。ビルドシステムは、誰もが、どこにいても、bitcoincore.orgのウェブサイトに掲載されているのとまったく同じバイナリを、独立して再現できるようにするために、大きな努力を重ねています。 この思想は、ケン・トンプソンの1984年のエッセイ「_Reflections on Trusting Trust_（信頼する信頼についての省察）」にまでさかのぼり、たとえ見た目にはきれいなソースコードでも、そのソフトウェアを作ったコンパイラ自体が侵害されていれば信頼できないと警告しました。Bitcoinの開発者たちは、この教訓を胸に刻みました。Bitcoin CoreのコントリビューターMichael Ford（fanquake）の言葉を借りれば： _「再現可能なビルドは重要です。私たちのソフトウェアを使う誰もが、中に含まれているものが私たちの言うものであることを信じる必要がないようにするためです。これは、常に独立して検証可能でなければなりません。」_ 技術的な目標であると同時に、ビットコインのエトスの一部でもある声明です。 セキュリティの世界では「攻撃面（attack surfaces）」という言葉が使われます。Bitcoin Coreのビルドシステムは、ビルドプロセスそのものを、最小化され、防御されるべき攻撃面として扱います。 再現可能なビルド：下まで続く検証-------------------------------------------------- Bitcoin Coreのリリースを作り出すプロセスは、GitHub上のオープンソースのコードベースから始まります。すべての変更は公開されます。すべてのプルリクエストがレビューされます。しかし、人間が読める _コード_ から、実行可能な _ソフトウェア_ のバイナリへ至る道のりには、コンパイラ、第三者ライブラリ、そして、それ自体が改ざん、バックドア、あるいはエラーの潜在的な手がかりとなり得るオペレーティングシステムが関わってきます。 「_信頼できる第三者はセキュリティ上の穴_」– Nick Szabo（2001） これらの懸念に対処するため、Bitcoin Coreのアーキテクトは、再現可能で決定論的なソフトウェア環境を作ることを目的に設計されたパッケージマネージャであるGuixを使って、ビルドプロセスのパイプラインを構築しました。 新しいBitcoin Coreリリースがタグ付けされると、複数の独立したコントリビューターがGuixを使って、ゼロからバイナリをビルドします。それぞれのビルダーは、同一のツールチェーン、コンパイラのバージョン、システムライブラリを保証する隔離された環境で作業します。すべてのビルダーが同一ビットの出力を生成した場合、ビルドが決定論的であることを彼らは確かめます。 その後、コントリビューターは生成されたバイナリに対して暗号学的に署名し、Bitcoin Coreの各リリースのこれらの証明（attestations）を一覧する、別のGitHubリポジトリ「guix.sigs」に署名を公開します。ビルダーの中にはBitcoin Coreの開発者もいますが、必須条件ではありません。証明プロセスは一般の公開範囲で誰にでも開かれているからです。実際のところ、多くの非コードコントリビューターが、定期的に署名を提供しています。 このプロセスは再現可能なビルドとして知られており、トンプソンの「信頼する信頼」に対する解毒剤です。つまり、誰もがオープンソースのコード、同じGuix環境を使って、公式バイナリが自分たちが構築したものと一致していることを独立して確認できるということです。再現可能なビルドは、ソフトウェアがソースコードの正真正銘の表現であることを検証できますが、ソフトウェアの正しさ（correctness）は、徹底したテストやコードレビューを含む周辺のプロセスに委ねられます。 ほとんどの人は、完全なコンパイルを行ったり、Guixのマニフェストを確認したり、ビルドハッシュを比較したりすることはありません。必要ないのです。そのインフラの存在と、それを維持している人々によって、すべてのユーザーは、獲得された信頼の土台を得られます。 bitcoincore.org上の公式バイナリは、「Bitcoin Coreの開発者によって作られた」だけではありません。何十人もの独立したビルダーの出力が交差した結果です。あなたが最終的にダウンロードするのは、誰もが作り、そして本物であると検証したものです。 検証は下まで続くのです。 依存関係の最小化：信頼すべきものを減らす-------------------------------------- 再現可能性は方程式の片側です。もう片側は、再現する必要があるものを最小化することです。Bitcoin Coreを動かすときに実行されるコードは、Bitcoin Coreのコードだけではありません。Bitcoin Coreは、開発と生産性を高めるために、外部の第三者コードやライブラリにも依存しています。 過去10年の間に、Bitcoin Coreの開発者たちは、OpenSSLやMiniUPnPのような、不要であり、場合によっては問題のある第三者依存を、着実に取り除いてきました。外部ライブラリであれツールキットであれ、こうした依存は複雑さを増やしたり、隠れた前提を持ち込んだりします。BoostやLibeventのような、かつてCoreのコードベースの定番だったものも、徐々に段階的に廃止されるか、より単純で自己完結的な代替へ置き換えられています。 なぜでしょうか？ あなたが引き継ぐ依存関係はすべて、潜在的なサプライチェーンのリスクになり得るからです。あなたが書いていないコードであり、監査できず、そして完全に制御できないコードが増えることになります。依存関係を減らすことで、ビルドシステムはより軽量になり、安全になり、そして検証しやすくなります。 Brinkは最近、その「Minimizing Dependencies（依存関係の最小化）」というブログ記事[1]で、この取り組みを強調し、「単に単純化の問題ではなく、プロジェクトのセキュリティと自律性を保つことが目的だ」と述べています。取り除かれた依存関係が1つあるごとに、プロジェクトが信頼しなければならない外部当事者が1つ減り、バックドアの可能性が1つ減るのです。 最終的な目標は、完全に静的なバイナリを作り出すことです。つまり、動作に必要なものをすべて含み、動的あるいはランタイムの依存関係がない実行ファイルのことです。この自己完結性により、OSごとに異なり得る外部ライブラリへの依存がなくなります。 ほとんどのソフトウェアがより重くなり、中央集権的なパッケージ・エコシステムへの依存が強まっていく世界では、Bitcoin Coreは逆の方向へ進んでいます。ミニマリズムと独立性へ向かっているのです。 自動アップデートなし--------------- ほとんどの現代的なソフトウェアでは、ユーザーは「どのソフトウェアバージョンへ更新するか」や「そもそもソフトウェアを更新するかどうか」といった判断からは隔離されています。アプリをインストールすると、それが静かに、そして自動的に、バックグラウンドで最新バージョンへ更新されます。これは便利ですが、Bitcoin Coreの哲学とは相容れません。 Bitcoin Coreには自動アップデートは含まれたことがなく、開発者たちはそれを将来も行わないと言っています。自動アップデートは権力を集中させます。ネットワーク上のすべてのノードへ（潜在的に悪意のある）コードを押し込める単一のグループを作ってしまいます。これは、Bitcoinが避けるべく作られたまさにその種の中央集権的な制御です。ユーザーに、新しいバージョンを手動でダウンロードし、検証し、インストールすることを求めることで、Bitcoin Coreは個々の責任と、検証可能な同意を強化します。 ビルドシステムと、自動アップデートがないことは、同じ原則の2つの側面です。何を実行するかを決めるのはノードの実行者だけであり、実行されるソフトウェアが真正であることを検証できるのもその人だけです。 継続的インテグレーション：遅く進めて、問題を直す------------------------------------------------ シリコンバレーでは、継続的インテグレーションと継続的デプロイメント（CI/CD）はアジャイルなソフトウェア開発の特徴とされています。速く出荷する。もっと速く反復する。あとは自動化に任せる。 Bitcoin Coreは別のアプローチを取っています。CIシステムは、デプロイを加速するためではなく、完全性を守るために存在します。自動化されたビルドは、プラットフォーム間での一貫性をテストします。Bitcoin Coreのビルドシステムは、可能な限り、ハードウェアやオペレーティングシステムに依存しないように設計されています。このプロジェクトは、x86_64、aarch64（ARM）、さらにはriscv64を含む複数のアーキテクチャだけでなく、Linux、macOS、Windows向けにもバイナリをビルドできます。継続的インテグレーションのシステムは、提案された各変更に対して何百ものテストを実行することで、この互換性とソフトウェアの完全性の両方を保証します。 その結果、「継続的インテグレーション」とは、継続的な革新ではなく、継続的なテスト、検証、そしてセキュリティを意味する文化が生まれます。 遅く進めて、問題を直す。 継続的な適応：まだ終わりですか？------------------------------------ ビルドシステムは固定されたものではありません。開発者たちは、依存関係を減らし、クロスアーキテクチャのビルドを改善し、そしてランタイム依存関係をゼロにした完全に静的なビルドの将来を探求することで、これを継続的に洗練させています。 Bitcoin Coreのビルドシステムは決定論を目指していますが、ビルドシステムそのものは静的であり得ません。ビルドシステムが動作する世界は、常に移り変わっています。オペレーティングシステム、コンパイラ、ライブラリ、ハードウェアのアーキテクチャはすべて変化します。macOSやglibcの新しいリリース、コンパイラフラグの廃止、あるいは新たに登場するCPUアーキテクチャは、対処が必要な微妙な非互換性をもたらします。じっと止まったビルドシステムは、時間の経過とともに、まったくビルドできなくなってしまうでしょう。 再現可能なビルドのパラドックスは、再現可能であり続けるためには継続的な進化が必要だという点です。開発者は、変化していく状況の背景に対して決定論性を維持するために、常にツールチェーンを固定し、パッチを当て、そして場合によっては置き換えなければなりません。安定性と適応性のバランスを保つことは、Bitcoinの継続的なレジリエンス（回復力）の一部です。 今すぐ『The Core Issue（コア・イシュー）』を入手してください！ **『The Core Issue』を所有するチャンスを逃さないでください** — 多くのCore開発者が、自分たちが取り組んでいるプロジェクトを説明した記事を掲載！ _これは、Bitcoin Magazineの最新Print edition（プリント版）「The Core Issue」に掲載されたEditor（編集者）からの手紙（Letter from the Editor）です。ここでは、号全体を通して探求されるアイデアの早いプレビューとして共有しています。_ [1]
核心問題：二進法の下で、信頼性を検証する
ほとんどの人がBitcoin Coreをダウンロードするとき、ビルドシステムとのやり取りは数回のクリックで終わってしまいます。彼らはソフトウェアの実行可能バイナリを手に入れ、（できれば！）署名を検証し、Bitcoinノードの実行を開始します。彼らがすぐに目にするのは、動いているソフトウェアです。見えていないのは、そのソフトウェアを生み出したビルドシステムと、膨大なプロセスです。つまり、ビットコインの分散化、透明性、検証可能性という原則を体現するビルドシステムです。
そのダウンロードの背後には、「なぜ誰かがこのソフトウェアを信じるべきなのか？」という単純な問いに答えるために設計された何年ものエンジニアリング作業があります。答えは、「信じる必要はない」です。検証できるべきなのです。
ソフトウェア・サプライチェーン攻撃が世界的な見出しを賑わせる時代において、侵害されたnpmパッケージ、バックドア付きのライブラリ、ならず者のCIサーバなどが取り沙汰される一方で、Bitcoin Coreのビルドプロセスは規律の静かなプロジェクトとして存在しています。「push to deploy」の、摩擦のない便利さと比べて、その手法は遅くて複雑に見えるかもしれません。しかしそれがポイントです。セキュリティは便利ではありません。
Bitcoin Coreのビルドシステムを理解するには、まず理解すべきことがあります：
Bitcoin Coreのビルドシステムの哲学
ビットコインの分散化となると、多くの人はマイナー、ノード、開発者に注目します。しかし分散化はプロトコルの参加者にとどまりません。ソフトウェアそのものが、どのように作られ、どのように配布されるかにも広がっています。
ビットコイン・エコシステムの一つの原則が「信じるな、検証せよ」です。自分自身でノードを動かすことは、検証の行為であり、合意ルールに照らしてすべてのブロックとトランザクションをチェックします。しかし、ビルドシステム自体が、ソフトウェアのレベルでもう一つの検証の機会をあなたに与えます。ビットコインは信頼できる仲介者のないお金であり、Bitcoin Coreは信頼できるビルダーのないソフトウェアとして機能するように努めています。ビルドシステムは、誰もが、どこにいても、bitcoincore.orgのウェブサイトに掲載されているのとまったく同じバイナリを、独立して再現できるようにするために、大きな努力を重ねています。
この思想は、ケン・トンプソンの1984年のエッセイ「Reflections on Trusting Trust（信頼する信頼についての省察）」にまでさかのぼり、たとえ見た目にはきれいなソースコードでも、そのソフトウェアを作ったコンパイラ自体が侵害されていれば信頼できないと警告しました。Bitcoinの開発者たちは、この教訓を胸に刻みました。Bitcoin CoreのコントリビューターMichael Ford（fanquake）の言葉を借りれば：
「再現可能なビルドは重要です。私たちのソフトウェアを使う誰もが、中に含まれているものが私たちの言うものであることを信じる必要がないようにするためです。これは、常に独立して検証可能でなければなりません。」
技術的な目標であると同時に、ビットコインのエトスの一部でもある声明です。
セキュリティの世界では「攻撃面（attack surfaces）」という言葉が使われます。Bitcoin Coreのビルドシステムは、ビルドプロセスそのものを、最小化され、防御されるべき攻撃面として扱います。
再現可能なビルド：下まで続く検証
Bitcoin Coreのリリースを作り出すプロセスは、GitHub上のオープンソースのコードベースから始まります。すべての変更は公開されます。すべてのプルリクエストがレビューされます。しかし、人間が読める コード から、実行可能な ソフトウェア のバイナリへ至る道のりには、コンパイラ、第三者ライブラリ、そして、それ自体が改ざん、バックドア、あるいはエラーの潜在的な手がかりとなり得るオペレーティングシステムが関わってきます。
「信頼できる第三者はセキュリティ上の穴」– Nick Szabo（2001）
これらの懸念に対処するため、Bitcoin Coreのアーキテクトは、再現可能で決定論的なソフトウェア環境を作ることを目的に設計されたパッケージマネージャであるGuixを使って、ビルドプロセスのパイプラインを構築しました。
新しいBitcoin Coreリリースがタグ付けされると、複数の独立したコントリビューターがGuixを使って、ゼロからバイナリをビルドします。それぞれのビルダーは、同一のツールチェーン、コンパイラのバージョン、システムライブラリを保証する隔離された環境で作業します。すべてのビルダーが同一ビットの出力を生成した場合、ビルドが決定論的であることを彼らは確かめます。
その後、コントリビューターは生成されたバイナリに対して暗号学的に署名し、Bitcoin Coreの各リリースのこれらの証明（attestations）を一覧する、別のGitHubリポジトリ「guix.sigs」に署名を公開します。ビルダーの中にはBitcoin Coreの開発者もいますが、必須条件ではありません。証明プロセスは一般の公開範囲で誰にでも開かれているからです。実際のところ、多くの非コードコントリビューターが、定期的に署名を提供しています。
このプロセスは再現可能なビルドとして知られており、トンプソンの「信頼する信頼」に対する解毒剤です。つまり、誰もがオープンソースのコード、同じGuix環境を使って、公式バイナリが自分たちが構築したものと一致していることを独立して確認できるということです。再現可能なビルドは、ソフトウェアがソースコードの正真正銘の表現であることを検証できますが、ソフトウェアの正しさ（correctness）は、徹底したテストやコードレビューを含む周辺のプロセスに委ねられます。
ほとんどの人は、完全なコンパイルを行ったり、Guixのマニフェストを確認したり、ビルドハッシュを比較したりすることはありません。必要ないのです。そのインフラの存在と、それを維持している人々によって、すべてのユーザーは、獲得された信頼の土台を得られます。
bitcoincore.org上の公式バイナリは、「Bitcoin Coreの開発者によって作られた」だけではありません。何十人もの独立したビルダーの出力が交差した結果です。あなたが最終的にダウンロードするのは、誰もが作り、そして本物であると検証したものです。
検証は下まで続くのです。
依存関係の最小化：信頼すべきものを減らす
再現可能性は方程式の片側です。もう片側は、再現する必要があるものを最小化することです。Bitcoin Coreを動かすときに実行されるコードは、Bitcoin Coreのコードだけではありません。Bitcoin Coreは、開発と生産性を高めるために、外部の第三者コードやライブラリにも依存しています。
過去10年の間に、Bitcoin Coreの開発者たちは、OpenSSLやMiniUPnPのような、不要であり、場合によっては問題のある第三者依存を、着実に取り除いてきました。外部ライブラリであれツールキットであれ、こうした依存は複雑さを増やしたり、隠れた前提を持ち込んだりします。BoostやLibeventのような、かつてCoreのコードベースの定番だったものも、徐々に段階的に廃止されるか、より単純で自己完結的な代替へ置き換えられています。
なぜでしょうか？ あなたが引き継ぐ依存関係はすべて、潜在的なサプライチェーンのリスクになり得るからです。あなたが書いていないコードであり、監査できず、そして完全に制御できないコードが増えることになります。依存関係を減らすことで、ビルドシステムはより軽量になり、安全になり、そして検証しやすくなります。
Brinkは最近、その「Minimizing Dependencies（依存関係の最小化）」というブログ記事[1]で、この取り組みを強調し、「単に単純化の問題ではなく、プロジェクトのセキュリティと自律性を保つことが目的だ」と述べています。取り除かれた依存関係が1つあるごとに、プロジェクトが信頼しなければならない外部当事者が1つ減り、バックドアの可能性が1つ減るのです。
最終的な目標は、完全に静的なバイナリを作り出すことです。つまり、動作に必要なものをすべて含み、動的あるいはランタイムの依存関係がない実行ファイルのことです。この自己完結性により、OSごとに異なり得る外部ライブラリへの依存がなくなります。
ほとんどのソフトウェアがより重くなり、中央集権的なパッケージ・エコシステムへの依存が強まっていく世界では、Bitcoin Coreは逆の方向へ進んでいます。ミニマリズムと独立性へ向かっているのです。
自動アップデートなし
ほとんどの現代的なソフトウェアでは、ユーザーは「どのソフトウェアバージョンへ更新するか」や「そもそもソフトウェアを更新するかどうか」といった判断からは隔離されています。アプリをインストールすると、それが静かに、そして自動的に、バックグラウンドで最新バージョンへ更新されます。これは便利ですが、Bitcoin Coreの哲学とは相容れません。
Bitcoin Coreには自動アップデートは含まれたことがなく、開発者たちはそれを将来も行わないと言っています。自動アップデートは権力を集中させます。ネットワーク上のすべてのノードへ（潜在的に悪意のある）コードを押し込める単一のグループを作ってしまいます。これは、Bitcoinが避けるべく作られたまさにその種の中央集権的な制御です。ユーザーに、新しいバージョンを手動でダウンロードし、検証し、インストールすることを求めることで、Bitcoin Coreは個々の責任と、検証可能な同意を強化します。
ビルドシステムと、自動アップデートがないことは、同じ原則の2つの側面です。何を実行するかを決めるのはノードの実行者だけであり、実行されるソフトウェアが真正であることを検証できるのもその人だけです。
継続的インテグレーション：遅く進めて、問題を直す
シリコンバレーでは、継続的インテグレーションと継続的デプロイメント（CI/CD）はアジャイルなソフトウェア開発の特徴とされています。速く出荷する。もっと速く反復する。あとは自動化に任せる。
Bitcoin Coreは別のアプローチを取っています。CIシステムは、デプロイを加速するためではなく、完全性を守るために存在します。自動化されたビルドは、プラットフォーム間での一貫性をテストします。Bitcoin Coreのビルドシステムは、可能な限り、ハードウェアやオペレーティングシステムに依存しないように設計されています。このプロジェクトは、x86_64、aarch64（ARM）、さらにはriscv64を含む複数のアーキテクチャだけでなく、Linux、macOS、Windows向けにもバイナリをビルドできます。継続的インテグレーションのシステムは、提案された各変更に対して何百ものテストを実行することで、この互換性とソフトウェアの完全性の両方を保証します。
その結果、「継続的インテグレーション」とは、継続的な革新ではなく、継続的なテスト、検証、そしてセキュリティを意味する文化が生まれます。
遅く進めて、問題を直す。
継続的な適応：まだ終わりですか？
ビルドシステムは固定されたものではありません。開発者たちは、依存関係を減らし、クロスアーキテクチャのビルドを改善し、そしてランタイム依存関係をゼロにした完全に静的なビルドの将来を探求することで、これを継続的に洗練させています。
Bitcoin Coreのビルドシステムは決定論を目指していますが、ビルドシステムそのものは静的であり得ません。ビルドシステムが動作する世界は、常に移り変わっています。オペレーティングシステム、コンパイラ、ライブラリ、ハードウェアのアーキテクチャはすべて変化します。macOSやglibcの新しいリリース、コンパイラフラグの廃止、あるいは新たに登場するCPUアーキテクチャは、対処が必要な微妙な非互換性をもたらします。じっと止まったビルドシステムは、時間の経過とともに、まったくビルドできなくなってしまうでしょう。
再現可能なビルドのパラドックスは、再現可能であり続けるためには継続的な進化が必要だという点です。開発者は、変化していく状況の背景に対して決定論性を維持するために、常にツールチェーンを固定し、パッチを当て、そして場合によっては置き換えなければなりません。安定性と適応性のバランスを保つことは、Bitcoinの継続的なレジリエンス（回復力）の一部です。
今すぐ『The Core Issue（コア・イシュー）』を入手してください！
『The Core Issue』を所有するチャンスを逃さないでください — 多くのCore開発者が、自分たちが取り組んでいるプロジェクトを説明した記事を掲載！
これは、Bitcoin Magazineの最新Print edition（プリント版）「The Core Issue」に掲載されたEditor（編集者）からの手紙（Letter from the Editor）です。ここでは、号全体を通して探求されるアイデアの早いプレビューとして共有しています。
[1]