State Channelの基礎と全体像

はじめに

こんにちは、中村（@veryNR）です。

最近プレスリリースが出たのでご存知の方もいらっしゃると思いますが、GunosyとAnyPayでブロックチェーン関連事業を行う合弁会社「LayerX」の設立を発表しました！

jp.techcrunch.com

このブログを書いていたメンバーは、これからはLayerXとして、引き続きブロックチェーン技術の研究開発を進めていきます！
少しでもコミュニティに貢献できればと思い、今後も情報発信を続けていきますので、引き続き宜しくお願いします。

さて、ここ最近僕はState Channelに熱中しており、調査を進めてまいりましたので、何回かに分けて記事を書いていこうと思います。

第一弾の今回は、State Channelの基礎と全体像を見ていきます。

State Channelの基本

State Channelとは、一言でいえば、 特定の参加者間で「チャンネルを開き」、メインチェーンに記録しないで（オフチェーンで）状態遷移を繰り返し、最終的な状態だけ記録する技術 です。 BitcoinのLightning NetworkやEthereumのRaidenなどに代表されるPayment Channelが有名ですが、State Channelはもっと広いカテゴリで、Ethereumの場合はペイメントに限らず、任意の状態遷移をチャンネルを利用して行うことができます。例えば、etherやERC系トークン以外のデジタル資産を送ったり、賭けチェスなどをやることも可能です。

メインチェーンにブロードキャストするトランザクションを減らすことで、スケーラビリティ問題のソリューションとして期待されるだけではなく、エンドユーザーにとっては、トランザクション手数料の削減や、レイテンシーの改善と言ったメリットがあります。

基本的な流れ

詳細な仕組みは後半で触れますが、State Channelの基本的な流れは以下です。

1. チャンネルをオープンする
   特定の参加者間で、ブロックチェーンのステートの一部をマルチシグ等でロック（特定の参加者全員が合意しないと更新できない様にする）します。

2. オフチェーンで状態遷移を行う
   参加者全員の合意の元、オフチェーンの状態を更新します。

3. チャンネルをクローズする
   チャンネル内で合意された状態をブロックチェーンに提出し、オンチェーンに反映します。

また、仲介者を経由することで、直接チャンネルを開いていない相手ともやりとりできます。例えば、AliceとIngridのチャンネルとBobのIngridのチャンネルがある場合、Ingridを経由してAliceとBobはチャンネルを開くことなしに送金やチェスを行うことができます。今回はこれを"State Channel Network"と呼びます。

ユースケース

仲介者を経由しない場合、State Channelでは、チャンネルのオープンとクローズ自体はオンチェーンのトランザクションが必要であり、単発の支払いなどのやりとりでは不向きです。そのため、「特定の（増減しない）参加者間で頻繁に状態遷移が行われる」ケースで効果を発揮します。 例えば、WiFiの利用料を1分ごとに支払うケース（毎分トランザクションを発行したら大変）や、チェス（駒を動かすごとにトランザクションを発行したら大変）などが挙げられます。

仲介者を介して既存のチャンネルを有効利用する場合は、オンチェーンの状態遷移が必要なくなるので、単発のやりとりでも活用できます。こちらは、例えば、通常だとトランザクション手数料のため現実的ではないマイクロペイメントなどでも利用されます。

一方で、「途中の状態遷移を書き込まない」という特徴のため、「取引をブロックチェーン上に記録して透明性を高めよう」という類のDappでは使い方が難しいです。

State Channelのタイプ

State Channelの設計は、その用途に応じて以下の三つに分類できると思います。それぞれについて簡単な説明と、代表的なプロジェクトやチームを紹介していきます。

Payment Channel

送金ためのチャンネルです。最も歴史が長く、実装も進んでいます。

Lightning Network

言わずと知れたBitcoinのPayment Channelです。様々なチームが取り組んでいます。 Rooting and Anonymity in Lightning - Speaker Deck

Raiden

EthereumのPayment Channelプロジェクトです。全体的にLightning Networkと近い設計になっています。
多対一の一方向チャンネルのμRaidenがメインネットで動いており、双方向チャンネルは今のところテストネットで実験中のステータスです。
etherだけでなく、ERC20, 223準拠トークンにも対応しています。 開発状況をオープンにしており、参考になります。

Liquidity Network

今年6月末に双方向Payment Channelをメインネットでリリースしたと発表しました。

https://t.co/60Ymuy7MZW goes #Mainnet on @ethereum: https://t.co/fL7KvRnwM6#Free, ETH transactions are now a reality on Ethereum.

Moreover, we release an additional academic paper NOCUST. NOCUST complements our existing REVIVE paper, check it out https://t.co/dXTyjQTyBk

— Liquidity.Network (@liquiditynet) 2018年6月30日

