Bitcoin Development Philosophy

プログラムにバグがなくても、提案がシステム全体を弱めることはあります。たとえば検証の一部を外部サービスに任せれば、使いやすくなるかもしれません。本書は、その交換で何を得て、誰を信頼し始めるのかを明らかにする手助けをします。説明は過去の議論や経験豊かな開発者の考えと結び付けられています。有名な人が支持するからではなく、提案の根拠を見て判断することを学びます。 [2]

前提となるのは、採掘時に示される仕事である Proof of Work、ブロックの作られ方、そして取引が送信されてからチェーンに入るまでの流れです。その先に、分散化、Trustlessness、プライバシー、供給上限、更新、Adversarial thinking、公開された開発、スケーリング、事故対応という 9 つの主要章があります。最初のビットコイン購入ガイドではなく、基礎を踏まえてルールや慣行の意味を考える本です。 [2] [1]

Trustlessness は、今後誰も信じないという意味ではありません。引用される Pieter Wuille の説明では、信頼する仲介者なしにプロトコルが動作できることを指します。Full Node、つまり完全な検証を行うノードは、受け取ったブロックが許可されないコインを作ったり、同じ金額を二重に使ったりしていないかを自分で確認します。自分で検証しなければ、その仕事を他者に任せます。ただしノードも、欠陥のあり得る具体的なソフトウェアとハードウェアの上で動きます。 [3]

支払いを記録したブロックが、後から別の有効なチェーン分岐に置き換わる場面を考えてみてください。この履歴変更を再編成と呼び、支払いの状態も変わることがあります。章では David Harding を参照し、ルールの検証と、このリスクへの対処を区別します。承認が増えるとは、そのブロックの後ろにさらにブロックが加わることで、通常は置き換えが難しくなります。それでも、自分のノードがすべての履歴変更を阻止できるという約束ではありません。 [3]

支払いを検証する前にも、確認すべきことがあります。ダウンロードしたプログラムは公開ソースコードに対応しているのでしょうか。再現可能なビルドでは、異なる人が同じ材料から同じ出力ファイルを作れます。その比較は配布プログラムの確認に役立ちます。ただし章は Carl Dong の説明も紹介しています。ビルドに使った道具の由来も重要です。ファイルの一致だけでは、コード、コンパイラー、コンピューターに欠陥がないとは証明できません。 [3]

Adversarial thinking は、敵対者の立場から提案を考える姿勢です。参加者が正直なら動くかだけでなく、攻撃者が悪用すると何を得られるかを問います。章では Andrew Poelstra と Jameson Lopp を参照し、安全性の前提を検討します。正直なネットワークからノードを隔離することや、公開された協力作業を意図的に妨げることが例です。これまで動いてきた事実だけで、システム全体の安全性が形式的に証明されるわけではありません。 [4]

引用される Eric Voskuil の抵抗の公理は、国家の統制にシステムが抵抗できるという仮定から始まります。ここで公理は思考の出発点であり、Bitcoin が無敵だと示す試験結果ではありません。普通の読者にも重要な違いです。強い仕組みを探す価値があることと、自分たちの作る仕組みが何にでも耐えることは別です。本書は、こうした前提を見つけ、見落としを減らす視点を示します。 [4]

各主張について、何を検証し、何が仮定のままで、変更が利用者にどんな便利さをもたらすのかを考えてみてください。著者は記事や講演へのリンクを添え、記事のコピーと出典情報をリポジトリ内の別資料集に保存しています。この紹介は、序文全文と Trustlessness、Adversarial thinking の両章全文に基づきます。他の章は目次から説明しており、全書と全リンクの書評でも、実施済みのセキュリティ監査でもありません。 [2] [3] [4]