ステートチャネル

最終編集者: @HiroyukiNaito(opens in a new tab), 2024年1月18日

ステートチャネルは、ユーザーに対して、イーサリアムメインネットとのやりとりを最小限に抑えつつ、トランザクションをオフチェーンで安全に実行できる方法を提供します。チャネル上のピア（同僚）は、当該チャネルをオープン／クローズするための2つのオンチェーンのトランザクションを送信するだけで、任意の数のトランザクションをオフチェーンで実行することができます。これにより、トランザクションのスループットが大きく改善され、ユーザーの手数料が軽減できます。

前提知識

イーサリアムスケーリングとレイヤー2のページを読んで理解しておくことをお勧めします。

チャネルとは何か？

イーサリアムをはじめとするパブリックブロックチェーンでは、分散型のアーキテクチャによりオンチェーンのトランザクションをすべてのノードが実行しなければならないため、スケーラビリティを実現が大きな課題になります。各ノードは、一般的なハードウェアを用いて各ブロックに含まれるトランザクションを処理しなければならないため、ネットワークの分散性を維持する上で、トランザクションのスループットには一定の限界が発生します。ブロックチェーンにおけるチャネルとは、トランザクションの最終的な決済のセキュリティをメインチェーンに依存しつつ、ユーザー同士がオフチェーンでやりとりできるようにすることで、このスループットの問題を解消しようとするアプローチです。

単純なピアツーピアのプロトコルであるチャネルを利用することで、チャネルに参加する2つのノードは、数多くのトランザクションを実行した上で、最終的な結果のみをブロックチェーンに送信するだけでよくなります。チャネルは、暗号技術を用いることで、メインネットに送信されるサマリーデータがノード間で実行された一連の有効なトランザクションの真の結果であることを証明することができます。「マルチシグ」のスマートコントラクトは、各トランザクションが適切なノードにより署名されたことを保証します。

チャネルにおける状態変化は参加ノードにより実行、検証されるため、実行レイヤーにおける計算を最低限に抑えることができます。これにより、イーサリアムの混雑が解消され、ユーザーにとってはトランザクションの処理速度が改善されます。

各チャネルは、イーサリアム上で実行されるマルチシグのスマートコントラクトで管理されます。ユーザーがチャネルを開設するには、オンチェーンでチャネルコントラクトをデプロイし、そこに資金を入金します。チャネルの両ユーザーは、状態更新に共同で署名することでチャネルの状態を初期化した上で、オフチェーンで迅速かつ自由にトランザクションを実行することができます。

チャネルを廃止するには、当該チャネルにおける最終的な同意済み状態をオンチェーンに送信します。これを受けて、マルチシグのスマートコントラクトは、チャネルの最終状態における各ノードの残高に従って、ロックされた資金を分配します。

ピアツーピアのチャネルは、特に事前に定義された参加者が処理速度の明らかな低下をもたらすことなく高頻度でトランザクションを行いたい場合に有益です。ブロックチェーンにおけるチャネルは、ペイメントチャネルとステートチャネルの2種類に大別できます。

ペイメントチャネル

ペイメントチャネルは、2つのノードが共同で管理する「双方向の台帳」と呼べるでしょう。この台帳における当初の残高は、チャネル開設時にオンチェーンのコントラクトにおいてロックされた両ユーザーからの入金の合計額になります。ペイメントチャネルにおける送金は、チャネル開設時と最終的なチャネル廃止時におけるオンチェーンのトランザクションを除き、ブロックチェーン自体を関与させずに瞬時に実行することができます。

チャネルの台帳における残高（つまり、ペイメントチャネルの状態）が変更される場合、チャネルに参加する全ユーザーの承認が必要になります。イーサリアムにおけるトランザクションの場合と同じように、チャネルの更新は、参加ユーザー全員の署名によりファイナライズされたと見なされます。

ペイメントチャネルは、ユーザーがオンチェーンで実行する単純なやりとり（例：ETHの送金、アトミックスワップ、少額決済など）の費用を軽減するために設計された最初期のスケーリング・ソリューションのひとつです。チャネルの参加ユーザーは、送金の合計額がデポジットされたトークンの合計を超えない限り、ユーザー間のトランザクションを瞬時に何回でも無料で実行することができます。

ステートチャンネル