オープンソースではなく、どこまで作り込まれているのか十分調査していないのですが、双方向Payment ChannelはEthereumとしては初です。 ブロックチェーン界隈でよく名を目にするスイス連邦工科大学チューリッヒ校のPh.Dの方が中心となったチームで、ICOも準備しているようです。

Sprites

Lightning NetworkやRaidenにおいてPayment Channel Networkを構成するために利用されるHashed Timelock Contract(HTLC)の改良案を提案しているプロジェクトです。 （別の記事で紹介します！）

Spritesを主導しているのはコーネル大学拠点のIC3という研究チームのメンバーですが、IC3には、先日プライベートプリセールで$45Mを調達した、オフチェーン計算系プロジェクトのOasis Labs（Enigmaと似たプロジェクト）を率いるDawn Songや、NiPoPoWsなど様々な論文のオーサーに名をつらねるAndrew Millerなど有名な研究者が多く在籍しています。

Enumaと言うチームがSpritesの実装を進めています。

他にも、NEOベースのPayment ChannelであるTrinityなどもあります！

Application-specific State Channel

（ペイメント以外の）特定のアプリケーションを利用するためのチャンネルです。（ペイメントもアプリケーションの一つとも言えるのですが、便宜上Payment Channelと分けました）

FunFair

ブロックチェーンを用いた、透明で公平なオンラインカジノプラットフォームを開発しています。
カジノゲームではたくさんの状態遷移を高速に（もちろん余計なガスコストなしに）行うことが望ましいため、State Channelの開発に取り組んでいます。 現在はテストネットでクローズドβ版が動いており、デモも公開されています。 State Channelでの乱数生成手法（カジノではとても重要！）も開発しています。

他にも、予測市場プラットフォームのGnosisなども取り入れていますし、ホワイトペーパーレベルでは多くのプロジェクトが提案しています。

Generalized State Channel

特定のアプリケーションに依存しないチャンネルです。細かく定義すると、「新しいアプリケーションを導入するに当たってオンチェーンでの状態遷移が必要ないチャンネル」です。
まだプロダクションで使える実装が出ているわけではありませんが、この数ヶ月でペーパーが次々に発表され、注目度が高まっている分野です。

Counterfactual

ここ数年に渡りState Channel分野をリードしてきたJeff Coleman氏が率いるL4 Mediaというチームのプロジェクトです。
「オンチェーンの処理を最小化する」という理想にもっとも忠実な、すっきりとした仕様を提案しています。
Ethereum Foundationから$1.4Mの資金援助を得ています。
先日Hi-EtherのLTで概要に関して話させていただきました。 speakerdeck.com

Perun

ドイツ人の研究者チームが進めるプロジェクトです。
実装自体にはあまり注力していない（？）印象を受けます。
Ethereum Foundationから$250Kの資金援助を受けています。

Celer Network

中国人の研究者チームが進めているプロジェクトで、Generalized State Channelに加えて、それを用いたアプリ開発のためのSDKや実行環境を開発しています。 五目並べのデモを公開しています。 www.youtube.com

ICOを準備中のようです。

他にも、実装案を公開しているチームが幾つか（Spankchain, Magmo, Connext, Machinomy）あります。
Generalized State Channelについては、次回以降の記事で解説します！

State Channelの仕組み

次は、State Channelの基本的な仕組みついて、Ethereumをベースに見ていきます。

オフチェーンの状態遷移の基礎

State Channelでのオフチェーンの状態遷移の基礎となるのは、「コミットメント」と「チャレンジ」です。

コミットメント

コミットメントとは、オフチェーンで合意された状態をチャンネルの参加者がいつでもオンチェーンで反映できるようにするものです。
例えば、Lightning Networkでは、チャンネル参加者両方が署名したcommitment txを作ることで、参加者いつでもそれをブロードキャストでき、チャンネル内で合意された送金結果をいつでもオンチェーンで確定できます。
この、「いつでもオンチェーンで反映できるが、実際には反映しないままにしておく」というのがポイントで、これによってオンチェーンの状態遷移をしなくても、チャンネル内で合意された状態遷移が実際に起こったかのように（例えば送金が実際にされたかのように）振る舞うことができます。相手が全く応答しなくなったなどの場合は、いつでもコミットメントを提出してオンチェーンで反映することができます。

Bitcoinの場合は仕様上トランザクションの形でコミットメントを作りますが、Ethereumの場合は、プログラムを書けば任意のデータ形式に対する署名を検証することができるので、コミットメントの形は自由に決めることができます。
例えばRaidenでは、下記のようなJSONフォーマットです。
（nonceがオフチェーンの状態遷移のバージョンナンバー、transferred_amountが送付されたトークン量、channel_addressはチャンネルを識別するもの、signatureがこれらへの署名）


