Plasma MVP を理解しよう！その１
この記事は、Plasma や Plasma MVP について聞いたことはあるがよく理解していないという読者を対象に、コードや仕様からは掴みづらいような背景・考え方なども理解できるような Plasma MVP の解説を目指すシリーズの第一弾です。
第一弾では Plasma MVP の詳細に入る前に、Plasma が解決する問題自体とそれをどのように解決するのか、Plasma 全体に共通すると考えられる特徴をふまえつつ紹介します。
2018/12/13更新： 第二弾も公開しました。
すでに良く言われているとおり Plasma は単一の仕様やプロジェクトではなくフレームワークのような存在なので、有志によってたくさんの具体的な仕様が考えられています。その中でも Plasma MVP は比較的シンプルで様々な派生の Plasma 仕様の基礎にもなっているので、理解を深めておくことが他の Plasma 仕様を調べる上でも役に立つでしょう。
また、Plasma の white paper を参照するような紹介記事がすでにたくさん存在していますが、本記事と内容が異なるかもしれない点には少し注意が必要です。ethresearch を中心とした活発な議論の結果、当初の white paper の内容をそのまま推し進めるというよりは Plasma MVP を出発点として個別の Plasma Cash や Plasma Snapp など種々雑多な Plasma 仕様が議論されているのが現状であり、white paper の内容は古くなっている可能性が十分にあるためです。
なぜ Plasma が必要とされているのか
Public Blockchain の Scalability 問題
Ethereum における現在の TPS(transaction per second) は 10–20 TPS 程度であり、既存のアプリケーションと比較して単位時間あたりの処理量が少なすぎるため、本格的な利用の普及にあたっては Scalability の改善が必須であろうと言われています。
なぜ Ethereum はこのように遅いのでしょうか？ 簡単に説明すると以下の二点が理由として挙げられます。
1. すべてのフルノードが同じ計算をしている
Ethereum フルノードは他のノードの計算結果を信頼するのではなく、自身で genesis block から続く blockchain の全 block について計算・検証することで不正が存在しないことを確認します。つまり、1 万を超える Ethereum ノードが稼働している現在も、新しい block が発行されるたび全てのフルノードで全く同じ処理を行なっているのです。
これは非中央集権性を失わないためには非常に重要でしたが、非中央集権性を担保しながら各ノードに別の transaction を分担して処理させることができるのならばその方が効率が良くなるのもまた自明です。Ethereum のメジャーアップデートである Serenity において Sharding としてこのような手法を取り入れることが検討されています。
2. 扱える transaction の数が制限されている
Ethereum では block に含まれる各 transaction に設定される gas limit の集計の上限値(block gas limit)が存在していて、これを超えて transaction を block に含めることはできません。block は一定間隔で生成されるように調整されるので、block 生成間隔と block gas limit 分の transaction しか処理できないことになります。
block gas limit の上限を単純にあげれば良さそうなものですが、必要なネットワーク帯域やストレージ領域の拡大に伴うコスト増がノード数の低下を招いて非中央集権性の低下に繋がってしまうと考えられており、簡単にこの上限を上げればそれで全て解決するというものでもないようです。同じ理由から block 生成間隔を単純に短くするのも上手くいかないでしょう。
そこでいま考えられているのが、セキュリティ的に重要な処理のみに絞って Ethereum 上で実行し、それ以外の処理は off-chain で実行させつつも mainchain のセキュリティを担保する手法です。Layer 2 (solutions) と俗に呼ばれていますが Plasma はこれに該当します。他にも Raiden Network、Truebit などのプロジェクトが存在します。
Sharding が Layer 1 である Ethereum のプロトコル自体を更新するものであることに対して、これら Layer 2 のプロジェクトは基本的にはその必要がないように Layer 1 を利用する別のアプリケーションを稼働させてそれぞれを何らかの方法で繋ぐことになります。
Public Blockchain のトリレンマ
Scalability の現状と改善策を簡単ではありますが見てきました。これらの課題を抱える形で Ethereum が稼働している背景には、 Public な Blockchain として Scalability よりも Decentralization および Security を優先してきたという事実があります。この3つのパラメータは Public Blockchain のトリレンマとして、3つ全てを同時に達成することはできないものと言われています。より詳しくは スケーリング狂詩曲〜パブリックブロックチェーンの技術革新は創造のムーブメントだ が参考になるかもしれません。
前述の Sharding や Plasma においても、Decentralization および Security を(可能な限り)これまで通りに確保した上で、いかに Scalability を伸ばすことができるかというアプローチであることに注目しておくべきです。この制約を理解しておくと一見まわりくどいような仕組みがなぜ必要とされているのか頭の中で整理するのに役立つと思います。
どのように Plasma は Scalability 問題を解決するのか
では Plasma とはどういった仕組みで、どのように Scalability に寄与するのでしょうか？
off-chain での処理
fee が高騰したり詰まったりしがちな mainchain のリソース消費を抑えるために、transaction の処理のほとんど大部分を mainchain 以外で行う(off-chain)ことで Scalability の向上をはかります。
Plasma MVP では、 sidechain と呼ぶ mainchain と異なる blockchain を稼働させ、mainchain の contract 経由で資産を sidechain に移動させることで sidechain 上での transaction 処理を可能にします。mainchain 上で処理が行われるのは sidechain への預け入れである deposit、その引き出しである withdraw、さらに後述する state commitment のみとなり、ユーザ間での transaction 処理はすべて off-chain で行われます。
state commitment
せっかく off-chain で処理した結果のすべてを mainchain に書き戻してしまっては無駄が大きいので、ある時点の blockchain の状態を圧縮した state commitment と呼ばれるようなデータだけを mainchain に書き込みます。
Plasma MVP では block が持つ複数の transaction から構成した merkle tree の merkle root を state commitment として mainchain に書き込むとされています。off-chain での処理の結果を state commitment として public な mainchain に書き込むことで、その Security(たとえば改ざん耐性など) を借りることが狙いです。このように mainchain にも書き込まれた結果を改ざんすることは、off-chain 単独でみた不正と比較して相対的に困難なものになるだろうという前提があります。
exit
当然ながら、off-chain で処理を実行するために deposit した資産をユーザの任意のタイミングで引き出すことができる必要がありますが、これは withdraw あるいは exit と呼ばれています。もちろん、実際に引き出すことができるのは、deposit した額から off-chain での transaction 送信によって増減した額になります。
ユーザは exit において自身が引き出そうとする資産が確かに存在することの証明を提出する必要があり、先に出てきた state commitment をこのために使うことになります。ユーザの資産情報を mainchain にすでに書き込まれている state commitment から参照することで、off-chain での処理に関わらず exit に不正がないことを検証できるのです。
まとめ
ここまで紹介したのは Plasma 全体のエッセンスのようなもので、もう少し具体的な手順を追わなければ理解したという気持ちにはなりづらいかも知れません。しかし、特に Plasma を調べる上でいきなり具体から入ってしまうと、なぜ？の部分がシコリになって大きな遠回りをしてしまう、あるいは深い理解に結びつかないということが私自身の体験としてありました。そういったこともあって、この記事で述べたような前提・背景を理解しておくことには大きな意味があると思います。
第二弾ではより Plasma MVP にフォーカスし、実装の紹介などもまじえながら詳細な解説をしたいと思いますので、ぜひそちらも読んでください！
