top of page
  • 執筆者の写真ICP Japan

ICP のビットコイン統合が秘密鍵を保護する方法

※この記事は How ICP’s Bitcoin Integration Secures Private Keys の内容を引用しています

ICP のネイティブ Bitcoin 統合により、クロスチェーン ブリッジの必要性がなくなり、Bitcoin のスマート コントラクト機能が解放されます。


ICP へのビットコインの直接統合により、高度なスマート コントラクトであるキャニスターがプロトコル レベルでビットコイン ネットワークとやり取りできるようになります。これにより、キャニスターは、セキュリティ上の問題が山積している仲介者やサードパーティのブロックチェーン ブリッジを使用せずに、ビットコイン メインネットで BTC を直接受信、保持、送信できます。グローバル Web3 セキュリティ レポートによると、2022 年には、これらのブリッジに関連するわずか 12 件のインシデントによって、約 18 億 9,000 万ドルが失われたとされています。


Bitcoin 統合により、ICP 上のキャニスターはBitcoin 台帳を安全に読み書きできるようになります。


(1) キャニスターは、インターネット コンピュータ プロトコルで実行されるビットコイン ライト ノードを通じて、ビットコイン ブロックチェーンの状態を読み取ることができます。このため、ICP ネットワーク内のノードは、ビットコイン ネットワークから直接ブロックを取得し、含まれるトランザクションを抽出して処理します。これにより、完全なビットコイン ネットワークの現在の未使用トランザクション出力 (UTXO) セットが最新の状態に保たれます。この UTXO 情報は API 経由でキャニスターに提供されるため、キャニスターはビットコイン アドレスの残高や UTXO などの情報にアクセスできます。つまり、キャニスターは、管理するアドレスを含むすべてのビットコイン アドレスの残高と UTXO を照会できます。これにより、ブロックチェーンの状態を確認することで、ビットコイン アドレスの使用可能残高 (および UTXO) を判断できます。


(2)ビットコイン ネットワークに書き込むために、キャニスターはビットコイン トランザクションに安全に署名し、それをビットコイン ネットワークに送信します。安全な署名は、チェーン キー ECDSA と呼ばれる新しいしきい値 ECDSA プロトコルを介して行われます。署名されたトランザクションは、プロトコル レベルの統合を通じて送信されます。これにより、ICP レプリカは、接続された多数のビットコイン ノードにトランザクションを送信します。


ICP の秘密鍵はどこに保存されますか?

---

キャニスターがトランザクションを書き込む (署名して送信する) こともできるようになったので、秘密鍵も保存することになるのでしょうか?


秘密鍵をキャニスターの状態で保持すると、ICP ネットワーク内の悪意のあるノードに公開され、ユーザーのデジタル資産へのアクセスが許可される可能性があります。これを防ぐために、ICP はしきい値暗号化を使用して、秘密鍵が単一のノードまたはキャニスターに完全に保存されないようにします。しきい値暗号化では、秘密 (秘密鍵など) を秘密シェアまたはシェアと呼ばれる複数の部分に分割できます。秘密を再構築したり、秘密を使用してメッセージに署名したりするには、これらのシェアの一定数 (少なくともしきい値) が必要です。


したがって、秘密鍵全体を 1 か所に保存するのではなく、秘密鍵を複数の部分に分割し、高レプリケーション サブネット (通常のアプリ サブネットよりもノード数が多いサブネット) 内のすべてのノードが保持します。さらに、これらの秘密鍵はノード間で定期的に再共有され、共有の侵害の可能性から保護されます。再共有とは、暗号化プロトコルを使用して現在の共有から新しい共有を作成することを意味します。再共有されると、以前に有効だった共有は無効になり、悪意のある人物が入手しても役に立たなくなります。


Bitcoin ネットワークに書き込む際、Bitcoin トランザクションはしきい値署名を使用して署名されます。つまり、サブネット内の十分な数のノードが署名に同意すると、各ノードはそれぞれのキー シェアを使用してトランザクションに共同で署名します。署名を計算するには、少なくともしきい値と同じ数のキー シェアが必要です。


これにより、キーは、いかなるエンティティ全体も、しきい値よりも少ない数のノードを制御する攻撃者も利用できなくなります。ICP の場合、キャニスター トランザクション要求時に、ノードは元の秘密キーを再作成するのではなく、シェアを使用して Bitcoin トランザクションに共同で署名します。この署名プロトコルでは、ノードの 3 分の 2 以上が誠実であり、3 分の 1 未満が侵害されていると想定されています。


ckBTCとビットコイン統合のためのICPの非カストディアルアプローチ

---

参加者間で分散されたキー シェアを使用して ECDSA 署名を共同で計算するように設計されたプロトコルのほとんどは、堅牢性または活性がゼロ、同期ネットワーク、またはその両方を前提としています。堅牢性がない場合、1 つのノードがクラッシュしたり参加しなかったりすると、プロトコルはデジタル署名を生成する能力を失う可能性があります。したがって、同期ネットワークを想定すると、単純なメッセージ遅延によって署名プロトコルが失敗し、署名が生成されなくなる可能性があるため、プロトコルは可用性に対する攻撃を受けやすくなります。


ICP はフォールト トレラントな設計になっており、非同期通信ネットワークでプロトコルが確実に機能し、メッセージの遅延を許容して障害が発生しないようにします。ノードの 3 分の 1 未満が危険にさらされたり、障害が発生したり、クラッシュしたりしている限り、システム全体が効果的に機能し続けます。つまり、スループットが低下しても動作し続けます。サブネット内のノードに障害が発生すると、ICP は障害が発生したノードの代わりに予備ノードを選択します。


参考文献

Comments


bottom of page