Plasmaの紹介

WARNING 2 ご存知の通り、ブロックチェーン技術に関してはまだ素人同然なので誤っている部分もあるかと思います。 誤っている箇所は適宜つっこんでください。 また、後からスライドを見た方で誤っている箇所に気づいた方は twitterなどで教えて貰えると助かります。

スケーリングに関する課題

今日のEthereumはどの程度Txを捌けるか ・1ブロックに150前後のTransaction ・ブロック生成速度は大体 15秒ペース 150tx/15sec = 10tx/sec 程のパフォーマンス （Visaは24000tx/sec程らしい） Eth stats: https://ethstats.net 4

ブロックにもっとTxを詰め込めば良い？ 単純に、1ブロックで捌けるTx量を増やせばスケールしていくはず BitCoin・・ブロックサイズ。1MB固定。 Ethereum・・ブロックガスリミット。投票により変動（今は 800万gas前後） 5 投票) ブロック採掘者がブロックガスリミットを「上げる or下げる」を選択 　　 「上げる」・・1/1024だけブロックガスリミットが増加 　　　「下げる」・・1/1024だけブロックガスリミットが現象

ブロックにTxを沢山詰め込む事の弊害 「中央集権化」とのトレードオフ 非中央集権的→フルノードがたくさん存在する状態 ブロックサイズが固定 →ブロックチェーンのサイズは線型的に増える ブロックサイズが指数関数的に増加 →ブロックチェーンのサイズは指数関数的に増える サイズが「線型的」に増える →技術の発展と共にフルノードは立ち上げ易くなる サイズが「指数関数的」に増える →フルノードの立ち上げコストが上がり続ける 6

スケールを可能にする技術

2つの考え方 ▫ メインチェーンで捌ける量を増やす ▫ メインチェーンに書き込む量を減らす 8 ・ProofOfStakeによりブロック生成間隔を短くする ・ブロックガスリミットを増やして Txを詰め込む ・シャーディングにより Txの承認を分散化する ・サイドチェーンで処理、最終的な stateだけをメインチェーンに書き込む (=>Plasma) ・オフチェーンで処理、最終的な stateだけをメインチェーンに書き込む (=>RaidenNetwork)

2つの考え方 ▫ メインチェーンで捌ける量を増やす ▫ メインチェーンに書き込む量を減らす 9 ・ProofOfStakeによりブロック生成間隔を短くする ・ブロックガスリミットを増やして Txを詰め込む ・シャーディングにより Txの承認を分散化する ・サイドチェーンで処理し、最終的な stateだけをメインチェーンに書き込む (=>Plasma) ・オフチェーンで処理、最終的な stateだけをメインチェーンに書き込む (=>RaidenNetwork)

Plasma 10

概要 サイドチェーンで処理し、結果をメインチェーンに書き込む (1) メインチェーンからサイドチェーンに資産（ etherやtoken)を移す (2) サイドチェーンで資産を取引する (3) 任意のタイミングで資産をメインチェーンに戻す （以下、Plasmaで用いるサイドチェーンを Plasmaチェーンと言います） 11 PlasmaはPlasmaチェーンとPlasmaコントラクト（資産の移動に関するコントラクト）から成ります

概要 12 の部分が安全ならメインネットワークは安全 Plasmaチェーン メインチェーン 資産の移動(deposit) 資産の回収(exit) が改竄されないよう、マークルルートをPlasmaコントラクトに書き込む Block#1 Block#2 Block#3 Block#4 Block#1 Block#2 Block#3 Block#4 Block#5

Plasmaチェーンの特徴 13 ・UTXOモデルに基づいたブロックチェーン ・コンセンサスアルゴリズムは Proof of Stakeベースのもの ・ネットワークの参加者全員でブロックの正当性を承認するものではない

[復習]UTXOモデル 14 UTXO・・Unspent Transaction Output、未使用トランザクションアウトプット ビットコインの残高管理に用いられている事から非常に有名 UTXO-1 #Alice 10 coin UTXO-2 #Alice 20 coin 例）#Bobに15コイン送金したい時 Transaction [Inputs] UTXO-1 UTXO-2 [outputs] #Bob 15coin #Alice 15coin UTXO-3 #Bon 15 coin UTXO-4 #Alice 15 coin BitCoinにおいてはInputとOutputの差額が「手数料」となってマイナーに支払われる 後述するPlasmaMVPにおいてはInput額=Output額としなければならない

Plasmaチェーン上での預金（Deposit） 15 (1)「#Bob 5ether deposit」というTransactionをPlasmaコントラクトに送信 (2) Plasmaコントラクトが5etherを保持（ロック）、depositイベントを発火 (3) Plasmaチェーンはdepositイベントを検知。5ether分のUTXOを作成

