メインコンテンツへスキップ
Change page

ステート・チャネル

ステート・チャネルを使用すると、参加者はイーサリアム・メインネットとのやり取りを最小限に抑えながら、安全にオフチェーンでトランザクションを実行できます。チャネルのピアは、チャネルを開くときと閉じるときの2つのオンチェーントランザクションを送信するだけで、任意の数のオフチェーントランザクションを実行できます。これにより、非常に高いトランザクションスループットが可能になり、ユーザーのコストが削減されます。

前提条件

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

チャネルとは何ですか？

イーサリアムなどのパブリックブロックチェーンは、その分散型アーキテクチャによりスケーラビリティの課題に直面しています。オンチェーントランザクションはすべてのノードで実行される必要があるためです。ノードは、ネットワークを分散化された状態に保つために、標準的なハードウェアを使用してブロック内のトランザクション量を処理できる必要があり、これがトランザクションスループットの制限となります。ブロックチェーンチャネルは、最終的なセトルメントについてはメインチェーンのセキュリティに依存しつつ、ユーザーがオフチェーンでやり取りできるようにすることで、この問題を解決します。

チャネルは、2つの当事者が互いに多くのトランザクションを実行し、最終的な結果のみをブロックチェーンに投稿できるようにするシンプルなピア・ツー・ピアプロトコルです。チャネルは暗号技術を使用して、生成されたサマリーデータが有効な中間トランザクションのセットの真の結果であることを証明します。「マルチシグ」スマート・コントラクトにより、トランザクションが正しい当事者によって署名されていることが保証されます。

チャネルを使用すると、状態の変更は関係する当事者によって実行および検証されるため、イーサリアムの実行レイヤーでの計算が最小限に抑えられます。これにより、イーサリアムの混雑が緩和され、ユーザーのトランザクション処理速度も向上します。

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

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

ピア・ツー・ピアチャネルは、事前に定義された一部の参加者が、目に見えるオーバーヘッドを発生させることなく高頻度でトランザクションを実行したい状況で特に役立ちます。ブロックチェーンチャネルは、ペイメントチャネルとステート・チャネルの2つのカテゴリに分類されます。

ペイメントチャネル

ペイメントチャネルは、2人のユーザーによって共同で維持される「双方向の台帳」と表現するのが最適です。台帳の初期残高は、チャネルを開くフェーズでオンチェーンコントラクトにロックされた入金の合計です。ペイメントチャネルの送金は、最初に行う1回のオンチェーンでの作成と最終的なチャネルの閉鎖を除き、実際のブロックチェーン自体を関与させることなく瞬時に実行できます。

台帳の残高 (つまり、ペイメントチャネルの状態) の更新には、チャネル内のすべての当事者の承認が必要です。すべてのチャネル参加者によって署名されたチャネルの更新は、イーサリアム上のトランザクションと同様に、ファイナライズ済みと見なされます。

ペイメントチャネルは、単純なユーザーのやり取り (ETHの送金、アトミックスワップ、マイクロペイメントなど) における高価なオンチェーンアクティビティを最小限に抑えるように設計された、最も初期のスケーリングソリューションの1つでした。チャネルの参加者は、送金の純額が入金されたトークンを超えない限り、互いに無制限の即時かつ手数料無料のトランザクションを実行できます。

ステート・チャネル

オフチェーンでの支払いをサポートすることを除けば、ペイメントチャネルは一般的な状態遷移ロジックの処理には役立たないことが証明されています。ステート・チャネルは、この問題を解決し、汎用計算のスケーリングにチャネルを役立てるために作成されました。

ステート・チャネルには、依然としてペイメントチャネルと多くの共通点があります。たとえば、ユーザーは暗号技術によって署名されたメッセージ (トランザクション) を交換することでやり取りし、他のチャネル参加者もそれに署名する必要があります。提案された状態の更新がすべての参加者によって署名されていない場合、それは無効と見なされます。

ただし、チャネルはユーザーの残高を保持することに加えて、コントラクトのストレージの現在の状態 (つまり、コントラクト変数の値) も追跡します。

これにより、2人のユーザー間でスマート・コントラクトをオフチェーンで実行できるようになります。このシナリオでは、スマート・コントラクトの内部状態の更新には、チャネルを作成したピアの承認のみが必要です。

これは前述のスケーラビリティの問題を解決しますが、セキュリティに影響を与えます。イーサリアムでは、状態遷移の有効性はネットワークのコンセンサスプロトコルによって強制されます。これにより、スマート・コントラクトの状態に対する無効な更新を提案したり、スマート・コントラクトの実行を変更したりすることは不可能になります。

ステート・チャネルには、同じセキュリティ保証はありません。ある意味で、ステート・チャネルはメインネットのミニチュア版です。限られた参加者のセットがルールを強制するため、悪意のある行動 (無効な状態の更新を提案するなど) の可能性が高まります。ステート・チャネルは、に基づく紛争仲裁システムからセキュリティを引き出しています。

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