ペイメントチャネルは、オフチェーンにおける支払機能以外の全般的な状態遷移のロジックを取り扱う際には有効ではないことが明らかになっています。ステートチャネルは、このペイメントチャネルの欠点を解消するために開発されたもので、汎用的な計算におけるスケーラビリティを実現するためのチャネルだと言えます。

ただし、ステートチャネルはペイメントチャネルと多くの点が共通しています。例えばどちらのチャネルでも、ユーザーが他のチャネル参加者とやりとりを行う際には、チャネルの全参加ユーザーが暗号学的に署名されたメッセージ（トランザクション）に署名しなければなりません。提案された状態更新が全参加ユーザーによって署名されていなければ、更新は無効とされます。

一方で、ステートチャネルでは、ユーザーの残高情報を保持するだけでなく、当該コントラクトのストレージの現在状態（つまり、コントラクトに含まれる各変数の値）を追跡することができます。

これにより、2人のユーザー間で、スマートコントラクトをオフチェーンで実行することが可能になります。この場合、スマートコントラクトの初期状態を変更するには、チャネルを開設した両ユーザー（ピア）の承認のみが必要になります。

これは、先ほど挙げたスケーラビリティの問題を解消する一方で、セキュリティが低下する可能性をもたらします。イーサリアムでは、状態遷移の有効性はコンセンサス・プロトコルにより強制されています。これにより、スマートコントラクトの状態に対して無効な更新を提案したり、スマートコントラクトの実行を改変することは不可能になっているのです。

ステートチャネルでは、このようなセキュリティの保証が提供されません。ステートチャネルは、言わばメインネットのミニチュア版と考えることができます。ルールを強制する参加者の数が限定されるため、悪意の行為（つまり、無効な状態更新の提案）が発生する可能性が大きくなります。ステートチャネルでは、

不正証明

に基づく紛争仲裁のメカニズムにより、セキュリティを確保します。

ステートチャネルの仕組み

ステートチャネルにおけるアクティビティは、基本的に、ユーザーとブロックチェーンによる相互のやりとりのセッションだと考えることができます。ユーザーが実行するやりとりの大部分は他の参加ユーザーとのオフチェーンでのやりとりであり、基盤であるブロックチェーンとのやりとりは、チャネルの開設／廃止ならびに参加ユーザー間で紛争が発生した場合の和解についてのみ実行します。

次のセクションでは、ステートチャネルの基本的なワークフローについて説明します：

チャネルの開設

チャネルを開設するには、参加ユーザーがメインネット上のスマートコントラクトにおいて資金をコミットする必要があります。このデポジットは仮想的な請求書（タブ）として機能するため、参加ユーザーはただちに決済することなく、自由に取引を実行することができます。チャネルがオンチェーン上でファイナライズされた際にはじめて、ユーザー間の取引が最終的に確定し、各自のタブから資金が引き出されます。

このデポジットは同時に、参加ユーザーが正直に行動することを保証する担保金の役割も担います。デポジットを提供したユーザーが紛争解決フェーズにおいて悪意の行為を実行したと決定された場合、スマートコントラクトはデポジットを没収します。

チャネルに参加する各ピアは、全員が同意したチャネルの初期状態に署名する必要があります。これによりステートチャネルが開設され、参加ユーザー間でトランザクションを実行できるようになります。

チャネルを使用する

チャネルの状態が初期化されると、各ピアは、自らが署名したトランザクションを他のピアに送信し、承認を求めることで、やりとりを行います。参加ユーザーは、このようなトランザクションを通じて、自らが状態更新を開始したり、他のユーザーからの状態更新に署名したりします。チャネルにおけるトランザクションは、以下の要素で構成されます：

ナンスは、トランザクションのユニークIDとして機能し、リプレイ攻撃を防ぎます。同時に、状態更新の発生順序を特定します（これは、紛争解決フェーズにおいて重要です）。
チャネルの古い状態。
チャネルの新しい状態。
状態遷移をトリガーするトランザクション（例：アリスがボブに5 ETHを送信するトランザクション）。

メインネットにおけるユーザー間の通常のやりとりとは異なり、チャネルの状態更新はオンチェーンでブロードキャストされません。これは、オンチェーンの負荷を最小化するというステートチャネルの目的に合致しています。参加ユーザーが同意する限り、状態更新はイーサリアムのトランザクションと同様のファイナリティを持ちます。参加者がメインネットのコンセンサスに依存するのは、紛争が発生した場合のみです。

