Slide 1
Slide 1 text
GORMOS
Hi-Ether Meetup #7 Fukuoka
2018.8
DMM.com スマートコントラクト事業部 篠原航
A high performance and scalable design for decentralized applications
Slide 2
Slide 2 text
自己紹介
篠原航
DMMスマートコントラクト事業
部テックリード。計算リソース
の効率化、継続的デリバリや
デプロイの開発を支える仕組
み作り、ウォレットの実装を担
当。夏が苦手。
https://www.amazon.co.jp/dp/4839965137/
Slide 3
Slide 3 text
本日のアジェンダ
● GORMOSとは
● GORMOSの設計
● GORMOSの課題
Slide 4
Slide 4 text
前提、Ethereumの現状
● Scalability ->
● Latency ->
● Gas Cost ->
Slide 5
Slide 5 text
前提、DEXの妥協
● KyberNetwork
○ 指値、レバレッジ、高頻度取引がない
● 0x, EtherDelta
○ オンチェーンのセキュリティを犠牲
● ex. Binanceは40,000 TXs/s
DEX
勝ち目なし
Slide 6
Slide 6 text
GORMOSとは
GORMOSの設計
GORMOSの課題
Section01
Section02
Section03
Slide 7
Slide 7 text
GORMOS ?
● 6/18にWhite Paper Draft公開
● Loi Luu, Yaron Velner, Alex Xiong at KyberNetwork
● SecurityとScalabilityの両立
● 数百万 TXs/sで低レイテンシ
● アプリケーション特化で高速なtx処理を実現
○ 応用範囲 = DEX, Game, Payment and Social Network
https://www.dropbox.com/s/y9a36dqcl0vbf0d/gormos.pdf
Slide 8
Slide 8 text
Scalable
● Plasmaによるスループット向上
● Plasmaによる安価tx fee
● Shardingによるスケールアップ
○ Low Latency
○ 4-5秒以下のブロック生成
Slide 9
Slide 9 text
Secure and Decentralized
● Plasmaと一緒で不正があったらサイドチェーンからexitできる
● fraud proofも出せる
Slide 10
Slide 10 text
Interoperability
● 異なるブロックチェーン間のやりとりに利用可能
● Shardごとにユーザー認証などを持たせることも
○ ex. KYCが必要なToken
BTC ETH
Slide 11
Slide 11 text
GORMOSとは
GORMOSの設計
GORMOSの課題
Section01
Section02
Section03
Slide 12
Slide 12 text
設計方針
● PlasmaとShardingのいいとこ取りをする
● 線形なScallingを実現
● ただしShardが相互作用を滅多に起こさない場合にのみ有効
Slide 13
Slide 13 text
他の解決方法は？
● 階層型Plasma
○ Plasma on Plasma
○ = Security trade-off on Security trade-off
● Sharding
○ Shard間通信が問題
● Payment Channel
○ Globalなオーダーブックが実現不可能
Slide 14
Slide 14 text
System Architecture
So Gormos is inspired by sharding in centralized systems very much.
人力シャード？
ex. Blog, Online
Game
Slide 15
Slide 15 text
Shardの分離指針
● Trading Pairを異なるShardに分離
○ ex. ETH / KNC と BTC / OMG は相互に影響がない
● 新しくTrading Pairを増やす時はShardを作成する
○ 既存のShardに影響しない
● ShardingでPlasmaを拡張
ETH / KNC
BTC / OMG
Slide 16
Slide 16 text
Main Shard and Local Shard
● Main Shard
○ Local Shardの処理結果を取得、集約
○ 基軸通貨(ETH, BTC)を処理
● Local Shard
○ 設定されたToken Pairの取引を処理
Slide 17
Slide 17 text
Use Case
● 基軸通貨はMain Shardで処理してからLocal Shardに移動
● Shard間通信が走るのは基軸通貨を移動する時のみ
○ 必ずメインシャードを通して移動する
● Local Shardでは複数pairを扱わない
○ リスクの分離
○ ex. コントラクトのバグなどで特定のトークンの取引を停止
Slide 18
Slide 18 text
Use Case(Game and Social Network)
● ex. Etheremon
○ 各ジムをShardに分ける
● 分散Uber
○ 各地域をShardに分ける
Slide 19
Slide 19 text
登場人物
● Consensus Validator
● Shard Inspector
● Validator Pool
Slide 20
Slide 20 text
Consensus Validator
● Shard内の合意に関与
● Local Shardごとに20ほど必要
○ Confirmationを2秒にする場合
○ 溢れた場合はShard Inspectorに
● 登録にはKNCが必要
○ デポジットを下げて大量に雇用
○ 公開市場で一定数バリデータ数のみを許可
tx承認します
Slide 21
Slide 21 text
Shard Inspector
● 不正を検出し、データの可用性を保証する役割
● Consensusに参加していない
● Shardのブロックを全て持つフルノードのようなもの
● データは一般に公開されているので誰でも不正報告ができる
○ ユーザーは常にオンラインでなくても良い
ブロックデータ
教えます
Slide 22
Slide 22 text
Validator Pool
● Shard Inspector -> Consensus Validator
● Consensus Validator -> 別ShardのShard Inspector
● Shard InspectorはすぐにValidatorとして活動できる
○ Sharding v1 specのlookahead periodみたいなもの
● Root ChainのBlock Hashを元にVRFかRandHoundでローテート
Another Shard
実際にはGORMOSがローテートを行う
のですが、簡略化してます
Slide 23
Slide 23 text
Interoperability
● PeaceRelay
○ EVM baseのTokenをEthereumに入れたり出したりできる
● Trustless Custodian approach
○ ETHやERC20などを担保にBTC Tokenを作成する保管人を用意
● MakerDao’s approach
○ ETHをBTC Tokenを作成するための担保として使用
○ 担保を超えなければ安定する
Slide 24
Slide 24 text
Tx Format
(addr, shard id, src token id, des token id, order type, src amount,
fee, metadata, nonce)
Slide 25
Slide 25 text
Block Format
● Local Block Format
○ (shard id, block number, prev block hash, new order merkle
root, balance merkle root, avail balance merkle root, open
order MMR root, closed order MMR root, cancelled order
MMR root, timestamp, signatures)
Slide 26
Slide 26 text
Block Format
● Main Block Format
○ (block number, prev block hash, new local headers merkle
root, new order merkle root, balance merkle root, avail
balance merkle root, open order MMR root, closed order
MMR root, cancelled order MMR root, timestamp, signatures)
Slide 27
Slide 27 text
MMR ?
Slide 28
Slide 28 text
Merkle Mountain Range
● https://github.com/opentimestamps/opentimestamps-server/blob
/master/doc/merkle-mountain-range.md
● Mekle treeを効率的に更新できるデータ構造
● 最新ブロックのMMRのみで前のブロックに含まれるtxを検証可能
Slide 29
Slide 29 text
Consensus Argorithm
● HoneyBadger BFT を検討
○ 64 Nodeで 12,000 TXs/s
● 各Local Shardは非同期にブロックを生成して送信
● Main Shardはその時に取り込み可能なブロック全てを記録
Slide 30
Slide 30 text
Fraud Proof
● Shard Inspectorに問い合わせ
● 不正ブロックとその前のブロックをMain Chainに提出
● 一定期間内にValidatorが正当なtxを出せない場合exitする
● もしもmass with-draw(mass exit)しても他のShardに影響しない
Slide 31
Slide 31 text
Incentive
● Validator
○ tx fee
● Inspector
○ Validatorの候補生
○ fraud proofからの手数料
Slide 32
Slide 32 text
Governance
● Token Pairの追加
● Validator登録の閾値変更
● Validator Poolの容量変更
Slide 33
Slide 33 text
Tokenの用途
● Validatorになる
● 取引手数料の割引
○ ex. Binance Token
Slide 34
Slide 34 text
GORMOSとは
GORMOSの設計
GORMOSの課題
Section01
Section02
Section03
Slide 35
Slide 35 text
Front Runningへの対処
● とはいえ、中央集権的な取引所でも依然として存在する問題
Slide 36
Slide 36 text
Release
We are building it,
expected testnet release is Q2 2019.
Slide 37
Slide 37 text
● 福岡盛り上げよう
○ https://dmm-corp.com/recruit/top
● Decentralizedにいこう。
最後に