ステートチャネル

ステートチャネルは、参加者がイーサリアムメインネットとのやり取りを最小限に抑えながら、オフチェーンで安全に取引できるようにします。 チャネルピアは、チャネルを開閉するために2つのオンチェーントランザクションを送信するだけで、任意の数のオフチェーントランザクションを実行できます。 これにより、トランザクションのスループットが大きく改善され、ユーザーの手数料が軽減できます。

前提条件

イーサリアムのスケーリングとレイヤー2に関するページを読み、理解しておく必要があります。

チャネルとは何か？

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

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

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

各チャネルは、イーサリアム上で実行されるマルチシグスマートコントラクトによって管理されます。 チャネルを開くには、参加者はチャネルコントラクトをオンチェーンでデプロイし、そこに資金を預け入れます。 両当事者は共同で状態更新に署名してチャネルの状態を初期化し、その後、オフチェーンで迅速かつ自由に取引できます。

チャネルを閉じるには、参加者はチャネルの最後に合意された状態をオンチェーンに送信します。 これを受けて、マルチシグのスマートコントラクトは、チャネルの最終状態における各ノードの残高に従って、ロックされた資金を分配します。

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

ペイメントチャネル

ペイメントチャネルは、2つのノードが共同で管理する「双方向の台帳」と呼べるでしょう。 台帳の初期残高は、チャネル開設フェーズ中にオンチェーンコントラクトにロックされた預託金の合計額です。 ペイメントチャネルでの送金は、最初の1回限りのオンチェーン作成と最終的なチャネルの閉鎖を除き、実際のブロックチェーン自体を介さずに瞬時に実行できます。

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

ペイメントチャネルは、単純なユーザーインタラクション（例：ETH送金、アトミックスワップ、マイクロペイメント）の高価なオンチェーンアクティビティを最小限に抑えるために設計された、最も初期のスケーリングソリューションの1つでした。 チャネルの参加ユーザーは、送金の合計額がデポジットされたトークンの合計を超えない限り、ユーザー間のトランザクションを瞬時に何回でも無料で実行することができます。

ステートチャネル

オフチェーン決済のサポートは別として、ペイメントチャネルは一般的な状態遷移ロジックの処理には役立たないことが証明されています。 ステートチャネルは、このペイメントチャネルの欠点を解消するために開発されたもので、汎用的な計算におけるスケーラビリティを実現するためのチャネルだと言えます。

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

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

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

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

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

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

ステートチャネルにおけるアクティビティは、基本的に、ユーザーとブロックチェーンによる相互のやりとりのセッションだと考えることができます。 ユーザーは主にオフチェーンで相互に通信し、チャネルの開設、閉鎖、または参加者間の潜在的な紛争を解決するためにのみ、基盤となるブロックチェーンと対話します。

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

チャネルの開設

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

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

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

チャネルの使用

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

• ナンス。トランザクションの一意のIDとして機能し、リプレイ攻撃を防ぎます。 同時に、状態更新の発生順序を特定します（これは、紛争解決フェーズにおいて重要です）。

• チャネルの古い状態。

• チャネルの新しい状態。

• 状態遷移をトリガーするトランザクション（例：アリスがボブに5 ETHを送信するトランザクション）。

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

チャネルのクローズ

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

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

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

• 参加ユーザーがオフラインになっために、状態遷移が提案できない。

• 参加ユーザーが、有効な状態更新の共同署名を拒否する。

• 参加者は、古い状態更新をオンチェーンコントラクトに提案することで、チャネルのファイナライズを試みます。

• 参加ユーザーが、無効な状態遷移を提案し、他のユーザーに署名させようとする。

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

紛争の解決

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

しかし、一方の当事者は、相手の承認を待たずに、スマートコントラクトの実行を終了してチャネルをファイナライズするようオンチェーンでリクエストを送信できます。 前述のコンセンサスを破るような状況が発生した場合、いずれかの当事者はオンチェーンコントラクトをトリガーしてチャネルを閉じ、資金を分配させることができます。 これによりトラストレス性が提供され、誠実な当事者は、相手方の行動に関係なく、いつでもデポジットを引き出すことができるようになります。

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

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

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