チャネルを廃止する

ステートチャネルを廃止するには、チャネルの最終合意状態をオンチェーンのスマートコントラクトに送信する必要があります。状態更新における参照情報には、各参加ユーザーが実行したアクションの数および承認済みトランザクションのリストが含まれます。

当該の状態更新が有効である（つまり、全参加ユーザーにより署名済みである）ことが検証されると、スマートコントラクトが当該チャネルをファイナライズし、ロックされた資金をチャネルの最終状態に基づき分配します。オフチェーンで実行された支払いがイーサリアムの状態に適用され、各参加ユーザーは、ロックされた資金のうち残余の部分を受け取ります。

上記の流れは、あくまでも問題が発生しない幸せな場合です。各ユーザーが同意に達することができず、チャネルをファイナライズできない場合（残念なケース）もあります。具体的には、以下のような可能性があります：

参加ユーザーがオフラインになっために、状態遷移が提案できない。
参加ユーザーが、有効な状態更新の共同署名を拒否する。
参加ユーザーが、オンチェーンのコントラクトに古い状態更新を提案することで、チャネルをファイナライズしようとする。
参加ユーザーが、無効な状態遷移を提案し、他のユーザーに署名させようとする。

チャネルの参加ユーザー間のコンセンサスが維持できなくなった場合の最後のオプションは、メインネットのコンセンサスを用いて、チャネルの最後に有効な状態を強制することです。この場合、ステートチャネルを廃止するにはオンチェーンにおける紛争解決が必要になります。

紛争を解決する

通常、チャネルの参加ユーザーは、事前にチャネルの廃止に同意し、最後の状態遷移に共同署名した上で、スマートコントラクトに送信します。チャネルの更新がオンチェーン上で承認されると、オフチェーンにおけるスマートコントラクトの実行が終了し、参加ユーザーは各自の資金を持ってチャネルを退出します。

しかし1名の参加ユーザーが、他のユーザーによる承認を待たずに、スマートコントラクトの実行終了とチャネルのファイナライズを要求するリクエストをオンチェーンで送信する可能性もあります。上述したようなコンセンサスが維持できない状況が発生した場合、各参加ユーザーは、オンチェーンのコントラクトに対し、チャネルを廃止し、資金を分配させるようにトリガーすることができます。これにより正直な参加ユーザーは、他のユーザーのアクションに関わらず常にデポジットを撤回できるため、トラストレス性が確保されます。

チャネルの廃止を実行したいユーザーは、当該アプリケーションの最後の有効な状態更新をオンチェーンのコントラクトに送信する必要があります。この最後の有効な状態更新が正しければ（つまり、全参加ユーザーの署名を含んでいれば）、資金は各ユーザーに再分配されます。

ただし、1名のユーザーによる廃止リクエストに対しては、実行までの保留期間が発生します。反対に、チャネルの廃止が満場一致で承認されている場合は、オンチェーンにおける廃止トランザクションはただちに実行されます。

1名のユーザーによる廃止リクエストについて保留期間が発生するのは、不正行為の可能性を防止するためです。例えば、1名の参加ユーザーが、チャネルの古い状態をオンチェーンに送信して、イーサリアム上でチャネルをファイナライズしようとする可能性があります。

ステートチャネルでは、このようなアクションを防止するために、正直なユーザーが最新の有効状態をオンチェーンに送信することで、無効な状態更新に異議を申し立てることが可能になっています。ステートチャネルは、より新しい同意済みの状態更新が、より古い状態更新よりも優先されるように設計されています。

特定のピアがオンチェーンにおける紛争解決システムをトリガーした場合、相手方のピアは、一定の時間内（チャレンジ期間と呼ぶ）に対応しなければなりません。このメカニズムを通じて、各ユーザーは、特に相手方のピアが状態更新を要求する場合に、廃止トランザクションに異議を申し立てることができます。

