目次
はじめに
本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
今回の内容
本記事は、最近盛んに議論されているPlasmaを改善する仕組みであるPlasma XTについての記事です。
前提として、Ethereumのスケーラビリティへの解決策、PlasmaやPlasma Cashについて理解をしておくことを推奨します。
第1章 ブロックチェーンのスケーラビリティ課題
まず、ブロックチェーンのスケーラビリティ課題、そしてPlasmaとはどのような技術なのか簡単におさらいをします。
現在のブロックチェーンには、同一ステートを全てのノードが保持するため、ネットワークがスケールしてもトランザクション処理速度を上げられないと言う制約があります。
Bitcoinでは秒間3トランザクション、Ethereumでは秒間10トランザクションあたりが最大値と言われています。
また、ブロックを生成する間隔もおおよそ固定されており、Bitcoinは約10分、Ethereumは約15秒ごとのブロック生成となっています。
このブロック生成にかかる時間を短く設定しているブロックチェーンも存在はしているのですが、ブロック生成間隔を短くすると、トランザクションの処理能力は向上するものの、セキュリティー面での懸念が生まれるなど、利便性と安全性とは互いにトレードオフの関係にあります。
現実的なアプリケーションとしてブロックチェーンを使うことを考える際には、必要なセキュリティを担保しつつ、このトランザクション処理能力を上げるということが必要となってきます。
現在では、このようなブロック生成間隔の短縮やブロックサイズの拡大といった、メインとなるチェーン本体の仕様を変えてしまうことなく、スケーラビリティを改善する解決策が盛んに議論されており、代表的なものとして以下の様なものがあります。
- オフチェーン
- サイドチェーン
- シャーディング
Plasma
Plasmaは上で挙げた例のサイドチェーンの分野にあたる解決方法です。
サイドチェーンの良さとして、サイドチェーン内ではメインチェーンとは独立した仕様でブロックチェーンを動かすことが可能です。
PlasmaはEthereumのEVMを利用し複数のチェーンを連携し、かつ階層的に深くし高速承認を実現したり、大量のトランザクションを Map Reduce的にタスク分割して処理することが可能です。
ただし、Plasmaの実現には課題がありました。ユーザーは自分が関わっているトランザクションを不正されていないか監視するために、ユーザー自身が関わる全ての階層のPlasmaチェーンをダウンロードする必要があります。
Plasma Cash
これを解決する手法として、デポジットしたトランザクションに順序を持った番号を持つNon Fungible Token（NFT）を振っていく手法がPlasma Cashです。このNFTはERC721として仕様が定義されています。
これにより、Merkle Treeで表現されているトランザクションツリー全体をダウンロードすることなく、自分がデポジットしたトランザクションに対応するMerkle Treeの枝のみを確認することによって、効率よくトランザクションを監視することができます。
しかし、そのようなPlasma Cashでも依然としてデータ量が大きくなってしまうという課題があります。
例として、下記のような想定でPlasma Cashチェーンを1年間運用した場合、どの程度のデータ量になるか考えてみたいと思います。
・とあるPlasma Cashチェーンで、Plasma Cashを用いて発行したコインの数量が 2^16 = 65536 であると仮定します。（この仮定はかなり小さく見積もっています） ・Hashが32bytesで、Merkle Proofを算出するために少なくとも16世代のHashを見なければならないとすると、1ブロックあたりのデータ量は 32 * 16 = 512bytes になります。 ・Plasmaチェーンのブロック生成速度が15秒に1ブロックだと仮定すると、1年間に生成するブロック数は年間の秒数（31,536,000sec.）を15で割ったものなので、31,536,000 / 15 = 2,102,400ブロックとなります。 ・算出したブロック数に、ブロックあたりのデータ量を乗じて見ると、2,102,400 * 512 = 1,076,428,800 bytes となります。 ・以上より、このPlasma Cashチェーンのデータ量は1年間で 1 GB強となります。 つまりPlasma Cashを利用するユーザは、不正を監視するために、1年間で1GB以上のデータを送受信する必要があります。
実際にはもう少し最適化される可能性がありますが、この不正を証明するためのデータサイズは、Plasma Cashチェーンのサイズに比例して直線的に増加します。
モバイル端末や組み込み機器等、計算上ストレージの制限があるものにはこのような大きなデータを持つことは難しいといえます。
そこで、この不正を監視するためのデータ量を少なくするために考えられた手法がPlasma XTです。
そういった意味では、Plasma XTはPlasma Cashをもう少し拡張した、Better Plasma Cashといえるでしょう。
それでは、Plasma XTではどのようにして不正監視のデータを小さくしているのでしょうか。
第2章 Plasma XTの手法
Plasma XTでは、ブロックのMerkle Treeとあわせて、コインの所有者を示す情報（アドレス、署名）を、一定のチェックポイントごとに証明データとして提出する仕組みを採用しています。
そうすることで、チェックポイントが正しければ、という条件付きではあるのですが、不正を証明するため最後のチェックポイント以降のデータを使うだけで済み、Plasmaチェーン全体を監視する必要がなくなります。
Crypto Ecnomics Signature Aggregation
しかしながら、チェックポイントに署名を置いていくのは結局データ量が多くなりそうな気がします。
そこで、Plasma XTで考えられているのはCryptoeconomic signature aggregationと呼ばれる手法です。
すべてのユーザの署名情報を公開するのではなく、特定の所有者が署名を提供しましたという主張だけを集約した状態で表現します。
例えば、4つのコインがあり、コイン＃0と＃3の所有者が署名を提供した場合、Plasmaチェーンの運用者はビット列として “1001”を発行します。
なおここでの「コイン」とは、Plasmaチェーンにdepositされる際にユニークなIDを割り振られたトークン（Non Fungible Token）のことを指すものとします。
チェックポイントがMerkle Treeで表現されていたとすれば、運用者がMerkle Root以外を公開しない場合、運用者が不正を行ったのかどうか確認することができず、運用者を全面的に信用するしかありません。
しかし、ビット列として全てのコインの署名状態を見ることができれば、ユーザー自身の署名情報が不正に書き換えられているかどうかは、ユーザー自身で確認することができます。
仮にユーザー自身が署名提出前であるにも関わらず、署名集約用のbitに1が立っていたりするなど、署名集約者によって不正に改ざんが行われていた場合、
ユーザーは署名情報を運用者に提出することで、不正証明のチャレンジを行うことができます。
図1 : #3と#0の所有者が署名を提出した場合のビット列
第3章 今後の課題
チェックポイントの肥大化
Plasma XTの考え方はPlasma Cashと比べるとベターな方法だといえますが、数百万や数千万のコインには対応できないかもしれません。
チェックポイントで利用するビット列は、コインの数（Non Fungible Tokenの数）に比例して直線的に大きくなります。
チェックポイント作成の拒否
現時点では、チェックポイントの作成はそのチェーンの運用者が行う想定になっています。
そのため、Plasma Cashチェーンの運用者がチェックポイントを作ることを拒否することも考えられます。
その場合はPlasma XTの恩恵は受けられず、Plasma Cashと同様の状態に戻ってしまうと言う危惧もあります。
まとめ
Plasmaの提案は主にEther Researchで議論されています。
まだ具体的な実装が少なく確定していない部分も多くありますが、近頃は日本国内でも盛んに議論され、Plasma専用の勉強会が開催されるなど注目度は日に日に高まっていってます。
Plasmaを実装しようとしているプロジェクトには、有名なものでOmiseGoやLoom Networkがあり、コードがGithubで公開されているものも一部あります。ぜひ、これらの実装もウォッチしてみてください。
参考資料
- https://ethresear.ch/t/plasma-xt-plasma-cash-with-much-less-per-user-data-checking/1926
- https://ethresear.ch/t/cryptoeconomic-signature-aggregation/1659
