ブロックチェーン設計論 — 台帳・状態・合意・実行・統治

NIST IR 8202は、ブロックチェーンを中央リポジトリを持たずに分散実装された台帳、つまり改ざんを検知でき、改ざんに抵抗できるデジタル台帳だと説明します。ここで重要なのは「改ざん不能」ではなく「改ざん検知可能・改ざん耐性」です。履歴を書き換えられるかどうか、書き換えにいくらかかるかは、ハッシュだけで決まりません。合意規則、参加者、鍵、ネットワーク、実装、そして社会的な採用の判断にも左右されます。

ブロックチェーンは分散システムの一種ですが、分散システムの同義語ではありません。複製データベース、P2Pファイル共有、ジョブ分配、透明性ログも複数のマシンにまたがって動きますが、そのすべてがブロックチェーンを必要とするわけではありません。逆に、ブロックチェーンを採用しても、運用権限、ホスティング、クライアント実装、資産の保有、統治が少数に集中することはあります。

したがって「どのチェーンが優れているか」より先に、保護したい資産、想定する攻撃者、障害モデル、参加の境界、利用者が自ら検証できる範囲を定義する必要があります。ブロック、トークン、スマートコントラクトは目的ではなく、その条件に応えるための選択肢です。

ブロックチェーンの保証は、単一の「コンセンサス層」から生まれるものではありません。誰を投票者として数えるか、どのデータを状態へ変換するか、検証に必要なデータを取得できるか、外部の情報を誰が報告するか、そして規則の変更を誰が採用するかが連鎖します。一つの層を強化しても、別の層に単独の管理者鍵があれば、システム全体の信頼境界はその鍵のところまで縮みます。

「分散化」も一つの数値で表せるものではありません。ブロック生成、完全検証、クライアントの多様性、ネットワークの到達性、運用の主体、資産の配分、改善提案、緊急用の鍵は、それぞれ別に観測すべきです。保証を説明するときは、平常時の速度ではなく、どの前提が破れたときに何が起きるかまで書きます。

合意の前に「誰を数えるか」を決めなければなりません。誰でも参加できるネットワークで単純に一ID一票とすると、一つの主体が多数の仮名を作れてしまいます。John Douceurが整理したSybil問題は、参加者の数が多いこと自体では、独立した主体が多いことを保証できないと示します。デジタル署名は同じ鍵による発言を認証できますが、その鍵が独立した人や組織を表すことまでは証明しません。

Proof of WorkやProof of Stakeは「正しい人を見つける魔法」ではありません。いくらでも安く作れるIDを、希少な資源や罰則へ結び付ける仕組みです。どちらも資源の市場、委任、カストディ、運用インフラから切り離せるわけではありません。誰が参加できるかと、ブロック生産が実際にどれだけ集中しているかは、分けて測る必要があります。

許可制のネットワークでは、Hyperledger FabricのMSPのように、証明書、役割、組織、失効を明示できます。これはSybil問題を消すのではなく、識別情報の発行者と、法的・組織的な境界へ移すだけです。公開参加と認証参加は優劣の関係ではなく、想定する敵対者、責任の所在、離脱のしやすさに対する異なる答えです。

台帳は順序付けられた出来事の記録で、状態はそれらの出来事を規則に従って適用した現在の値です。複製状態機械では、各レプリカが同じ決定論的な遷移を同じ順序で実行すれば、同じ状態へ到達します。ブロックチェーンはこの考えを利用しますが、全ノードが同じ履歴を永久に保存するとか、すべての読み取りを合意の対象にするといったことまで意味するわけではありません。

ビットコインのUTXOモデルでは、未使用の出力を消費して新しい出力を作ります。アカウントモデルはアドレスごとの残高やナンス、コントラクトのストレージを更新します。オブジェクト中心やイベント中心の設計もあります。UTXOは依存関係と並列検証を表しやすく、アカウントは共有状態を扱いやすい一方で、どちらにも並行処理、ストレージ、プライバシー、開発体験のトレードオフがあります。

ハッシュチェーンは過去の変更を後続のコミットメントへ波及させ、Merkle treeはルートに対する要素の包含を小さな証明で示せます。しかし証明が示すのは「この値がこのルートにコミットされた」という関係にすぎません。その値が現実に正しいこと、そのルートが正当なチェーンに属すること、元のデータが今も取得できることは、別に確かめなければなりません。

合意は一語で語られがちですが、少なくとも四つに分けて考えるべきです。取引が規則に適合するかという有効性、競合する提案をどう並べるかという順序、どの履歴を正典とみなすかというフォーク選択、そして決定を巻き戻せる条件であるファイナリティです。多数派が投票したからといって、無効な状態遷移が有効になるわけではありません。検証ノードは自らの規則にもとづいて不正な提案を拒否します。

