plasma.md

軽いアイデア出し

• 目的 Plasmaの論文で触れられていた2階層以上のPlasmaチェーンについて、本当に意味はあるのか、攻撃方法はあるのか、実装はどうすればいいのかなどを考え実際に実装してみる。

• 通常のEthereumはチューリング完全にワールドステートを変更する必要があり、そのためユーザーが好きにコードを書け自由に動かせる。

• これから作るPlasmaチェーンにはVMはいらない。送金の機能と、下位チェーンからのSubbmit block、exit、depositだけ組み込めればいい。

• Plasma MVPが上位チェーンにしている機能をほぼそのまま実装する。ただ検証や状態変移関数はスマートコントラクトではなくクライント組み込み。 こうすることで、2階層以上のブロックチェーンの実装が非常に簡単になる。

• Plasma MVPで組み込みPlasmaコントラクトを実装するために一番楽な方法

  • 2 way pegのやり方を真似するのが楽そう
  • 既にあるフィールドを変えたくない場合、Counterpartyのように特定のアドレスにPlasmaチェーン内で送金（Burn）する
    • この場合、そのアドレスだけがPlasmaチェーンの中で特別扱いされる
    • Burn、もしくはUnBurnする人間以外はそのアドレスの存在を知る必要はない?
      • いや、トランザクションを遡っていくときに見つけるので理解する必要がある
    • そのアドレスをハードコードする必要がある
      • アドレスの先頭prefixを勝手に変更してロック専用アドレスにする?
  • Plasma MVPがState型のEthereumの子で動くことを前提にしているので、UTXOの子で動かすのは難しいかも
  • ブロックの情報をPlasma MVPチェーンにどうやって取り入れよう
    • 自分自身に同じ額を送金するトランザクションを作ればデータの保管自体は可能。
  • アドレスに意味を持たせる、Bitcoin script?

• Ethereumより下位のチェーンはストレートがそこまで高価ではないので、マークルルートだけじゃなくてツリー本体を保存してもいいかもしれない。 ->その場合機械的にdouble spend判定ができる。ユーザーのchallengeがいらない。

• 不正な状態遷移のUTXO Contractが存在した時どうする？ →認めない。正しいブロックがコミットされないと送金や下位チェーンの遷移を決定したと見なさない。これは従来の一階層のPlasmaで偽のブロックがsubmitされた時と同じ考え。 不正なブロックをいくつsubmitしたところで、Exitするときにはマークルツリーにトランザクションが含まれている証明をしなければならなない。

以下、ether researchに載せる内容

---

階層的なPlasmaの提案

私は、Plasmaのwhite paperで、Plasma chainが多階層になる例を見ました。 そこで、2より深い階層のPlasmaチェーンを作成する場合の実装方法、問題点、解決方法を提案します。

階層的なPlasmaの目的

さらなる手数料の減少、データの圧縮が考えられます。ただ私には具体的な利用法が思いつきませんでした。

Plasma MVPでの実装アイデア

Plasma MVPのPlasmaのコントラクトとしてPlasma MVPでコントラクトが動作しなければならない。特殊なUTXOで表現する。これをUTXO Contractと表現する。

• 新しく、ContractFlagフィールドを作り、そこが0x01だとPlasmaのアドレスだとみなす
• 新しく、Stateフィールドを作り、そこにrootとtimestampを入れる
• 提出されたBlockデータは、自分自身に送金するトランザクションのStateに含まれる
• ContractFlagが0x0なUTXOと自身をInputにする場合はDepositしたということになる
• Exitする場合、ContractFlagが0x01なトランザクションをInput1、ContractFlagが0x01でOutput1(newowner1)が自身のアドレス、Output2(newowner2)がExit先のアドレスを示すトランザクションを作る。

これにより、上位のチェーンではトランザクションが使用されているかどうか、で有効なトランザクションがそうでないかを判別できる。 今回　EVMやBitcoin scriptのような汎用仮想マシンを利用しなかったのは簡単化のためです。おそらくそれらを使用しても同じことができます。今回はクライアントの組み込み実装により動作を決定します。

不正なマークルツリー変更がされ、ユーザーがChallengeをする場合

従来通りexitするUTXOがspentな証明をする。 1.「exitしようとしているトランザクションが含まれているブロックの高さ」 2.「exitしようとしているUTXOをInputにするトランザクションがある証明」 3.「2が、1とり後のブロックに含まれている証明」 4.「そのトランザクションが正しい証明(署名など)」 - 以上4つを提出する。 - 提出方法は、ContractFlagが0x01なトランザクションをInput1とOutput、ContractFlagが0x03、Stateに以上4つを含めたトランザクションをブロードキャストする

オペレーターはContractFlagが0x02なトランザクションをInputとしてContractFlagが0x01なトランザクションを作り直す。ContractFlagが0x02のトランザクションをInputにできるのはContractFlagが0x01のトランザクションのみ。

Ethereum conractとUTXO contractが従わなければいけないルール

Ethereum contract UTXO contractで従うルールを示します。 - ContractFlagが0x02なトランザクションはExitできない - ContractFlagが0x01なトランザクションはExitできない - skip exitの実行 - rebase exitのためのexportBlocks()の実装

下位チェーンで争う場合、つまり不正exitに対するchallengeが合った場合に、上位チェーンはExitを却下しなければならない。どんどん上告していくことは可能である。そのため、チェーンは自分より下に存在する全てのチェーンをチェックできる必要がある。

2階層 Plasmaでの送金について注意すべきこと

ユーザーは自分の送金が最上位であるEthereumブロックチェーンに記録されているか確認するため、自分が送金したトランザクションを含むチェーンより上の全てのチェーンを監視し、整合性を確認しなければならない。

想定される攻撃方法

1. オペレーターspentなトランザクションをexitさせる攻撃(従来のもの)
2. 下のチェーンで、オペレーターがブロックを生成しない嫌がらせをした場合、もしくはトランザクションをブロックに含めない嫌がらせをした場合

1番目に対しての解決策として、今まで通り上位のチェーンにmerkle proofを提出しchallengeすることができる。

2番目の問題に対して説明する。 下の全チェーンのオペレーターが全員悪人な場合、お金を取り残すユーザーが出てくる。 一番大事な点は、一番上の実際にトークンやETHをプールしているスマートコントラクトはEVMで動いており、オペレーターはおらず、必ずEVM bytecodeどおりの振る舞いをするということ。ルートチェーンでの安全性はPoWにより担保されている。 Exitについて、3つexitの方法の提案がある。このうちskip exitとrebase exitはこの攻撃に対する有効な解決方法になるだろう。

Normal exit

通常通りExitをする。

Skip exit

一番上のEthrerum contractに、下位の全部のチェーンの情報をすべてmerkle proofとして提出する（UTXOもブロックチェーンも大きなハッシュツリーである） Ethereum contractは全て検証し、Deposit eth poolからユーザーが持っている分の量のETHを強制的にExitさせてあげればいい。これをskip exitと呼ぶ。

Rebase exit

2番目、3番目にあるplasmaチェーンが、exitのために直接Ethereum Contractを作り、そのチェーンが持っているETHの総量分だけpoolから新しいコントラクトに送金する。 また、1番目のPlasmaチェーンの中にある2番目のPlasmaのUTXO contractを無効化する。 そこにブロックのデータをエクスポートする。 この場合、自分より上のチェーンを待たずにExitできる。 つまり、手数料と速度低下を引き換えに安全にExitできる。