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

01ブロックチェーンは「設計の束」である

• NIST IR 8202は、ブロックチェーンを中央リポジトリなしに分散実装された、改ざんを検知し抵抗できるデジタル台帳と説明します。ここで重要なのは「改ざん不能」ではなく「改ざん検知可能・改ざん耐性」です。履歴を書き換える可能性と費用は、ハッシュだけでなく、合意規則、参加者、鍵、ネットワーク、実装、社会的な採用判断に依存します。
• ブロックチェーンは分散システムの一種ですが、分散システムの同義語ではありません。複製データベース、P2Pファイル共有、ジョブ分配、透明性ログも複数機で動きますが、すべてがブロックチェーンを必要とするわけではありません。逆に、ブロックチェーンを採用しても、運用権限、ホスティング、クライアント実装、資産保有、統治が少数へ集中することはあります。

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

02信頼仮定を層に分解する

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

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

03MembershipとSybil耐性 — 一票を何に結び付けるか

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

• Proof of WorkやProof of Stakeは「正しい人を見つける魔法」ではなく、無制限に安いID作成を、希少資源や罰則へ結び付ける仕組みです。どちらも資源の市場、委任、custody、運用インフラから独立ではありません。参加可能性とブロック生産の実効的な集中度は分けて測る必要があります。
• Permissioned networkでは、Hyperledger FabricのMSPのように、証明書、役割、組織、失効を明示できます。これはSybil問題を消去するのではなく、identity発行者と法的・組織的な境界へ移します。公開参加と認証参加は優劣ではなく、敵対者、責任主体、離脱可能性に対する異なる答えです。

04台帳・状態・commitmentを混同しない

• 台帳は順序付けられた出来事の記録で、状態はそれらの出来事を規則に従って適用した現在値です。複製状態機械では、各replicaが同じ決定論的な遷移を同じ順序で実行すれば同じ状態へ到達します。ブロックチェーンはこの考えを利用しますが、必ずしも全ノードが同じ履歴を永久保存することや、すべての読み取りを合意対象にすることを意味しません。
• BitcoinのUTXOモデルでは、未使用の出力を消費し、新しい出力を作ります。accountモデルはaddressごとの残高やnonce、contract storageを更新し、objectモデルやイベント中心の設計もあります。UTXOは依存関係と並列検証を表しやすく、accountは共有状態を扱いやすい一方、どちらにもconcurrency、storage、privacy、開発体験のtrade-offがあります。
• hash chainは過去の変更を後続commitmentへ波及させ、Merkle treeはrootに対する要素の包含を小さなproofで示せます。しかしproofが示すのは「この値がこのrootにcommitされた」という関係です。値が現実に正しいこと、rootが正当なchainに属すること、元データが今も取得できることは別途確かめなければなりません。

05Consensusとfinality — 有効性、順序、確定度

• Consensusは一語で語られがちですが、少なくとも取引が規則に適合するvalidity、競合する提案のordering、どの履歴をcanonicalとするfork choice、決定を戻せる条件であるfinalityを分けるべきです。多数派が投票しても無効な状態遷移が有効になるわけではなく、検証ノードは自らの規則で不正な提案を拒否します。
• Safetyは矛盾する二つの値が同時に確定しない性質、livenessは有効な要求が最終的に進む性質です。network partitionや遅延の下で両方を無条件に得ることはできません。Crash faultだけを想定するprotocolと、署名済みの矛盾した投票まで扱うByzantine fault tolerant protocolでは、必要なreplica数、quorum、通信量が異なります。

• Bitcoinのconfirmationは絶対的な時間保証ではありません。後続Proof of Workとともに履歴を置き換える期待費用が増すという、確率的・経済的なsettlementです。一方、BFT系protocolの明示的finalityも、validator鍵の侵害、集合更新、実装バグ、社会的な緊急forkまで超越するものではありません。用途は「finalか否か」ではなく、どの失敗条件と待ち時間を受け入れるかで設計します。