基本的に、ステート・チャネルでのアクティビティは、ユーザーとブロックチェーンシステムが関与するやり取りのセッションです。ユーザーは主にオフチェーンで互いに通信し、チャネルを開く、チャネルを閉じる、または参加者間の潜在的な紛争を解決するためにのみ、基盤となるブロックチェーンとやり取りします。

次のセクションでは、ステート・チャネルの基本的なワークフローの概要を説明します。

チャネルを開く

チャネルを開くには、参加者がメインネット上のスマート・コントラクトに資金をコミットする必要があります。この入金は仮想的なツケとしても機能するため、参加するアクターは支払いをすぐにセトルメントすることなく、自由にトランザクションを実行できます。チャネルがオンチェーンでファイナライズ済みになったときにのみ、当事者はお互いにセトルメントを行い、ツケの残りを引き出します。

この入金は、各参加者の誠実な行動を保証するための保証金としても機能します。紛争解決フェーズで入金者が悪意のある行動をとったと判断された場合、コントラクトはその入金を没収 (スラッシュ) します。

チャネルのピアは、全員が合意した初期状態に署名する必要があります。これがステート・チャネルのジェネシスとして機能し、その後ユーザーはトランザクションの実行を開始できます。

チャネルの使用

チャネルの状態を初期化した後、ピアはトランザクションに署名し、承認のために互いに送信することでやり取りします。参加者はこれらのトランザクションで状態の更新を開始し、他の参加者からの状態の更新に署名します。各トランザクションは以下で構成されます。

  • トランザクションの一意のIDとして機能し、リプレイ攻撃を防ぐナンス。また、状態の更新が発生した順序も識別します (これは紛争解決にとって重要です)。

  • チャネルの古い状態

  • チャネルの新しい状態

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

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

チャネルを閉じる

ステート・チャネルを閉じるには、合意されたチャネルの最終状態をオンチェーンのスマート・コントラクトに送信する必要があります。状態の更新で参照される詳細には、各参加者のアクションの数と承認されたトランザクションのリストが含まれます。

状態の更新が有効である (つまり、すべての当事者によって署名されている) ことを検証した後、スマート・コントラクトはチャネルをファイナライズ済みとし、チャネルの結果に応じてロックされた資金を分配します。オフチェーンで行われた支払いはイーサリアムの状態に適用され、各参加者はロックされた資金の残りの部分を受け取ります。

上記で説明したシナリオは、ハッピーケースで起こることを表しています。場合によっては、ユーザーが合意に達せず、チャネルをファイナライズ済みできないことがあります (サッドケース)。この状況では、以下のいずれかが当てはまる可能性があります。

  • 参加者がオフラインになり、状態遷移を提案できない

  • 参加者が有効な状態の更新への共同署名を拒否する

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

  • 参加者が他の参加者に署名させるために無効な状態遷移を提案する

チャネルに参加しているアクター間でコンセンサスが崩れた場合、最後の選択肢は、メインネットのコンセンサスに依存してチャネルの最終的で有効な状態を強制することです。この場合、ステート・チャネルを閉じるには、オンチェーンで紛争をセトルメントする必要があります。

紛争のセトルメント

通常、チャネルの当事者は事前にチャネルを閉じることに合意し、最後の状態遷移に共同署名して、それをスマート・コントラクトに送信します。更新がオンチェーンで承認されると、オフチェーンのスマート・コントラクトの実行が終了し、参加者は資金を持ってチャネルからエグジットします。

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

チャネルのエグジットを処理するには、ユーザーはアプリケーションの最後の有効な状態の更新をオンチェーンコントラクトに送信する必要があります。これが確認された場合 (つまり、すべての当事者の署名がある場合)、資金は彼らに有利に再分配されます。

ただし、単一ユーザーのエグジットリクエストの実行には遅延があります。チャネルを終了するリクエストが全会一致で承認された場合、オンチェーンのエグジットトランザクションは直ちに実行されます。

不正行為の可能性があるため、単一ユーザーのエグジットでは遅延が発生します。たとえば、チャネルの参加者が古い状態の更新をオンチェーンに送信することで、イーサリアム上でチャネルをファイナライズ済みしようとする場合があります。

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

ピアがオンチェーンの紛争解決システムをトリガーすると、もう一方の当事者は制限時間 (チャレンジウィンドウと呼ばれます) 内に応答する必要があります。これにより、ユーザーは、特に相手が古い更新を適用している場合に、エグジットトランザクションに異議を唱えることができます。

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

ステート・チャネルはイーサリアムとどのようにやり取りしますか？