状況の如何を問わず、チャネルの各ユーザーに対しては強力なファイナライズの保証が提供されます。つまり、ユーザーが所有する状態遷移が他のユーザー全員により署名されており、最新の更新であれば、オンチェーンにおける通常のトランザクションと同じファイナリティを持ちます。他のユーザーに対してオンチェーンで異議を申し立てる必要は残るものの、紛争解決メカニズムにより、最終的にはこのユーザーが所有する最後の有効状態がファイナライズされます。

ステートチャネルは、イーサリアムとどのようなやりとりを行うか？

ステートチャネルはオフチェーンのプロトコルとして存在しますが、オンチェーンの構成要素、つまりチャネル開設時にイーサリアム上でデプロイされたスマートコントラクトを持ちます。このコントラクトは、ステートチャネルにデポジットされた資産を管理し、状態更新を検証し、参加ユーザー間の紛争を仲裁する機能を持ちます。

ステートチャネルは、レイヤー2のスケーリング・ソリューションとは異なり、メインネットに対してトランザクションデータやステートコミットメントを送信しません。しかし、サイドチェーンなどと比較するとメインネットとの接続性が高いため、やや安全性が高いと言えます。

ステートチャネルは、以下の事項につきメインのイーサリアムプロトコルに依存します：

1. ライブネス

チャネル開設時にオンチェーンでデプロイされるスマートコントラクトは、チャネルの機能に対して責任を負います。このコントラクトがイーサリアムで稼働中であれば、このチャネルは常に利用できることになります。一方、サイドチェーンの場合、メインネットが稼働している場合でも機能が停止される可能性があるため、ユーザーの資金に対してリスクが発生します。

2. セキュリティ

ステートチャネルでは、セキュリティを維持し、悪意のピアから善意のピアを保護するために、ある程度イーサリアムに依存しています。以下のセクションで説明するように、ステートチャネルでは、無効な／古い状態更新でチャネルをファイナライズしようとするユーザーに異議を申し立てることが可能な不正証明メカニズムを採用しています。

このメカニズムでは、正直なユーザーが不正証明として最新の有効な状態をオンチェーンのコントラクトに提示し、検証を要求します。不正証明を使用することで、相互に信頼しない当事者間において、資金リスクを発生させずにオフチェーンでトランザクションを実行することが可能になります。

3. ファイナリティ

チャネルの各ユーザーが共同で署名した状態更新は、オンチェーンにおけるトランザクションと同等の効果を持つと見なされます。とはいえ、チャネル内のすべてのアクティビティが真のファイナリティを達成するのは、チャネルがイーサリアム上で廃止された時点においてです。

楽観的なシナリオにおいては、両当事者が連携して最終の状態更新に署名し、オンチェーンに送信してチャネルを廃止することで、チャネルの最終状態に基づいて資金が分配されることになります。一方、悲観的なシナリオにおいては、いずれかのユーザーが正しくない状態更新をオンチェーンに送信することで、チャレンジ期間が経過するまでトランザクションがファイナライズされない可能性があります。

仮想ステートチャネル

ステートチャネルのネイティブ実装は、オフチェーンでアプリケーションを実行したい2名のユーザーが、新規のスマートコントラクトをデプロイすることを想定していました。しかし、このようなアプローチは実現不可能であるだけでなく、ステートチャネルに求められるコスト効率性も失われます（オンチェーンでのトランザクション費用が大きくかさむため）。

この問題点を解消するために、「仮想チャネル」が開発されました。チャネルを開設／廃止するためにオンチェーンでのトランザクションが必要な通常のチャネルとは異なり、仮想チャネルは、メインチェーンとのやりとりを行うことなく、開設、実行、およびファイナライズが可能です。このメソッドを用いて、紛争をオフチェーンで解決することすら可能です。

仮想チャネルのシステムが機能するには、オンチェーンですでに資金が入金されている、いわゆる「台帳チャネル」が存在する必要があります。これは、既存の台帳チャネルの上に2名のユーザー間の仮想チャネルを構築し、台帳チャネルの所有ユーザー（複数可）が仲介者の役割を果たすというモデルです。

各仮想チャネルに参加するユーザーは、当該コントラクトの新規インスタンスを通じてやりとりを行い、台帳チャネルが複数のインスタンスをサポートします。また、台帳チャネルの状態には複数のコントラクトにおけるストレージ状態が含まれるため、オフチェーンにおいて、複数のユーザーがアプリケーションを並列的に実行することが可能になります。