06実行層 — 何を全員で再計算するか

• 共有台帳が送金だけを検証するのか、汎用programを実行するのかで攻撃面と費用は大きく変わります。Bitcoin Scriptは取引出力を支出できる条件を表現する制約的な言語です。EthereumはYellow Paperで状態遷移とEVMを仕様化し、contractが共有状態を更新する一般的な実行環境を構成しました。
• replicaが同じ結果へ到達するには、実行は決定論的でなければなりません。各nodeのlocal clock、randomness、外部HTTP応答をそのまま読むと結果が分岐します。resource meteringは無限loopや過大な計算・storageを抑えますが、fee市場、state growth、失敗取引、利用者が理解しにくい実行結果という新たな設計問題を生みます。

• 「code is law」は技術的説明ではありません。codeにはcompiler、client、upgrade proxy、admin key、frontend、oracleが接続され、利用者が意図した契約とmachineが実行する規則は一致しないことがあります。仕様、実装、監査、権限、停止・復旧経路を一体として評価します。

07Data availability — rootへの合意だけでは検証できない

• block headerやstate rootに合意しても、そのrootを再計算するためのtransaction dataが隠されれば、第三者は状態遷移を独立検証できません。Data availabilityとは、blockを検証するために必要なdataが参加者へ提供されたという保証です。Ethereumの公式資料が区別するように、これは過去のdataを永久に検索できるdata retrievabilityとは別の性質です。
• monolithic chainのfull nodeはblock dataをdownloadして実行し、欠落したblockを受理しません。light client、rollup、modular designは全dataを各参加者が処理しないことでscaleしますが、その代わりavailability sampling、fraud proof、validity proof、committee、base layerへのdata公開など、異なる保証を必要とします。proof of executionが正しくても、利用者が自分の状態を復元・退出するdataが得られるとは限りません。

• 可用性の設計はstorage費用と不可分です。「すべてを永久にon-chain」は高価でprivacyや削除要件とも衝突します。一方、安いoff-chain保存は、保存者が撤退したときの復旧を弱めます。保持期間、archive責任、同期方法、検証に必要な最小dataを明文化すべきです。

08Oracleとbridge — 合意の外側から入る信頼

• 決定論的なcontractは、現実の価格、天候、配送完了、裁判判断をprotocolだけで知ることはできません。oracleは外部sourceからdataを取得し、検証・集約し、chainへ伝える仕組みです。多数のvalidatorが同じoracle値へ合意しても、その値が現実に正しいことは合意から導けません。これは「oracle problem」と呼ばれる境界です。
• oracle設計ではsourceの多様性、報告者の独立性、更新頻度、操作費用、異常値、停止時のfallback、署名鍵、governanceを調べます。複数feedを平均しても、同じupstream APIや同じ事業者へ依存すれば実質的な独立性は増えません。遅い正確なdataと速い操作可能なdataのtrade-offもあります。
• bridgeはchain Aの事象をchain Bで表現するため、light-client verification、validator署名、multi-signature、optimistic challengeなどを使います。移動先tokenの安全性は、両chainのconsensusだけでなく、message検証、custody、upgrade key、relayer、frontendまで含む新しいtrust domainに依存します。

09Governance — 仕様、実装、採用は別の層

• protocolは自然法則ではなく、文書とsoftwareと参加者の選択で維持されます。旧BIP 2を置き換えたBIP 3やEIP-1は、改善提案を記述し議論するprocessを定めますが、提案番号の取得や著者の承認だけでnetwork規則が変わるわけではありません。仕様、複数clientの実装、node operator、block producer、wallet、exchange、利用者の採用が重なって初めて変更が実効化します。
• soft forkは旧規則から見て有効な集合を狭める変更、hard forkは旧nodeが受理しない履歴を許し得る変更として説明できます。ただし互換性の分類だけでは、誰が決定したか、反対者が安全に残れるか、資産名やmarket infrastructureをどちらが引き継ぐかは決まりません。governanceはformal voteの有無だけでなく、release権限、標準化process、communication、資金提供にも存在します。

