PlasmaはマークルツリーでTxが特定のブロック高にいたことを存在証明します。これが必要な理由は、チェーンから出るときにまつわる親チェーンコントラクト（exit, challenge）で使われるからです。「Tx処理の安全な外注（オフロード）」がしたいから、価値を取り出すそのときまで、なるべく親チェーンに負荷をかけたくないという設計ですね。

存在証明だけでは親チェーンさんは引き出し金額にyesと言ってはいけません。存在（Tx）を無から作りだすことはオペレーターにのみ許されています。そう、ちょうど親チェーンのDepositイベントに応じて最初のTxを子チェーンに反映させるみたいにですね。

じゃあ、あと、どんな情報があればお金の引き出しにyesと親チェーンに言わせても安全なのでしょうか？これは質問が逆です。「十分な目玉の数さえあればバグは恐るるに足らぬ」と言ったのはLinusだったでしょうか、逆転の発想で、「どんな情報がしばらくこなければ引き出しにyesと言えるのだろう」と考えましょう。つまり、「履歴不正証明」があれば引き出しを拒否でき、「不正な引き出しには拒否可能なのに拒否されていないこと」を以て「履歴証明」とします。余談ですが、この履歴証明は十分な時間がないと安心できないので、exitで存在証明されているTxを一週間寝かせます。その不正Txのexitで損害を被るユーザーが一週間に一度アクセスする限り、ウォレットが自動でChallengeしてくれるセキュリティモデルです。exitに1ヶ月待たせる決めをするなら、1ヶ月に1度のアクセスでいいです。(余談ですが引き出したい金額の5%を手数料にすることで、1週間後に引き出し満額を得る権利を貸し方にさしだして、借り方の自分は95%の金額を早急に引き出すような提案もあります。)

さて、Plasma CashにおいてはTxInputもTxOutputも一つづつしかありえないので、履歴が一直線になります。だから履歴検証がシンプルで、「もう使われてる（Spent/challenge[By]After[TxProof]）」「二重支払い（Double Spend/challenge[By]Between[TxProof]）」「不正履歴（Invalid History/challene[By]Before[TxProof]）」の3パターンに不正が限定できます。素晴らしいですね。（既存提案の命名に不満があるので補足を入れてます）

どんなパターンのTxもchallengeできるのはすばらしいですね。challengeが完全です。この完全性をいかなるときも保てれば、5000兆円預けても安心ですね。いや、ギャグじゃなしに。

Plasma MVPだとオペレーターが無から生み出したUTXOに関してはExitコントラクトの時点で拒否できます（InputがOutputよりも少ないことをチェックできる）。しかし、その「錬金術UTXO」が百回ばかりオペレーターの持つ善良そうなアカウントの間で使用されると、前述のチェックにはかかりませんし、履歴も樹状なので全件チェックが必要です。これが、trusted watchtowerが必要な理由です。challengeできないTxがあるということは、challenge完全性がないので、「MassExit」という皆で逃げる方法が取られます。逃げなくてはならないタイミングで監視を怠っていてTxを作ってしまうと、逃げることはできません。履歴が一直線なら、Invalid Hisotry Challenge（challengeBefore）で回れているパターンなのですが。

さて、Plasma Cashflowではswapを導入することでコインのチェーン内交換を実現し、かつコインにrangeを導入することでfungibleに使えるように試みました。これによってTxの履歴が樹状に分岐しうるところを、confsigと呼ばれる受取確認署名によって切り捨てる（要検証）ことによってシンプルさを保っているようです。Plasma Primeはこれにライトクライアントのストレージスケーラビリティを加えたものなので割愛します。（余談: RSA Accumulatorのtrusted setupが来年中旬かもですが、Plasmaとtrusted setupって相性悪げじゃありません？Plasma SnappのSNARKも…）

さて、弊所CELのChamberも2nd layerで資産保全しながらスマコンやりたいので、Txの複雑化をするための方法論を整理しているわけですが、基本的にUTXOモデルで作れるコントラクトなら何でもできるわけで結構表現力高いわけです。DEXとかマルチシグとかいけます。開発者からの見え方としても「コントラクトにInputとして何らかの価値をぶち込んで、価値ではないデータもぶち込んで、結果としてログが出る」「このログをまた次回コントラクトに価値としてぶち込む」という考え方でいけるので、メンタルモデルを苦しめることもそんなにないはずです（英語ですが詳細はこちら https://speakerdeck.com/shogochiai/stateful-txo-is-the-new-contract）

そのような新しい拡張の際は、必ず「存在証明」「履歴証明」という「履歴中心設計」と、「Challenge完全性」を担保しないとだめだよ、と。また、Fast FinalityやCommit Aggregation(解説は learnplasma.org/research や research.cryptoeconomicslab.com にあるよ)のような新しい改善案は、上記指針を満たす限り楽観的に進めてよいだろうと判断できるようになります。これは結構すごいことで、これまで戦士(Plasman)たちは ethresear.ch の議論を全て読んで「Plasmaらしさ」を感じるSensibilityを養っていたわけですが、上記のような設計指針が言語化されはじめると、より効率的に最短ルートで設計のよしあしの匂いを感じるSensibilityを養えるわけです。素晴らしいですね。confsigや、Plasma Cashのexitの引数にTxが2つ必要な理由など不可解な仕様も、遡ると上記指針につながるのではないでしょうか。

テニスで言う「打ったら戻る、真ん中へ」的なメンタルモデルの基本をみなさんに叩き込むのが目的の記事でした。勢いで書いたのでフィードバック頼みます。おしまい。