State Channel 最前線

CONFIDENTIAL : copyright © by 2018 LayerX Inc. all rights reserved.
1
State Channel 最前線
2018-10-24
@veryNR

View Slide

2
自己紹介
● LayerX Inc.
○ R&Dチーム
● やっていること
○ Vyper
○ Formal Verification
○ zk-snarks
Twitter: @veryNR
GitHub: nrryuya
Ryuya Nakamura

View Slide

3
LayerX R&D Team
ポリシー
● キャッチアップで終わらない
● 全てオープンにやる
● 専門家じゃないけど頑張る
リサーチテーマ
● zk-sn[t]arks
● Formal Verification
● Vyper(半分趣味)
ScrapBoxにレポート書いているよ!
https://scrapbox.io/layerx/
●
基礎技術の深い理解とブロックチェーンへの応用の模索

View Slide

4
やったこと
VyperによるPlasmaの実装
https://github.com/LayerXcom/plasma-mvp-vyper

View Slide

5
やったこと
Remix用のVyperプラグイン
https://github.com/LayerXcom/vyper-remix

View Slide

6
やったこと
GoでのTinyRAMのエミュレータ実装
https://github.com/LayerXcom/gram
TinyRAMはSNARKsのサーキットに変換しやすい計算モデル

View Slide

7
やっていること
[WIP] KEVMを使ったPlasmaコントラクトのFormal Verification
https://github.com/LayerXcom/verified-smart-contracts

View Slide

8
1：基本と全体像
3：Generalized State Channel
今日話すこと
4：最近の話題
5：今後の予想
2：より深い基礎

View Slide

9
1. State Channelの基本と全体像

View Slide

10
Ethereumのインフラ系プロジェクト
Layer1
● Casper(PoS)とShardingの合体 → Shasper
● EVMに代わるeWASMはテストネット開始
Layer2
● Plasmaの分化と発展
○ Minimal Viable Plasma → More Viable Plasma
○ Plasma Cashの各種改善
○ Smart Contracts in Plasma (e.g. Plasma Leap)
○ Plasma ❤ zk-snarks (e.g. Plasma Snapp)
● あれ、State Channelは？
○ 今日話します

View Slide

11
State Channelとは?
●
オフチェーンで状態遷移をして最終結果だけ書き込む方法
ハブ
チャネルチャネル
● 基本の流れ
1. チャネルをオープン: ステートをマルチシグでロック（デポジット）
2. コミットメント: オフチェーンで状態遷移
3. チャネルのクローズ: オンチェーンに結果を反映
● 「中継」することで直接チャネルを開いていない相手ともやりとり可能

View Slide

12
State Channelとは?
● マルチシグ
○ アセットをマルチシグでロック
● コミットメント
○ オフチェーンでやり取りに関するメッセージに全員で署名
○ マルチシグを介してオフチェーンの状態を「いつでもオンチェーンで反映でき
る」ようにする
● チャレンジ
○ 古いコミットメントの提出は防げない
○ 新しいコミットメントを提出することで無効化
●
マルチシグ・コミットメント・チャレンジが基本的な仕組み

View Slide

13
State Channelの分類
● Payment Channel
○ ether、ERC20系トークンの送金
○ e.g. Lightning Network, Raiden, Liquidity Network
● Application-specific Sate Channel
○ 特定のアプリケーションに特化したチャンネル
○ FunFair, Magmo
● Generalized State Channel
○ アプリケーションに依存しないチャンネル
○ Counterfactual, Celer Network, Perun
●
Ethereumの場合Payment以外のステートにも適用できる

View Slide

