「【Dfinity】Internet Computer の概要と Bitcoinとの統合についての解説」 を噛み砕いて粉砕する

こんにちは、DfinityJPの @hokosugi です。

長い時間がかかりましたが、BTCインテグレーションがいよいよ間近に迫ってきています。まずはBTCのテストネットから統合して、後にメインネットを統合する予定です。BTCインテグレーションは馴染みのあるブリッジとは違うとは聞きますが、どのように違うのか、安全性はどうなのか、この統合がどのようなインパクトををもたらすのか、興味が付きないところです。

このブログでは、hoosan さんが書いてくれた「【Dfinity】Internet Computer の概要と Bitcoinとの統合についての解説」をもっと分かりやすく、なるべく専門用語を少なくして体感的に分かるようにして、自分が理解出来るように、噛み砕いていこうとする試みです。

もし、読んでいて分からないところがありましたら、ご連絡ください。その都度、加筆、修正していきます。

「Peer-to-peer 層」から

この層では、外部からのユーザー入力や、他のサブネットからのメッセージをサブネット内のノード間に複製するための Peer-to-peer メッセージングを行います。

サブネットの複数ノードそれぞれに集まったデータはノード間で共有しないといけません。そのために P2P 層と呼ばれるデータを共有プールのような空間に一旦集めます。よくあるクライアント・サーバモデルのデータベースは基本的に一つの巨大なサーバにデータを集積しますが、これを複数ノードで協力して共有する形で集積していきます。BTC 初めほとんどのブロックチェーンはこの peer-to-peer の仕組みを使ってコンセンサスを取っています。有名なのが Winny（ファイル共有システム）で、開発者の金子勇さんはこのためサトシナカモトではないかと言われたりしています。これだけではデータを保存しているだけなので、スマートコントラクトを実際に行う実行層へ移動させて、スマートコントラクトで演算ができるようにに入力値と入力順序を確定するコンセンサスを取るコンセンサス層に移します。

なお、この Peer-to-Peer に集まったデータは改ざん、削除されないのか気になりましたが、wiki のデメリットにも記載がないので、そういったことはない、もしくは影響を与えるほどのことではない、と認識しています。

「コンセンサス層」から

コンセンサスの仕組みは下記の図のようになってます。以下、簡単に説明します。

1.  Random Beacon （これは Chain Key によって生成されます）で得られた Random Value （この値を元にランク付け）で、 Replica の中から Block Maker が選出されます。このBlock Maker 以外の Replica は Notary に回ります。しかし、Block Maker や Notary になることが自動的に決まるわけではなく、優先順序上位でなくともブロック提案することは可能で同一ブロック高さで複数ブロック提案になる可能性はあります、この Random Beacon で複数ブロックを抑制する効果があると言ったほうが適切かもしれません。また、Notary に複数公証（極端な話、すべてのブロック提案に公証してもよい）を認めることで2/3以上の同意を得やすくし（理由は、Random Beacon はすべての Replica の同意を得ているので適切な Maker として認められやすい）、どの提案も2/3以上の公証を獲得できずに立ち往生してしまう状態を防止します。
2.  選出された Block Maker は、P2P 層にあるユーザーからの入力データ等を選択 (*1 )して順序立てて Block 候補を作成、Notary に提案します。
3. Notary は提案された Block のシンタックスが問題なければ（他にも検証すべき箇所があるかもしれませんが主にシンタックスがBlock提案の拒否、もしくは「正直なBlock Maker」として認定されない原因と思います）、これを受け入れ、公証 Share という秘密鍵断片で署名します（これも Chain Key）。

（*1 ）「選択」としたのはブロック自体かもしくは一つのデータに制限が掛かっているため、P2P 層にあるすべてのデータを一つのブロックとして格納出来ないのではないかと思ったからです。理由は こちら 。

