Plasma Introduction and its Future.

暗号通貨論文輪読会にて。
Plasmaの概略から現状の議論までの解説。

Transcript

1. Plasmaの概略とその発展 @y_matsuwitter
2. 2 ©Gunosy Inc. ⾃⼰紹介 n Gunosy Inc. – 新規事業開発室 執⾏役員 CTO n 業務 – 開発全般のマネジメント – 技術に関する横断的な課題対処 – 現在は新規事業⽴ち上げも担当 n 経歴 – 在学時に⼆社のベンチャーの⽴ち上げ・ 開発に携わる – 2013年3⽉ 東京⼤学⼯学部卒業 – 2013年1⽉よりGunosyに⼊社 – 2014年6⽉執⾏役員就任、現在に⾄る 松本 勇気 @y_matsuwitter
3. 3 ©Gunosy Inc. 本⽇のアジェンダ Plasmaとはなにか l Blockchainの課題とSidechain l EthereumとPlasmaの関係 l Deposit / Exit / Challengeによる資⾦移動 l Plasma PoS, Blockchain in Blockchain, Map Reduce l Plasmaの可能性 Plasma MVPで理解する不正対策 Plasmaの先端議論 l Plasma Cash/XT l Simple Withdrawal…etc Plasmaに関してWPを元にしたその概略と発展について。
4. 4 ©Gunosy Inc. Plasmaとは
5. 5 ©Gunosy Inc. Blockchain全体の課題 現実世界での利⽤を促進するにはパフォーマンス改善が急務。 n Block sizeの制約 – ⼀つのBlockに含められるtxの数は上限 がある。 – 上限が⾼すぎると中央集権的になる可能 性も。 n Block timeの制約 – Blockの⽣成間隔は短すぎるとセキュリ ティ的トレードオフが発⽣。 n Ethereumの場合 – 現状は毎秒10tx程度が上限 実利⽤においてスケーラビリティの不⾜が重要課題。 Block tx tx tx tx Block tx tx tx tx Block生成間隔 Blockあたりの キャパシティ
6. 6 ©Gunosy Inc. Sidechainという解決策 複数のブロックチェーンをpeggingによってつなげる。 n Peggingによる連携 – 2つのBlockchain上のトークン同⼠を固 定レートで対応付けし、アトミックに交 換する仕組みを⽤意する。（預け⼊れ） n スケーラビリティへの貢献 – サイドチェーンの数だけtxを捌ける。 – サイドチェーンは親チェーンとは独⽴し た仕様を採⽤可能 n 課題 – Trustlessなpeggingの難しさ l SPV Proof, NIPoPoWs…etc スケーラビリティに対する解決策の⼀つ。 Parent Chain Side Chain 固定比率交換
7. 7 ©Gunosy Inc. Plasma = Sidechain + α DecentralizedなSidechain + PoS + MapReduce n EVMでのDecentralizedなpegging – 後述するが、不特定多数の参加者の中で peggingに伴う預け⼊れ・引き出しを実 現する仕組みを既存のEVMにて実現。 n 拡張性と安全性を上げるさらなる仕組み – Plasma PoS – Map Reduce – Plasma Cash – …etc EVMを利⽤して複数チェーンを連携しスケーラビリティを⾼める。 図: RootChainに様々なチェーンを繋げていく 出展： https://plasma.io/plasma.pdf
8. 8 ©Gunosy Inc. Plasmaの登場⼈物 Rootchian Contract ó Plasma Chainの連携で成り⽴つ。 n Rootchainコントラクト – 資⾦をPlasmaチェーンに⼊⾦・出⾦し その安全性を担保するスマートコントラ クト。 n Plasmaチェーン – SidechainとしてRootchainコントラク トと連携するチェーン。 – 後述するPlasmaのプロトコルに準拠し ていればどのようなチェーンでも原理上 使えるはず。 Ethereumと協調するSidechain相当のチェーン。 Ethereum RootChain Contract Plasma Chain 関連する Stateの監視 ⾃⾝の状態 記録 Plasmaの利用 PlasmaChain への入出金 User
9. 9 ©Gunosy Inc. User ⼊⾦と出⾦・不正報告 Plasma Chain ETHなどを送金し預託 預託のイベント発生 UTXOの生成を確認 自身のチェーンに 入金UTXO生成 預託金取出のための署名送付 出金依頼を優先キューに 追加する 7日後、出金を有効化する。 出金依頼分のETH等を取り出し 預託金の記録 不正があれば このタイミングで 証拠を提出し棄却
10. 10 ©Gunosy Inc. User ⼊⾦と出⾦・不正報告 Plasma Chain ETHなどを送金し預託 預託のイベント発生 UTXOの生成を確認 自身のチェーンに 入金UTXO生成 預託金取出のための署名送付 出金依頼を優先キューに 追加する 7日後、出金を有効化する。 出金依頼分のETH等を取り出し 預託金の記録 不正があれば このタイミングで 証拠を提出し棄却 詳細はPlasma MVPの項で！！
11. 11 ©Gunosy Inc. Priority Queue 最終⼿段としてのMass-exit Mass exit後のチェーンは基本的に停⽌、別チェーンの作成を想定 n あくまで将来的な仕様で、exitしたい全ての ⼈から署名を集めて実⾏。 n Priority QueueによるExit優先度調整 – 古いUTXOから順に出⾦ n 古い順に処理されるため、不正な出⾦・アク ション以前に関しては、かならず正しい持ち 主に正しい⾦額が変換される。 n ユーザー喪失を⽣むため、運⽤者の不正に対 するマイナスのインセンティブになる。 全Depositに対してExitを提出する。 Exit Frauded Block: 123 Block: 122 Tx idx: 2 Block: 115 Tx idx: 14 Exit ここでは Deposit不足に
12. 12 ©Gunosy Inc. Plasma PoS ノード運営にあたっての不正のインセンティブを潰す。 n 仕組みとしては⼀般的なPoS – Staking⽤トークンを⽤いてPlasmaチェ ーンをvalidation、tx⼿数料等を得る。 n Stakerとなることでチェーン⾃体の価値を毀 損する不正のインセンティブを無くす。 – 不正はMass Exitに繋がり価値が0へ。 n 想定されるstakerの構成 – WPではPlasmaチェーン運⽤者が1つの addressに対して3%程度を上限とした stakingを想定。 Plasmaチェーンに推奨されるコンセンサスアルゴリズム。 Block: 2 Bさん Block: 3 Aさん Block: 1 Cさん 100ブロック内で Staker⽐率に応じた Block提案割合を 維持するよう設計する
13. 13 ©Gunosy Inc. Blockchains in Blockchains 多くのBlockchainが連携することで全体として数百万tx/secを達成する。 n Plasmaの構造は複数階層作れる – Rootから⼦、更にその⼦から孫にデポジ ットを繰り返していくことで深い階層の チェーンを使う。 – 多量のチェーンが最終的に連携され、そ の分だけスケーラビリティが向上。 n ⼦チェーンで不正 => Mass Exitで親の階層 に避難可能。 – 最終的にはRoot（⼀般的にはEthereum の階層）まで脱出する。 沢⼭のBlockchainを親、⼦、孫…の関係でつなぐ。 https://plasma.io/plasma.pdfより 図: Blockchains in Blockchains
14. 14 ©Gunosy Inc. Plasma MapReduce Map Reduceの形式を取ることで1txの処理能⼒を拡張していく。 n 課題 – Blockchainではtxの処理が⼤きすぎると 現実的に計算が難しい。 n Map Reduce – ⼊⼒データを複数チャンクに分割して多 数のノードに分散処理させる。 n Plasmaでのmap reduce – 親⼦孫…のチェーン階層間でタスクを分 散処理。 – TrueBitを参考に設計されている模様。 複数階層のPlasmaチェーンを⽤いて分散処理基盤へ。 Parent Chain Chain For Word Split Chain For Word Split Chain For Word Count Chain For Word Count Text Words Words 図：Map Reduce のイメージ Text
15. 15 ©Gunosy Inc. Plasmaの可能性
16. 16 ©Gunosy Inc. Plasma Chainの⾃由さ ⽬的・⽤途に応じた独⾃のチェーンを⽤い、スケーラビリティを担保。 n Plasmaである為に必要なこと – RootChainとの連携 – e.g. Deposit/Exit/Challengeの監視等 n 独⾃のチェーン実装を持ち込む – 挙動が正しければ、そこにあるのはEVM 実装のチェーンでなくともよい（はず） – TendermintやLoom Networkの事例 仕様に準拠していればそれ以外は⾃由に実装可能。 Tendermint Ethereum Loom Network Hyperledger Fabric Original Chain
17. 17 ©Gunosy Inc. Plasma Chainによる安全な拡張 Ethereumを⽀えるハッシュパワーに安全性を担わせる。 n Plasmaチェーンであるとは – そのチェーンにおけるblockを RootChainコントラクトに記録 – つまりEthereumを⽀える Miner/Validatorのセキュリティに乗る ことができる！ n ユーザーの資⾦の責任はユーザーが負う – 資⾦盗難等の可能性を極⼒まで抑え込ん で独⾃機能を作れる。 – 最悪ケースでもExitで守れる。 Plasma Chainとすることで⾃⾝の作ったチェーンのセキュリティ強化に。 Block Block Block Root chain Block Plasma Chain Block Block Rootchainの コンセンサスの元 記録される submit
18. 18 ©Gunosy Inc. 事例：分散取引所 GOXを避けた安全なDEXの構築を⽬指すことができる。 n 階層構造を活かしたPlasma – ⼦チェーンに通貨ペアを割り当てし、そ れぞれで売り買いをマッチする。 – ユーザーは関⼼のある通貨ペアのチェー ンのみ利⽤すればいい。 n Plasmaチェーンである利点 – Depositの保護機構により取引所のGOX リスクが⼩さくなる。 – 通貨ごとの⼤量の取引をMap Reduce的 な機構で分散スケールさせられる。 DEXをPlasma チェーンとして構築する。 Ethereum Chain DEX Chain DEX Chain For GNT/ETH DEX Chain For OMG/ETH DEX Chain For eBTC/ETH 図: 通貨ペアごとの子チェーン
19. 19 ©Gunosy Inc. 事例：プライベートチェーン 利⽤者保護とプライバシーを両⽴することができる。 n Private Chain – ⼀般にそのデータを公開しておらず、ブ ロックの提案も特定の集団で⾏われるチ ェーンを指す。 – 特にプライバシー等の課題でPublicが現 状使えないユースケースに対応。 n Plasmaであるメリット – Ethereumのセキュリティを利⽤。 – チェーン利⽤者のデポジットを不正から 保護することができる。 プライベートなチェーンもEthereumの恩恵を受けることができる。 Block Block Block Ethereum Secret Block Data Private Chain Merkle Root記録 Exit
20. 20 ©Gunosy Inc. Plasma MVP
21. 21 ©Gunosy Inc. Minimal Viable Plasmaとは あくまでPlasmaの挙動の⼀部をシミュレートするものだが学習には最適。 n おおよその構成 – RootChainコントラクト – Plasma準拠の擬似的なBlockchain n 現状の実装例 – omisego/plasma-mvp – voltairelabs/plasma – …etc n 今回はomisego/plasma-mvpをベースに話 をします。 主にdepositとチェーン運⽤周辺の最⼩構成を⽰す実装提案。 https://ethresear.ch/t/minimal-viable-plasma/426 より
22. 22 ©Gunosy Inc. RootChain コントラクトの役割 ⼊出⾦とチェーン運⽤の最低限のデモを⽰すコントラクトがRootChain。 n DepositとExit – Plasmaチェーンに対する⼊⾦と出⾦。 – ⼊⾦イベントに応じてPlasmaチェーン がトークン発⾏ – Exit申請で⼀定期間後に出⾦ n Challenge – 不正な出⾦への控訴 n PlasmaチェーンのBlock記録 – Root側のセキュリティ強度に乗る。 – MerkleRoot記録による不正の防⽌。 ethのdepositとwithdrawal、その不正証明の取扱を担当します。 RootChain Deposit Plasma Chain Exit Challenge Block記録 User 監視
23. 23 ©Gunosy Inc. RootChainコントラクトを読んでみよう
24. 24 ©Gunosy Inc. Plasmaチェーンのブロックの記録 n ⼀定のBlock間隔で Plasmaチェーン側の BlockのMerkle rootを コントラクトへ記録。 n omisego/plasma-mvpに おいてはブロック⽣成と 同時に呼び出しの模様
25. 25 ©Gunosy Inc. Deposit（Plasmaチェーンへの⼊⾦） n 送信者と送⾦額のハッシュ値 をコントラクトに記録。 n 主に⼦チェーンに向けて、 Depositイベントを発⾏し⼊ ⾦された旨を伝える。
26. 26 ©Gunosy Inc. Deposit②⼦チェーン側の動き 上: Ethereumのチェーンイベント監視 下: Depositを自身のチェーンに反映させる 下記は子チェーン側の実装 n Depositイベントを監視し検 した場合はapply_depositを 呼び出す。 n apply_depositでは⼊⾦に対 応するUTXOを⽣成し⼊⾦ BlockとしてBlock⽣成を⾏ う。 n UTXOがDepositを返還する 際の預り⾦証明となる。
27. 27 ©Gunosy Inc. DepositからExitの流れ①Exitの提出 Exit開始のリクエストをユーザーが生成 TxのRLPをdecodeして txの位置、address抽出 ・exit提出者のUTXOである ・署名が正しい ・Merkle treeに含まれる という点のチェック Utxoの存在位置を重みとした Priority Queueに追加
28. 28 ©Gunosy Inc. DepositからExitの流れ② finalize n 定期的にfinalizeExitsを呼び 出す。（主体は誰でもいい） n ⼀定期間たったExitを古い UTXO順に 出⾦完了させる。
29. 29 ©Gunosy Inc. User 正常系をまとめると Plasma Chain Send deposit (ETH) Send deposit event Check UTXO Record deposit & Create UTXO Start Exit with tx & signature Check signature & Add to Priority Queue Wait 7 days… & finalizeExit Return ETH corresponded to a tx. Record deposit
30. 30 ©Gunosy Inc. 不正なExitの類型 不正がないか監視し、その証拠を提出するという作業が必要になる。 n ⼆重⽀払い – 使⽤済みのUTXOの引き出しとも⾔える – 不正証明（Fraud Proof）の提出で対処 n 過剰な引き出しや不正なトークン⽣成 – 対応するUTXOが記録されていないので 不可能 n Block Withholding Attack等のチェーン全体 の不具合 – Mass Exitでチェーンに対するDepositを 全て元の持ち主が取り返す。 不正にDepositを引き出すなどのケースにDecentralizedな対応が必要。 Unused Tx Output Tx Output ①使用済みTXO 存在しない Tx Output ②虚偽のTXO ③チェーン自体の不正 Exit Exit
31. 31 ©Gunosy Inc. Fraud Proofの提出 提出したtxからFraudな UTXOの位置を取り出す 対象exitのownerのものか 確認し、またtxがmerkle root に正しく含まれるものか確認 Fraud Proofが正当なら Exitを削除 confimationHashとsigは startExit時に提供されたもの
32. 32 ©Gunosy Inc. Priority Queue 最終⼿段としてのMass-exit Mass exit後のチェーンは基本的に停⽌、別チェーンの作成を想定 n あくまで将来的な仕様で、exitしたい全ての ⼈から署名を集めて実⾏。 n Priority QueueによるExit優先度調整 – 古いUTXOから順に出⾦ n 古い順に処理されるため、不正な出⾦・アク ション以前に関しては、かならず正しい持ち 主に正しい⾦額が変換される。 n ユーザー喪失を⽣むため、運⽤者の不正に対 するマイナスのインセンティブになる。 全Depositに対してExitを提出する。 Exit Frauded Block: 123 Block: 122 Tx idx: 2 Block: 115 Tx idx: 14 Exit ここでは Deposit不足に
33. 33 ©Gunosy Inc. Minimal Viable Plasmaに無いもの MVPはあくまで⾮中央集権的なデポジット運⽤の最⼩実装。 n Blockchain間の連携 – 親チェーンが⼦チェーンにタスクを委譲 – MapReduceのような処理機構を作る。 n Plasma PoS – 専⽤トークンによってPoSコンセンサス を実⾏。（e.g. OMGトークン） n 余談だがMVP実装のPlasmaチェーンはHash chainではなく挙動を模しただけのもの Plasma⾃体は他にもいくつかの機能・制約を提案している。 Parent Chain Chain For Word Split Chain For Word Split Chain For Word Count Chain For Word Count Text Words Words 図：Map Reduce のイメージ Text
34. 34 ©Gunosy Inc. Plasma Cash / XT
35. 35 ©Gunosy Inc. Plasmaの課題とPlasma Cash
36. 36 ©Gunosy Inc. Plasmaの課題 利⽤者に対するデータサイズ等の負荷が⼤きく、⾮⼒な環境で動かせない。 n ⾃分のUTXOの不正使⽤確認にあたって、ブ ロック内の全データを検証必須 – Merkle Treeのどの位置に⾃分のUTXO に関する不正TXが記録されるか不明 – 特に通常のUserは⾃分の通貨監視を常に ⾏えないため、同期時に全txを取りに⾏ くことになる n 結果として、ユーザーは全てのブロックデー タを保持することになる。 – 1年運⽤するだけでも数⼗GB以上、相当 量のデータになる⾒込み。 不正を監視し、UTXOが利⽤可能だと⽰すために必要なデータの量が課題。 Merkle Treeのどこに関連する 不正なtxが記録されるか不明
37. 37 ©Gunosy Inc. No Fungible Token それぞれのコインがIDを持つ Fungible Token コインに区別が無い、等価 前提知識：No Fungible Token 特定のトークンが誰から誰に渡ったか記録可能な仕組み。 n Fungibility（代替可能性） – 「どの1万円札も等しく価値は1万円であ る」という概念と考えるとよい。 n NFT = 各トークンに個別の価値を付加 n ⼀つ⼀つのトークンに唯⼀性が備わることで 様々な⽤途に利⽤されている。 – 有名な事例: Crypto Kitties n Ethereumでの仕様 – ERC721トークン 1つ1つのTokenにIDを付与したToken設計を指す。 ID:１ ID:2 ID:3 1ETH 1ETH 1ETH
38. 38 ©Gunosy Inc. Plasma Cashの登場 ユーザーが監視すべきデータを log(Coin発⾏数) に抑える。 n ⼊⾦額に応じた個別のコイン(NFT)を発⾏ – 現状の提案では、1つのコイン⾃体を分 割することは不可、⼊⾦に応じたコイン が発⾏される。 n コインの譲渡記録としてのMerkle Tree – 各ブロックにはコインの譲渡を表現する データ構造をNodeとしたMerkle Treeの Rootが記録される。 n ユーザーは⾃⾝の持つコインのIDに応じた Merkle Treeのノードだけに関⼼を持てば良 くなる。 DepositしたものをNFTのような個別のCoinとしてPlasmaチェーン側で利⽤。 Parent Chain Side Chain 1 入金 入金額分のNFT 2
39. 39 ©Gunosy Inc. Plasma Cashのメリット ⾃⾝に関連するデータに限定して監視できるため⾼効率。 n 監視するデータ構造 – Plasma: Merkle Treeの全体 – Cash: Merkle Treeのうち、⾃⾝のもつ CoinのID対応部と必要最低限のMerkle Proof n ブロック当たりのチェックすべきデータの効 率はlog(コイン数）へ n Exitの監視がしやすく、不正を潰すための期 間も短く出来る可能性 ユーザーがチェックすべきデータを削減できる。 ・署名 ・前回txへのポインタ ・NFTの移転先
40. 40 ©Gunosy Inc. Plasma CashのDeposit/Exit Depositで発⾏したコインのIDを⽤いてExitを要求する。 User Plasma Chain ETHなどを送金し預託 預託のイベント発生 NFTが自身の所有に なっていることを確認 自身のチェーンで NFTを発行 当該コイン所有の証拠となる 所有者の移転履歴2つを提出 出金依頼を優先キューに 追加する N日後、出金を有効化する。 出金依頼分のETH等を取り出し 預託金の記録 不正があれば このタイミングで 証拠を提出し棄却
41. 41 ©Gunosy Inc. Plasma CashのChallenge 特定のコインの移転履歴を提供することで不正を証明。 １ １ 正常なExit 2 3 4 E １ E 所有権移転 Exitの発生 参照関係 不正なtx Txの提出 １ 不正① 消費済みcoinのExit 2 3 4 E Txの提出 このケースでは4番のtxが 含まれるMerkle Proofを Challengeで提出
42. 42 ©Gunosy Inc. Plasma CashのChallenge 特定のコインの移転履歴を提供することで不正を証明。 １ １ 不正② 二重使用 2 3 4 E １ E 所有権移転 Exitの発生 参照関係 不正なtx Txの提出 １ 不正③ 不正なtx以降のCoinに対するExit 2 3 4 5 Txの提出 3番のtxが含まれる Merkle Proofを Challengeで提出 このケースでは対話的Challenge Challengerは1,2番のMerkle Proof を提供、それに連なる4番までの BlockをExiterが提供できるか確認 E
43. 43 ©Gunosy Inc. Plasma XT
44. 44 ©Gunosy Inc. Plasma Cashの課題 ブロック数×log（Coin発⾏数）を下回るサイズに押さえ込みたい。 n Blockあたりデータサイズはlog(コイン数） のハッシュ⽂字列のサイズ n 1年運⽤した際のブロックサイズの事例 – Hash = 32byte – Coin = 65532（=2^16）枚 – Block time = 15秒 – 上記仮定のもとでBlockあたり512byte – 結果として1年で1GBに達する。 n 1GBのデータを同期するのはモバイル端末等 ⾮⼒な環境だと厳しい。 Plasma Cashになってもデータ量はやはり⼤きい。 図: ID=3のホルダーが保持しておくべきMerkle Proof
45. 45 ©Gunosy Inc. 前提知識：署名を収集する 収集対象者数分のbitデータサイズで署名の提出状況を記録する⼿法。 n ある議題mにたいして、n⼈の投票者が署名 することで投票する状況を考える – Mに対して各位が秘密鍵で署名すること で偽り無く投票したことがわかる – このケースではデータサイズが投票⼈数 分必要になる n n bitsのビット列Bを⽤意し、署名集約者cが 投票者から署名を集め、投票者iが署名を提供 した場合1をBのi bitに設定する – 仮にcが不正にbitを1にした場合、対象 の投票者はchallengeを⾏い、cが署名を 公開できるか確認することで不正を防ぐ 投票⾏動において、データ効率を改善するための提案。 n = 4 B = 0x1101 Sig Sig Sig 署名提出者
46. 46 ©Gunosy Inc. Plasma XTの登場 Coinが利⽤可能だと⽰すにはチェックポイントを⽰すだけで⼗分に。 n 最終的に知りたいのは特定のCoinを誰が最後 に持っていたかという信頼できる情報 n Plasma XTでは、BlockのMerkle Treeだけで はなく、各コインの所有者アドレスをNode としたチェックポイントデータを構成する。 n チェックポイントが正しい限りにおいて、 Exitの不正を証明するにはチェックポイント 以降のデータで済むはず。 n チェックポイントの作成はBlockchainの運⽤ 者が⾏う。 署名を集約して、Coinの保有者リストを定期的にチェックポイント化する。
47. 47 ©Gunosy Inc. チェックポイントの作成とChallenge 単純な考え⽅だと、都度チェーンの運⽤者がチェックポイントを作る。 Deposit 署名 所有権に対する 不正証明 この時点での各コインの 所有者情報を集約、提出 Challenge Depositの付与 チェーン オペレータ User Plasma Chain 【Operator依存の課題】 オペレータがMerkle Root以外 伏せた場合に不正が⾒えない
48. 48 ©Gunosy Inc. チェックポイント 署名集約を利⽤したチェックポイントの作成 ⼩さなデータ量で不正を判断できる。 チェーン オペレータ 1 3 4 2 Coin (数字はID) 署名提出 Bit列 1101 当該bitのコイン 所有証明 ⾃⾝のコインのBitが 不正に1だったらChallengeし Bitを0にする。 User User 空値
49. 49 ©Gunosy Inc. Plasma Cash/XTに対する疑問点 Plasma Cash/XT ⾃体もまだ研究段階の技術、今後の改善が必要。 n 部分的コイン利⽤の難しさ – 例：10ETHをdepositしたコインで 5ETH分だけを消費することが現状想定 されていない。 l コインを⼩さくしすぎるとProofサ イズやWithdrawのコスト増⼤に。 l 確率的paymentなるものも提案さ れている。 n XTでのチェックポイント設計 – Challengeに必要なコストを正しく設計 しなければPlasma Cashと同等のデータ サイズに戻ってしまうが、正しさとは？ Plasma Cash/XTでは分割不可能なNFTを利⽤することによる制約がある。 10 ETH 5 ETH 5 ETH Bさん Aさん Aさん
50. 50 ©Gunosy Inc. 最近の動き
51. 51 ©Gunosy Inc. 直近の議論 n Exit中の資⾦を証券と⾒ ⽴てた⼿法 n 証券をディスカウント して売却することで結 果的に⾼速Exit n ルートチェーンの特定 コントラクトアドレス を利⽤したBurnの仕組 みが斬新。 Simple Fast Withdrawal n Plasma CashのCoinが 表現する⾦額を書き換 え可能にする変更 n BlockのMerkle Treeの Nodeをアドレス + coinの額⾯に変更 n 額⾯をtx時に書き換え られる仕組みへ。 Plasma Debit n Plasma MVPのより具 体的な実装 n Exitの処理優先度を Outputの古さから Input基準に切り替える など。 n 形式証明でその仕組の 正当性を証明している。 More Viable Plasma 未だ実装については様々進んでおり、キャッチアップが重要。 Plasma Cashの改善や⾼速なExitといったトピック。
52. 52 ©Gunosy Inc. 最後に
53. 53 ©Gunosy Inc. 最後に n Ethereumの機能の先端はWhitePaperではなくethresear.chとEIP だと思います。 – 積極的に⾃分の気になるトピックを読んで⾏こう。 – 必要に応じて質問も投稿しよう。