• HUNNY

Mithrilとは - より強く、より軽いブロックチェーンを繋ぐ【翻訳文字起こし全文】


Mithrilはステークベースの閾値マルチ署名スキームを提示する研究論文です


以下の文章は、IOHKのYouTube動画「Mithrilとは - より強く、より軽いブロックチェーンを繋ぐ」(2021/10/14)を翻訳文字起こししたものです。



HUNNYプールにステーキングしましょう!


HUNNY:ff5eb7a210b3b322271da7f17753a06d107bda666f34be10017ad723

PoolToolで詳細を見る:こちら


要点


・Mithrilが解決する最初の問題は 複数の署名を効率的に集約することです


Mithrilは 特定のメッセージを検証するために所定の数の参加者が必要とされる標準的な閾値設定とは異なる ステークベースの閾値設定で動作します 


ステークベースの閾値設定において 正しい署名を生成するためには メッセージの検証に 総ステークの何分の一かを要求します 


プルーフ・オブ・ステークメカニズムにすでに存在する前提条件以外は 一切追加することなく この合意形成の証明を実現しています 


・この署名方式を採用することで さまざまなステークホルダーにチェーン履歴の転送のチェックポイントを検証してもらうことができます 


新しいクライアントや長期間オフラインになっていたクライアントが 取引履歴全体を調べて最終状態を検証するのではなく 最終ステップが有効であることを納得してもらうために これらのチェックポイントを経由するだけですむのです 


・Mithrilはステークベースの閾値マルチ署名スキームを提示する研究論文です


ステークを活用し 少人数のステークホルダーにそのメッセージに署名してもらうのです 


それは各ユーザーに署名を試みさせて 個々のユーザーが自分の署名が抽選の当選対象かどうかを確認できるようになり その署名を出力することができます 


そして 異なるくじのK個の署名が揃ったら それらを集約して1つのMithrilの署名とすることができるのです 


・計算などの時間や必要なリソースが大幅に改善され 高速な同期が可能となり 高いセキュリティ保証が得られるため より制約の多いデバイスへの適用が可能となりました


・ゼロ知識証明に基づく自己主権型IDプロトコルを構築しており組織が 顧客の個人情報を取得・保存することなく 顧客のIDを洗練することを可能にしています 


例えば ある年齢以上であることを証明するために 書類を見せずに生年月日を共有したり 特定のアプリケーションのために対象国に居住していることを証明したりすることができます



本文


Inigo Querejeta Azurmendi:皆さんこんにちは IOGの暗号エンジニア Inigo Querejeta Azurmendiです 今日はセッションと参加するスピーカーの紹介をしたいと思います 


この講演では 研究とエンジニアリングの両方を行っているMithrilについて紹介します 


Mithrilはステークベースの閾値マルチ署名スキームを提示する研究論文ですが IOG内でプロトコルを実装し Cardanoブロックチェーンの実世界の問題を解決するための取り組みを指してMithrilと呼んでいるのです 


そこで私は Mithrilが解決する問題の概要を説明し その後 他の講演者にその詳細な説明を譲りたいと思います 


Mithrilが解決する最初の問題は 複数の署名を効率的に集約することです Mithrilは 署名者が有効な署名を作成するために他の署名者とやりとりする必要がない公開鍵の設定で動作します そして 有効な署名をすべて受け取りそれを一つの有効な署名に集約する集約者の役割を担います 


この集約は署名の数に対して対数的であり Mithrilの集約はサブリニアの性能となります 


このため Mithrilは 特定のメッセージを検証するために所定の数の参加者が必要とされる標準的な閾値設定とは異なる ステークベースの閾値設定で動作します 


ステークベースの閾値設定において 正しい署名を生成するためには メッセージの検証に 総ステークの何分の一かを要求します 


Mithrilには 追加の信頼性の前提はありません 


そのため プルーフ・オブ・ステークメカニズムにすでに存在する前提条件以外は 一切追加することなく この合意形成の証明を実現しています 


最後に カルダノに非常に関連する問題です 


より一般的には プルーフ・オブ・ステークに関連する問題です 


ブロックチェーンには 高速なチェーンブートストラップという問題があります 