なお、公証が否定されたり、ネットワークが非同期的（asynchronous）だった場合には、他のノードが Block Maker となります。複数のブロックが提出された場合、時間内に提出されて公証されたブロックのうち最もランクが低い（0が最も低く、1, 2と続く）Block Maker が提出したブロックが最終的に採用（Finalized）されることになります[参照]。

2. でも書いたように Block Maker はランク付けされており、優先順序が高い順に Maker が変更されていきます。サブネットのノードは Dfinity foundation（具体的は ICA ）で認可を受ける許可・登録制なので、そもそもノードが悪意を持っているわけではありませんが、攻撃を受けて不正側になることや突発的に落ちたりする可能性があるので、予備（fallback）として Maker を選出する必要があります。それをしないと第一候補の Maker の提案が失敗した場合、正当でないレプリカからの提案、若しくは他の提案がない事態に陥るので Fault Tolerance （耐障害性）がないことになります。また、ランダムに選出するのは固定や予期可能な順であれば、それを狙った攻撃が考えられるためです。また、Maker を完全に固定して一つの Replica が担当すると検閲も可能になります。

また、同じ高さのブロックで Notary の1/3以上が複数ブロック提案に公証 Share を付ける（署名する）場合は finalized はされません。公証のように複数の 公証 Share で署名するレベルではなくて、より確実な確定をする必要があると考えられています。BTCや他のチェーンでは確定的な Finalized は出来ず、確率的にしか Finalized されません。この確定時期が不明瞭であることが問題視されており、Finalized の確定は重要です。

覆されることなく確実な Finalized をするために、Notary の1/3以上が複数 Finalized Share していない（つまり、2/3の Replica が一つの Finalized Share しか発行していない）時に確定します。これを待って確定となりますが（つまり、毎ブロックで Finalized はされない可能性がある）、それまでの Finalized されていないブロックはどうなるのでしょうか？一つだけ確定してもその前のブロックは未確定では不自然です。そこで、一つ前の Finalized されたブロックに遡って Finalized されたことを暗黙のうちに確定しているとすることになっています。なお、Finalized が長期間出来ない状況が続くと立ち往生してしまうので（Livenessが失われる）、 Replica が少しずつ公証するのを遅らせることで余分な複数公証を減らす Delay 関数が用意されています。これにより、Finalized が行われること（Liveness があること）が証明されています。

秘密計算とBLS閾値署名

Chain key に使われている暗号技術をリスト化してみました。

1. MPC は複数人で協働してそれぞれが持ち寄った秘密の数値を計算することです。
   1. 閾値署名は秘密計算の一種で、一定数以上の秘密の数値が集まれば、暗号化された数値が復号できる仕組み、 ii. と iii. の技術も含む
   2. 秘密計算の構成方法の一つ。元の秘密の数値を単独では復元できないように複数個に分散させる仕組み。乱数を用いて分散化させるのが一般的。
   3. 秘密計算で復元・復号されてその秘密の数値は公表されてしまうのではいみがないので、公開せずにこの数値が正しいことを検証し証明する方法。
2. NiDKG（non-interactive distributed key generation）は、Dfinity Foundation が開発した暗号技術。
   1. サブネットを生成する際、関連する初期ノード（Replica）と対話をせずに乱数生成、秘密鍵 Share を作成できる。非対話型にすることでノード（Replica）に秘密鍵を推定させる痕跡をなくすメリットがある
   2. 初期段階と Re-Sharing 毎に各ノードへ安全に秘密鍵 Share をセキュアに分配する
3. Chain Evolution は Dfinity Foundation 独自の暗号技術です。重要なのは、秘密鍵 Share（断片）の更新で Re-Sharing と呼ばれています。これによって長期間秘密鍵を固定しておくことでの漏洩リスクを軽減できます。Re-Sharing やガーベッジコレクション等を実行するために数百ラウンド毎に「エポック」と呼ばれるブロックのを束ねるオペレーションを行います。このエポックを一つの単位にして、秘密鍵 Share（断片）を更新し、それまでのブロックをハッシュ化しマークルツリーのルートだけ次に生成されるブロックに引き継ぐことでブロックデータを消去するガーベッジコレクション等を実施します。

