Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
State Channelエコシステムと実用上の課題
Search
Ryuya Nakamura
July 24, 2018
Technology
3
4.4k
State Channelエコシステムと実用上の課題
Ryuya Nakamura
July 24, 2018
Tweet
Share
More Decks by Ryuya Nakamura
See All by Ryuya Nakamura
AIオンボーディングとAIプロセスマイニング
nrryuya
5
1.6k
アルファを作る人になる
nrryuya
0
300
学生時代のキャリア探索の心がけ
nrryuya
0
210
フィードバックされやすい人になろう
nrryuya
31
22k
間違いが許されなくてもLLMが使えるユースケースとは @GenAI Playground Meetup #01
nrryuya
13
6.2k
20240725 LLMによるDXのビジョンと、今何からやるべきか @Azure OpenAI Service Dev Day
nrryuya
4
2.5k
「知的単純作業」を自動化する、地に足の着いた大規模言語モデル (LLM) の活用
nrryuya
9
13k
20240130 エンプラDXにおける2024年の生成AIトレンド予測 @生成AI新年会2024
nrryuya
2
2.3k
20240125 開発側・ビジネス側という壁を作らない LLMアプリ開発 @生成AI Conf
nrryuya
8
4k
Other Decks in Technology
See All in Technology
kubellが挑むBPaaSにおける、人とAIエージェントによるサービス開発の最前線と技術展望
kubell_hr
1
310
自分を理解するAI時代の準備 〜マイプロフィールMCPの実装〜
edo_m18
0
110
doda開発 生成AI元年宣言!自家製AIエージェントから始める生産性改革 / doda Development Declaration of the First Year of Generated AI! Productivity Reforms Starting with Home-grown AI Agents
techtekt
0
160
Create a Rails8 responsive app with Gemini and RubyLLM
palladius
0
120
マルチテナント+マルチプロダクト SaaS への AI Agent の組み込み方
kworkdev
PRO
2
350
データ戦略部門 紹介資料
sansan33
PRO
1
3.2k
工具人的一生: 開發很多 AI 工具讓我 慵懶過一生
line_developers_tw
PRO
0
200
「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの 考え方・育て方 / Cursor Rules for Coding Styles, Domain Knowledges and Operations
yuitosato
6
1.8k
TODAY 看世界(?) 是我們在看扣啦!
line_developers_tw
PRO
0
210
宇宙パトロール ルル子から考える LT設計のコツ
masakiokuda
2
100
AWS と定理証明 〜ポリシー言語 Cedar 開発の舞台裏〜 #fp_matsuri / FP Matsuri 2025
ytaka23
9
2.5k
成立するElixirの再束縛(再代入)可という選択
kubell_hr
0
290
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
BBQ
matthewcrist
89
9.7k
Agile that works and the tools we love
rasmusluckow
329
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
123
52k
The Cost Of JavaScript in 2023
addyosmani
50
8.4k
Practical Orchestrator
shlominoach
188
11k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Transcript
State Channelエコシステムと実用上の課題 @veryNR 2018.7
2 ©Gunosy Inc. 自己紹介 中村龍矢 @veryNR ▪ Gunosy Inc. –
データ分析部 2017年2月~ • 動画配信ロジックの開発など • Python, Go, SQL – 新規事業開発室 2018年6月~ • ブロックチェーン技術の研究 ▪ 経歴 – Coubic株式会社 • 営業をやっていました – 日本ヒューマンビートボックス協会 • お手伝い – 東京大学工学部システム創成学科 • 休学中
3 ©Gunosy Inc. 目的とアジェンダ ▪ State Channelとは ▪ State Channelのエコシステム
▪ ユースケース – 利用時の注意点 – 具体例 ▪ 実用上の課題 – UX上の課題 – 開発上の課題 State Channel界隈の現状と実利用について考える
4 ©Gunosy Inc. State Channelとは
5 ©Gunosy Inc. State Channelとは ▪ 基本の流れ 1. チャンネルをオープンし、ステートをマルチシグでロック(デポジット) 2.
オフチェーンで状態遷移(コミットメント) 3. チャンネルのクローズ、オンチェーンでの反映 ▪ Payment Channelが有名 – Lightning Network, Raiden Network ▪ Ethereumの場合Payment以外のステートにも適用できる – オンラインカジノ、チェス、etc. – 汎用ステートチャネル(Generalized State Channel)もある オフチェーンで状態遷移をして最終結果だけ書き込む方法
6 ©Gunosy Inc. Application-specific State Channel: FunFair https://showcase.funfair.io/
7 ©Gunosy Inc. State Channelとは ▪ マルチシグ – アセットをマルチシグでロック ▪
コミットメント – オフチェーンでやり取りに関するメッセージに全員で署名 – マルチシグを介してオフチェーンの状態を「いつでもオンチェーンで反映できる」ようにす る ▪ チャレンジ – 古いコミットメントの提出は防げない – 新しいコミットメントを提出することで無効化 マルチシグ・コミットメント・チャレンジが基本的な仕組み
8 ©Gunosy Inc. State Channelとは https://blockchain.gunosy.io/entry/state-channel https://blockchain.gunosy.io/entry/counterfactual 詳細はこちら
9 ©Gunosy Inc. State Channelのエコシステム
10 ©Gunosy Inc. State Channelのエコシステム State Channelの実用化には様々なサービスが必要 ▪ ウォレット/クライアントアプリ ▪
監視サービス – 古いコミットメントの提出 – 監視とチャレンジを代行 ▪ バックアップサービス – 端末故障時等に備えコミットメントを保管 – 暗号化して保管 ▪ ネットワーク系サービス – ハブ – ルーティング バック アップ ハブ 監視
11 ©Gunosy Inc. State Channelのエコシステム ▪ Lightning Networkより発展していない – 双方向ペイメントが最近やっとメインネットで動いたくらい
– BOLTのような標準仕様なし ▪ ICOによる(?)垂直統合の研究開発スタイル – ICOトークンのエコシステムを設計しないといけない – 結果としてプロトコルレイヤーからサービスレイヤーまで担当 Ethereumにおいてはまだまだ未成熟
12 ©Gunosy Inc. State Channelのユースケース
13 ©Gunosy Inc. State Channelのユースケース ▪ Non-Fungibleなアセットは仲介できない – 多くのDappではState Channel
Networkが使えない ▪ 固定された参加者セットで沢山のやり取りがある場合に使う – 参加者は増減できない – チャンネル開閉の2txはどうしても必要 ▪ 途中の過程は(通常)書き込まれない – 「取引の過程をオープンにして透明性を hogefuga」系のDappでは使いにくい • 後からトラストレスに取引の過程を記録することは理論上可能 ▪ サブスクリプション型サービスの支払い、賭けチェス , etc. 利用時の注意
14 ©Gunosy Inc. State Channelのユースケース ▪ 必要なやり取りの例 – レンタル注文→承諾/拒否 –
キャンセル→承諾/拒否 – レンタル延長→承諾/拒否 ▪ デポジットするアセット – 借りる側: 支払い用のトークン – 貸す側 : 車のデジタル所有権 カーシェアリングのDappの例 http://news.livedoor.com/article/detail/9038214/ デジタル資産の取引はなんだかんだ沢山のやり取りが必要 → 意外と多くのケースで利用可能(かも)
15 ©Gunosy Inc. 実用上の課題
16 ©Gunosy Inc. State Channelの実用上の課題 ▪ チャンネルの開閉はオンチェーン – レイテンシー・手数料 ▪
問題発生時にユーザーの手間が増える – 相手が応答しなくなったことに気づいてコミットメントの提出 – 監視・バックアップサービスとのやり取り ▪ コミットメント作るために毎回署名 – チェスで一手ごとにパスワード入力 – アプリ利用ごとに一時的な鍵を作って登録するなどの提案もある ▪ デポジット – 事実上の先払い – デポジット額の悩み「もしかしたら延長するから多めに入れとこう」 現状はユーザーがState Channelをかなり意識することが多い
17 ©Gunosy Inc. 最後に ▪ ペイメント以外のState Channelの実利用はかなり先になりそう ▪ とはいえ多くのDappで検討する意義はある 間違い等あれば是非@veryNRまでお知らせください