2019.04.11

Plasmaフレームワーク

こんにちは。L.W.です。ビットコイン、イーサリアムなどのパブリックブロックチェーンに対しては、スケーラビリティの低さが重要課題となりつつあります。解決策としてあげられているのはレイヤー2におけるスケーリングソリューションで、サイドチェーンソリューションとも呼ばれています。今日はこのサイドチェーンの代表の一つのPlasmaソリューションについて、紹介します。

Plasmaとは

ビットコイン、イーサリアムでは、全てのトランザクションの処理はこれらのメインチェーンのみで行われるので、トランザクションが多くなると、チェーンはパンクします。全てのデータもこれらのメインチェーンに書き込まれるので、かなり手数料が掛かります。メインチェーンの計算の負担、データ記録の負担を軽減するように、サイドチェーンソリューションが考案されました。 2017年8月にイーサリアム創設者のVitalik Buterin氏とライトニングネットワークの共同開発者であるJoseph Poon氏によってPlasmaのホワイトペーパーは発表されました。（日本語版もありますよ。）イーサリアムのブロックチェーンをルートチェーンとして、階層的にプラズマブロックチェーンを接続していきます。ルートチェーンで余分なデータを保存する必要がなくなり、階層的に接続されたブロックチェーンで並行的に計算を行うことができるので1秒間に数十億のトランザクションが実行できると見込まれています。現段階の研究では主にPlasmaチェーンの1階層に注力しています。以下の形となります。

ルートチェーンでのスマートコントラクトと連携して、Plasmaチェーンは自身のチェーンでのトランザクションの処理とデータ記録を行い、最小限の情報だけルートチェーンに提出することで、ルートチェーンの負担を大幅に軽減することができます。レイヤ2スケーリングソリューションとして、スループットを大幅に向上できますが、最終のセキュリティはルートチェーンにより裏付けられるので、ファイナリティはルートチェーンに依存します。

例えば、ルートチェーンはイーサリアムとし、15-second block timeの場合、ファイナリティは数分が掛かります。（10 confirmationsの場合、3分位が掛かります。このVitalik のブログからすると、「ten confirmations (~three minutes) to achieve a [99.99% probability] of security」となります。）

Plasmaの進化

Plasmaはただ一つのプロジェクトではなく、「a framework for building scalable decentralized applications」を実現するために、多くのプロジェクトが取り組んでいます。以下のマップからすると、主に二つの方向に進化しています。左側のUTXOベースの簡単送金（Simple Transfer）方向と右側のアカウントベースのスマートコントラクトサポートの「ゼネラルステートとコンピュータ」の方向です。 Plasmaチェーンでスマートコントラクトを実行できるかはいろいろ議論されていますが、未だに結論に至らないようです。これに対して、UTXOベースの簡単送金の研究は盛んに行われています。本ブログは重点的にこれを紹介します。

出典：　https://ethresear.ch/t/plasma-world-map-the-hitchhiker-s-guide-to-the-plasma/4333

UTXOベースとアカウントベース

ブロックチェーン残高管理で使われている二種類のモデルです。ビットコインではUTXOベースを採用、イーサリアムではアカウントベースを採用しました。

UTXOベース

UTXO（Unspent Transaction Output）は、日本語で「未使用トランザクションアウトプット」と呼ばれます。簡単に言えば、過去の取引データから現在の残高を割り出す方法のことです。 UTXO はコインに例えることができます。 UTXOの優れている点を簡単に説明すると以下の通りです。

匿名性が高い
リプレイアタック耐性が強い
スケーラビリティが優れている
並行的に処理が可能

最大のデメリットはUTXOごとの署名の追加によるトランザクションサイズの増大です。

アカウントベース

アカウントベースはアカウントの残高を複雑な計算なしに直接データとして記録する方法です。クレジットカード、デビットカードに例えることができます。アカウントベースの優れているいる点は以下の通りです。

スマートコントラクトなどの複雑な処理が簡単
ウォレット上で簡単なシステムだけで実装ができる

イーサリアムがアカウントベースを選んだ理由については、興味がある方はVitalikのこの文書を読んでいただければと思います。

PlasmaチェーンでUTXOベースを採用する理由

