核心問題:二進法の下で、信頼性を検証する

ほとんどの人が Bitcoin Core をダウンロードするとき、ビルドシステムとのやり取りは数回のクリックで終わります。彼らはソフトウェアの実行可能なバイナリを取得し、署名を確認し(願わくば!)、Bitcoin ノードを実行し始めます。彼らがすぐに見るのは実行中のソフトウェアです。彼らが見えないのは、そのソフトウェアを生み出したビルドシステムと広範なプロセスです。ビルドシステムは、ビットコインの分散化、透明性、および検証可能性の原則を体現しています。

そのダウンロードの背後には、「なぜ誰もがこのソフトウェアを信頼すべきなのか?」という単純な質問に答えるために設計された数年分のエンジニアリング作業があります。答えは:あなたは信頼する必要はありません。あなたは検証できるべきです。

ソフトウェア供給チェーン攻撃が世界の見出しを飾る時代に、侵害された npm パッケージ、バックドア付きライブラリ、悪意のある CI サーバーから、Bitcoin Core のビルドプロセスは静かな規律のプロジェクトとして存在しています。その方法は、「プッシュしてデプロイ」の摩擦のない利便性に比べて遅く複雑に見えるかもしれませんが、それがポイントです。セキュリティは便利ではありません。

Bitcoin Core のビルドシステムを理解するためには、以下を理解する必要があります:

  • Bitcoin Core のビルドシステム哲学
  • 再現可能なビルド
  • 依存関係の最小化
  • 自動更新なし
  • 継続的インテグレーション
  • 継続的な適応

Bitcoin Core のビルドシステム哲学

ビットコインの分散化に関して、多くの人々はマイナー、ノード、開発者に焦点を当てます。しかし、分散化はプロトコルの参加者にとどまりません。それはソフトウェア自体の構築と配布の方法にまで及びます。

ビットコインエコシステムの原則の一つは「信頼せず、検証する」ということです。自分自身のノードを運営することは、合意ルールに対してすべてのブロックとトランザクションをチェックする検証の行為です。しかし、ビルドシステム自体は、ソフトウェアレベルで別の検証の機会を提供します。ビットコインは信頼された仲介者なしの通貨であり、Bitcoin Core は信頼されたビルダーなしのソフトウェアを目指しています。ビルドシステムは、誰でもどこでも bitcoincore.org ウェブサイトに表示されるのとまったく同じバイナリを独立して再作成できるようにするために大きな努力をしています。

この哲学は、1984 年のケン・トンプソンによるエッセイ「信頼の信頼について」にさかのぼります。このエッセイでは、見た目がクリーンなソースコードであっても、そのソフトウェアを構築したコンパイラが妥協されている場合は信頼できないことが警告されています。ビットコインの開発者たちはこの教訓を真剣に受け止めました。Bitcoin Core の貢献者であるマイケル・フォード(fanquake)の言葉を借りれば、

「再現可能なビルドは重要です。なぜなら、私たちのソフトウェアのユーザーは、内部に含まれているものが私たちが言っているものと同じであると信頼する必要はありません。これは常に独立して検証可能であるべきです。」

これは技術的な目標であると同時に、ビットコインの精神の一部です。

セキュリティの世界では、人々は「攻撃面」について話します。Bitcoin Core のビルドシステムは、ビルドプロセス自体を最小化し、防御すべき攻撃面と見なしています。

再現可能なビルド:すべての段階での検証

Bitcoin Core のリリースを作成するプロセスは、GitHub 上のオープンソースコードベースから始まります。すべての変更は公開され、すべてのプルリクエストはレビューされます。しかし、人間が読める コード から実行可能なバイナリ ソフトウェア への道のりには、コンパイラ、サードパーティライブラリ、およびオペレーティングシステムが含まれ、これらはそれ自体が改ざん、バックドア、またはエラーの潜在的なベクトルとなります。

信頼できる第三者はセキュリティホールです」 – ニック・ザボ (2001)