安全性は矛盾する二つの値が同時に確定しない性質、活性は有効な要求が最終的に前へ進む性質です。ネットワークの分断や遅延の下で、この二つを無条件に両立させることはできません。クラッシュ障害だけを想定するプロトコルと、署名済みの矛盾した投票まで扱うビザンチン障害耐性のプロトコルとでは、必要なレプリカ数、クォーラム、通信量が異なります。

ビットコインの確認数は、絶対的な時間の保証ではありません。後続のProof of Workが積み上がるほど、履歴を置き換える期待費用が増すという、確率的・経済的な決済です。一方、BFT系プロトコルの明示的なファイナリティも、バリデータ鍵の侵害、集合の更新、実装のバグ、社会的な緊急フォークまで超えられるわけではありません。用途は「finalか否か」ではなく、どの失敗条件とどれだけの待ち時間を受け入れるかで設計します。

共有台帳が送金だけを検証するのか、汎用のプログラムまで実行するのかで、攻撃面と費用は大きく変わります。Bitcoin Scriptは、取引の出力を支出できる条件を表すための、制約された言語です。EthereumはYellow Paperで状態遷移とEVMを仕様化し、コントラクトが共有状態を更新する汎用の実行環境を作りました。

レプリカが同じ結果にたどり着くには、実行が決定論的でなければなりません。各ノードのローカル時計や乱数、外部のHTTP応答をそのまま読み込むと、結果は分岐します。資源の計量は無限ループや過大な計算・ストレージを抑えますが、その代わりに手数料市場、状態の肥大化、失敗する取引、利用者には予測しにくい実行結果という、新しい設計問題を生みます。

「code is law」は、技術的な安全性のモデルではありません。コードにはコンパイラ、クライアント実装、アップグレード用のプロキシ、管理者鍵、フロントエンド、オラクルがつながっており、利用者が意図した契約と、機械が実際に実行する規則は一致しないことがあります。仕様、実装、監査、権限、停止と復旧の経路は、一体として評価します。

ブロックヘッダーやステートルートに合意しても、そのルートを再計算するためのトランザクションデータが伏せられていれば、第三者は状態遷移を独立に検証できません。データ可用性とは、ブロックを検証するために必要なデータが参加者へ実際に提供されたという保証です。Ethereumの公式資料が区別するように、これは過去のデータをいつまでも取り出せるというデータ取得可能性とは別の性質です。

一枚岩のチェーンでは、フルノードがブロックデータをダウンロードして実行し、データの欠けたブロックを受理しません。ライトクライアント、rollup、モジュラー型の設計は、全データを各参加者が処理しないことで規模を伸ばします。その代わりに、可用性サンプリング、不正証明、妥当性証明、委員会、基盤層へのデータ公開といった別の保証を必要とします。実行が正しかったことを証明できても、利用者が自分の状態を復元して退出するためのデータまで手に入るとは限りません。

可用性の設計は、ストレージ費用と切り離せません。「すべてを永久にオンチェーンへ」は高価で、プライバシーや削除の要件とも衝突します。一方、安いオフチェーン保存は、保存者が撤退したときの復旧を弱めます。保持期間、アーカイブの責任、同期の方法、検証に必要な最小限のデータは、あらかじめ明文化すべきです。

決定論的な契約は、現実の価格、天候、配送の完了、裁判の判断を、プロトコルだけで知ることはできません。オラクルは外部の情報源からデータを取得し、検証・集約したうえでチェーンへ伝える仕組みです。多数のバリデータが同じオラクル値に合意しても、その値が現実に正しいことまでは合意から導けません。これは「oracle problem」と呼ばれる境界です。

オラクルの設計では、情報源の多様性、報告者の独立性、更新の頻度、操作にかかる費用、異常値の扱い、停止時の代替手段、署名鍵、ガバナンスを調べます。複数のフィードを平均しても、同じ上流APIや同じ事業者に依存していれば、実質的な独立性は増えません。遅いが正確なデータと、速いが操作されやすいデータのトレードオフもあります。

ブリッジは、チェーンAの出来事をチェーンBで表すために、ライトクライアントによる検証、バリデータの署名、マルチシグ、楽観的な異議申立てなどを使います。移動先のトークンの安全性は、両チェーンの合意だけでなく、メッセージの検証、カストディ、アップグレード鍵、リレーヤー、フロントエンドまで含む新しい信頼の領域に依存します。