一言でいえば、Plasmaチェーンでの資産をルートチェーンに戻す（Exit Game）設計のしやすさにあります。 PlasmaチェーンではUTXO単位でExitを行うので、不正なExitがあっても関係するエンドユーザーによるチャレンジも容易に行うことができます。チャレンジ（Challenge）もUTXO単位となります。

Plasmaチェーンの構成

Plasmaチェーンコンセンサス

PoA（Proof of Authority）、PoS(Proof of Stake)、DPoS(Delegated Proof of Stake)なども利用できます。PoW（Proof of Work）は効率が悪く、コストが高いことがあるので、採用しないほうが良いと言われています。

PoAが一番多く採用されています。PoAとは直訳すると「権利の証明」となり、その名の通り信頼された参加者のみがブロック生成の権利を持つコンセンサスアルゴリズムです。 Plasmaチェーンでのブロック生成者は通常一つのマイナーに任せます。このマイナーはOperatorと呼ばれます。このOperatorの役割は、Plasmaチェーンで発生したトランザクションを処理し、定期的にPlasmaチェーンのブロックに格納し、トランザクションのMerkle Rootハッシュをルートチェーンに送信することです。 PlasmaチェーンでのPoAの設計により、block timeはカスタマイズできます。

スマートコントラクト

スマートコントラクトはルートチェーンにデプロイされます。最低限、以下の機能を備えなければならなりません。

Deposit

Plasmaチェーンへの入金となります。送金者、送金額、送金のタイムスタンプなどの情報をハッシュ値にして、ルートチェーンのスマートコントラクトに記録し、Plasmaチェーンに向けて、depositが成功したイベントを発行し入金された旨を伝えます。 Plasmaチェーンではこのイベントを受けて、ただ一つのdepositトランザクション（UTXO）のブロックを生成します。

Withdrawal/Exit

UTXOごとにPlasmaチェーンから離脱となります。不正Exitすることを防ぐために少額の保証金(Security deposit、あるいはEXIT BOND)が設けられています。不正の疑いを他者が申告（チャレンジ）できるようにするために離脱期間（EXIT PERIOD）も設けられています。 Exit提出者のUTXO、Merkle Tree Proof、署名など情報をスマートコントラクトに提出し、検証されます。離脱期間（EXIT PERIOD）内では、チャレンジが無ければ、あるいはチャレンジ失敗した場合、FinalizeExitでルートチェーンに戻ります。不正Exitと証明されたら、EXIT BONDを失い、Exitもキャンセルされます。

Challenge

Exitに不正を行なっているかExitに対して不正申告を行うことです。チャレンジするためには、ローカルにある証拠（UTXO、Merkle Tree Proof、署名などの情報）をスマートコントラクトに提出します。そのためにエンドユーザーは定期的にオンラインしなければなりません。チャレンジが成功する、つまり不正行為を見つけることができた場合はこの保証金を報酬金として与えられます。

SubmitBlock

OperatorはPlasmaチェーンでのトランザクションを検証し、トランザクションのMerkle Treeを構築します。Merkle Tree Rootのハッシュ値をスマートコントラクトに提出します。 Plasmaチェーンでのトランザクションは幾つあっても、最終は32バイトのハッシュ値が提出されます。注意を払うのは、トランザクションのMerkle Treeのブロックではdepositトランザクションを含めないことです。 depositトランザクションのブロックと通常のトランザクションのブロックはPlasmaチェーンではっきり分けられています。こうすることで、効率がよくなると言われています。詳しくはこのリンクに参照して頂ければと思います。

ブロックとトランザクション

ブロックタイムは何秒か、何分かカスタマイズできます。ブロックサイズはブロックに収まるトランザクションによります。トランザクションの数はMerkle Treeの階層に関わります。Merkle Tree Proofは通信帯域（Bandwith）に関わります。 Plasmaチェーンでは、Operatorも信頼できないことを前提で、不正UTXO、不正Exit、不正Challengeの検証を行うためには、そのトークンの履歴（Plasmaチェーンにデポジットされてから、誰から誰に送られてきたか）とMerkle Path Proofをクライアントにダウンロードし、二重支払いを行なっていないか検証するも可能となります。全てのMerkle Treeデータをダウンロードするか、それとも部分にダウンロードしてもいいか、設計により異なります。ローカルにMerkle Treeデータの保持により、Plasmaチェーンで不正を行っても、あるいはPlasmaチェーンはダウンとなっても、ローカルの情報を証拠として自分の資金は守られます。