対抗策として、ステートチャネルでは、誠実なユーザーがチャネルの最新の有効な状態をオンチェーンで送信することで、無効な状態更新に異議を唱えることができます。 ステートチャネルは、より新しい同意済みの状態更新が、より古い状態更新よりも優先されるように設計されています。

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

どのような場合であれ、チャネルユーザーは常に強力なファイナリティ保証を得られます。もし所有する状態遷移がすべてのメンバーによって署名され、かつ最新の更新であるならば、それは通常のオンチェーントランザクションと同等のファイナリティを持ちます。 彼らは依然として相手方に対してオンチェーンで異議を申し立てる必要がありますが、唯一可能な結果は、彼らが保持する最後の有効な状態をファイナライズすることです。

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

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

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

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

1. 生存性

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

2. セキュリティ

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

この場合、誠実な当事者は、検証のためにチャネルの最新の有効な状態を不正証明としてオンチェーンコントラクトに提供します。 不正証明により、相互に信頼しない当事者同士が、その過程で資金を危険にさらすことなく、オフチェーントランザクションを実行できるようになります。

3. ファイナリティ

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

楽観的なケースでは、両当事者が協力して最終的な状態更新に署名し、オンチェーンに送信してチャネルを閉じ、その後、チャネルの最終状態に応じて資金が分配されます。 悲観的なケースでは、誰かが不正な状態更新をオンチェーンに投稿して不正を働こうとした場合、そのトランザクションはチャレンジ期間が経過するまでファイナライズされません。

仮想ステートチャネル

ステートチャネルの単純な実装は、2人のユーザーがオフチェーンでアプリケーションを実行したい場合に新しいコントラクトをデプロイすることです。 これは実行不可能であるだけでなく、ステートチャネルの費用対効果を無効にします（オンチェーントランザクションのコストはすぐに加算される可能性があります）。

この問題点を解消するために、「仮想チャネル」が開発されました。 開設と終了にオンチェーントランザクションを必要とする通常のチャネルとは異なり、仮想チャネルはメインチェーンと対話することなく、開設、実行、ファイナライズが可能です。 この方法を使えば、オフチェーンで紛争を解決することも可能です。

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

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

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

仮想ペイメントチャネル

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

ステートチャネルのアプリケーション

支払い

初期のブロックチェーンチャネルは、2人の参加者がメインネットで高いトランザクション手数料を支払うことなく、オフチェーンで迅速かつ低料金の送金を行えるようにするシンプルなプロトコルでした。 ペイメントチャネルは現在でも、イーサ（ETH）やその他のトークンの交換や預入を行う目的において有益だと言えます。

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

1. スループット: チャネルあたりのオフチェーントランザクションの量は、ブロックサイズやブロック時間など様々な要因に影響されるイーサリアムのスループットとは無関係です。 オフチェーンでトランザクションを実行することで、ブロックチェーンチャネルはより高いスループットを達成できます。

2. プライバシー: チャネルはオフチェーンに存在するため、参加者間の対話の詳細はイーサリアムのパブリックブロックチェーンには記録されません。 チャネルユーザーは、チャネルへの資金提供や閉鎖、または紛争解決時にのみオンチェーンで対話する必要があります。 このため、トランザクションのプライバシーを重視するユーザーにとってチャネルは有益だと言えます。

3. レイテンシー: チャネル参加者間で行われるオフチェーントランザクションは、両当事者が協力すれば即座に決済でき、遅延を減らすことができます。 対照的に、メインネットでのトランザクションの場合、各ノードがトランザクションを処理し、トランザクションを含む新規ブロックを生成した上で、コンセンサスを達成するまでの時間が必要になります。 さらに、トランザクションがファイナライズされる前に、より多くのブロックが確認されるまで待たなければならない場合もあります。