• 変更可能性は常に悪いわけではありません。bug修正や暗号移行にはupgrade経路が必要です。重要なのは、不変性を標榜しながら隠れたadmin keyを持つことではなく、変更条件、時間遅延、監査可能性、key rotation、権限放棄、緊急時の責任を明示することです。

10Permissioned ledger — identityを信頼境界へ置く

• permissioned blockchainは、参加組織、validator、reader、writerをidentity policyで制限します。Hyperledger Fabricでは、組織、peer、orderer、channel、policy、MSPがnetworkの責任境界を構成します。公開参加型の資源競争を避け、既知の相手とのprivacy、承認workflow、規制上の責任、性能を設計しやすくできます。
• 一方、認証局、consortium規約、revocation、ordering service、channel管理者が新たな信頼点になります。署名付きの複製履歴は単一組織のdatabase管理者による無断変更を発見しやすくできますが、加盟組織が結託する場合や、正当な権限で誤情報を入力する場合までは防ぎません。

• 「blockchain」という名称自体に価値を置かず、通常のdatabase、append-only transparency log、digital signature、BFT replicationと比較します。全writerが一社の指示に従い、同じ管理者がdatabaseとvalidatorを操作し、利用者が独立検証しないなら、chain構造が増やす複雑性に見合う保証は小さい可能性があります。

11採用判断 — 技術名ではなく脅威モデルから始める

• 採用前に、共有状態の所有者、writer、validator、reader、監査者を実名または役割で列挙します。次に、クラッシュ、network partition、悪意ある署名、管理者侵害、検閲、data消失、鍵紛失のうち何を扱うかを決めます。「中央管理者を信頼しない」が要件なら、誰をどの条件で信頼する設計へ置き換えるのかまで答えなければなりません。

• 一つの組織が正規writerで高速な更新・検索・訂正を必要とするなら、通常のdatabaseと署名付きaudit logが適することがあります。公開検証が必要でも、透明性logやcontent-addressed archiveで十分な場合があります。複数主体が共同で順序を決め、単独管理を避ける価値が複製・合意・鍵管理の費用を上回るとき、blockchainは候補になります。
• pilotではtransaction件数だけでなく、validator停止、partition、key rotation、software upgrade、誤入力訂正、archive復元、participant退出を試験します。平常時のdemoより、権限とdataが失われたときのrecoveryが制度として実行可能かを検証する方が、本番の保証をよく表します。

12設計空間におけるBitcoinの位置

• Bitcoinは、中央のidentity発行者なしに公開参加者が電子現金の履歴を維持するという目的に対し、Proof of Work、UTXO、hash-linked block、peer-to-peer伝播、難易度調整、発行とfeeによるincentiveを組み合わせました。full nodeはblockの作業量だけでなく、transactionとblockが自らのconsensus rulesを満たすかを検証します。minerは有効性を投票で上書きする権限を持ちません。

• Bitcoinの設計は、permissioned supply-chain ledgerや高頻度の汎用計算にそのまま移植するtemplateではありません。同様に、別のchainが高速finalityや豊富なexecutionを持つことだけで、Bitcoinと同じ公開検証、退出可能性、通貨policyを持つことにはなりません。比較はTPSやblock timeではなく、目的と信頼仮定を揃えて行います。
• 最も重要な教訓は、個々の部品より組み合わせの一貫性です。供給規則を検証するnode、Sybil耐性を担うwork、履歴選択、incentive、制約的な実行、保守的な変更processが同じ目的へ向いています。Bitcoinを分散システム史の終点ではなく、この設計空間の一つの深く統合された地点として捉えると、他方式との差を誇張も矮小化もせず評価できます。