Exit Game

PlasmaチェーンのExitでは、以下のようなケースが想定されています。これらの攻撃に耐えられるかが、Plasmaチェーンのセキュリティーに問われるところです。

Exit Spent Coin Challenge

離脱者（Exiter）は既に払い済のトランザクション（Spent Tx）でExitしようとする場合、チャレンジ（Challenger）は自分の所有するトランザクションでこのExitをキャンセルします。

Exit Double Spend Challenge

離脱者（Exiter）は2重払いのトランザクションでExitしようとする場合、チャレンジ（Challenger）は2重払いのことを証明することで、このExitをキャンセルします。

Exit with Invalid History Challenge

離脱者（Exiter）は履歴に不正のあるトランザクションでExitしようとする場合、チャレンジ（Challenger）は最新の有効な履歴の提示することで、このExitをキャンセルします。

Block Withholding

Operatorはトランザクションをブロードキャストせず、Block Withholdしようとする場合、不正ExitにChallengeするエビデンスがなくなります。このケースでは、Confirmation Signatureメカニズム（Plasma MVPが採用した方法）あるいはExitの優先順位付け（Plasma Chamberが採用した方法）でExitをキャンセルします。

　上の図の出典：https://karl.tech/plasma-cash-simple-spec/

Plasma MVP

Plasma MVP（Minimal Viable Plasma）は、2018年1月、VitalikがJoseph PoonおよびDavid Knottの協力で、Plasma MVPの規範として発表しました。幾つかのプロジェクトはPlasma MVPを実装できました。有名なのは、OmiseGoの MVP 実装となります。ただいずれも研究段階となるので、プロジェクトレベルに達していません。始めてVyper言語でスマートコントラクトを実装したプロジェクトもあります。LayerXcom社のplasma-mvp-vyperとなります。

MVPでは、Operatorはフルノードを構築し、全てのトランザクションを集めて、Merkle Treeを構築します。トランザクションのMerkle Tree Rootをルートチェーンに送信し、ルートチェーンのブロックに記録させます。UTXOの2重払いを防ぐためにPlasmaエンドユーザーも全てのトランザクションの履歴をローカルに保持し、同じMerkle Treeを構築します。

Plasmaエンドユーザーが全てのトランザクションの履歴を保持する理由はセキュリティを維持するためです。Operatorを信頼しなくても良いように、自力で保持します。

Plasmaチェーンのセキュリティを維持するためには、以下のコンセンサスが取られています。

不正な履歴があるUTXOでのコインを受け取ってはいけない。（取ったら、Challengeチャレンジされて、Exitできない）
履歴は不正ExitにChallengeするためのエビデンスとなる。（上のExit Game部分の参照）

以下はMVPの課題です。

エンドユーザー（Plasmaウォレット）の肥大

UTXOのMerkle Tree採用で、不正を検挙するためには、エンドユーザーは全てのデータをダウンロードしなければなりません。トランザクションの追加につれて、ローカルに保持する履歴のサイズはどんどん肥大化します。履歴データの送付にも問題となります。

Mass Exit

攻撃者が大量の不正なExitリクエストを大量に送り、トランザクションを詰まると、正常なExitが妨げられてしまいます。自分の資産を守るためには、不正があったら一定期間以内に全てのUTXOをルートチェーンに戻さないといけない。

Confirmation Signature

攻撃の中でBlock Withholdingがあるので、これに対抗するために、confirmation signatureメカニズムを導入しました。 OperatorはBlock情報をブロードキャストせず、Block Withholdしようとする場合、送金者はconfirmation signatureしないことで、不正を防げます。但し、一つの送金に対して二回署名が必要になるなんて、UXではよくないと指摘されています。

Plasma Cash