プロトコルは自然法則ではなく、文書とソフトウェアと参加者の選択によって維持されます。旧BIP 2を置き換えたBIP 3やEIP-1は、改善提案を書き、議論するための手続きを定めます。ただし提案番号を得ることや著者の承認だけで、ネットワークの規則が変わるわけではありません。仕様、複数のクライアント実装、ノード運用者、ブロック生成者、ウォレット、取引所、そして利用者の採用が重なって、はじめて変更が効力を持ちます。

ソフトフォークは旧規則から見て有効な集合を狭める変更、ハードフォークは旧ノードが受理しない履歴を許し得る変更として説明できます。ただし互換性の分類だけでは、誰が決定したのか、反対する側が安全に残れるのか、資産の名前や市場インフラをどちらが引き継ぐのかは決まりません。ガバナンスは形式的な投票の有無だけでなく、リリースの権限、標準化の手続き、情報発信、資金提供にも宿ります。

変更できること自体が常に悪いわけではありません。バグ修正や暗号方式の移行には、アップグレードの経路が要ります。重要なのは、不変性をうたいながら隠れた管理者鍵を持つのではなく、変更の条件、時間の遅延、監査可能性、鍵の更新、権限の放棄、緊急時の責任を明示することです。

許可制のブロックチェーンは、参加する組織、バリデータ、読み手、書き手を、識別情報のポリシーで制限します。Hyperledger Fabricでは、組織、peer、orderer、channel、ポリシー、MSPがネットワークの責任境界を構成します。公開参加型の資源競争を避けることで、既知の相手とのプライバシー、承認のワークフロー、規制上の責任、性能を設計しやすくなります。

その一方で、認証局、コンソーシアムの規約、失効の仕組み、ordering service、channelの管理者が、新しい信頼点になります。署名付きの複製履歴があれば、単一組織のデータベース管理者による無断の変更は見つけやすくなります。ただし加盟組織どうしが結託する場合や、正当な権限で誤った情報を入力する場合までは防げません。

「blockchain」という名称自体に価値を置かず、通常のデータベース、追記のみの透明性ログ、デジタル署名、BFTによる複製と比較します。すべての書き手が一社の指示に従い、同じ管理者がデータベースとバリデータを動かし、利用者が独立検証をしないのであれば、チェーン構造が増やす複雑さに見合う保証は小さいかもしれません。

採用の前に、共有状態の所有者、書き手、バリデータ、読み手、監査者を、実名または役割で列挙します。次に、クラッシュ、ネットワークの分断、悪意ある署名、管理者の侵害、検閲、データの消失、鍵の紛失のうち、どれを扱うかを決めます。「中央管理者を信頼しない」が要件なら、誰をどの条件で信頼する設計に置き換えるのかまで答えなければなりません。

一つの組織が正規の書き手で、高速な更新・検索・訂正を必要とするなら、通常のデータベースと署名付きの監査ログが適していることがあります。公開検証が必要な場合でも、透明性ログや内容アドレス方式のアーカイブで足りることがあります。複数の主体が共同で順序を決め、単独管理を避ける価値が複製・合意・鍵管理の費用を上回るとき、ブロックチェーンは候補になります。

試験導入では、取引の件数だけでなく、バリデータの停止、ネットワークの分断、鍵の更新、ソフトウェアの更新、誤入力の訂正、アーカイブの復元、参加者の離脱まで試します。平常時のデモよりも、権限とデータが失われたときの復旧が制度として実行できるかを確かめるほうが、本番の保証をよく表します。

ビットコインは、中央の識別情報発行者を置かずに、公開の参加者が電子現金の履歴を維持するという目的に対して、Proof of Work、UTXO、ハッシュで連結したブロック、ピアツーピアの伝播、難易度調整、発行と手数料による誘因を組み合わせました。フルノードは、ブロックの作業量だけでなく、取引とブロックが自らの合意規則を満たすかどうかを検証します。マイナーには、有効性を投票で上書きする権限はありません。

ビットコインの設計は、許可制のサプライチェーン台帳や高頻度の汎用計算へ、そのまま移植できるひな型ではありません。同様に、別のチェーンが高速なファイナリティや豊かな実行環境を持つからといって、ビットコインと同じ公開検証、退出のしやすさ、通貨政策を備えることにはなりません。比較はTPSやブロック時間ではなく、目的と信頼前提を揃えて行います。

最も重要な教訓は、個々の部品よりも組み合わせの一貫性です。供給規則を検証するノード、Sybil耐性を担う作業量、履歴の選択、誘因、制約された実行、保守的な変更手続きが、いずれも同じ目的を向いています。ビットコインを分散システム史の終点ではなく、この設計空間のなかで深く統合された一点として捉えると、他方式との差を誇張も矮小化もせずに評価できます。