14
State Channelの分類
●
Ethereumの場合Payment以外のステートにも適用できる
● Payment以外のチャネルも実はシンプルで、コミットメントの中身が変わるだけ
● コミットメントの作り方は大きく二通り
○ コントラクトの関数呼び出しトランザクションに署名する
■ マルチシグがデポジットを預かり、このトランザクションの実行者となる
○ コミットメントのフォーマットを決めておき、オンチェーンのコントラクトがそれをパース
して実行する(もちろん署名は必要)
■ Raidenだと以下のようなJSON
{
"nonce":13, "transferred_amount":15000,
"channel_address":"0x87F5636c67f2Fd4F11710974766a5B1b6f33FB1d",
（略）
"signature":"0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"}

View Slide

15
※Plasmaとの比較
● 似ているところ
○ メインチェーンの状態遷移とは別に(より速く)状態遷移
○ デポジット・エグジット（・チャレンジ）などの概念
○ 階層化できる
● 違うところ
○ そもそもPlasmaは「別のブロックチェーン」
○ 参加者全員が同意(署名)することで状態遷移する
●
Plasmaとは異なる「全会一致での」状態遷移

View Slide

16
注意点
● Non-Fungibleなアセットは仲介できない
○ 多くのDappではState Channel Networkが使えない
● 固定された参加者セットで沢山のやり取りがある場合に使う
○ 参加者は増減できない
○ チャンネル開閉の2 txはどうしても必要
● 途中の過程は(通常)書き込まれない
○ 「取引の過程をオープンにして透明性をhogefuga」系のDappでは使いにくい
○ 後からトラストレスに取引の過程を記録することは理論上可能ではある
● サブスクリプション型サービスの支払い、賭けチェス, etc.

View Slide

17
2. より深い基礎

View Slide

18
“Counterfactual” という概念
● “Counterfactual X”とは、以下が満たされていること
○ 「Xがオンチェーンで起きるが、まだ起きていない」
○ 「参加者の誰でも一方的にXをオンチェーンで起こせる機構がある」
○ 「参加者がXが実際に起こったかのように振る舞うことができる」
● 取引情報に全員が署名する（コミットメント）ことでその取引はCounterfactualに
なる
○ Lightning Networkはトランザクション自体に署名
○ Raidenはjsonデータに署名 & オンチェーンに署名検証のロジック
●
L4が提唱したState Channelの状態遷移の本質的な概念

View Slide

19
State ChannelのAssumption
Assumption: 参加者の行動に関する仮定
→これがないとプロトコルの議論はできない
● ブロックチェーン自体のliveness
○ ここはその他Layer2のAssumptionと同様
○ e.g. 検閲耐性: 特定のチャネルのtxだけ排除されたらダメ
● 参加者のavailability
○ チャネル内の最新のコミットメントを保持し続けること
○ 状態遷移のたびに応答してコミットメントができること
○ ブロックチェーンに常にアクセスでき、チャレンジ等が行えること
○ (Layer1では秘密鍵さえ管理しておけば問題なかった)
※他にも、外部インセンティブなどもassumptionに入ることがある
●
ユーザーの比較的強いavailabilityが前提

View Slide

20
State ChannelのAssumption
● availabilityのassumptionを緩和するためのプレイヤー
● 古くはLightning Network文脈で提案された”Watchtower”が有名
● Pisa: 2018年5月頃提案された、Watchtowerを改善したプロトコル
○ ステートのハッシュだけを預けることでプライバシー向上
○ 公平でリアルタイムの報酬
○ カストディアンが責務を果たさなかった場合の懲罰
● あくまでassumptionの変更であることに注意
○ 脅威モデルを修正して議論する必要がある
●
チャネル監視の代行サービスの必要性

View Slide

21
State Channelエコシステム
バックアッ
プ
ハブ
監視
● ウォレット/クライアントアプリ
● 監視サービス
○ 古いコミットメントの提出
○ 監視とチャレンジを代行
● バックアップサービス
○ 端末故障時等に備えコミットメントを保管
○ 暗号化して保管
● ネットワーク系サービス
○ ハブ
○ ルーティング
●
プロトコルの発展の他に、実用上は様々なプレイヤーが必要