この場合も、通常のチャネルと同様に、ユーザーは状態更新を相互に交換することで状態マシンを前に進めることができます。紛争が発生しない限り、仲介者とのやりとりはチャネルの開設／廃止時のみに限定されます。

仮想ペイメントチャネル

仮想ペイメントチャネルは、仮想ステートチャネルと同じ発想に基づいており、同じネットワークに接続された参加ユーザーは、オンチェーンで新たなチャネルを開設する必要なしにメッセージをやりとりすることができます。仮想ペイメントチャネルでは、送金は1名または複数の仲介者を介して実行されるため、意図した受取人のみが資金を受け取ることが保証されます。

ステートチャネルの応用例

支払い

ブロックチェーンにおける初期のチャネルは、メインネットにおいて高額の手数料を発生させることなく、2名のユーザーがオフチェーンで、迅速かつ安価な送金を行うことができるシンプルなプロトコルでした。ペイメントチャネルは現在でも、イーサ（ETH）やその他のトークンの交換や預入を行う目的において有益だと言えます。

チャネルを活用した決済には、以下の利点があります：

スループット: イーサリアムのスループットは、特にブロックサイズやブロック時間といった様々な要因に影響を受けますが、チャネルにおいてオフチェーンで実行できるトランザクションの数はこれらに影響を受けることがありません。ブロックチェーンのチャネルは、オフチェーンでトランザクションを実行することで、スループットの向上を実現できます。
プライバシー: チャネルはオフチェーン上に存在するため、参加ユーザー間のやりとりの詳細はイーサリアムのパブリックブロックチェーンに記録されません。チャネルの各ユーザーがオンチェーンでやりとりする必要があるのは、チャネルの開設に伴う入金、チャネルの廃止、および紛争解決が必要な場合のみです。このため、トランザクションのプライバシーを重視するユーザーにとってチャネルは有益だと言えます。
レイテンシー: チャネルの参加ユーザーがオフチェーンで実行するトランザクションは、双方に異議がなければ瞬時に決済されるため、遅延が発生しません。対照的に、メインネットでのトランザクションの場合、各ノードがトランザクションを処理し、トランザクションを含む新規ブロックを生成した上で、コンセンサスを達成するまでの時間が必要になります。さらに、トランザクションがファイナライズされる前に、より多くのブロックが確認されるまで待たなければならない場合もあります。
コスト: ステートチャネルは特に、特定のユーザー集団が長期的に数多くの状態更新を交換する必要がある場合に有益だと言えます。発生する唯一のコストは、ステートチャネルのスマートコントラクトの開始／終了に伴う費用のみです。決済コストは、チャネルの最終状態に従って配分されるため、チャネルの開設から廃止に至るまでの各状態変化のコストは最後の状態変化のコストよりも安価になります。

ステートチャネルは、ロールアップなどのレイヤー2ソリューションで実装することで、さらに魅力的な決済手段になる可能性があります。チャネルは、安価な決済手段を提供するものであるとは言え、開設時におけるメインネットでのオンチェーンコントラクトの設定費用は、特にガス料金が急騰した際には高額になる可能性があります。イーサリアムベースのロールアップは安価なトンラザクションフィー(opens in a new tab)を提供するため、チャネル参加者はセットアップ手数料を抑えることで全体の間接費用を削減できます。

マイクロトランザクション

マイクロトランザクションとは、企業にとって損失が発生するような微少な価値（例：1ドル未満）の決済を指します。これらの事業体は、決済サービスプロバイダーに手数料を支払う必要がありますが、顧客売上の利益率が低すぎる場合には損失が発生する可能性があるためです。

ペイメントチャネルは、マイクロトランザクションにおける間接費用を縮小することでこの問題を解消します。例えばインターネットサービスプロバイダー（ISP）であれば、顧客が自社サービスを利用するごとに少額の支払いがストリーミングされるペイメントチャネルを開設することができます。

チャネルの参加ユーザーは、チャネルの開設／廃止時における費用を負担すれば、実際のマイクロトランザクションにおいて費用を発生させずに済むのです（ガス代がかかりません）。顧客は受け取るサービスに対してより柔軟に支払うことができ、企業は収益性を持つマイクロトランザクションを放棄する必要がなくなるので、双方にとって有益なサービスになります。