上図は ICP プロトコルで利用される Chain key の主な用途一覧です。Chain key が如何にプロトコルレベルで多用されているかよく分かります。

Internet Computer と Bitcoin ネットワークの統合

これは hoosan さんのブログとほぼ同じ解説図ですが、BTCの統合の動き数字で示しています。

1. Bitcoin Adapter は ICP ブロックチェーンの外にあって、Replica（ノード）の OS で動作しているプロセスの一部になります。ここで BTC チェーンが 展開する Peer-to-Peer層にアクセスして、以下のデータを取得します。これが ICP で BTC を統合するための第一歩です。
   • BTC全ブロックのブロックヘッダ（BTC=>ICP）
   • ICP からの BTC へリクエストするブロックキャッシュ（ICP=>BTC）
   • 送信 TX のキャッシュ（ICP=>BTC）
2. 1. で入手した BTC のブロックチェーンデータは ICP プロトコル内のコンセンサスを経てペイロードが Networking (P2P層) => Consensus => Message Routing を経て実行層である Bitcoin Component に渡されます。
3. Bitcoin Component は Canister で BTC の UTXO のほぼ全履歴を保持します。ほぼと書いたのは、 BTC がフォークした場合を考慮して直近の UTXO を確定せずに「遊び」を設けているからと考えられます（wikiに具体的な解説がありますが、未だ理解出来ておりません）。この Component からその他の Canister が BTC をスマートコントラクトに乗せる事ができる BTC API に接続出来るようになります。
4. 各 Canister は BTC API によって、直接 BTC の出入金や流動性プール等の提供が可能になります。BTC のアドレスを付与されてユーザーから BTC を入金を可能にします。スマートコントラクトを実行する際に、署名をするのが次の ECDSA 閾値署名です。
5. Threshold ECDSA（ECDSA閾値署名）は、BTC の秘密鍵を乱数から生成・各ノードに秘密分散（MPC）させて署名のリクエストがある時に秘密鍵の断片を各 Replica から集め、閾値（2/3以上の分散された秘密鍵）を超えると署名します。
6. Canister のスマートコントラクトで実行された TX は、通常のアップデートコールと同じように Canister からアウトプットされ、1. の「送信 TX のキャッシュ」となって、 BTC の  P2P層にブロードキャスト（転送）されます。

これが一連の BTC 統合後に行われる BTC の送金と Canister でスマートコントラクト実行するフローです。

ここからは推測と私見になります。

Bitcoin Component は最初は一つとされているので、ECDSA 閾値署名で生成される秘密鍵・公開鍵も１対だと思いますが、ウォレットが BIP32 に準拠するとなると、アドレスはいくらでも生成可能です。主に Canister に与えられるアドレスの秘密鍵が　Canister 単位で生成できるならユーザー単位で秘密鍵を保持する Canister を作成すれば、ユーザー毎に秘密鍵が振り当てられることも可能にかるかもしれません。

自分のイメージでは、BTC を ICP へデポジットして、その後 ICP でサービスを受けていくと思っていましたが、もっとシームレスでボーダーレスな世界感かもしれません。例えば、BTC アドレスからいきなり Spinner Cash へ送金しサービスを受けてそのまま立ち去るようなことも想像できます。これが ICP でのサービスかどうかすら意識することもなしにです。但し、そうはいっても ICP でのサービスではユーザーの BTC と ID の紐付けが必要になることも多いはずなので、II や Plug で認証するアプリが主流になるはずです。

今回は以上です。

Dfinity のプロトコルは従前のブロックチェーン技術の理解では収まらないところが多々あり、理解に苦しみました。また、 Chain key の暗号プリミティブへの理解も必要となります。理解が大きく外している箇所もあるかもしれません。なんでも構いませんのでご指摘いただければ幸甚です。

疑問点や不明な点がありましたら、@hokosugi までお願いします。なんでも結構です。