Plasmaのミニマル要件を簡単な日本語で列挙
概要
1. ルートチェーンRにぶらさがるPlasmaチェーンPを作成
2. Rのdepositコントラクトにロックされた資本がPの中でUTXOを生成する
3. R上のPlasmaコントラクトのwithdrawal関数により、PのUTXOは削除される
4. 定期的にPのブロックヘッダをRのcommit関数に入力する
5. ブロックヘッダは状態遷移を証明するために十分な情報をもっている
6. P上の不正な状態遷移はRのコントラクトにあるfraud-proofs情報によってロールバックされる
7. R上のコントラクトに対するExitトランザクションのリストは、過去のPのブロックによって不正なアウトプットの失敗を確認するために優先づけられる
8. fraud-proofsに必要な情報がblock withIfolding攻撃の影響を受けたら、PからRへのmass exitをする
Plasmaの軽量な仕様
入金 (Deposit)
1. デポジットをする人は資産を送る to Plasma contract C
2. Cはdepositトランザクション(TxD)の証明をルートチェーンに作る
3. TxD はコンパクトな証明とともにコミットされる in Plasma block (Pb1) (who does this)
4. もしこのPlasmaチェーンのdeposit情報を含んだトランザクションを含んだブロックがStakerにwithholdされたら, deposit は復旧可能 (どうやって? race conditionなどを含めて考える)
5. デポジットをする人はTxDをPlasmaに署名して提出する
6. TxD は確認される in plasma block (Pb2)
7. Plasma内でDepositされた資産の利用準備が整う
8. もし5が終わらなかったら
9. withdrawトランザクションをルートチェーンに「多めの供託」とともに提出する
10. 「かなり長い時間」待つ
11. withdrawの残高の詐欺が証明されたら, 供託を失う, そうでなければ withdrawを行う (race conditionについて考える)
支払い (Spending)
1. 支払いのトランザクション(TxS) に署名してP上でブロードキャストする
2. TxSの入ったブロックがwithholdされた際は、Aliceはルートチェーンに使用されたコインをwithdrawalできる
3. TxSがPlasma Block 3(Pb3)内で確認されるまで待つ
4. TxSの入ったブロックがwithholdされた際は、どちらの側も引き出しができる (ブロックチェーンなのに非決定論的処理!)
5. Bobは “acknowledgement”に署名して、TxAckを送信する
6. TxAckの入ったブロックがwithholdされた際は, Bob は withdrawできる (race condition)
7. TxAck が Plasma Block 4 (Pb4) に取り込まれる
8. Challenges - 異議申し立て:
a. 支払われたコインのトランザクションアウトプットが引き出し中じゃないか検証する
b. 支払い済みのUTXOを支払いを試みていないか検証する
c. ブロックが正当か検証する
引き出し (Withdrawal)
1. 署名済みwithdrawalトランザクション(TxW)のアウトプットだけを以下の情報とともにRに提出する
a. アウトプットのうち、引き出しに使うもののビット位置情報
b. 「かなりの量」の供託
2. 異議申し立て(challenge)可能期間のあいだ待つ
3. 異議申し立てというのは「プルーフオブ『もうこのアウトプット使われてます』」のこと(MerkleTrieに対する不存在確認として実装されるはず)
4. もしchallengeが成功したら、供託は没収される
5. それ以外の場合: よりブロック高の低いblockのタイムアウトを待つ
6. 誰でもパブリック関数であるfinalizeExitを呼べる
7. finalizeExit関数はUTXOの作成時間で優先度をつけられる
緊急退避 (Mass withdrawal/exit)
1. Aliceはmass exitを他の参加者と実行するために調整を開始する(mass exitはブロック生成停止やtx選択除外などを検知したときに要請されるセキュリティモデルであり、1. ユーザーの資金保全 2. チェーンの調査復帰 を目的としてデザインされている. 資金保全が第一目標なので復帰に関しての議論はまだ少ない)
2. Patさんは資金の逃げ先を調整する(直接の親じゃなかったら資金ロックアドレスがないから逃げられないというわけではなく、ロックを解かずに別の子チェーンの資本として付け替えることができるような書き方になっている。しかし、爺チェーンに移動させることは合理的でないし、叔父チェーンも同様に合理的ではない。「兄弟チェーン」か「親チェーン」くらいしか選択肢はないだろう)
3. Patは参加者に目的地となるチェーンを知らせる
4. Patは参加者から署名を集め、資本の可用性の正当性を確認する
5. 不正な資本の参加者は除外する
6. 「大量の供託」とともにexitトランザクション(TxE)を作る
7. 全参加者の署名をTxEに得る
8. 署名をしないユーザーは除外する
9. 他にTxEが別のチェーンから作られていないか確認する (例えば自身の子チェーンからTxEが来ていた場合、典型的な4要素連想配列の中間要素同時削除によるrace conditionに陥りうるため、2 phase commitおよびそれ以上の故障モデルを想定した分散ロックアルゴリズムが必要になる)
10. 他のTxEの中に重複TxEがあれば除外する
11. 9にもどる
12. 親ないしはルートチェーンにブロードキャストする
13. exitしていることの「状態のbitmap二分木」をpublishする(二分木の枝がbit値で決定される木は、少ないデータ量でMerkleTrieを記述できる)
14. もし重複するwithdrawalがある場合、bitmapと残高を更新する
15. Mass exitが異議申し立てられた場合:
16. 異議申し立てを供託とともにブロードキャストする
17. If withdrawal challenge is not disputed Mexit is cancelled
18. If challenge is disputed, challenge the dispute with “large” bond
19. Dispute challenger should produce a valid spend or dispute is cancelled
20. それ以外の場合: 供託は没収される
21. ファイナライズのために数週間待つ
課題
入門向けじゃなく理解を阻むので省略します(ソースの英文を呼んでください)
抄訳
race conditionの存在について
Mass Withdrawalの仕様が曖昧という指摘
数億txいけるよという根拠となる計算が曖昧という指摘
MapReduceを実装するとデータをRootchainから子チェーンに送らないといけず高額で相性が悪いという指摘
---
*ビタリクはコメントで「PlasmaMVPやりゃええやん・・・」と消極的だった
*この情報はLeverjチームがまとめてくれた