分散型のアプリケーション

ステートチャネルでは、ペイメントチャネルと同様に、ステートマシンの最終状態に従って条件付きの決済を行うことができます。ステートチャネルはまた、任意の状態遷移ロジックをサポートしているため、オフチェーン上で汎用的なアプリケーションを実行するためにも有益です。

多くのステートチャネルでは、オンチェーンのコントラクト上でコミットされた資金を管理するのに用意であるため、単純な相互のやりとりを行うアプリケーションのみに使用が限定されています。また、オフチェーンのアプリケーションにおける状態を一定間隔で更新するユーザーの数が制限されるため、不正直なユーザー行動を罰するのが比較的容易です。

また、ステートチャネルを用いたアプリケーションの効率性は、その設計により異なります。例えば、デベロッパーはアプリケーションのチャネルコントラクトをオンチェーンで1回デプロイし、利用者がオンチェーンにアクセスすることなくアプリを再利用できるように設計することが可能です。この場合、アプリケーションの当初のチャネルが台帳チャネルとして複数の仮想チャネルをサポートするので、アプリケーションのスマートコントラクトは、オフチェーン上で新規インスタンスとして実行することができます。

ステートチャネルを用いたアプリケーションのユースケースとしては、ゲームの結果に基づいて資金が分配される2人対戦型のゲームが想定できるでしょう。この場合のメリットとしては、各プレイヤーが相手プレイヤーを信頼する必要がなく（トラストレス性）、資金の分配や紛争の解決を管理するのはプレイヤーではなくオンチェーンのコントラクトである（分散性）という点です。

ステートチャネルを用いたアプリケーションにおけるその他のユースケースとしては、ENSの名前解決サービスやNFT台帳など、様々な可能性があります。

アトミック送金

初期のペイメントチャネルでは、2名のユーザー間の送金のみが可能だったため、用途が限られていました。しかし、仮想チャネルが導入されたことで、オンチェーン上で新規チャネルを開設せずに、仲介者を通した送金の転送（つまり、複数のP2Pチャネルを利用した送金）が可能になりました。

転送を伴う支払いは一般的に「マルチホップ送金」と呼ばれ、アトミックな性質を持ちます（つまり、トランザクションに含まれるすべての部分が成功しない限り、全体が無効になります）。アトミック送金では、ハッシュ化されたタイムロック・コントラクト（HTLCs）(opens in a new tab)を用いて、特定の条件を満たす場合のみ支払いが実行されるため、カウンターパーティリスクが軽減されます。

ステートチャネルの活用に伴うデメリット

ライブネスの想定

ステートチャネルでは、効率性を維持するために、チャネルの参加ユーザーにおける紛争対応能力に時間的な制限を設けています。このルールは、各ピアが常にオンラインでチャネルのアクティビティを監視でき、必要に応じて異議申立に対応できることを想定しています。

実際には、ユーザーは各自の責任ではない理由でオフラインになる可能性があります（インターネットの接続不良や機器の不調など）。このため、悪意のユーザーは、正直なユーザーがオフラインである間に仲裁者コントラクトに古い中間状態を送信し、コミットされた資金を窃盗することが可能です。

一部のチャネルでは、他のユーザーの代理としてオンチェーン上の紛争イベントを監視し、必要に応じてアクション（関連当事者にアラートを発信するなど）を実行する「監視塔」のエンティティを設定しています。ただしこのアプローチでは、ステートチャネルの利用コストが上昇する可能性があります。

データ入手不可能性 (Data unavailability)

すでに述べたように、紛争が無効であるとして異議を申し立てるためには、ステートチャネルの最終有効状態を送信する必要があります。これも、各ユーザーがチャネルの最新状態にアクセス可能であるという想定に基づいたルールだと言えます。

チャネルユーザーに対し、オフチェーン上のアプリケーションの状態コピーを保持するように要求するのは合理的であるものの、このデータは、エラーや機器の故障により失われる可能性があります。ユーザーが当該データのバックアップを作成していない場合、相手方のユーザーが所持している古い状態遷移を用いて無効な終了リクエストをファイナライズしないように祈るしかありません。

イーサリアムにおいてこの問題が発生しないのは、イーサリアムネットワークによりデータの可用性に関するルールが強制されるためです。トランザクションデータはすべてのノードが保存し、伝播されるため、ユーザーは必要に応じて常にダウンロードすることができます。

