Ralph Merkle

暗号化したメッセージを送りたいとします。相手が読むには秘密の鍵が必要ですが、通信をすべて見られているなら、鍵をどう渡せばよいのでしょうか。Ralph Merkle は 1978 年の論文で意外な方法を説明しました。送信者が多数の暗号化パズルを用意し、受信者は無作為に選んだものを解いて、内部に隠されていた識別子を公開して送り返します。これで両者は共通の鍵を知ります。盗聴者にも識別子は見えますが、それがどのパズルに入っていたかは分かりません。論文のモデルでは、参加者の作業量は問題の規模に比例し、盗聴者の作業量はその二乗に比例して増えます。差は二次的であり、指数的ではありません。歴史的な突破口ではありますが、現在のメッセージ暗号化の推奨手順ではありません。 [1]

1978 年の論文を理解するには、攻撃者に何ができるかが重要です。盗聴は可能ですが、改変や偽造は検出できるという前提が残っています。手紙を読む人と、書き換えたうえにあなたの名前で署名する人を想像してください。後者には、実際に誰と通信しているのかを確かめる追加の保護が必要です。計算作業量の差だけでは、その問題は解決しません。したがって、このパズルは能動的な仲介攻撃者を通る任意の通信の安全性を保証しません。示したのは、明示された前提の下なら、事前に秘密鍵を共有していなくても合意できるということです。 [1]

Merkle Tree が扱うのは別の問題です。この認証木は Merkle の 1979 年の博士論文に登場します。契約書の保管庫を考えてみましょう。全体をダウンロードせず、特定の契約書だけ確認したい場面です。各項目からハッシュという短いデジタル指紋を計算します。指紋を対にして結合し、再びハッシュ化することを繰り返すと、共通の根が残ります。ハッシュ化は内容の暗号化ではなく、一致を検証するための処理です。検証には、正しい保管庫のものと事前に認証された根が必要です。詐欺師が文書と任意の根を両方渡せるなら、その一致は元の保管庫について何も証明しません。 [2]

8 項目を持つ平衡二分木を例にします。選んだ葉を検証するには、各階層で隣の枝を表す、合計 3 個の兄弟ハッシュが必要です。自分の葉とこれらの指紋から根を計算し、認証済みの根と比較します。葉そのものと根は、この補助ハッシュの数には含みません。木の構造と結合の順番、つまり隣の値を左に置くか右に置くかも知っている必要があります。データの節約は、隠された情報を使う手品ではありません。遠くの部分は指紋で表されるので、この検証に他の文書の全文は不要なのです。 [2]

Merkle Tree が示すのは、項目と特定のデータ集合との関係です。誤った情報を真実に変えるわけではありません。例の保管庫には、名前を間違えた契約書も入れられます。証明はその収録を正しく示しても、名前の誤りを見つけません。同様に、指紋は文書の作成者に権限があったことも示しません。項目はこの根に対応するのか、根をどこから知ったのか、どの規則で内容を受け入れるのかを分けて考えましょう。そうすれば、同じ技術が Bitcoin でできることと、他の構成要素に必要な役割が分かります。 [2]

Bitcoin は Merkle Tree で取引とブロックの要約記録であるブロックヘッダーを結び付けます。根はヘッダーに含まれ、収録した取引の変更は共通の指紋に反映されます。Satoshi Nakamoto は whitepaper の第 7 節でこの構造を説明し、Merkle の研究を参考文献に挙げています。これは技術的な影響の記録であり、Merkle が Bitcoin の作者だという証拠ではありません。木は有効な履歴を選ばず、ノードの代わりに取引の署名を検証することもありません。Bitcoin は取引検証や、計算作業の証明である Proof of Work などと組み合わせて使います。ひとつの部品にシステム全体の能力を当てはめず、その役割を理解することが大切です。 [3]

whitepaper の第 8 節は SPV、簡易支払い検証を説明しています。軽量クライアントはブロックヘッダーと、取引を対象ブロックに結び付ける木の枝を使います。データ量は減りますが、累積作業量が最大のチェーンや採掘者の行動に関する前提に依存します。収録証明だけでは、完全検証を行う Full Node と同じように取引の全規則を確認できません。また、ある出力が後から使われたかどうかも分かりません。その後の出来事を知る必要があるからです。初心者にとって重要なのは、「この支払いがこのブロックにある」と「今使える資金を完全に確認した」を混同しないことです。 [3]

1979 年の博士論文では、認証木を有限個の一回限りのデジタル署名にも利用しています。デジタル署名は、特定の秘密鍵の持ち主がメッセージを承認したか確認する仕組みで、紙の署名を写した画像ではありません。木は多数の検証用の値を、ひとつの既知の根に結び付けられます。ただし、この構成で使える署名の数には限りがあり、いずれ根を更新する必要があります。同じ一回用の鍵を無制限に再利用してよいという意味ではありません。この高度な部分にも、必要な範囲を小さな証明で確かめ、その成立条件を正確に理解するという共通の考え方があります。 [2]