2018年3月、Vitalik、Karl FloerschおよびDan Robinsonの三人がPlasma Cashを共同発表しました。デポジットするそれぞれのトークンに対して、特有のTokenIDを与え、異なるTokenIDのトークン毎にブロックのMerkle Treeでの固定のポジション（Each block has a ‘slot’ for each coin (unique deposit)）を割り当てます。

これにより、ユーザーは自身のTokenIDとマークル木のインデックス番号を照合するだけで、そのトークンは有効であることが証明できます。 Plasma Cashでは、TokenIDが1のマークル・ブランチの履歴を送り手に提示するだけでOKです。他の関係のないTokenIDに関するデータは一切必要ありません。これで、エンドユーザーがPlasmaチェーンのデータを全てダウンロードする必要がなく、TokenIDと関わるブランチだけローカルにダウンロードしても十分です。

Sparse Merkle Treeの導入で、さらなるLight client Merkle proofを実現できました。 Sparse Merkle Treeとは、簡単に言えば、階層数が固定となり、ツリーのリーフにインデックスが付けられ、各データポイントがそのデータポイントのインデックスに対応するリーフに配置されることです。O(logN)の計算量でトランザクションの存在証明(inclusion-proof)、非存在証明(exclusion-proof)を検証できます。 Plasma Cashはトランザクションの履歴を激減できましたが、依然として以下の課題があります。

NFTしか対応できない（NFTs only）

Plasma Cashにおいてはデポジットしたトークンに対して固有のTokenIDが割り当てられ、それらは分割したり結合したりすることはできません。

トークンの一部送金（Partial Spending）問題を解決できません。

Plasma CashFlow

Plasma CashflowはPlasma Cash、Plasma Debit と Plasma Defragmentationをベースに、さらに改良されたものです。トークンの一部送金問題を解決できました。

MVPではコインをUTXOプールとされることと異なり、Plasma Cashflowでは、コインを数字横軸でのレンジ（Range）として扱われています。

これで、Plasmaチェーンでのコインを特定できます。

上図のように、アドレス0x3からアドレス0x4に0.5ETHを送金する場合、レンジを使うことで、実際にこの0.5ETHは判別できます。このトランザクションは以下のように設計できます。