流動性に関する問題点

ブロックチェーンでチャネルを開設するには、チャネルが存在する限り継続的にオンチェーンのスマートコントラクトで資金をロックする必要があります。これにより、チャネルに参加するユーザーの流動性に関する問題が軽減されますが、メインネットに資金をロックできるユーザー以外はチャネルに参加できなくなります。

しかし、オフチェーンのサービスプロバイダー（OSP）が提供する台帳チャネルを活用することで、ユーザーの流動性に伴う問題を軽減することが可能です。台帳チャネルに接続した2名のピアが仮想チャネルを構築することで、完全にオフチェーンのチャネルを開設し、いつでもファイナライズすることが可能になります。

OSPの側も、複数のピアが参加するチャネルを開設できるため、支払いの転送サービスを提供する上で有益です。もちろん、このようなサービスを利用するユーザーはOSPに手数料を支払う必要があるため、好ましくないと思うユーザーもいるでしょう。

グリーフィング攻撃

一般に、不正証明ベースのシステムにはグリーフィング攻撃がつきものです。グリーフィング攻撃とは、攻撃者に直接的な利益をもたらすものではないものの、被害者に苦痛（＝損害）を与えることを目的とするもので、苦痛付与攻撃とも言えます。

不正証明においてグリーフィング攻撃が発生してしまうのは、正直なユーザーが無効な紛争を含むすべての紛争に対応しなければならず、それを怠った場合には資金を失うリスクが発生してしまうためです。悪意のユーザーは、古い状態遷移を継続的にオンチェーンに送信することで、正直なユーザーに対して有効な状態を用いて応答するように仕向けることが可能です。このような攻撃を繰り返すことで、オンチェーンにおけるトランザクションのコストが急激に増加し、正直なユーザーが負担できなくなる可能性があるのです。

定義済みの参加者セット

ステートチャネルでは、その設計に基づき、チャネルの存続期間を通じた参加ユーザー数が固定されています。これは、特にチャネルへの資金供給や紛争の解決などにおいて、参加できるユーザー数を変更するとチャネルの運用が複雑化するためです。さらに、参加者の追加／削除はオンチェーンでのアクティビティを追加するため、ユーザーの間接費用が増加してしまいます。

これらの理由により、ステートチャネルが定義済みの参加者セットを導入するのは理にかなっているものの、アプリケーションのデベロッパーにとってはチャネルの設計における有用性を低めるものでもあります。この点は、ロールアップなどその他のスケーリング・ソリューションと比較して、ステートチャネルの利用度が下がっている原因のひとつだと言えます。

トランザクションの並列処理

ステートチャネルの参加ユーザーは状態更新を交互に送信しあうため、「順番ベースのアプリケーション」（例：対戦型のチェスゲーム）に最も適しています。このアプローチでは、複数の状態更新を同時に実行する必要がないため、オンチェーンのコントラクトにおいて古い状態を送信したユーザーを罰する負担が軽減されます。ただしこの設計の副作用として、トランザクションが相手方のアクションに依存するため、レイテンシーが増化し、全般的なユーザー体験の質が損なわれる可能性があります。

一部のステートチャネルでは、当該のオフチェーンの状態につき、2つの一方向性の状態（「インプレックス」）に分割し、双方における同時の状態更新を可能にする「全二重設計」を採用することで、この問題を解消しています。このような設計は、オフチェーンのスループットを高め、トランザクションの遅延を軽減します。

ステートチャネルを使う

複数のプロジェクトにおいて、Dappに統合できるステートチャネルの実装が提供されています：

参考文献

ステートチャンネル

イーサリアムにおけるレイヤー2のスケーリング・ソリューションを理解する：ステートチャネル、プラズマ、およびTruebit(opens in a new tab) - 2018年2月12日、ジョシュ・スターク作成。
ステートチャネルの説明(opens in a new tab) - 2015年11月6日、ジェフ・コールマン作成。
ステートチャネルの基礎(opens in a new tab) - District0x
ブロックチェーンにおけるステートチャネル：現在の状況(opens in a new tab)

役に立つコミュニティリソースをご存知の場合は、このページを編集して追加してください。

back-to-top ↑