ステート・チャネルはオフチェーンプロトコルとして存在しますが、オンチェーンのコンポーネントを持っています。それは、チャネルを開くときにイーサリアムにデプロイされるスマート・コントラクトです。このコントラクトは、チャネルに入金された資産を制御し、状態の更新を検証し、参加者間の紛争を仲裁します。

ステート・チャネルは、レイヤー2 (L2)スケーリングソリューションとは異なり、トランザクションデータや状態のコミットメントをメインネットに公開しません。ただし、たとえばサイドチェーンよりもメインネットに密接に接続されているため、いくらか安全です。

ステート・チャネルは、以下の点についてメインのイーサリアムプロトコルに依存しています。

1. Liveness

チャネルを開くときにデプロイされるオンチェーンコントラクトは、チャネルの機能に責任を持ちます。コントラクトがイーサリアム上で実行されている場合、チャネルは常に使用可能です。逆に、サイドチェーンはメインネットが稼働していても常に失敗する可能性があり、ユーザーの資金を危険にさらします。

2. Security

ある程度、ステート・チャネルはセキュリティを提供し、悪意のあるピアからユーザーを保護するためにイーサリアムに依存しています。後のセクションで説明するように、チャネルは不正証明メカニズムを使用しており、ユーザーは無効または古い更新でチャネルをファイナライズ済みしようとする試みに異議を唱えることができます。

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

3. Finality

チャネルユーザーによって共同で署名された状態の更新は、オンチェーントランザクションと同等と見なされます。それでも、チャネル内のすべてのアクティビティは、チャネルがイーサリアム上で閉じられたときにのみ真のファイナリティを達成します。

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

仮想ステート・チャネル

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

この問題を解決するために、「仮想チャネル」が作成されました。開いたり終了したりするためにオンチェーントランザクションを必要とする通常のチャネルとは異なり、仮想チャネルはメインチェーンとやり取りすることなく、開いて実行し、ファイナライズ済みすることができます。この方法を使用して、オフチェーンで紛争をセトルメントすることさえ可能です。

このシステムは、オンチェーンで資金が提供されている、いわゆる「台帳チャネル」の存在に依存しています。2つの当事者間の仮想チャネルは、既存の台帳チャネルの上に構築でき、台帳チャネルの所有者が仲介者として機能します。

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

通常のチャネルと同様に、ユーザーは状態の更新を交換してステートマシンを進行させます。紛争が発生しない限り、仲介者に連絡する必要があるのは、チャネルを開くときまたは終了するときだけです。

仮想ペイメントチャネル

仮想ペイメントチャネルは、仮想ステート・チャネルと同じアイデアに基づいて機能します。同じネットワークに接続されている参加者は、オンチェーンで新しいチャネルを開くことなくメッセージを渡すことができます。仮想ペイメントチャネルでは、価値の移転は1つ以上の仲介者を経由してルーティングされ、意図した受信者のみが送金された資金を受け取ることができるという保証があります。

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

支払い

初期のブロックチェーンチャネルは、2人の参加者がメインネットで高いトランザクション手数料を支払うことなく、オフチェーンで迅速かつ低手数料の送金を行えるようにするシンプルなプロトコルでした。今日でも、ペイメントチャネルはイーサやトークンの交換や入金のために設計されたアプリケーションに役立ちます。

チャネルベースの支払いには、以下の利点があります。

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

  2. プライバシー: チャネルはオフチェーンに存在するため、参加者間のやり取りの詳細はイーサリアムのパブリックブロックチェーンには記録されません。チャネルユーザーは、チャネルへの資金提供や閉鎖、または紛争のセトルメントを行うときにのみオンチェーンでやり取りする必要があります。したがって、チャネルはよりプライベートなトランザクションを望む個人にとって役立ちます。

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

  4. コスト: ステート・チャネルは、参加者のセットが長期間にわたって多くの状態の更新を交換する状況で特に役立ちます。発生するコストは、ステート・チャネルのスマート・コントラクトを開くときと閉じるときだけです。チャネルを開いてから閉じるまでの間のすべての状態変更は、セトルメントコストがそれに応じて分散されるため、前回よりも安くなります。

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

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

マイクロトランザクションは、企業が損失を被ることなく処理できない少額の支払い (たとえば、1ドルの数分の一未満) です。これらの企業は決済サービスプロバイダーに支払う必要がありますが、顧客の支払いに対するマージンが低すぎて利益が出ない場合は支払うことができません。

ペイメントチャネルは、マイクロトランザクションに関連するオーバーヘッドを削減することでこの問題を解決します。たとえば、インターネットサービスプロバイダー (ISP) は顧客とペイメントチャネルを開き、サービスを使用するたびに少額の支払いをストリーミングできるようにすることができます。