この署名方式を採用することで システムのさまざまなステークホルダーにチェーン履歴の転送の所定のチェックポイントを検証してもらうことができます 新しいクライアントや長期間オフラインになっていたクライアントが 取引履歴全体を調べて最終状態を検証するのではなく 最終ステップが有効であることを納得してもらうために これらのチェックポイントを経由するだけですむのです 


まずはPyrrosから プロトコルの設計についてもう少し詳しく話してもらうことにします 


次に RomanがMithrilの使用例をいくつか紹介します 


最後に IOGの戦略的パートナーであるGaloisとIdyllic Visonに Mithrilの開発方法について話してもらいます 


ありがとうございます それではトークを楽しんでください 


Pyrros Chaidosというわけで 私はPyrrosです 


アテネ大学ブロックチェーン技術研究所の研究員で Mithrilの研究論文の共著者になります 


さて Mithrilのデザインですが 3つのコアとなるアイデアがあります 


1つ目は 効率を得るためにステークを活用することです 


2つ目は 透明なセットアップと呼ばれるものです 


つまり 必要なセットアップが 信頼を高める必要もなければ 非常に手の込んだセレモニーが行われることもないのです 


Mithrilのデザインにおけるもう一つのコアコンセプトは モジュラーコンポーネントというものです 


最初の研究論文でも 2つの異なる証明システムを用意し どちらも透明で サイズと効率の間で異なるトレードオフができるようにしました 


ステークを活用する方法について少し詳しく説明しますと 基本的なシナリオとして ステークホルダー全員を想定した署名を作成したい場合を考えてみます 


最も単純な方法は 各ステークホルダーに適切なメッセージに署名するよう依頼することです 


今 それは可能であることが判明していますが 非常に非効率的でもあります 


これまでにも より効率的に同様の目的を達成することを目的としたマルチシグネチャやアドホック対マルチシグネチャと呼ばれる構成がありましたが 悪意のある部分が行われないこと ユーザー数に応じて拡張することに関しては まだ未解決の課題が残っています 


一方 極端な話 ステークホルダー間で選挙を行い 一人の人間をリーダーとして選出し 特定のメッセージを支持するかしないかを問うだけでいいということも考えられます 


それならうまくいくかもしれません 


しかし ユーザーが選ぶのは 正直なプレーヤーではない可能性が高いのです 


そこで 私たちがたどり着いた解決策は ステークを活用し 少人数の株主にそのメッセージに署名してもらうことです 


つまり より現実的な解決策は ある特定の数の株主にだけ この特定のメッセージに署名するよう依頼することです 


それを次のような方法で行います 


M個の個別抽選を行います 


そして これらのくじのK人の当選者によって署名された場合 そのメッセージは有効であるとみなします 


さて その方法ですが 各ユーザーに署名を試みさせて その署名を抽選関数と思われるものに渡します 


これで 個々のユーザーが自分の署名が抽選の当選対象かどうかを確認できるようになり 待たずにその署名を出力することができます 


これは Cardanoのような標準的なブロックチェーンで起こっていることとは異なります ローカルでは 参加するために自分のスロットがアクティブになる時間を待つ必要があります 


そして 異なるくじのK個の署名が揃ったら それらを集約して1つのMithrilの署名とすることができるのです 


さて 実際のところ Mithrilの設計は セットアップ 初期化 運用の3つのフェーズを特徴としています 


また Mithrilは セットアップを繰り返すことなく 簡単に再初期化できるように構築されています 


これは 初期化がステーク分布によって異なるため いくつかのアプリケーションで非常に重要になるでしょう 


さて Mithrilをセットアップするために 暗号が行われるグループ設定を確定する必要があります 


インターチェンジMを選択します これは簡単に言うと これから行う選挙の数です 


そしてクォーラムサイズK これは署名が受理されるために必要な当選者の数です 


また 証明システムのための参照文字列を提供する必要があります 


しかし すでに述べたように これは透明性のある方法で行うことができ 高い信頼性の前提を必要としません 


さて 初期化ですが まず ステーク分布の更新が必要です 


これは 各ステークホルダーがどれだけのステークを保有しているかを知っているようなもので 各ステークホルダーは鍵を登録する責任があり これはオンチェーンでもオフチェーンでも行うことができます 


しかし これはほとんどのブロックチェーンで共通する機能であるため 比較的安価に収益を上げることができるのです 


最後に ステーク分布とテストキーを圧縮します 


