HiÐΞClassic

[Dfinity] chain key技術の簡単な解説 part1

hoko𝕊ugi
2 years ago
概略ブロックの署名と検証(典型例)永続性の説明拡張性の説明まとめおまけ

DfinityのInternet Computer(以下、IC) protocolに使われる chain key技術 は名前は知っていても具体的にどういう技術なのか、まだまだ理解されてはおりません。Dfinity Foundationが出しているブログや動画はありますが、早々に退散する人が多いのではないでしょうか。私もその一人で何を言っているのか全く分からず、未だ全く理解できておりません。しかし、浅〜〜くではあるものの爪痕くらいは残せた(ような気がする)ので少し纏めてみます。 文章にしても自分ですら読み返して理解出来る自信がないので簡単な図にして、図解を中心にして説明していきます。

概略

DfinityのConsensus SystemについてのドキュメントではDfinityのコンセンサス・アルゴリズムについて、大まかに言って以下の3点に纏められるようです。

  1. (サブネットの)永続性
  2. (サブネットの)拡張性
  3. ライブネス(すべてのtxを含む)の瞬間的なファイナリティ

このブログでは1、 2について主に説明します。3は次回にでも解説したいと思いますが、私にとって相当に難解で時間かかりそうです。

(サブネットの)永続性とは、ブロックチェーンが永続するためにどう担保を取るかという話。BTCで言えば、マイニングして儲けることが出来るので新規参入もあり、どんどんブロックが伸びていける経済合理性がその担保になるわけです。

(サブネットの)拡張性とは、これはICのユニークで他のブロックチェーンと違う特徴で、データセンターがあるという理由ではなく、コンセンサスを取る上で理由付けをすることになります。

では、見ていきましょう。 その前に、ICでどのようにブロックの署名と検証がされて伸びていくかを典型例を見ていくます!

ブロックの署名と検証(典型例)

下図は一連のブロックチェーンフローを一部切り取っていますので端が切れて見にくくなっていますがご了承ください。
まずはブロック作成後のフローを見ていきます(ブロック生成時の詳細は次回に回します)。

典型例

  1. (前提)秘密分散法(シャミアの秘密分散法:SSSS)(注1)で秘密鍵は分散されています。
  2. ノード(以下、replica)(注2)に「秘密鍵share」を分散して、2/3以上のreplicaが同意するとブロックにあるcanisterのstate遷移に 署名 します。これをBLS閾値署名と言います。このとき、ブロックはそれぞれのreplicaが状態を保持していて、どのreplicaの状態をブロックにするか、のアルゴリズムを経なくてはなりません(これも次回です)。
  3. 署名されたブロックは署名に参加したreplica以外のreplicaによって検証されてファイナリティを得ます。この時replica以外のユーザー(よく分かっていない)でも検証することが出来ます。
注1

秘密分散法では1つのマスター秘密鍵を分解して複数者へ提供し、その総所持者の一定割合が集まれば署名できる仕組みのことです。そしてこのマスター秘密鍵はBLS署名から作成されます。詳しくはDfinityコンセンサスにおけるBLS署名の応用事例を考えるBLS署名と秘密分散を組み合わせるを御覧ください。後者の筆者はこのDfinityのBLS閾値署名の考案者、光成 滋生@herumiさんです。

注2

replicaはICプロトコルのインスタンスでソフトウェア、
Nodeはハードウェアであるといった、微妙な使い分けがなされているようです。

永続性の説明

BLS閾値署名では上図からもわかるように、replicaが悪意のある攻撃者であったり、何らかの理由で落ちたりした場合、追加でreplicaの補充がない限り、総数が減りセキュアな状態ではなくなります。最悪、閾値を越えない状態にも陥ります。そこでreplicaを追加しますが、このとき、「注1」のように新たにマスター秘密鍵生成してそれに対応する「公開鍵」をサブネットのユーザーに配布するのでは「継続性」から問題になります。すべてのユーザーに配布出来ても過去の公開鍵から切り替えるのはユーザーに委ねられるからです。
そこで公開鍵を変更せずにマスター秘密鍵を変更するNiDKGという暗号技術を独自に開発したようです(後述)。
これによって、公開鍵を変更させることなく、マスター秘密鍵を変更・分散・再共有させることが出来るようになりました。