{
   "nonce":13,
   "transferred_amount":15000,
   "channel_address":"0x87F5636c67f2Fd4F11710974766a5B1b6f33FB1d",
   （略）
   "signature":"0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"
}

コミットメントを提出する場合は、このようなメッセージをオンチェーンのコントラクトに渡します。するとそのコントラクトがメッセージの署名検証を行い、記載された内容の通りにトークンのtransferを行います。
State Channelにおける状態遷移とは、このようなメッセージを作り参加者全員で署名することです。

チャレンジ

このように、コミットメントを提出することでチャンネル内で合意された状態を確定できますが、ここで、古い（最新ではない）コミットメントが提出されてしまうという問題がおきます。
例えば、悪意のある人が、オフチェーンで送金をしたのに、送金前の状態のコミットメントを提出するということが可能です。
署名されたコミットメント自体はこの世から消すことはできないので、提出自体を防ぐ方法はありません。そのため、古いコミットメントが提出された場合に、それが古いと主張する「チャレンジ」の仕組みが必要になります。
具体的には、

• コミットメントが提出された場合、その内容をすぐに反映するのではなく、ブロック数などで定められた一定のチャレンジ期間待つようにする
• 期間内にそれより新しい（例えばバージョンナンバーが大きいなど）コミットメントを提出すれば、古いコミットメントを却下する
• チャレンジ期間が終了したら、提出された最も新しいコミットメントの内容をオンチェーンに反映する

というものです。
また、古いコミットメントを提出したと証明された場合は、提出者のデポジットを没収するなどのペナルティを設計することもできます。

基本プロトコル

次に、State Channelの一般的なプロトコルを説明します。

Open: チャンネルをオープンする

チャンネルにデポジットします。デポジットは、参加者全員の署名がないと動かせないようにします（ロック）。

Update: オフチェーンでの状態遷移

オフチェーンの状態を参加者全員の合意のもと更新して行きます。コミットメントを作り全員で署名します。

Cooperative Close: 協力的クローズ

全員の合意のもと、ステートのロックを解除し、オフチェーンのステートをオンチェーンに反映します。 次の一方的クローズとは異なり、オンチェーンに即時反映されます。

Uncooperative Close: 非協力的クローズ

協力的クローズとは異なり、全員の合意なしにオフチェーンの状態をメインチェーンで主張することです。
通常は協力的クローズができることが望ましいですが、相手が応答しなくなった（オフラインになったなど）のときに、チャンネルから資産を引き出すべく用いられます。
例えば賭けチェスをしていて相手が負けそうになって逃げてしまった、といったケースでこれが考えられます。

Challenge: チャレンジ

古いコミットメントが提出された場合に、それより新しいコミットメントを提出することで、最新ではない状態がオンチェーンで反映されるのを防ぎます。

Splicing: スプライシング

チャンネルをクローズすることなしに、デポジットした資産を引き出したり、追加で資産をデポジットすることです。 これによって、元々予定していた額以上を送金するべくデポジットを増やしたい！といった場合に、チャンネルを閉じて開きなおすのに比べて低コストで済みます。

補足

チャンネル・デポジット管理の設計

チャンネル・デポジットの管理の設計方法として、大きく分けて二つの方針があります。

1. マルチシグコントラクトを作る
   チャンネル毎にマルチシグウォレットの仕組みを持つコントラクトを作る方法です。
   一般的なマルチシグウォレットに備わっているようなロジックを用いてチャンネルのデポジットを管理します。（ちなみに: Ethereumでのマルチシグウォレットの設計については、Gnosisのものなどが詳しいです。）

2. グローバルのコントラクトを共有する ブロックチェーン上に1つだけあるコントラクトを、全てのチャンネルで共有する方法です。
   一つのコントラクトに全てのチャンネルのデポジットをまとめて所有させ、各チャンネルにおいて誰がいくらデポジットしたのかはストレージで管理します。 参考: Raidenの実装例

2の場合はコントラクトのデプロイにかかるガスコスト（gas cost: 32000）を節約できます。Raidenは元々マルチシグコントラクトを用いる方針だったのですが、ガスコスト削減のため、トークンの種類毎にグローバルのコントラクトを予めデプロイしておいてそれを共有する方式に変更しました。

github.com

とはいえ、グローバルのコントラクトを用いたとしてもストレージの書き換え処理が発生するので、どちらが良いかはケースバイケースです。

マルチシグコントラクトを用いる場合、デポジットは単純にそのマルチシグにetherやトークンを送るだけなので、「任意のステートをデポジット可能にする」と言ったことが比較的簡単に実装できます。（今後仮にERC2000という仕様が出たとしても同じマルチシグでデポジットできるなど） Counterfactualではマルチシグコントラクト方式が採用されています。

