古い記事の広告や記事そのものを削除できなかったので、広告除外版を再掲します！昔の記事なのでご了承ください🙇♂️
ーーー
今回は、Cardano研究の集大成であり目玉である”Hydra”入門解説にチャレンジします！
…とは言いましても、今回はかなり”入門”中の”入門”的なところを正確さより”分かりやすさ”重視でお伝えするものですので、その辺りご容赦ください…私も鋭意勉強中です！
まずはHydraの論文はここに格納されており、PDFを開きますとまず最初のページはこんな感じです。（なお、せっかくなのでちょっとコメントつけてます。）
さて、まずはタイトルからいきましょう！
Hydra-Fast Isomorphic State Channels
「Hydra」これはギリシャ神話の頭を複数もつ竜が元で、並列処理のことを指しています。このHydra論文でも「ヘッド」という言葉がちょくちょく出てきます。
「Fast」速い、という意味で、これがまさにHydraのやりたいこと、目的です。理論的には（実際はこのように素直になりませんが）1,000TPS×1,000プールで100万TPSの速度を出せる可能性があります。なお1,000TPSでVISAレベルです。
「Isomorphic」これがHydraの最大の特徴です。これは数学の用語で同型とも訳されますが、チェーン（胴体）とヘッド（頭）で同じシステムが使えるよ、という意味になります。同じシステムが使えるということはシンプルであるためセキュリティも速度も高まります。これはHydra特有の特徴で、他の似たシステムは基本的に「異型」ということになります。
「State Channels 」これは一般的な用語で、胴体（メインのチェーン）に記録せず、複数の頭（ヘッド）に記録を並行して行ってあげることで、より高速化する技術です。
つまりつまり…このタイトルが言わんとしていることはFast
（速さ）を目的として、Isomorphi（同型で速くなる）という最大の特徴を持つ、State Channels（速くする技術）、その名もHydra！ということとなります。
さて、一体それはどんな仕組みなのか…ということで、
Abstract（概要）と目次
を少し読んでみます。
Hydra（同型のマルチパーティState Channel）は、「１層目のスマートコントラクトシステムをそのまま2層目で採用」でき、高速・シンプル・セキュリティレベル変更なし・トランザクションの決済に必要な時間と単位時間あたりに決済可能なトランザクションの数が物理的限界まで高速になります。
みたいな話が書いてあります。つまり速くて安全レベルが下がりません、ということが書かれています。逆にいうと、速いということは、通常は、「安全レベル」を基本的には下げることでした。ただ単純に速度だけが上がるなら、みんなもうやってます、という話ですよね。
それでは本文へ入っていくのですが、少し目次をチラッと眺めておきましょう！
1Introduction はじめに
2Preliminaries 予備考察
3Protocol Overview 概要
4Protocol Setup：セットアップの仕組み
5Mainchain：胴体（メインチェーン）の仕組み
6Simple Head Protocol Without Conflict Resolution：頭（ヘッド）の仕組み
7Simulations：シミュレーション
というのが全体の流れです。1-2で準備体操して3で大まかな説明をして、4-6で詳しく話して、7でどうなるか実験、というような雰囲気です。
またちょっとだけ補足しますと、Hydra簡易版とHydra完全版の２つがあり、説明の都合上基本的にすべてHydra簡易版について書かれていますが、概要部分で完全版との違い、付録で完全版の詳細について書かれています！
ということでまずは準備体操していきましょう。
1 Introductionはじめに
まず、そもそも解決したい問題は、「処理時間、処理量、データ量が追いつかない」という問題です。この問題に対する解決策は大きく２つで、１つのチェーンか、２つ以上か、で分かれます！
■１■１つのチェーンだけで改善する方法→１つの高速道路だけで渋滞を改善しようとするもの…その道路の摩擦度をどうのこうの、信号の設定を改善してどうのこうの…限界あり！
■２■２つ以上のチェーンで改善する方法→（１）サイドチェーン（２）ノンカストディアルチェーン（３）オフチェーンの３つがあります！
（１）サイドチェーンによる方法
質は問わないけどサブ道路をメインの高速道路の横に作ることができ、メインの高速道路とサブ道路の行き来を厳格に安全にする方法です。これはメインの高速道路及びサブ道路への往来については安全ですが、サブ道路自体の安全性は分かりませんので少し安全性は下がります。
（少し厳密な説明：ペギングメカニズムを介しメインチェーンとサイドチェーン間で資産を転送でき、メインチェーンは「ファイアウォールプロパティ」によってサイドチェーンのセキュリティ障害から保護されます。ただし、サイドチェーンには独自のコンセンサスルールがあり、サイドチェーンのセキュリティが崩壊した場合、資金が失われる可能性があります。（例１） Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille. Enabling blockchain innovations with pegged sidechains, 2014. （例２）P. Gazi, A. Kiayias, and D. Zindros. Proof-of-stake sidechains. In 2019 2019 IEEE Symposium on Security and Privacy (SP), pages 677–694, Los Alamitos, CA, USA, may 2019. IEEE Computer Society. （例３） Aggelos Kiayias and Dionysis Zindros. Proof-of-work sidechains. IACR Cryptology ePrint Archive, 2018:1048, 2018. ）
（２）ノンカストディアルチェーンによる方法
メインの高速道路を監視網として、その下に小さな道路をたくさんぶら下げるような方法です。これは攻撃した車が大量に高速道路へ引き返そうとするmass-exit攻撃の懸念があり、安全性としてはまだ課題があります。
（少し厳密な説明：noncustodial chainsは、メインチェーントランザクション処理を信頼できないアグリゲーターに委任し、ステートチャネルのように、セキュリティ障害から保護することができるが、多数のユーザーが同じ非カストディアルチェーンによってサービスを提供される設定では、その破損は「大量退出」問題を引き起こします。一方で、Hydraはじめステートチャネルは、チャネルごとにたくさん人がいなくてよく、ネットワークを介し多数のユーザーに拡張できます。なおoptimistic rollupsは同型プロパティに似た機能だが、メインチェーンを解決に使うために、Hydraの「レイテンシ」の利点はありません。（例１） John Adler. The why’s of optimistic rollup. Medium of-optimistic-rollup-7c6a22cbb61a, November 2019. （例２） Stefan Dziembowski, Grzegorz Fabianski, Sebastian Faust, and Siavash Riahi. Lower bounds for off-chain protocols: Exploring the limits of plasma. Cryptology ePrint Archive, Report 2020/175, 2020. Cryptology ePrint Archive: Report 2020/175 - Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma. （例３） Georgios Konstantopoulos. Plasma cash: Towards more efficient plasma constructions, 2019. （例４） J. Poon and V. Buterin. Plasma: Scalable autonomous smart contracts. http://plasma.io/ plasma.pdf. ）
（３）オフチェーンによる方法→①PAYMENT CHANNELS②STATE CHANNELSの２つがあります！
これもサブ道路をメインの高速道路の横に作ることができ、メインの高速道路とサブ道路の行き来を厳格に安全にする方法です。サイドチェーンとの違いは、メインの高速道路へ引き返そうと思ったらすぐに安全にできる点です。そのため、現状安全性は比較的高いと思われます。これもたくさんの種類がありますが大きく２つの種類があります。
①Payment Channels
ビットコインのライトニングネットワークが代表的ですが、シンプルに、送金関係についてオフチェーンで高速化するものです。ただし、スマコンのような複雑なものには対応しきれませんので…
②State Channels→「異型」と「同型」の２つがあります！
というものが出てきました。これはライトニングネットワークのスマコン対応版のような感じです。ここにも２つ種類があり、
1)異型State Channels
これは胴体と頭で違うプログラムが適用されるものです。違うプログラムを使うので、遅く、複雑で、スマコンを書くにあたっても難しく、スムーズではありません。
（例１）Andrew Miller, Iddo Bentov, Surya Bakshi, Ranjit Kumaresan, and Patrick McCorry. Sprites and state channels: Payment networks that go faster than lightning. In International Confer- ence on Financial Cryptography and Data Security, pages 508–526. Springer, 2019. （例２）Stefan Dziembowski, Lisa Eckey, Sebastian Faust, Julia Hesse, and Kristina Hostáková. Multi- party virtual state channels. In Annual International Conference on the Theory and Applica- tions of Cryptographic Techniques, pages 625–656. Springer, 2019.
2)同型State Channels（Isomorphic…Hydra！）
これは胴体と頭で同じプログラムが適用されるものです。同じプログラムを使うので、速く、シンプルで、スマコンを書くにあたっても簡単で、処理がスムーズです！
というわけで、一言に高速化と言っても色々ありますが、色々あるなかで安全性や高速性やシンプルさの意味でもピカイチなのがHydra！ということで、もう少しHydraについてざっくり列挙されているところを触れてみますと…
︎同型（元の元帳の正確な状態表現を再利用する）のため処理コストが低い。
︎クローズされると、先に登録しておく必要なしで、自然にオフチェーンのコードがオンチェーンに適用されるようになる。
︎同型であるには、任意のチャンクの効率的切り分け、独立処理、効率的マージが必要。Bitcoin-style UTxOはこの並列性に適しており（アカウントスタイルよりシンプルで、依存関係が分かりやすいから。）、ただこれには限界もあったが、拡張UTXOによりこの限界も無くなった。拡張UTXOは最小の労力で検証ができ、並列処理に当たって最適だ。
︎ 対話なしにヘッドで処理を進められる。しかもチェーンとヘッドでは全く同じコードを利用し、適用されるため開発コストも少ない。
︎クローズしたくなったらヘッドメンバーはヘッドをチェーンに戻せる。
︎デコミットは快適かつ高速な２つの理由：デコミットプロセスは、ヘッドの最新の状態が非常に大きい場合に、ヘッドの状態を小さな（しかし並列の）チャンクでデコミットできるように設計・デコミットするのに必要な時間は、ヘッドに参加しているパーティの数またはヘッドの状態のサイズとは無関係
︎ヘッドを閉じずにUTXOを追加、削除できる。
うん、なるほどよくわからん！という場合はとりあえず、「同型」だから「速い・シンプル・簡単」という理解で、とりあえず先へ進みましょう！
2 Preliminaries 予備考察
ここでは議論の前提を整える…という作業と行っています。ちょっと難しいのでさらっとだけいきます。よくわからないと思ったら飛ばしてください！
MultisignaturesとExtended UTxO model & state machinesの２つについてこの章では整理されています。
Multisignaturesは、複数署名機能です。これはState Channelsは送金をしたい参加者が何人か集って行う、というようなイメージで、その人たちの署名を集める、という作業が必要になります。そのための複数署名です！
Extended UTxO model & state machinesは、両方ともキーワードで、Extended UTxO modelというのはビットコインのUTxOモデルをETHのアカウントモデルの良さを踏まえて改良したもの、というような意味合いです。専用の論文をIOHKが出していますが、Hydraがやろうとする処理はビットコインのUTxOモデルがやりやすいけどそれではスマコンがやりづらいのでそれの拡張版を作りました、といようなものになります。state machinesはそのなの通り、State Channelsを動かす仕組みです。
（１）Multisignatures
MS-AVKを介して検証キーVのタプルからavkが生成される場合、すべての誠実な関係者が保持しない限り、集合署名̃σが検証MS-Verify（avk、m、̃σ）をパスできない。Vのキーに署名m完全な処理は、付録Aに記載。
（２）拡張UTxOモデルおよびステートマシン
・高速同型状態チャネルの基礎は、BitcoinのUTxO元帳モデル
①拡張UTxO：拡張UTxOモデル（EUTxO）はシンプルさとスマートコントラクトの両立。txで構成され、txは５つ。
tx = (I,O,valForge, r,K)
入力のセットI：出力参照out-ref（トランザクションIDとトランザクション内の出力を識別するインデックスで構成される）と引き換え元ρ（供給に使用される）のペア
出力のリストO：各出力o∈Oは、値val、検証スクリプトν（これはν（val、δ、ρ、txpend）で実行（txpend＝tx＋i∈I（oだけでなく）によって参照されるすべての出力））、およびデータ値δのトリプル（val、ν、δ）
偽造/焼き付けされたトークンの値valForge
スロット範囲r =（ rmin、rmax）：txを確認できるスロット
公開鍵Kのセット：txが署名される公開鍵
・最終的に、txは、すべてのバリデーターがtrueを返す場合にのみ有効です。
という感じです、では詳しいところに突っ込んでいきます！
3 Protocol Overview：概要
HydraはメインチェーンのUTXOをロックし、オフチェーンで処理できるようにし、かつ、UTXOをロックがヘッド内の最新のUTXOに置き換えられ、いつでもオフチェーン処理を終了できるよ、という仕組みですが、もう少し時系列を追って説明しますと…
STEP1：イニシャル１：ヘッド作りたい人A（イニシエーター）が、メンバーへ（A、B、C 、D）ヘッドのID「123」を伝えてヘッドに参加するようにお願いする。その後、A、B、C 、Dが互いにペア認証のチャネルを確立して（ダメだったら中止）、A、B、C 、Dが公開鍵をチャネルで交換する。（A、B、C 、Dだけができる処理に使う）(ただし実際はこのペアワイズメカニズムはすでに公開鍵インフラによってすでに設置されていると想定できます。)
STEP2：イニシャル２：Aは、「イニシャルトランザクション」をメインチェーンに送信してヘッドを確立し、セットアップフェーズ中にA、B、C 、Dが配布した公開キーに各トークンを割り当ててメンバー識別する。
STEP3：オープン：パーティがヘッドにコミットするUTxOを（メインチェーン上で）ロックする。コミットトランザクションが収集され、「オープン状態」に移行し、ヘッドが行われる。コミットに一部の人が失敗したら、最初から最後に直接進むことでヘッドを中止できる。
STEP4：ヘッドでトランザクション処理：まずオープンされた直後、UTxOの初期セット（オンチェーンでロックされている量と同じ）がある状態で、その後、発行された各トランザクションのマルチ署名を個別に収集配布し完全並行して個々のトランザクションを確認し、確認されたらすぐヘッドに組み込まれて使用可能になる。（クローズすればメインチェーンで使用できる。非同期なのでみんな違うデータを持っている。）
STEP5：ヘッドでスナップショット実施：スナップショットリーダーは、新しいスナップショットとしてマルチ署名するよう要求し署名されたら確認済みとなる。これをしっかり確認したらトランザクションを削除できる。
STEP6：クローズ・ファイナル：A、B、C、Dは誰でもいつでも今のヘッドの状態（確認済スナップショット＋スナップショットにない確認済取引）をメインチェーンに送り、ヘッドを閉じることができる。調整期間で確認済のものも他のメンバーが追加していくことができる。その後ファイナルへ移行することがある。（攻撃者は、新しい取引確認を認めながら、スナップショット停止させる攻撃をするかも。保存トランザクションが増えすぎるのを避けるため、この制限に達すると新しい取引が確認されなくなりヘッドがクローズします。）
※上記は簡略版Hydraであり、完全版との違いは、以下が完全版にはあること
•コミットとデコミットの増分処理（UTxOをクローズせずにヘッドに追加またはヘッドから削除）
•オンチェーンの競合を必要としない楽観的なワンステップヘッドクロージャー、
•nに依存しないO（∆）競合期間を伴う悲観的な2段階ヘッドクロージャー。ここで∆はトランザクションのオンチェーン決済時間です。
•最終的なUTxOセットの分割されたオンチェーンデコミット（単一のトランザクションに収まるには大きすぎる場合）。
という感じです！なお、4 Protocol Setup 5 Maincha 6 Simple Head Protocol Without Conflict Resolution はこの数学的詳細の議論、7 Simulationsはその実験という感じなので、省略です。
したがって、これで扱う内容は以上なので、まず「安心」してください！「安心」していただいた上で、3 PROTOCOL OVERVIEWのSTEPの説明がこれではあまりにも不親切なので、もうちょっと噛み砕きます。
STEP1：Hydraさんの頭を何人かの間で作って、送金を速くし、また同時に手数料ももらいたいYUTAは、頭の番号（POOLとします）を叫んで、頭を一緒に作りたい人（BさんCさんDさん）を集めて、みんなで自分の公開鍵をシェアします。
STEP2：YUTAは自分とBさんCさんDさんの公開鍵を使ってHydraの首POOLを作る証明書をCardanoチェーンに送りつつ、POOLコインをみんなに配ります。POOLコインを持っている人が、POOLというHydraの頭を扱えます。
STEP3：POOLコインを持つみんながCardanoチェーンのADAを各々ロックしたら、POOLのHydraの頭が出来上がります。（しない人がいたらできません）
STEP4：HydraのPOOL頭が出来上がったらそこで参加したPOOLコインを持つメンバーはADAを送金したりできます。その取引は、POOLコインを持つみんなで取引を承認し、承認されたらPOOL頭に反映されます。
STEP5：また定期的に、みんなが持つPOOL頭上でのADAの配分を確認します。それをみんなで確認しあったら、それまでの取引を削除することができます。
STEP6：YUTA、Bさん、Cさん、Dさんは誰でもいつでも今のPOOLヘッドの状態（STEP5で確認した配分、その後出てきた確認済取引）をCardanoチェーンに送り、POOLヘッドを閉じることができます。その他の人も、閉じるときは、調整期間で追加していくことができます。
という感じです…ちょっとまだ分かりづらいかもしれませんが、要するには、POOLというヘッドをCardanoチェーンの横に作ってそっちで取引を分担して承認してあげるんだ、ということです！
以上です！今回ちょっと難しい記事だったかもしれませんが、またもうちょっと分かりやすく楽しい記事も書くつもりなので、楽しみにしていてください！
また、CardanoADA非公式オープンチャットコミュニティも、全体チャット、上級チャット、運営チャットにわかれ、より分散化が進みました、700名以上総計で参加されいます！テレグラムに近い、匿名で（LINE本アカウントを知られることなく）参加できるLINEのチャットです。とはいえ、まだできたでホヤホヤのコミュニティですので、いざこざもたくさん起きていますし今後も起きます。その度に都度ルール等を改善してまずは日本最強のクリプトコミュニティにして行きたいと思います😄
それではまた！