目次
はじめに
本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
今回の内容
本記事は前回に引き続き、Ethereum Community Conference（EthCC）で発表されたPlasma Cashについて解説します。
第2回となる今回は、Plasma Cashの前提知識であるPlasmaと、Plasmaの最小限の実装であるPlasma MVPについて解説します。かつ、現在のPlasmaではどのような課題が残されているかを確認し、次回のPlasma Cashの話につなげていきたいと考えています。
前提としてPlasma Cash解説 第1回 Ethereumのスケーラビリティを読んでおくことが望ましいです。なおUTXOモデルとアカウントモデルや、Map Reduce処理について知見があるとさらに良いでしょう。
第1章 Plasma
PlasmaはEthereumのブロックチェーンを大元のチェーンとして、それを階層的に拡張する技術です。そして大元のチェーンで処理すべき処理内容をその次の階層のPlasmaチェーンに移譲することで処理性能を大きく向上させることが可能になっています。
Plasmaチェーンを構築する主体は大元のEthereumチェーン上のコントラクトに資金をデポジットしておき、Proof of StakeまたはProof of Authorityで各々のトランザクションを処理します。
Map Reduce処理
PlasmaはMap Reduce処理を用いて処理速度を大幅にアップさせることができます。
ここで言うMap処理とは、大元のブロックチェーンに存在する大きな処理のトランザクションを子階層のPlasmaチェーンに分割する処理を指します。分割したチェーンの下に、その子Plasmaチェーンが存在する場合はさらに分割します。
こうやって分割した処理は計算量が減るため、各々の処理は高速に完了します。
計算が完了したあとは、親階層のチェーンに処理結果をまとめあげて送ります。
この処理結果をまとめ上げる処理がReduce処理と呼ばれるものになります。
(HaskellやScalaなどの関数型言語の経験がある方であれば、リスト操作の際によく使うmap()やreduce()をイメージしていただければお分かりになるかと思います)
親階層のチェーンでは、子チェーンから送られてきた処理結果をさらに結合し、さらに親階層のチェーンに送ります。
この処理を大元のブロックチェーンまで続けることで大量のトランザクション処理を行うことが可能となります。
図 : PlasmaのMap Reduce処理の構造
①Step1の処理（図の青文字部分）でトランザクション処理を子Plasmaチェーンに分割します。
②Step2で子Plasmaチェーンで完了した処理を親チェーンに送り、まとめあげます。
これを大元のチェーン（図では緑色）まで繰り返します。
多段階層チェーン
これらのMap Reduceの処理は多段にすることができます。
上記の例ですとPlasmaが3階層になっていますが、これは何階層でも実現可能です。階層を多くすればするほど分割するステップが増えますが、どれだけ分割して階層化しても大元のEthereumのチェーンに書き込む回数は変わりません。
また、分割する粒度を細かくし、水平方向にPlasmaチェーンを増やすことで、１つのチェーンで処理する内容を削減することができます。
この場合も分割のコストは増加しますが、大元のチェーンに書き込む回数に変化はありません。このためスケーラビリティには原理的に限界はないといえます。 （実際には、分割コストやネットワークのコストがあるため、どこかで性能が頭打ちになると考えられます。）
Fraud ProofによるBlock Withholding Attacksの回避
Plasmaのチェーンの構築運用は不特定多数に任されています。
そのため、もしも利用しているPlasmaチェーンが悪意ある者によって運営されていたとすると、最悪の場合、Plasmaチェーン上で利用している資金が失われてしまうことが考えられます。
そうした不正を防ぐために、ユーザーアカウントは、いつでも自分の資金が不正に利用されていないか確認する必要があります。 そして、もし不正が行われていた場合は親チェーンに対して不正が行われた証明(Fraud Proof)を出すことができます。
このFraud Proofを出すことで、提出から一定の時間が経過した後に、ユーザーアカウントは不正が行われる以前の状態の資金を引き出すことができます。また、このような不正を行ったブロックの生成者はペナルティを受けることとなります。
図 : 赤いブロックが不正だとすると、Aliceは不正証明を親チェーンに提出し、このPlasmaチェーンを抜け出します。のちに資金は返ってきます。
（出典：https://plasma.io/plasma.pdf）
また、逆に悪意あるユーザーがPlasma上で使用している資金を大元のチェーンで引き出そうとする場合も考えられます。それを解決するために、PlasmaではUTXOモデルのトランザクションを採用しています。（大元のチェーンであるEthereumではこれとは異なるアカウントモデルと呼ばれる方法が採用されています。）
Plasma上で使用されたトランザクションはユーザーによる署名が行われ、この署名をPlasmaチェーンが親チェーンに提出することで不正を防止しています。
第2章 Plasma MVP
Plasma MVPはPlasmaの最小限の簡易実装として提案されており、OmiseGOプロジェクトなどで利用される予定です。
GitHub上に公開されており、Consensysが提供しているGanacheを利用することで簡単に挙動を確認できるようになっています。
Ganacheをインストールし、Ganache上のプライベートチェーンにPlasma用のコントラクトをデプロイしたものをこれをルートチェーンと呼びます。
そしてルートチェーンにひもづく形でPlasmaチェーンを起動したものをチャイルドチェーンと呼びます。
具体的なサンプルの動作方法はGitHubにまとめられているので興味があれば動かしてみてください。また、具体的な動作の流れはKarl Floersch氏がYouTubeで公開しています。 図 : Plasma MVPのYouTube解説。ステップごと動作を解説しています。
第3章 Plasmaの課題
ユーザー自身によるチェーン監視が必要
Ethereumの処理性能を向上させるスケール技術としては有力であるPlasmaですが、ユーザーが前述の不正証明を行うためには、自分が発行したトランザクションが関わるチェーンを全て監視しておく必要があります。
監視できていなければ、どこで不正が行われたのか検証が不可能だからです。
多段階層化によるチェーンサイズの肥大
また、それぞれのチェーンのトランザクションを確認する必要があるため、関わるブロックをダウンロードする必要性が出てきます。 チェーンが多段構造になればなるほど、ユーザーがダウンロードするブロックのサイズは増えていき、利便性を損なうことになります。
アカウントの状態管理が煩雑になる
もう１つの課題はPlasmaチェーン上で処理されたトランザクションの状態を更新するためにはアカウントの状態をアップデートする必要があるということです。
Plasmaチェーンでの処理内容が大元のチェーンに取り込まれた後、トランザクションを発行したユーザーは、トランザクション対象のアカウントに正しく処理が完了したことを通知する必要があります。
これはUTXOモデルとアカウントモデルを併用した欠点と言えますが、単純にアカウント更新の二度手間となってしまいます。
Plasmaの課題を解決するための提案がPlasma Cash
Plasmaが抱えているこれらの課題を解決するための機構として提案されたのが、本シリーズのテーマであるPlasma Cashです。
次回はいよいよ、Plasma Cashを用いてこれらの問題がどうスマートに解決するかを見ていきたいと思います。
まとめ
今回はPlasmaの詳細と簡易実装のPlasma MVP、Plasmaの課題点について解説しました。 次回はPlasma Cashを導入することでPlasmaの課題がどのように解決するのかを見ていくことにしましょう。
参考資料
- https://plasma.io
- https://github.com/omisego/plasma-mvp
- https://github.com/BANKEX/PlasmaParentContract
- https://github.com/shogochiai/plasma-whitepaper-jp
