Plasma Cash Variantについてです。
そして「いかに資産保全性を捨てずにPlasma維持費（＝submitBlock a.k.a. commitのガス代）を減らすか」についてです。
DBMLとCommit Aggregation
これらの技術は本家でもまだあまり深まっていない
基本的にDBMLはcommit hashをwitness化してmerkle rootだけを記録していく設計によってストレージ使用料を減らそうという話で、どのくらいの周期でwitnessとしてくくり出すかを楽にするためにMMRを使ってwitness生成コストを減価償却のようにflattenしてる感じらしい。
Commit Aggregation については Plasma Commit Aggregationについて でも述べたが、特に2番目のBLS Hubに近い「オフチェーンでPlasma Operatorsで合意してBLS集約署名を作ってMerkle Root(=MR)で作った"Merkle Forest"のRoot(=MFR)だけを記録する」というVitalikの設計が妥当という感じがする。余談だが、BLS Aggretate Signatureはできることが多すぎて設計に迷うが、基本的に「各OperatorがN-1本のchildchainのRPCを叩いて（pull型）Merkle Rootを集めてMFRを作り、このroothashをBLS署名したものを提出する。Hubは提出されたhashに関して多数決をとり、少数派はbondを失う」というstaking basedなものにしなければSybil Attack Vectorを緩和しきれない。この設計は「選択的に不正MRを返して特定の参加者のMFRを不正にすることで多数決に負けさせる」というGriefing Vectorが残っており、要改善である。 - (1)
別の設計としてHubに各OperatorがBLS署名済みなMRを提出して（push型）、Hub側で署名ごと線形結合させるBLS Accumulatorの利用法もある。この場合はAccumulatorに対応するAggregate SignatureとAccumulatorをETHに提出して、Exit時にInclusion Proofとして使えるんじゃないかと思っているが、childchain数が増えた時にpairing暗号の計算が間に合うのか怪しさも感じている。 - (2)
Monolithic PlasmaかAggregated Plasmaか
Commit Aggregationの問題としてProofサイズの問題がある。なぜなら、このチューニングの本質は資産保全性に関わるExitに必要なデータを増やすということによって成されているからだ。(1)の設計でいくとaggregateされるchildchain数をNとして 32bytes*logN*Blocks のサイズを「SMT ProofやRSA range non-inclusion proofとは別に」クライアント側で占める。
このMFR Proofはrange non-inclusion proofと相性が悪く、せっかくレンジ圧縮できているブロックもストレージを食ってしまう。一応RSA Accumulatorの素数採番を参加childchain全て含めて一意にしてしまえばrange non-inclusion proofできなくもないかもしれない(巨大Accumulatorというのは邪道ではある)が、それは巨大なPlasmaを管理していることにかなり近くなってしまう（違いとしては、aggregateされているチェーンごとに違う実装にできたり、オペレーターが違ったり、サーバーの地理的所在が異なったり、くらいになる。）
もちろんaggregatedだと途中で出入りできる利点はあるし、monolithだと途中から別のアプリが増えていくupdatableなPlasmaというのはsecurity的にどうなのだという見方もある。
個人的結論
Aggregate Plasma推しで、ガス代節約効果をそこそこにする（＝集約する数を10そこらにする）ならエンドユーザーストレージを200MB/年しか専有せず、checkpointingなども取り入れればガス代90%節約の対価としてはお釣りが出るくらいだと思っている。また、個人的にはネットワークレイヤの検閲耐性をつけるオプションを残したいのでSMTを深くしすぎず運用できる設計のほうが好ましい（ノードが一つのときは問題にならないが、冗長化したりPoS化するとビッグブロックはTorの帯域を食う）
これは後で気づいたことだが、同じ規格に則ったPlasmaて、別の主体が独自に開発運営しているとき、事後的にそれをCommit Aggregationの輪に入れることができる（Sybil対策のstakingは必要である）。これはサービス的、厳密に言えばプロトコル的であり、Monolithic Plasmaには実現しにくいオープンさである。