Monolithic PlasmaかAggregated Plasmaか


#1

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には実現しにくいオープンさである。


#2

個人的にはバランスだよねという話になった


#3

ビザンチン故障による選択的不正MR返却による「蹴落とし攻撃」

前提

  • P=(p1, p2, p3) というPlasma Operatorsを仮定する。 p3 がビザンチン故障を起こしており、ランダムに誤ったMerkle Root( MR )を返却する。
  • Hubは P から M = (m1, m2, m3) を受け取り多数決を取る。(1:1になるケースは一旦無視して)選ばれた M のサブセットを m とする。 m P MR の文字列結合として仮定する。
  • p1 はAという MR p2, p3 からのRPC Requestに対して返す
  • p2 はBという MR p3, p1 からのRPC Requestに対して返す

正常系

  • p3 はCという MR p1, p2 からのRPC Requestに対して返す ⇒ このとき m = ABC で多数決が取れ、誰も損失を受けずにCommit Aggregationが成功する。

異常系

  • p3 はCという MR p1 へ、Zという MR p2 に返す。 ⇒ このとき m = ABC で多数決が取れ、Bはbondをfreezeされる。これは100round後にSlashされる。 p2
    は不正実行者の特定に成功した場合、不正実行者のbondの1/2を得ることができる。 p2 P にSlashの残り1/2を対価として M の作成に用いたMerkle Forest( MF )を提供するように求める。 p1 MF を提供する。 p2 は自分の MF と異なるLeafとその持ち主を特定でき、(何らかの方法で)Proofをコントラクトに提出する。 p3 のbondはSlashされ、 p1, p2 は報酬を受け取る。 p2 のfrozen bondはunlockされる。
  • p3 がどちらにもZを提出した場合、多数決はとれ、 p3 チェーンのユーザーだけが困るためAggregationプロトコル外の問題になる。

次に着手すべきアタックベクタ等

  • 多数決で決まらないシナリオの整理
  • 51%攻撃で不正な m がETHに提出され、資産が脅かされないか?
  • 不正証明方法が未定義
  • Delay Factor =\frac{length(P)}{ Child Blocktime} が大きければ大きいほど、Aggregationが間に合わない。現状ここが集約可能なチェーン数を規定する。
  • Childchain間のClock Disparityによる多数決の割れの解決
  • 適切なbond金額の算定