-startpoint (4 in this case)
-endpoint (4.5 in this case)
-recipient (0x4 in this case)
-signature (0x3's in this case)

Plasma CashflowでのExitはこのレンジを単位とするので、Exitは以下のように設計できます。

-startpoint
-endpoint
-claimant

Mass Exit攻撃の退避

この設計で、MVPでのMass Exit攻撃を解決できます。

Plasma MVPでは、Operatorは不正な（「どこにも存在しない（out-of-nowhere）」）トランザクションを作成し、このUTXOを使用して不正なExitを作成する可能性があります。エンドユーザーのローカルではだれでもこの（無効な）履歴を保持していないので（Operatorによりwithholdされたなど）、このExitは適切にChallengeすることはできません。

レンジの導入によって、Mass Exitを回避でき、Operatorは資金の不正Exitは出来なくなります。

例で示すように、今回は、Exitの申請者が自分たちがやろうとしているレンジを指定することを強いられ、正当な所有者は所有権証明にChallengeすることができます。

自分の資産を守るためには、常にオンラインして、自分の資産と関わる不正なExitをChallengeします。Challengeは、Exitしようとしているレンジで特定のトークンの無効（レンジの重なること(range overlap)）があることを証明する必要があります。 1つのトークンが無効であることを証明すると、Exit全体が取り消されます。

クライアントの軽量化（thin clients）

Plasma CashではSparse Merkle Treeの導入により、軽量(lightweight)なMerkle Path Proofを実現できました。特定の範囲のトランザクションは特定のブランチでのみ有効という設計でブロック全体をダウンロードせずに安全性を確認できることです。

Plasma Cashflowでは、レンジでコインを判別することで、range-basedのトランザクションの設計で軽量(lightweight)なMerkle Path Proofを実現できるはずです。

但し、通常のMerkle Treeでレンジをブランチで監視できるようにしただけでは、他のブランチの内容が見えないことから問題が発生しやすくなります。 Operatorは2つのブランチをわざと重複させて、2重払い（double spend）が行えます。

2重払い（double spend）を防ぐためには、エンドユーザーは全てのデータをダウンロードしなければならない。これで、軽量のクライアントの実現は不可能となります。

Treeのストラクチャーをちょっと改良し、Treeのブランチ（branches）にsumを追加することで、軽量(lightweight)なMerkle Path Proofを実現できました。これは、Merkle Sum Tree(またはSum Merkle Tree) と呼ばれています。

（以上の図の出典：https://ethresear.ch/t/plasma-cash-was-a-transaction-format/4261）

この構造では、各merkleノードは、その2人の子によってカバーされる合計範囲を合計します。これで単一のブランチを作成して、それを使用してレンジを左右に合計し、それらが自分のレンジと一致することを確認できます。

このMerkle Sum Treeで、2重払い（double spend）を防ぐことが証明されました。

Plasma Cashflowの課題

Plasma Cashflowはトークンの一部送金問題を解決できましたが、課題もあります。

Thin Client（軽量ウォレット）の実現

トランザクションの取引の回数につれて、トランザクションの履歴は線形的に増えます。セキュリティを保証した上で、履歴の削減ができるかが課題です。

Defragmentation Strategies（断片の整合）

トランザクションの取引の回数につれて、Rangeで連続できないコインが大量に生成されることが見込まれます。

トランザクション断片の追加につれて、Exitのコストがもっとかかる、かつエンドユーザーのトランザクションの履歴も増えます。

Automated Guarding（自動Challenge監視）

不正Exitを迅速に検知し、Challengeするのはエンドユーザー（Plasmaウォレット）に頼ります。つまり、エンドユーザーは常にあるいは定期的にオンラインしなければなりません。オフラインの内に、Challenge機能は起動せず、Exitを見逃すリスクが高いです。

Plasma Chamber

Plasma Chamberは日本福岡のスタートアップ企業である会社Cryptoeconomics Labにより開発されている汎用Plasmaを生成するフレームワークです。 Plasma Cashflow をベースにし、もっと複雑な機能を実装できました。

Plasma Chamberのアーキテクチャにより、サービスプロバイダとそのユーザーは、ルートチェーンから派生するセキュリティを犠牲にすることなく、低いトランザクションコストと高いスループットを利用できます。 Plasmaチェーンブロック上の複数のトランザクションデータを束ねて、それをルートチェーン（この例ではEthereumブロックチェーン）に送信するプロセスによって達成されます。

　出典：https://github.com/cryptoeconomicslab/plasma-chamber

ChamberでのUTXOはセグメント（segment）の形で管理されています。

class Segment {
  tokenId: BigNumber　//トークン種類（ETHか、ERC20から）
  start: BigNumber　　//レンジのスタート
  end: BigNumber　　　//レンジのエンド
}

Defragmentation

fragmentationが多くなる場合の課題

マイクロペイメントの応用ではトランザクションが頻繁に発生するため、fragmentation（トランザクションの断片、お釣りと認識してもOKです）が多くなります。これは望ましくありません。

fragmentationが多くなる場合、以下の問題をもたらします。

Exitコストの増加

Exitにかかるガスはセグメントの数に関連し、セグメントの額面には関連しません。

segmentごとにExitする構図なので、セグメントの数は多ければ多いほどガスがかかります。

defragmentation機能により、断片化したsegmentをまとめてexitすることでガスコストを下げます。

トランザクションの履歴検証効率の低下

送金する時には、送り手側はセグメントのトランザクションの履歴を受け手側に送信し、受け手はこのセグメントの正当性を検証します。セグメントのトランザクションの履歴はセグメントの数と関わり、セグメントの額面と関わりません。セグメントの数は多ければ多いほど、セグメントのトランザクション履歴の検証に時間が掛かり、非効率的となります。

defragmentation機能により、segmentのトランザクション履歴も圧縮でき、送金の受け手側のトランザクションの履歴検証の効率も向上できます。

Plasma Chamberでの対応

Plasma Chamberでの最適化にはいくつかの重要な要素があり、それらの重要な機能はすでに実装されています。

Atomic Swap of segments

現時点では、セグメントを交換している2人のエンドユーザー、理論的には送金の送信者と受信者は、両方が同時にオンラインになっている必要があります。これは、取引の発行後に確認署名（confirmation signature）を交換する必要があるためです。

Force Include

confirmation signatureが揃わなかった時のためにforce includeでSwapを実現しようとしています。

ウォレットのdefragmentationの実装

完全なdefragmentation機能を実現するための取り組み

現状のDefragmentationの機能は限られている（関係するエンドユーザの同時オンラン）ので、Operatorを仲介として、swapを行うという案が考えられています。

以下のはデフラグの処理プロセスの一例となります。

出典：https://github.com/cryptoeconomicslab/plasma-chamber/wiki/Defragmentation

Fast Finality

ファイナリティとは、トランザクションが特定のブロックで記録されると、その履歴が永遠に残ることを意味し、その操作を元に戻すことはできません。

Fast Finality機能を利用する場合、上手く設計できれば、ファイナリティはミリ秒レベルに抑えられると言われています。

ステートチャンネル（State Channel、ビットコインのライトニングネットワークも利用）の技術と似ているものと言われています。

merchant（店舗）との取引では、ファイナリティが一番重要になります。オペレーターの仲介によるFast Finalityを利用することで、トランザクションのファイナリティは直ぐに決まります。保険やファクタリングと似た「損失補填コントラクト」からいつでもお金を引き出せるので、店舗ユーザーが安心してTxを受け取れます。

以下のステップで行います。

1. ユーザがトランザクションに署名をして、merchantに送信します
2. merchantはオペレーターにトランザクションを送信します
3. オペレーターはトランザクションに署名して、merchantに返却します

2重払い（あるいは一定期間中にTxはPlasmaブロックに書き込まれていない（transaction didn’t get included into a Plasma chain block in a certain period））の場合、関係エンドユーザーはSecond disputeを通してOperatorにチャレンジでき、自分の資産も守られます。

以下はシナリオとなります。

　出典：https://github.com/cryptoeconomicslab/plasma-chamber/wiki/Fast-Finality

（このdisputeシナリオは、筆者もまだ完全に理解しておらず、ソースを確認中です）

Checkpoint

Checkpointのストラクチャー

struct Checkpoint:
  owner: address
  blkNum: uint256
  # 8bytes tokenId, 8 bytes start, 8bytes end
  segment: uint256
  isAvailable: bool
  finalizeAt: uint256
  challengeCount: uint256

Checkpointのプロセスを理解するにはこのリンクを参照してください。（筆者もまだ研究中です）

履歴の検証にあたり、起点がdeposit transactionからcheckpointに変わるので、エンドユーザーはその前の履歴を持つ必要なくなります。これで、トランザクションの履歴はかなり軽減できます。

どれくらい軽減できるかは以下のように試算されています。

出典：https://github.com/cryptoeconomicslab/plasma-chamber/wiki/Checkpoint

まとめ

Plasmaの有識者の不断の努力で、Plasmaは進化し続けています。ペイメントにの実用化に段々近づいている気がしますが、以下の課題をクリアしないといけないと思われています。

プロダクト実用までまだ道が遠い

スマートコントラクトのAudit、Exit Gameの数学的証明など現時点では見えづらいです。

クライアントのオンランが必須

UTXOのExit期間中に、クライアントは最低一回でオンランしないといけないです。Exit期間は、クライアントのオンラインになるべき頻度と関係します。Exit期間を定めるのは容易ではないかと思います。大きくするとUXが悪いし、小さくすると不正Exitを見逃すリスクがあります。

Automated Guarding（自動Challenge監視）技術が望まれているので、zk-SNARK技術をPlasmaに応用する研究は進んでいます。

軽量ウォレットの実現

ウォレットのローカルでUTXOの履歴を保持しないといけないので、ビットコインでのSPVウォレットのように実装できないです。上のChamberの試算からすると、UTXOの履歴のサイズはまだまだ大きいです。RSA accumulator技術で取引履歴の圧縮の研究が進んでいます。これからどこまでウォレットは軽量化できるか、見守っていきます。

さいごに

　今回はPlasmaフレームワークの概要を紹介させて頂きましたが、これからPlasma Chamberの実装に注目して、研究したいです。研究結果を次期に共有します。お楽しみにしてください。

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。皆さんのご応募をお待ちしています。

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

Follow @GMO_RD