commit aggregation service

何が嬉しいの？

現状

オペレーターが、deposit金額を増やしたい場合はplasma chainを深くすればいいが、gascostを減らしたい場合はblock timeを長くするしか方法がない。

commit aggregation serviceがあると

gasコストを減らしたい場合はcommit aggregationすることができる。

どちらにしてもproofサイズは増える。という欠点はある。

具体的な方法

merkle rootに対してオペレーターが署名をする。

merkle rootをleafにして、merkle forestを構成する。

merkle forest rootをhubがsubmitする。

withholdシナリオやinvalid blockのシナリオは通常のexit-game通り

invalid exit attemptsなどへの対応

関心ごとは、penalizeするべきなのが、オペレーターなのかhubなのかということに絞られる

もしそのブロックを使ったexitやchallengeが行われていれば、proofはすでに公開済みである

オペレーターは自分の提出したmerkle rootが含まれていて、かつそれが自分の署名を持っている

Hubがオペレーターの提出したmerkle rootと署名を提示できなければpenalizeされる

逆に提示できればオペレーターがpenalizeされる

withholding scenarioへの対応

withholdingシナリオが起きた場合、オペレーターのwithholdなのか、Hubのwithholdなのかを知ることはできない。

ある時点でwithholdが起きたとする。

Hubがwithholdしているケース

Operatorは最後のmerkle rootを固定したい

exit, challengeモデルで最後のmerkle rootは決まる

この場合のexitは、最新のmerkle rootはこれだと主張すること

challengeは、もっと新しいmerkle rootが存在すると主張すること

それ以降の料金を返還してほしい

Operatorがwithholdしているケース

Hubは料金をもらいたい

Operatorは料金を返還してもらいたい

どちらのケースでも最後のMerkle Rootが決まり、返還すべき料金が正確に求まれば良い

ゲーム理論的

OperatorとHubが最善の策をとると、最後のMerkle Rootが決まるようにしたい

Operatorは10,000block分の料金xを支払っている

100blockでwithholdが起こる（100block分の料金はa)

10,000-100blockの料金b=x-a

exit bondはe、料金に対してとても少ない

table:利益(op, hub)

op/hub 何もしない challenge

exit 0, 0 -e,e

何もしない -b, b できない

operatorは必ずmerkle rootをexitする

そしてhubは必ずchallengeする

このchallengeは一度しか起きない

hubがwithholdしている場合、operatorはそれ以上の署名は辞める

operatorがwithholdしている場合も

つまりOperatorに2回のexitチャンスを与えると良い

何度でも良いのかもしれない（オペレーターは最も新しいMRを提出するのが最善である）

必ずoperatorはexitし、hubはchallengeする。

その時operatorは-e, hubはeの利益を得る

eは最小限で良い

aggregationサービス

各オペレーターはhubに通常より安い手数料と、merkle rootを渡すことで、submitを委託できる。

この委託はcontractでなく、通常のSaaS契約

BLS署名を使って、一定数のoperatorによってmerkle forest rootを承認した方がいいかもしれないけど、そのtrustは安定稼働性な気がする

これは通常のWeb APIで実現される。