Plasmaチェーン上での送金 16 #Aliceが#Bobへ1 ether送金した、という情報は Plasmaチェーンのみが保持する (1) #Aliceは#Bobへ1 ether送金するトランザクションを作る (2)トランザクションが承認されブロックに取り込まれると、そのヘッダは RootChainへと伝搬していく (3)#Aliceと#Bobはトランザクションとブロックを承認したということを署名する

Plasmaチェーン上での出金(exit) 17 (1) #Bobは自分へ1ether送金されたというUTXOと共に、Plasmaコントラクトにexitリクエストを投げる (2) その際、このexitが不正なものだった時に払う供託金も収める (3) exitリクエストが「チャレンジ期間」に突入する（ ~1週間程度？） (4) 「チャレンジ期間」が何事もなく過ぎれば供託金と 1etherを受け取れる (5) 「チャレンジ期間」に不正が証明されたら無効 & 供託金はチャレンジした人の元へ

チャレンジ 18 要求された送金や出金が不正なものでないかを監視する仕組み ・送金/出金に使われるUTXOが既に使用済みのものじゃないか、などを確認する ・不正が証明されたら、供託金をチャレンジした人に回収される ・ブロックが不正なTxを含む事が発覚したら、ロールバックが走りブロック承認者は罰せられる 不正の証明 = Fraud Proof 現状,Aliceに関連する不正を証明するためには全てのブロックをダウンロードしなければならない （何処にAliceに関連するUTXOがあるかわからないので）

mass exit 19 withholding attack ・ブロックを承認しない（こちらが主？） ・51%攻撃（PlasmaはPoSを用いるのでStakerが分散していればリスクは低い） withholding attackなどによりPlasmaチェーンそのものが壊れた場合、みんなで撤退する ・単純なexitでは多額のgas代がかかってしまい少額 UTXOが消失してしまう ・実装必須のものではない ・別のPlasmaチェーンに撤退。仲介者が新しい Plasmaチェーンで資金が利用可能になるように整える ・mass exitリクエストに不正なexitが含まれないように仲介者は監視、排除する ・多額の供託金と共に、 mass exitリクエストを提出する

多段構成のPlasma 20 MapReduceの枠組みでTransactionを分散させることができる 実装例を見てみたい・・

Plasma MVP

Plasma MVP 22 Minimal Visible Plasma・・最小限実装のPlasma 提案・・https://ethresear.ch/t/minimal-viable-plasma/426 実装例・・https://github.com/omisego/plasma-mvp 提案を見て要件を把握した後、実装例を見ていきたいと思います

Plasma MVPの要件（ざっくり） 23 Plasmaコントラクト 以下のデータを保持 ・operator（デプロイ時に決定） ・Plasmaブロックのリスト ・submitされたExitTransactionのリスト。優先度順(=>古いUTXO優先)にポップできるようにしておく。 ブロックはoperatorが生成する or ユーザがdepositした時に生成（分散合意アルゴリズムなし） Exitにしかチャレンジできない。不正ブロックを検知したら Exitする事を前提 Plasmaチェーン ・Transactionは2つの入力と2つの出力を入れることができる。 RLPエンコードされたオブジェクト

