GORMOS - A high performance and scalable design for decentralized applications -

2018/08/17 Hi-Ether Fukuoka #7 の発表資料です。20分に収めるために色々省略しています。

Transcript

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