永続性

リストにして纏めます。
サブネット内のreplicaが何らかの原因で追加のreplicaが必要になった場合。

  1. NiDKGで秘密鍵を再分割・再共有、この時追加のreplicaに秘密鍵shareを渡す。
  2. NiDKGで 1. を実行しても「公開鍵」は変化しない。
  3. 署名の検証する際には「公開鍵」は変化していないのでユーザーは何もせずに手持ちの「公開鍵」で検証できる。

【注】
秘密鍵の再共有はNiDKG直接の技術ではなくて「re-sharing」と呼ばれいているようです。

拡張性の説明

「永続性の説明」でも言及したNiDKGですが、サブネットを新規生成するには必ず必要な技術になります。ここでブログmediumから引用します。

The Internet Computer can use the NIDKG protocol to start a new subnet and give the initial nodes a threshold signing key, without the initial nodes having to be involved in the setup process.

ここにもあるように初期ノードはサブネット生成時に関わることなく(ということは非対話的に)マスター鍵から秘密鍵分散、秘密鍵shareをノード(replica)に渡せます。

NiDKGNon-Interactive Distributed Key Generate)とはマスター鍵を1つの機関から生成するDKGを進化させて複数機関(dealer)から非対話的にマスター秘密鍵を生成する。これにより、秘密分散法の弱点である「一つの機関を信用せず」に秘密分散&BLS閾値署名を実行することが出来ます。

拡張性

NiDKGの概要は上記のmediumかyou tubeを御覧ください。 このyou tubeで説明されてますが、複数のdealerの暗号鍵を重複する値を除外して「compression」していてdealerが単独で追跡してもわからないような構造になっています。(下図参考) NiDKG

まとめ

  1. (サブネットの)永続性
  2. (サブネットの)拡張性

について説明してきました。
秘密分散法とBLS署名を組み合わせるBLS閾値署名と公開鍵を一定にしつつ秘密鍵の再共有する技術(本文中ではNiDKGとしましたが範疇内か定かではないためここではre-sharingとします)での「永続性」と新規サブネット構築を独自のDKGであるNiDKGでトラストレスでマスター秘密鍵を生成して秘密分散法の弱点をカバーしてセキュアな署名を実現する「拡張性」を担保していることを少なくとも確認できたと思います。

これらのコンセンサス・アルゴリズムに使われるchain key技術ですが、纏めると、

  • NiDKG
  • 秘密鍵のre-sharing
  • BLS閾値署名

から成り立っているように思えます。まだ確証はありませんけどw また「chain key」というネーミングも気になります。ブロックを積み上げていかないICの独自の暗号使ったやり方に「block chain」を意識したネーミング付けしたようにも感じられます。

最後に上図をまとめてブロック進行図全体を貼っておきます。

全体

おまけ

ICプロトコルでは、概略で上げた残りの1つ、ライブネスをどう担保するかを見ていく必要があります。これは次回に説明したいと思いますが、今わかっていることを列挙しておきます。

  1. ブロック生成者はランダムビーコンでアットランダムに優先順位が決定される。
  2. ブロックは 1.の優先順位の高いブロックが優先される。
  3. ブロック生成者が追加された場合は「catch up package」で同期される。
  4. replicaが2/3以上署名したらファイナリティ?
  5. replicaはすべてのブロックを保存する必要はない。(ファイナリティが重要になるがどうなっているんだろうか?)

コメント
いいね
投げ銭
最新順
人気順
hoko𝕊ugi
2 years ago
コメント
いいね
投げ銭
最新順
人気順
トピック
アプリ

Astar Network

DFINITY / ICP

NFT

DAO

DeFi

L2

メタバース

BCG

仮想通貨 / クリプト

ブロックチェーン別

プロジェクト

目次
Tweet
ログイン