これらの懸念に対処するために、Bitcoin Core は再現可能で決定論的なソフトウェア環境を作成するために設計されたパッケージマネージャーである Guix を使用してビルドプロセスパイプラインを構築しました。

新しい Bitcoin Core リリースがタグ付けされると、複数の独立した貢献者が Guix を使用してバイナリをゼロから構築します。各ビルダーは、同一のツールチェーン、コンパイラバージョン、およびシステムライブラリを保証する隔離された環境で作業します。すべてのビルダーが同一の出力を生成した場合、彼らはビルドが決定論的であることを知っています。

その後、貢献者は結果のバイナリに暗号学的に署名し、各 Bitcoin Core のリリースに対するこれらの証明をリストする別の GitHub リポジトリ「guix.sigs」にその署名を公開します。一部のビルダーは Bitcoin Core の開発者ですが、証明プロセスは一般の誰でも参加できるため、必須ではありません。実際、多くの非コード貢献者が定期的に署名を提供しています。

このプロセスは再現可能なビルドとして知られており、トンプソンの「信頼の信頼」に対する解毒剤です。これは、誰でもオープンソースコード、同じ Guix 環境を取り、独立して公式バイナリが自分たちが構築したものと一致することを確認できることを意味します。再現可能なビルドは、ソフトウェアがソースコードの真の表現であることを検証できますが、ソフトウェアの正確性は徹底的なテストとコードレビューのプロセスに依存しています。

ほとんどの人は完全なコンパイルを行ったり、Guix マニフェストを確認したり、ビルドハッシュを比較したりすることはありません。彼らはそれをする必要はありません。そのインフラストラクチャの存在と、それを維持する人々が、すべてのユーザーに得られた信頼の基盤を提供します。

bitcoincore.org 上の公式バイナリは「Bitcoin Core のメンテナーによって生成された」だけではありません。それらは、数十の独立したビルダーの出力の交差点です。最終的にダウンロードするものは、他のすべての人が構築し、認証されたものであることが確認されています。

それはすべての段階での検証です。

依存関係の最小化:信頼するものを減らす

再現性は方程式の一側面です。もう一方は、再現する必要のあるものを最小限に抑えることです。Bitcoin Core のコードは、Bitcoin Core を実行する際に実行される唯一のコードではありません。Bitcoin Core は、開発と生産性を加速するために外部のサードパーティコードやライブラリにも依存しています。

過去 10 年間、Bitcoin Core の開発者たちは、OpenSSL や MiniUPnP のような、不要で時には問題のあるサードパーティ依存関係を着実に取り除いてきました。外部ライブラリやツールキットであれ、これらの依存関係は複雑さを追加したり、隠れた仮定を取り入れたりします。かつて Core のコードベースの主力だった Boost や Libevent のようなプロジェクトは、徐々に廃止されたり、よりシンプルで自己完結的な代替品に置き換えられています。

なぜですか?それは、引き継ぐすべての依存関係が潜在的な供給チェーンリスクだからです。それは、あなたが書いていないコード、監査していないコード、完全に制御できないコードです。依存関係を減らすことで、ビルドシステムはよりスリムで安全で、検証しやすくなります。

Brink は最近、この取り組みを「依存関係の最小化」というブログ投稿で強調し、単純さの問題だけでなく、プロジェクトのセキュリティと自律性を維持することについて述べています。各削除された依存関係は、プロジェクトが信頼しなければならない外部の当事者が一つ減り、バックドアの可能性が一つ減ります。

最終的な目標は、完全に静的なバイナリを生成することです:実行に必要なすべてを含む実行可能ファイルで、動的またはランタイムの依存関係はありません。この自己包含性は、オペレーティングシステムによって異なる可能性のある外部ライブラリに依存しないことを意味します。

ほとんどのソフトウェアが重くなり、中央集権的なパッケージエコシステムに依存する方向に進む中、Bitcoin Core は反対の方向、すなわちミニマリズムと独立性に向かっています。

自動更新なし