Plasmaチェーン内での送金フロー 24 (1)送信者のアドレスを尋ねる (2)Transactionを送信する (3)オペレータに承認されるまで待つ (ルートチェーンに反映される） (4) 承認後、UTXOのinputに使用したキーで署名された confirm sigを送信する (4)のステップは一体何・・・？ confirm sigによりセキュリティが向上する例を見ていきます。 （こちらの解説記事が非常にわかりやすいです。「 1つ目の理由」を次スライドで話します） https://scrapbox.io/m0t0k1ch1/Why_do%2Fdon%E2%80%99t_we_need_two_phase_sends_plus_confirmation

confirm sigがない場合 25 #Alice -> #Bob 10ETH #Alice -> #Ope 10ETH(不正) オペレータが不正な Transactionをブロックに含めて承認する 不正Txの方が優先度が高くなるよう後ろにつける #Bobはこれを発見し10ETHをExitしようとするが、OperatorのExitが#Bobのものより早く処 理されdepositは空になり、#BobはExitできなくなってしまう (Plasmaブロック)

confirm sigがある場合 26 #Alice -> #Bob 10ETH #Alice -> #Ope 10ETH(不正) オペレータが不正な Transactionをブロックに含めて承認する #Aliceはこれを発見したので confirm sigを生成しない #Aliceは->#BobのTxに含まれるInput UTXOをExit申請する(Txが承認されてないので Exit可能) これはOperatorのExit申請より前ブロックに含まれるので優先度が高く、先に Exitできる

omisegoのPlasmaMVP実装概要 27

Deposit (in Plasmaコントラクト） 28 コントラクトに記録 Plasmaチェーンに通知

Deposit (in Plasmaチェーン） 29 通知を受けとり、Plasmaブロックを追加

SendTransaction (in Plasmaチェーン） 30 有効なTransactionかvalidateして、次のブロックに追加する このTxの出力に対応するUTXOのIDを返す。 ExitやTransactionのInputに使う

StartExit (in Plasmaコントラクト） 31 UTXOのIDを元に位置を算出する UTXOがsenderのものかを確認する Plasmaチェーンに存在するものか、署 名は正しいか確認する Exitキューに登録。チャレンジ期間に突入する

ChallengeExit (in Plasmaコントラクト） 32 cUtxoPos・・チャレンジするUTXO eUtxoIndex・・提出したtxに含まれる二重支払いの証拠になる UTXOの位置 提出したUTXOのownerがexit対象のUTXOのownerと一致するか、 マークル木に含まれているかを確認 問題なければ、exitを取り下げる。MVPにおいては報酬制度等はないよう

finalizeExits (in Plasmaコントラクト） 33 誰かが定期的にこの関数を呼び出す getNextExitはキューからUTXOの古い順にExit対象UTXOを取り出す UTXOのownerに送金する _tokenは処理するトークンの種類を示す。 ERC20にはまだ未対応なので 0x0以外入れてはいけない

Plasmaの発展

Plasma Cash 35 全ブロックをダウンロードしなくても自分に関連する Txを監視できるように 提案・・https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298 実装例・・https://github.com/loomnetwork/plasma-cash DepositしたトークンにNFTを割り振ることで MerkleTreeの何処に自分のトークンに対するトランザクショ ンがあるかを発見することができる メリット）自分に関連するトランザクションの枝だけダウンロードすればトランザクションの検証可能 デメリット）トークンに NFTを割り振るので、細かい単位にトークンを分けることができない。 まだスマートフォン等の端末に載せるにはデータ量が多すぎる

Plasma XT 36 チェックポイントを生成し、検証コストを大幅削減 提案・・https://ethresear.ch/t/plasma-xt-plasma-cash-with-much-less-per-user-data-checking/1926 実装例・・なし 定期的にチェックポイントを作り、その時点では全てのトランザクションが正当なものであることを保証 する メリット）検証しなければいけない範囲が著しく少なくなる どのようにチェックポイントを作り出せばいいのか議論中。（議論が停滞中？ 2018/9/9現在）

Plasma Debit 37 Plasma Cashの分割ができないデメリットを解消 提案・・https://ethresear.ch/t/plasma-debit-arbitrary-denomination-payments-in-plasma-cash/2198 実装例・・なし オペレータが各々の残高を管理する。ユーザとオペレータはペイメントチャネルを介して接続されてい る。送金した際は、オペレータに預けた 2者間で金額の総額が変わってないかをオペレータが検証する メリット）残高管理を可能にし、 PlasmaCashのデメリットを取り除いた デメリット）性質上、オペレータに預けた金額以上の金額を受け取る事ができない。 PlasmaCashチェーンが単独のオペレータによって運用されている事を前提とした提案。

参考資料 38 ethresearch https://ethresear.ch/ Lean Plasma https://www.learnplasma.org/index.html Sidechain, Plasma, PlasmaMVPの話をしました https://blockchain.gunosy.io/entry/sidechain-plasma-plasma-mvp PlasmaDebit https://scrapbox.io/m0t0k1ch1/Plasma_Debit omisego/plasma-mvp https://github.com/omisego/plasma-mvp Plasmaのミニマル要件を簡単な日本語で列挙 https://scrapbox.io/plasma-research-jp/Plasma%E3%81%AE%E3%83%9F%E3%83%8B%E3%83%9E%E3%83%AB%E8%A6%81%E4%BB%B6%E3%82%92%E7%B 0%A1%E5%8D%98%E3%81%AA%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%81%A7%E5%88%97%E6%8C%99 shogochiai/plasma-whitepaper-jp https://github.com/shogochiai/plasma-whitepaper-jp Plasma Cash Simple Spec https://scrapbox.io/m0t0k1ch1/Plasma_Cash_Simple_Spec Why do/don’t we need two phase sends plus confirmation https://scrapbox.io/m0t0k1ch1/Why_do%2Fdon%E2%80%99t_we_need_two_phase_sends_plus_confirmation Cryptoeconomics Research https://research.cryptoeconomicslab.com/ PlasmaからPlasmaCashへ。その仕組みとメリットと課題点 https://zoom-blc.com/what-is-plasma-cash プラズマがイーサリアムのスケーラビリティ問題を解決する理由と仕組み https://zoom-blc.com/plasma-ethereum （順不同）