View Slide

22
攻撃ベクター
● Unavailability
○ Aliceが「Bobが反応しない」と主張した時、ブロックチェーンは本当か嘘か判
断できない
○ 具体的には、非協力的なチャネルのクローズで対処に悩む
● Posting Stale State
○ 古い状態もCounterfactualのまま残ってしまう
○ Challengeの仕組みが必要
■ 提出された古いコミットメントに対し新しいコミットメントを提出すれば良い
■ コミットメントにバージョンなどの内容が必要
●
Unavailability & Posting Stale State

View Slide

23
※Plasmaとの比較(再)
Snapp以前のPlasma (MVP, Cash, etc.)と比べると、
● より強いavailability assumption
○ 監視するだけではなく、毎回の状態遷移に関して署名
● 保持するデータは少ない
○ 最新のコミットメントさえ持っておけばそれより古い状態の提出は全てチャレン
ジできる
●
Plasmaとはassumptionがかなり異なる

View Slide

24
3. Generalized State Channel

View Slide

25
Generalized State Channel
● 厳密には「新しいアプリケーションを導入するとき、オンチェーンの操作が特に必
要がない」チャネル
○ 既に別の目的で開いてあるチャネルを他のアプリケーションを利用する時に
活用できる
● Perun, Celer Network, Counterfactual
● 以降のスライドはL4によるCounterfactualフレームワークを元に説明します
●
アプリケーションに依存しないチャネル

View Slide

26
How to “generalize” channels?
● チャネル内で以下の状態遷移が出来れば良い
○ 1. 新しいアプリケーションの導入
○ 2. 導入されたアプリケーションの利用
● つまり、以下のコミットメントが作れれば良い
○ 1. コントラクトのデプロイ
○ 2. そのコントラクトのコール
● 問題は「まだデプロイされていないコントラクトAへのコールtx」をどう作るか
●
“generalize”を実現するコミットメントは2種類

View Slide

27
Counterfactual Instantiation
● 問題: デプロイされないとアドレスはわからない
→ アドレスがわからないとコールするコミットメントは作れない
● 解決策: デプロイせずに決定的に決まる値で参照する
○ 具体的には、keccak256(バイトコード, マルチシグのアドレス)
○ Counterfactual addressと呼ぶ
● オンチェーンのRegistryコントラクトが、Counterfactual addressと実際のアドレスの
mappingを記録する
■ deploy() : デプロイと同時に実際のアドレスとのmappingを記録
■ resolve(): Counterfactual addressから実際のアドレスを取得
●
オフチェーン（チャネル内）で「デプロイ」する方法

View Slide

28
Counterfactual Instantiation
1. デプロイのコミットメント →
● Registryコントラクトのdeploy()をコールするコミットメント
2. そのコントラクトのコール
● Registryコントラクトのresolve()で解決したアドレスのコントラクトをコールするコミッ
トメント
● Ethereum Name Serviceと近い

View Slide

29
マルチシグウォレット
● Counterfactualでは、チャネルのオープンに必要なのは、チャネル参加者をオーナーと
するマルチシグウォレットのみ
○ ※Registryコントラクトは全世界で使い回し
● 役割1: チャネル内資産のロック
○ マルチシグが保有できる任意のステートをデポジット可能
■ ether, ERC系トークン等
● 役割2: 各種コミットメントの実行ロジック
○ executeTransaction関数をもつ
■ 署名されたコミットメントを受け取り任意の関数を実行する
○ DELEGATECALL/CALLによりオフチェーンの状態をCounterfactualにする
●
マルチシグウォレットのみがチャネル毎に必要

View Slide

30
基本プロトコル
Instantiate
Registry経由でのデプロイにコミット
CommitWithdrawal
Counterfactual objectのstateを参照した引き出しにコミット
Update
Counterfactual objectのstateの更新にコミット

View Slide

