checkpointのgriefing vectorの緩和方法が欲しい

#1

References

Plasma XT: https://ethresear.ch/t/plasma-xt-plasma-cash-with-much-less-per-user-data-checking/1926
Chamber checkpoint: https://github.com/cryptoeconomicslab/plasma-chamber/wiki/Checkpoint#evaluation

Background

Plasma XTでは、operatorがstate merkle treeを提出して、皆がそれにchallengeする形でcheckpointを作成する
正確にはoperatorでなくても良い

しかしこれでは間違ったstate merkle treeが提出されたり、state merkle tree自体がwithholdされた場合にmass exitしなければいけない。これに対して上記のfancy checkpointの提案では、state merkle rootと署名bitを提出することで、mass exitのシナリオを防いでいる。署名bitがoffになっていれば、自分のcoinに関するcheckpointは無効であるし、署名bitがonになっていれば、署名を求めるchallengeを行うことができる。これによりcheckpointはchallengeされるので、全員がexitする必要はない。

この提案、署名bitの構築が非常に大変である。特にPlasma cashflow以降ではcoinは2^50程度であるので難しい。

そこでchamberの提案では少し違うアプローチをとっている

  • checkpointはstate merkle treeではなく、Plasmaブロック番号とcoinの範囲のみを指定する。
    • 指定したブロック番号時点での状態、つまりブロック番号から古い方向に遡った時に、一番最初に現れるtxがcheckpointとする。これはchallengeTooOldExit というchallenge関数で実現する。上記のルールよりも前のtxでexitすると、どんな内容でもchallengeが可能である。これは擬似的にcheckpointを実現している。
      • state merkle treeが存在しないため、state merkle treeがwithholdされることはない。
        • またユーザは事前に、チェックポイントに同意することを表す署名を、オペレーターに提出する
        • この構成でも、オペレーターが通常のPlasma tx merkle treeをwithholdした上で、checkpointをリクエストした場合、checkpointが確定する前にmass exitしなければいけなくなる。
        • しかしリクエストされた範囲内の誰かがchallengeすれば、そのcheckpointはキャンセルされる。
          • challengeは以下のように行われる
            • ユーザはリクエストされたチェックポイントより前の、自身の持つ最新のTxを提出する
            • オペレーターはそのtxのspentを示すか、チェックポイントに同意したことを表す署名でrespondしなければいけない
            • respondできなければcheckpointはキャンセルされる

今回の本題はcheckpoint嫌がらせについて

checkpointの成立には、checkpointの範囲にいるユーザの同意が必要。同意がなければchallengeできてしまうので成立しない。
Plasma XTは署名bitがあるので、緩和できている感じがする。しかし同意しないユーザがいればいるほど署名bitはまだらになり圧縮しにくい。
結局署名bitを効率よく作れるか?に問題が帰着するのかもしれない。

結局はPlasma XTと同じように1から10, 飛んで25から32までの範囲に関して同意を得ていることがわかるような、効率の良い圧縮アルゴリズム(連長圧縮など)があれば問題は解決する。しかしこれはオンチェーンで検証可能でないといけない。

2 Likes