4. コスト: ステートチャネルは、参加者の集まりが長期間にわたって多くの状態更新を交換する状況で特に有用です。 発生する唯一のコストは、ステートチャネルのスマートコントラクトの開始／終了に伴う費用のみです。決済コストは、チャネルの最終状態に従って配分されるため、チャネルの開設から廃止に至るまでの各状態変化のコストは最後の状態変化のコストよりも安価になります。

ロールアップなどのレイヤー2ソリューションにステートチャネルを実装することで、支払いにとってさらに魅力的なものになる可能性があります。 チャネルは安価な支払いを提供しますが、開設フェーズでメインネットにオンチェーンコントラクトを設定するコストは高くなる可能性があります。特にガス料金が急騰した場合はなおさらです。 イーサリアムベースのロールアップはより低いトランザクション手数料 (opens in a new tab)を提供し、設定手数料を下げることでチャネル参加者のオーバーヘッドを削減できます。

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

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

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

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

分散型アプリケーション

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

ステートチャネルは、オンチェーンコントラクトにコミットされた資金の管理を容易にするため、単純なターンベースのアプリケーションに限定されることがよくあります。 また、限られた数の当事者が一定間隔でオフチェーンアプリケーションの状態を更新するため、不正行為の処罰は比較的簡単です。

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

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

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

アトミック送金

初期のペイメントチャネルでは、2名のユーザー間の送金のみが可能だったため、用途が限られていました。 しかし、仮想チャネルの導入により、個人はオンチェーンで新しいチャネルを開設することなく、仲介者（つまり複数のP2Pチャネル）を介して送金をルーティングできるようになりました。

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

ステートチャネルを使用する際の欠点

生存性の仮定

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

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

一部のチャネルでは、「監視塔（ウォッチタワー）」、つまり他者に代わってオンチェーンの紛争イベントを監視し、関係者への警告など必要な措置を講じる責任を負うエンティティを使用します。 ただしこのアプローチでは、ステートチャネルの利用コストが上昇する可能性があります。

データの非可用性

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

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

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

流動性の問題

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

しかし、オフチェーンサービスプロバイダー（OSP）によって運営される台帳チャネルは、ユーザーの流動性の問題を軽減できます。 台帳チャネルに接続された2つのピアは仮想チャネルを作成でき、いつでも完全にオフチェーンで開設およびファイナライズできます。

オフチェーンサービスプロバイダーは、複数のピアとチャネルを開くこともでき、支払いのルーティングに役立ちます。 もちろん、このようなサービスを利用するユーザーはOSPに手数料を支払う必要があるため、好ましくないと思うユーザーもいるでしょう。

グリーフィング攻撃

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

不正証明においてグリーフィング攻撃が発生してしまうのは、正直なユーザーが無効な紛争を含むすべての紛争に対応しなければならず、それを怠った場合には資金を失うリスクが発生してしまうためです。 悪意のある参加者は、古い状態遷移を繰り返しオンチェーンに投稿し、誠実な当事者に有効な状態で応答させることを決定する可能性があります。 これらのオンチェーントランザクションのコストはすぐに積み重なり、その過程で誠実な当事者が損をする原因となります。

事前定義された参加者セット

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

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

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

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

一部のステートチャネルは、オフチェーンの状態を2つの単方向の「シンプレックス」状態に分離する「全二重」設計を使用することでこの問題を解決し、同時状態更新を可能にします。 このような設計は、オフチェーンのスループットを向上させ、トランザクションの遅延を減少させます。

ステートチャネルを使用する

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

• Connext (opens in a new tab)
• Kchannels (opens in a new tab)
• Perun (opens in a new tab)
• Raiden (opens in a new tab)
• Statechannels.org (opens in a new tab)

参考リンク

ステートチャンネル

• イーサリアムのレイヤー2スケーリングソリューションを理解する：ステートチャネル、Plasma、Truebit (opens in a new tab) – Josh Stark、2018年2月12日
• ステートチャネル - 解説 (opens in a new tab) 2015年11月6日 - Jeff Coleman
• ステートチャネルの基礎 (opens in a new tab) District0x
• ブロックチェーンステートチャネル：最新技術 (opens in a new tab)

役に立つコミュニティリソースを知っていますか? Edit this page and add it!