協力的/非協力的とは

チャンネルのクローズ方法には、参加者全員がクローズに合意してやる協力的クローズと、参加者の誰かが勝手に行う非協力的クローズがあります。
協力的クローズの場合、全員が最新の状態を合意するので、チャレンジの期間は必要なく、通常はこちらを使います。
例えばRaidenの場合、最終状態、クローズしますという内容のコミットメントを作ってそれを提出するクローズ方法を用います。

相手が応答しなくなったなどの場合、この合意が得られないので、非協力的クローズを行います。
この場合、既に作ってあるコミットメントを提出するのですが、本質的にそれが最新のコミットメントなのか区別ないので、前述したチャレンジ期間が伴います。

クローズと同様に、スプライシングにも、チャレンジ期間なしで協力的にできるようにする設計方法があります。

他のオフチェーン技術との比較

最近Twitter上でVladとVitalikが議論したこともあり、State Channelと他の技術の違いについてはよく話題になることがあります。

PLASMA IS NOT A STATE CHANNEL!!!!!

State channels have instant updates because they progress through unanimous consent and do not require on-chain hashes. Plasma does not.

I prefer "counterfactual state transition system" to cover both.

— Vitalik "Not giving away ETH" Buterin (@VitalikButerin) 2018年6月8日

オフチェーン技術の中でも、State Channelは、サイドチェーン、Plasmaと共に「オフチェーンで状態遷移をするもの」に含まれ、今回はこれらの違いについて考えてみます。

サイドチェーンとの違い、Plasmaとの共通点

まず、PlasmaとState Channelには、サイドチェーンにはない共通点があります。 それは、オフチェーンの状態遷移とメインチェーンの状態遷移が直接連動せず、オフチェーンの状態遷移をメインチェーンに反映する（Vlad氏は"Settlement"と呼んでいる）明示的な作業があることです。
オフチェーンにデポジットした資産を引き出すとき、Plasmaの場合はメインチェーンのコントラクトに出金依頼をしますし、State Channelの場合はチャンネルのクローズ（または合意の元での中間的な引き出し）をします。

加えて、この引き出しのタイミングでチャレンジをすることができ、オフチェーンでの状態遷移メカニズムに問題があった場合もデポジットした資産を守ることができます。
つまり、PlasmaとState Channelには「セーフティネット」があるといえます。一方、サイドチェーンの状態遷移メカニズムが崩壊した時、メインチェーンの資産を守る方法はありません。

Plasmaとの（実用上の）違い

Plasmaの状態遷移はあくまでブロックチェーン上で行われます。したがって、Dappなどで実際に使う場合、State ChannelはPlasmaと以下のような違いがあります。

1. 固定された参加者間のやりとりに関してしか適用できない やりとりするユーザーが増えたりする場合は新しくチャンネルを開き直すなどオンチェーンの処理が必要になります。

2. オフチェーンでの状態遷移は参加者全員の同意を必要とする チャンネル参加者の誰かが応答しなくなった場合はオフチェーンの状態遷移は進みません。

3. ブロック生成を待つ必要はない Plasmaのようにブロックチェーンで状態遷移するわけではないため、ブロックに取り込まれるのを待つ必要はありません。

4. 途中の状態は記録されない Plasmaは少なくともPlasmaチェーンに全て記載されます。

このような違いのため、PlasmaとState Channelはユースケースが異なると思います。 また、チャンネルの開閉に伴うトランザクションに伴う手数料やレイテンシーがクリティカルなケースでは、PlasmaチェーンでさらにState Channelを使うなどが考えられます。

最後に

今回の記事では、State Channelの基本と全体像をつかむべく、基本から始まり、他のオフチェーン技術との比較を行いました。 State Channelは、Dapp開発では多くのケースで利用が検討できるので、ぜひ注目して行ってください！

間違いの指摘やご質問も歓迎していますのでTwitterなどでご連絡お願いしますmm

（余談）
最近、Master workshop: off the chainというイベントがベルリンで開催されました。 https://binarydistrict.com/workshop/master-workshop-off-the-chain/

State Channel分野の代表的なチームのほぼ全てが参加していると言っても過言ではない豪華なスピーカーたちによりトークが行われた（行きたかった。。。涙）ようで、 YouTubeに動画が上がっているので、こちらも是非チェックしてください。

www.youtube.com

宣伝

LayerXではブロックチェーン技術の研究・開発を進めており、メンバーを募集しています。

少し話を聞いてみたい！という方も歓迎していますので、下記のリンクからの応募お待ちしております。

www.wantedly.com

また弊社では、blockchain.tokyo を主催しています。

イベントグループへメンバー登録をしていただくとイベント参加者募集の通知が来るので、こちらもぜひ登録してみてください。

blockchain-tokyo.connpass.com