私たちの設計では これはマークルツリーによって行われます 


これにより Mithrilの署名は そのマークルツリーを表す単一のハッシュに対して検証されるようになります 


そのため 署名を検証するために必要な状態のサイズを低く抑えることができます 


運用フェーズでは ユーザーはアグリゲートを作成し Mithril署名を検証することができます 


さて 先にも述べたように 署名の作成は ユーザーが署名を試み 作成した署名が実際に並行して行われている宝くじの当選者であるかどうかを確認することで成り立っています 


それが本当であれば ユーザーは自分の署名をブロードキャストすることになります 


また 異なる選挙で特定のメッセージを支持する署名が十分にあれば それらを1つのメソッド署名に集約することができます 


そして その署名はブロードキャストされます 


そしてその署名は 証明システムの参照文字列と ステーク分布の非常に短いマークルツリーハッシュを使うだけで 誰でも検証することができるのです 


では最後に 一人のユーザがMithrilで署名を作成する手順を説明しましょう 


そこでまず ユーザーは自分の保有するステーク量を確認し それをスコア関数に通して自分のスコア閾値Tを求め 署名候補Sを作成しようとするのです 


さて 各インデックスについて 自分たちが作成した署名候補と 今署名したメッセージ そして照合しているくじのインデックス番号の組み合わせが 閾値Tよりも小さいスコア値を生成するかどうかを評価することになります 


もしそれが真であれば 彼らが生成した候補は 実際にその特定のインデックス番号の抽選に当選したことになります 


そうでない場合は 次のものを試すことになります 


さて 可能な限りのインデックスを試した結果 署名Sが実際に有効であるインデックスが1つ以上ある可能性があります 


そのインデックスごとに 自分の署名候補と そのインデックス番号が有効であることからなるMithrilでいうところの個人署名を出力し そのスコアが確かに自分が登録したステーク分布と一致することを検証する証明を示したのです 


そして 先ほども言ったように 次に起こることは これらの個々の証明署名がブロードキャストされます 


そして 同じメッセージで異なるインデックス番号のものがK個作られると それらを1つのMithril署名に集約することができます 


さて それでは次のセッションに移ります Romanがアプリケーションについてお話します 


Roman Oliynykov:Pyrrosさん ありがとうございます 


現在 分析・開発中のシステムの全体計画アーキテクチャを考慮しながら Mithrilのユースケースを見ていきたいと思います 


このスライドでは ステークプール運営者が実行するソフトウェア Cardanoピアツーピアネットワークへの接続 Mithrilノードピアツーピアネットワーク ステークプール運営者が実行するノードに接続されたMithrilクライアントをハイレベルで見ることができます 


SPOプラットフォームのMithrilノードは 検証済みのブロックチェーンとローカルストレージにアクセスし プロトコルを実行してMithril証明書を生成し ストレージのMithrilに保管されます 


その際 専用のピアツーピアMithrilノードネットワークが使用されます 


必要な証明書がすでに生成されると ミスリルのストレージに保管され ネットワーク全体の間で検証可能な同期が行われます 


したがって ステークプールの運営者は カルダノ・ブロックチェーン全体と そのための有効なMithril証明書のリストの両方を共有する準備が整っているのです 


次に Mithril クライアントがネットワークに接続すると Mithril 証明書のリストを要求し Cardano チェーンのうち最も長いチェーンのヘッダーのみを要求します 


そのために複数のSPOを独立して使用することもでき その後Mithrilクライアントは 証明書が取得したCardanoブロックチェーンを完全に確認することを検証します 


全体の手順は軽量なものであり 重要なネットワークストレージや計算リソースの関与を必要としません 


ノード同期のCardanoとMithrilの手続きは 相互に排他的ではないことも知っておきましょう 


これらは並行して実行することができ 同期用のMithrilは後でフルノードの同期によって確認されます 


ウロボロス・クラシックのベースコンセンサスに対して ミスリルアプローチを用いると どの程度の作業を安全に省略できるかがスライドで確認できます 


たとえば すでに少なくともスロットリーダーを持っている場合 我々はコミットメントステージ内のトランザクションを解析し 次のウロボロスエポックのためのそれらのランダムネスからコミットメントを抽出する必要があります 


その後 通常の取引でブロックチェーンが成長する間 ステーク分布のスナップショットを維持する必要があります