31
余談: Meta Channel
● 各中継チャンネルでAlice-Bob Payment Objectの残高のProxy Objectへの反映をコ
ミット
○ 仲介者にデポジットしてもらってその範囲で自由に使うイメージ
● 一般的なHTLC方式と異なり状態遷移ごとに仲介者に協力してもらう必要がない
○ 賭けチェスなどでは便利
●
Counterfactualにおける仲介の仕組み

View Slide

32
4. 最近の話題

View Slide

33
標準化
●
L4を中心とした、State Channel技術の標準化の流れ
● State ChannelにはLightning NetworkのBOLTのようなものがない
● 標準化により、各コンポーネント開発の責務が分担される
■ Dapp(コントラクト)開発者
■ ウォレット
■ web3, SDK, etc.
● 具体的には以下の標準化
○ プロトコル
○ チャネル内コントラクトのAPI
○ 用語
● 今年8月、L4とCelerが提携を発表

View Slide

34
プロトコルの議論
● ZK-SN[T]ARKSのState Channelへの応用
○ disputeにzk proofを使う
■ Generalizedだとdispute時のコストが大きい
● 沢山のコントラクトのデプロイ、それぞれのstorage書き換え
○ 「チャネル内の履歴残らない問題」に活用できるかも
● State Channel Network関連の提案がいくつか出ている
○ 仲介者の資産のロック期間を超える方法
■ https://ethresear.ch/t/channels-can-enforce-contracts-beyond-interme
diary-lockup-time/2941
○ Forward Timelockd Contracts(FTLC)
■ ハッシュとプリイメージを利用しない仲介方法
■ Grantで1チーム採択された
■ https://ethresear.ch/t/forward-timelocked-contracts-ftlc/3264
● 形式的検証
○ UCモデルなど

View Slide

35
5. 今後の予想

View Slide

36
State Channelの特徴
●
Plasmaより高速な状態遷移、複雑なコントラクトの導入も容易
● Plasmaに対する利点
○ ブロックチェーンではないのでマイナーに依存しない
■ ブロック生成を待つ必要がない
■ 携帯ゲームの通信対戦のように、P2P通信で完結し、高速
○ スマートコントラクトの導入が用意
■ Smart Contract in Plasmaの道のりは険しい
● Plasma Leapなどはあるが。。。
■ 特に、Optimisticなケースでは圧倒的に優位
● コントラクトのデプロイが不要
● State Channel in Plasmaは将来的には可能性あるが、Plasmaで
出来ること以上のことは当然チャネル内でも出来ない

View Slide

37
State Channelのユースケース
● 有名なユースケースはペイメントとゲーム
● 鍵は”Conditional Payment”
○ 特定参加者の複雑な金融的契約
■ コントラクトのデプロイなしに複雑な契約ロジックを導入でき、
問題が起きなければそのままデプロイ不要
○ 例: オンチェーンのオラクルを使った保険
■ 注: チャネル内でオラクルの結果使うこともできます
○ 例: スワップ取引

View Slide

38
今後の予想
●
ユースケースに応じプロトコルの分化が進むと思われる
● State Channelのアーキテクチャにはトレードオフがある
● 変数: LockTime, Gas Cost, UX, etc.
○ それぞれ、平常時と問題発生時で大きく異なる
■ e.g. Counterfactualは、平常時はオンチェーンでマルチシグ
ウォレットのデプロイだけで済むが、問題発生時は沢山のコ
ミットメントを提出する
● ユースケースにより異なる
○ DappによってどれくらいPessimistic(Optimistic)かは異なる
■ 例: 法人同士で使うチャネルの方がネットの匿名の相手との
チャネルよりOptimistic

View Slide

39
最後に
間違いのご指摘やご意見は @veryNRまでお願いします

View Slide

State Channel 最前線

State Channel 最前線

Ryuya Nakamura

More Decks by Ryuya Nakamura

Other Decks in Technology

Featured

Transcript