ほとんどの現代のソフトウェアでは、ユーザーはどのソフトウェアバージョンに更新するか、またはそもそもソフトウェアを更新するかの決定から保護されています。アプリをインストールすると、それは静かに自動的に最新バージョンに更新されます。これは便利ですが、Bitcoin Core の哲学には反します。

Bitcoin Core には自動更新機能は含まれておらず、開発者たちはそれが決して含まれないと言っています。自動更新は力を集中させます。それは、コードをネットワーク上のすべてのノードにプッシュできる単一のグループを作り出します。これは、ビットコインが回避するために構築された中央集権的な制御そのものです。ユーザーに手動で新しいバージョンをダウンロード、検証、インストールさせることで、Bitcoin Core は個々の責任と検証可能な同意を強化します。

ビルドシステムと自動更新の不在は、同じ原則の二つの半分です。ノードランナーだけが何を実行するかを決定し、実行されるソフトウェアが本物であることを確認できます。

継続的インテグレーション:遅く進み、問題を修正する

シリコンバレーでは、継続的インテグレーションと継続的デプロイメント(CI/CD)がアジャイルソフトウェア開発の特徴です。迅速に出荷し、さらに迅速に反復します。自動化に残りのことを任せます。

Bitcoin Core は異なるアプローチを取ります。その CI システムは、デプロイを加速するためではなく、整合性を守るために存在します。自動ビルドは、プラットフォーム間の一貫性をテストします。Bitcoin Core のビルドシステムは、ハードウェアとオペレーティングシステムにできるだけ依存しないように設計されています。このプロジェクトは、Linux、macOS、Windows 用のバイナリを構築できるほか、x86_64、aarch64(ARM)、さらには riscv64 を含む複数のアーキテクチャ向けにもビルドできます。継続的インテグレーションシステムは、この互換性とソフトウェアの整合性を確保するために、提案された変更ごとに数百のテストを実行します。

その結果、「継続的インテグレーション」は継続的なテスト、検証、セキュリティを意味し、継続的な革新ではありません。

遅く進み、問題を修正します。

継続的な適応:もう終わりですか?

ビルドシステムは静的ではありません。開発者たちは、依存関係を減らし、クロスアーキテクチャビルドを改善し、ランタイム依存性ゼロの完全静的ビルドの未来を探ることで、継続的にそれを洗練しています。

Bitcoin Core のビルドシステムは決定論を目指していますが、ビルドシステム自体は静的にはなりません。動作する世界は常に変化しています。オペレーティングシステム、コンパイラ、ライブラリ、ハードウェアアーキテクチャはすべて変わります。macOS や glibc の新しいリリース、コンパイラフラグの廃止、または新たに登場する CPU アーキテクチャはすべて、対処すべき微妙な互換性の問題を引き起こします。静的なビルドを行うビルドシステムは、時間と共にビルドを行うことができなくなります。

再現可能なビルドの逆説は、それらが再現可能であり続けるために継続的な進化を必要とすることです。開発者たちは、変化の動く背景に対して決定論を維持するために、常にツールチェーンを固定し、パッチを当て、時には置き換えなければなりません。この安定性と適応性の間のバランスを維持することは、ビットコインの継続的な復元力の一部です。

今日、The Core Issue を手に入れましょう!

The Core Issue を手に入れるチャンスをお見逃しなく — 多くの Core 開発者が自身のプロジェクトについて説明する記事を掲載しています!

この記事は、最新の Bitcoin Magazine の印刷版で特集された編集者からの手紙です。私たちは、全体の号で探求されるアイデアの早期のプレビューとしてここに共有しています。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
コメントを追加
コメントを追加
コメントなし
  • 人気の Gate Fun

    もっと見る
  • 時価総額:$0.1保有者数:1
    0.00%
  • 時価総額:$2.25K保有者数:1
    0.00%
  • 時価総額:$2.26K保有者数:1
    0.00%
  • 時価総額:$2.26K保有者数:1
    0.00%
  • 時価総額:$2.26K保有者数:1
    0.00%
  • ピン