チャネルを開くときと閉じるときのコストを除けば、参加者はマイクロトランザクションにそれ以上のコスト (ガス代) を負担することはありません。顧客はサービスに支払う金額をより柔軟に決めることができ、企業は利益の出るマイクロトランザクションを逃すことがないため、これは双方にとってメリットのある状況です。

分散型アプリケーション (dapp)

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

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

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

ステート・チャネルアプリケーションの潜在的なユースケースは、ゲームの結果に基づいて資金が分配される単純な2人用ゲームです。ここでの利点は、プレイヤーが互いを信頼する必要がなく (トラストレス性)、プレイヤーではなくオンチェーンコントラクトが資金の割り当てと紛争のセトルメントを制御する (分散化) ことです。

ステート・チャネルアプリのその他の可能なユースケースには、ENS名の所有権、NFT台帳など、多くのものがあります。

アトミック送金

初期のペイメントチャネルは2つの当事者間の送金に制限されていたため、その使いやすさが制限されていました。しかし、仮想チャネルの導入により、個人はオンチェーンで新しいチャネルを開くことなく、仲介者 (つまり、複数のp2pチャネル) を介して送金をルーティングできるようになりました。

一般に「マルチホップ送金」と呼ばれるルーティングされた支払いはアトミックです (つまり、トランザクションのすべての部分が成功するか、完全に失敗するかのいずれかです)。アトミック送金はハッシュタイムロックコントラクト (HTLC) (opens in a new tab)を使用して、特定の条件が満たされた場合にのみ支払いが解放されるようにし、それによってカウンターパーティリスクを軽減します。

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

Livenessの前提

効率を確保するために、ステート・チャネルはチャネル参加者が紛争に対応できる時間に制限を設けています。このルールは、ピアが常にオンラインであり、チャネルのアクティビティを監視し、必要に応じて異議申し立てに反論することを前提としています。

実際には、ユーザーは自分では制御できない理由 (インターネット接続の不良、機械的な障害など) でオフラインになる可能性があります。誠実なユーザーがオフラインになった場合、悪意のあるピアは、古い中間状態を裁定コントラクトに提示し、コミットされた資金を盗むことで、その状況を悪用する可能性があります。

一部のチャネルでは「ウォッチタワー」を使用しています。これは、他の人に代わってオンチェーンの紛争イベントを監視し、関係者に警告するなどの必要なアクションを実行する責任を持つエンティティです。ただし、これによりステート・チャネルの使用コストが増加する可能性があります。

データの利用不可

前述のように、無効な紛争に異議を唱えるには、ステート・チャネルの最新の有効な状態を提示する必要があります。これは、ユーザーがチャネルの最新状態にアクセスできるという前提に基づくもう1つのルールです。

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

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

流動性の問題

ブロックチェーンチャネルを確立するには、参加者はチャネルのライフサイクル中、オンチェーンのスマート・コントラクトに資金をロックする必要があります。これにより、チャネルユーザーの流動性が低下し、メインネットに資金をロックし続ける余裕のある人にチャネルが制限されます。

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

オフチェーンサービスプロバイダーは複数のピアとチャネルを開くこともでき、支払いのルーティングに役立ちます。もちろん、ユーザーはOSPのサービスに対して手数料を支払う必要があり、これは一部の人にとっては望ましくない場合があります。

グリーフィング攻撃

グリーフィング攻撃は、不正証明ベースのシステムによく見られる特徴です。グリーフィング攻撃は攻撃者に直接的な利益をもたらしませんが、被害者に苦痛 (つまり、害) を引き起こすため、この名前が付けられています。

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

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

設計上、ステート・チャネルを構成する参加者の数は、その存続期間を通じて固定されたままです。これは、参加者のセットを更新すると、特にチャネルへの資金提供や紛争のセトルメントを行う際に、チャネルの運用が複雑になるためです。参加者の追加または削除には追加のオンチェーンアクティビティも必要になり、ユーザーのオーバーヘッドが増加します。

これによりステート・チャネルの推論は容易になりますが、アプリケーション開発者にとってのチャネル設計の有用性は制限されます。これは、ステート・チャネルがロールアップなどの他のスケーリングソリューションを支持して放棄された理由の一部を説明しています。

並行トランザクション処理

ステート・チャネルの参加者は順番に状態の更新を送信するため、「ターンベースのアプリケーション」 (たとえば、2人用のチェスゲーム) に最適です。これにより、同時の状態の更新を処理する必要がなくなり、古い更新の投稿者を罰するためにオンチェーンコントラクトが行う必要のある作業が軽減されます。ただし、この設計の副作用として、トランザクションが互いに依存するようになり、レイテンシが増加し、全体的なユーザーエクスペリエンスが低下します。

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

ステート・チャネルの使用

複数のプロジェクトが、dappに統合できるステート・チャネルの実装を提供しています。

参考文献

ステート・チャネル

役に立ったコミュニティリソースをご存知ですか？このページを編集して追加してください！