4レベル進化で考えるPlasma、チェーン外のトラストレス

この記事は日置 玲於奈さん(極度妄想(しなさい)さん）に寄稿していただいたものです

はじめに

Ethereumのネットワークの手数料が定期的に高騰しており、’18年の6月〜7月間で最大700%のGasPriceの高騰、そしてトランザクションフィーのボラティリティはさらに激しく、以下のとおりです。

(縦軸のメモリは1Kずつ)

ここでこういった外部不経済を避けるため、メインネットからチェーン外への処理の移行は2017年にもRaiden、iExec、Aeternity、Enigma等の一部のプロジェクトで努力がなされました。Plasmaはこういった中の提案でもVitalikが発案したこともあり、もっとも大きなチェーン外への移行のムーブメントになっています。

Plasmaがエンジニアを惹きつける理由は、中央集権な子チェーンの中央を、メインチェーンでトラストレスに見張ることで、非中央集権にするという仕組みにあります。もっともコストの低いトラストレスとはどうやって実現するかという根源的な問題に近づくからかもしれません。今回は、既存の仮想通貨知識で構築できる、多少一般的ではないPlasmaについて、順を追って考えることで解説します。

さて、当然メインネットのブロックチェーンがトラストレスの保証を行うものであったため、チェーン外に適当に処理を放り出せばトラストフルになります。Plasmaでは、チェーン外の処理をとりまとめるオペレーターと呼ばれるノードが中央集権的に結果をチェーン内の管理コントラクトに提出し、そこに間違いがあれば任意のノードが指摘することで、オペレーターの処罰が行えます。故に、中央集権ノードを非中央集権的に監視するTrust But Verify型のトラストレスとなっています。この性質を1中央監視(仮)としましょう。

レベル1

では1中央監視(仮)をもっとも簡単に行う仕様はなんでしょう?
まず中央を作ります。

ここで一時話題になったCryptoKittyのonlyCEO関数をまず参考にしましょう。CEOだけがこのプロジェクトの全体コントラクトの更新を一時停止できる関数であり、中央集権的だと批判されたものです。

CEOに全ての署名付きトランザクションを集めて、CEOがまとめてコントラクトの関数にデータを送り、状態更新・資産移動を行うカンジにしましょう。CEOによる手数料建て替えシステムですね。

よって加える変更は

(1) onlyCEO関数によるトランザクション提出関数

(2)トランザクションを検証し、コントラクト内の残高・変数の更新を行う関数

この場合、受け取るトランザクションをCEOが選べてしまうという欠点があり、恣意的な502 Bad Gatewayができるので、偽造はできないが操作はできるいうトラストレスとは言い難いシステムとなります。

レベル2

では署名付きトランザクションのブロードキャスト(共有)と提出は相互監視の下で行いましょう。というわけで試しにCEOアドレスが提出するのではなく、PoWでマイナーがブロックを採掘してコントラクトにアップロードする形式をかんがえてみましょう。ブロックの中には署名付きトランザクションが沢山入っています。

ブロックの正当性確認をコントラクトで行います。ブロックここでコントラクトを使った検証関数が初めて出てきます。これがあたらしい中央監視(仮)です。

よって加える変更は、

(1)PoWによるブロック生成とアップロード

(2)コントラクトにブロック確認コード

おそらくこの仕組み、この時点ではお世辞にも知的とも実用的とも言えないでしょう。当然、

1. PoWにする必要はないのでは?
2. トランザクションをそのまま入れるのは非効率では?

という意見が出ると思います。改良しましょう!

レベル3

では1の承認方式の改良を考えます。コントラクトの中のトークン保有量と投票システムだけで作れるのでPoSがもっとも効率がよく簡単であると言えるでしょう。重み付きの投票を行い、ブロックのハッシュ値を決めることでつなげるブロックを指定・承認します。

次に2の効率的なトランザクションのまとめ方を考えましょう。当然普通に今までブロックに入れていたトランザクションを全部計算して、結果だけまとめてブロックに入れるようにするのでも実装できます。ここで問題なのは、PoS形式で承認してこれが間違っていても、承認側は痛くも痒くもないことです。痛く痒くするために、間違っていたら罰するようにしましょう。

間違いを検証する関数を用意します。これをchallengeと呼びます。challengeではEthereumで洗練された方法をそのまま使いましょう。つまりMerkleハッシュの値を比較することで、計算結果(アカウント情報)が一致することを確認します。この方法の最大の特徴は部分情報だけで全体が間違っているかどうか分かる点です。例えばですが、僕が20円、あなたが30円、サトシが100円持っている残高情報をハッシュ化する際に合計値を使うとします。正しい値は150です。この時、もしあなたの残高を0として提出された120というハッシュが間違っていることは、あなたが30円持っている情報だけでは証明できません。全員のデータを用いて初めて分かります。

一方、Merkleハッシュは木構造になっており、部分が間違っていることが分かればすぐに全体が間違っていることを証明できます。つまり、少なくとも自分の情報が正しく反映されているか、各々のノードが調べることができます。

これにより、自分の権利が侵害されれば、すぐにchallenge関数を使って通報し、承認した悪いノードかアホなノードを罰することができます。この際、残高を正すことは全体データを含むブロック自体を作らないと難しいです。つまりまともなブロックが作られるまで、challengeし続けます。

よって加える変更は

(1)トランザクションを子チェーンで検証・実行し、計算結果をブロックに保存

(2)マークルハッシュを利用した検証関数(challenge)

中央監視(仮)はchallengeと名付けられました。完成??いえいえ。この話の違和感を思い出しましょう。コントラクトの内側の話ばかりしていて、自分の資産は永遠にこの狭い世界に閉じ込められてしまうのでしょうか?

レベル4

コントラクトのナカミを見てみます。

コントラクトの中にいる内は、例えコントラクトの中に残高表があって管理されていても、コントラクトが資産を所有しています。コントラクト内の残高表はもしかしたらまた、オペレーターの不正提出によって一時的にイジられる可能性もありますし、何より、自分のアドレスに移さなければいつまで経っても他のサービス・コントラクトで使えません。
今あなたの資産は子チェーンのマークルハッシュの中に存在しています。このマークルハッシュを利用して、メインチェーンでコントラクトの資産になっているこの資産をあなたのアドレスに正式に移せなければなりません。

ExitやWithdrawと呼ばれるものです。当然ですが、子チェーン内での資産の移動と矛盾がない必要があり、Exit(資産退避)したのに関わらず、子チェーンで資産があるかのように振る舞うのは防ぐ必要があります。このためには、ブロックを作るノード、承認するノードは子チェーン内の署名・トランザクションだけでなく、コントラクトも見張らなければなりません。

よって加える変更は

(1)コントラクトから自分のアドレスへの資産送金

(2)ブロック生成・承認(PoS)の際にメインチェーンのコントラクトでのトランザクションの反映

レベル5でこの子チェーンとメインチェーンの関係を、そのまま新しい子子チェーンと子チェーンに持ち込むことで拡張するのを記したいところですが、この記事の主旨に反しそうなのでこの辺で。

ここまで子チェーンがシッカリしているなら、何故わざわざEthereumを使うのか?

お気づきの方はいらっしゃるかもしれませんが、これある程度子チェーンだけでもブロックチェーンとして機能しそうですよね?なぜ、わざわざEthereumを使うのでしょうか?

たしかにERC20トークン化すると取引所に上場しやすくなるなどの効果は無視できません。しかし、それより大きい根本的な構造があります。

Ethereumを使わなかったとして、子チェーンでの不正コストを考えてみましょう。1番コストの低い方法はPoSの重要ノードになってからブロック承認で間違ったブロックを作って選ぶことです。

Ethereumをつけた時は、PoSの不正はメインのコントラクトで暴かれ罰されるので、さらに追加されることになります。あるいはEthereumへの51%攻撃でしょうか?

このようにして子チェーンの不正コストを跳ね上げることが、Ethereumに管理コントラクトを置くことによって可能になります。つまりチェーンが”Ethereum並”の分散性を持つことができるということです。

この考え方を使えば、今ある脆弱な弱小チェーンや、プライベート・ブロックチェーンをトラストレス化して完成させる能力がPlasmaに期待できます。たとえばLoomのDappsチェーンはそのような段取りで有名なPlasmaプロジェクトとなりました。

結論として、Plasmaはスケールだけでなく、導入に関しても優れたムーブメントであることが期待されます。