スター型ヘッドネットワーク
🛠️ この資料は、現在作成中のものです。
このドキュメントでは、いわゆるスター型のHydraネットワークの動作について詳しく説明します。
概要
スター型のHydraネットワーク、より正確にはスター型のヘッドネットワークは次のもので構成されます。
- ダウンタイムの少ない「Head-as-a-service」を提供する中央サーバーノード。おそらくこのサービスをホストするのに十分なリソースを持つ企業または組織が運営しています。
- クライアントノード。DAppインスタンス、またはモバイル/パーソナルウォレットで、常にオンラインであるとは限らず、行ったり来たりする可能性があります。
クライアントノードは、L2ソリューションを使って全てのHydraの安全性を保証しながら、常にオンラインの「フル」Hydraノードを操作するという運用上の負担を負わずに（例えば、ノードの組み込み版や軽量版を使って）効率的に、低コストで相互作用できるようにしたいと思っています。その数は100台、1000台と多いかもしれませんが、常にすべてが同時に稼動しているわけではありません。
クライアントノードはサーバーとペアヘッド(例えば チャネル )を確立します。このセットアップは通常のマルチパーティヘッドよりも簡単です。 サーバーは既知のIDを持ち、 このドキュメントの範囲外である特定のサービスを使用してヘッドをセットアップするときに、クライアントは必要なパラメータ(キー、IP)を 常にサーバーに提供することができます。
クライアントノードが「その」ヘッドに投稿するトランザクションは、サーバーによって、サーバーが維持する他のヘッドに反映される必要があります。
質問:
- ペアワイズヘッドの「持続時間」が変化することは想定されているのでしょうか。例えば、クライアントが来てヘッドを開き、いくつかのことを行いそれを閉じた場合、同じサーバーによって維持されている他のヘッドは開いたままですか？
- サーバーは、ペアワイズヘッドごとにHydraヘッドの基本的な安全性を維持することをどのように保証しますか？
- この図が示唆するのは、ハッシュタイムロックコントラクト (HTLC) を使用することで、サーバーがトランザクションをその宛先に適切にルーティングしなかった場合に、クライアントが常にUTxOを取り戻せるようにすることです。
- どのようなトランザクションをサポートする必要がありますか？ HTLCは、支払いスタイルのトランザクションには適していますが、たとえばDAppには適していません。そうでない場合は、それらを適応させる必要があります。
- サーバーが1つのヘッド内のトランザクションを適切なヘッドに「ルーティング」できるという暗黙の前提があるようです。これは、サーバーがヘッドに投稿されたUTxOのアドレスを「理解」していることを意味します。
オンチェーントランザクション
以下のトランザクション図は、アリス、ボブの間の2つのペアワイズヘッドのライフサイクルを表しています。
備考:
- これは、一方のヘッドで起こったトランザクションがもう一方のヘッドに反映され、その結果、最終的なUTxO
cが（強く）一貫していると仮定しています。- つまり、両方のヘッドが同じ $U_0$ セットから始まる必要がありますが、これはどのように実行できるかわかりません（図では赤で囲んでいます）。
- 最終的なUTxOセットの整合性が取れていれば、どのようなパーティでもFanoutが可能です。つまり、1つの
ν_headがぶら下がったまま、既にあるUTxO（図ではグレーアウトしたトランザクション）を再現するように使用不可能になる可能性があるのです。
- ヘッドのライフサイクルは結びついています。一方が閉じられると、もう一方も閉じられます。サーバーはそれが事実であることを確認します。
オフチェーントランザクション
次の図は、トランザクションの伝播を確実にするために、様々な「ノード」間で交換されるメッセージのシーケンスを表しています。
備考:
- サーバは2つのノード
M(A)とM(B)で表現されます。 Aliceが自分のノードで発行したnewTxは、サーバによってBobのノードにもnewTxとして伝搬されます。- この図は、サーバーが
AliceとBobのどちらかまたは両方に保証を提供するために投稿する必要のある追加のトランザクション（たとえば、ヘッド内のHTLCトランザクション）を表すものではありません。 - スナップショットの一貫性を確保するため、サーバーは常にリーダーでありスナップショットの発信をトリガーするものと仮定します。