Plasma における cryptoeconomic finality


#1

Plasma における fast finality の議論 の中で登場する cryptoeconomic finality が具体的にどのように実装できるのかを考えてみたいです。ここでの議論の延長線として、具体的な提案を ethresearch に出せたらおもしろいなあとも思っています。

以下、Learn Plasma から表題に直結する文章のみを抜粋します。

Another way to reach some sense of finality is known as “cryptoeconomic” finality. Basically, cryptoeconomic finality guarantees that a transaction will be included in the chain within some period of time, or someone will cover the full amount. In the context of plasma, this “counterparty” will probably be the operator.

A simple example of cryptoeconomic finality might involve a customer making a purchase. We want this transaction to be guaranteed as quickly as possible. The merchant might make a deal with the operator that states the operator will include this transaction within some period. If the operator doesn’t include the transaction, the merchant can take the transaction amount straight from the operator. Therefore, the operator is incentivized to include the transaction in a timely manner and the merchant knows they’ll get the money either way.

端的に言うと、オペレータに対して 「私(オペレータ)はいついつまでにこの tx をチェーンに含めます。もし含められなかった場合は私の資産から同額を奪い取ってもらって構いません。」 という契約を結ばせ、この契約をもってして実質的(cryptoeconomic)な finality とみなす、ということみたいです。

冒頭で述べたとおり、一旦は Plasma Cash を前提として、どのように実装できるのかを考えてみたいです。


#2

see also https://github.com/omisego/research/issues/29#issuecomment-388088073


#3

私も全然方法がわからないので、考えだけ書きます。

送金者が受取手にtransferするようなトランザクションを作成して、オペレーターに渡すとして。送金して5s後ということは受取手は、署名付きのトランザクションのみ持っているという状態。という前提はとりあえず置いて良いのかと思っています。

このトランザクション自体はダブルスペントなものを作成し放題なわけですが。
送金者、受取手、オペレーターの中で、オペレーターがmaliciousの場合と、送金者と受取手がmaliciousの場合との区別が付かないのが、現状の私の中の課題になっています。

この状態でオンチェーンで申し立てのようなものを行うと、どちらが正しいのかわかりませんね:thinking:


#4

@m0t0k1ch1 よく考えるとオペレーターが、トランザクションをもらった時に、状態遷移や入力のチェックだけ行って、オペレーターの署名もくっつけたTxを受取手に返す。(この間5sほど?)
時刻に関してはtime rangeパラメーターを最初にTx作成者入れておいて、そのmaxTimeを超えていた場合、オペレーターから支払いを受けられる。
これでオペレーター署名つきのTxだけ、オンチェーンでの申し立てに使えるようにする(オペレーター署名つきのTxが2個存在してしまった場合もオペレーターはpenalizeされます)

これでどうでしょう?

time rangeについて


#5

なるほど。確かに案外シンプルにいけるのかもしれませんね。

time range がよいのか block number range がよいのかなどの各論はありますが、叩き台のスペックとして具体化するには支障ないと思うので、自分の現状の理解でスペックを整理してみます!


#6

いきなり疑問が生まれてしまいました :sweat_smile:

送金者を Alice、受金者を Bob とし、Alice から Bob への送金 tx に対して Bob が crytoeconomic finality を適用したい状況を考えます。また、送金 tx は time range をパラメータを含むこととし、送金 tx に対して Alice の署名(送金への合意)と operator の署名(time range への合意)が揃う必要があると仮定します。

この場合、以下のような問題が発生してしまうような気がするのですが、どうでしょう?

Alice → operator の順で署名する場合の問題?

operator が最終的な署名済み tx を Alice or Bob に返す保証はない?返されなかった場合、operator が time range 内に tx をチェーンに含められなかった場合に罰する証拠がなくなってしまう?

operator → Alice の順で署名する場合の問題?

operator が署名した時点で time range の条件は確定しているはずなので、Bob or Alice が最終的な署名済み tx を withhold することで、operator が time range 内に tx をチェーンに含められなかったことにしてしまえる?すなわち、operator の資産を奪えてしまう?


#7

おそらく Alice → operator の順が正しそうで、
operatorが返さなかったっ場合はfast finalityは成立せず、通常のfinalityになる。そこでもproofを返してもらえなかったりblock withholdが起こると、通常の手順で1weekかけて明らかにしていかなければいけないという感じでしょうか?
あまり網羅して考えてないので、穴がありそうですが。


#8

自分も概ね同じ考えに至っていました。fast finality が失われることで Alice or Bob の資産保全が崩れるわけではないので、proof だろうと block だろうと withhold されたらされたでしょうがないのかなという気がします。

蛇足ですが、operator が正しく cryptoeconomic finality の条件を満たした場合に operator に対して Alice or Bob から fee が入るようにできれば、善行を促すことはできるのかなあと思ったりはしました。また、少し論点がズレますが、cryptoeconomic finality は operator に一方的な負荷をかけることになる仕組みな気がするので、ユーザー側が operator に対して DoS 攻撃のようなことを仕掛ける動機を緩和するためにも、上記 fee のような何らかのコストはあって然りなのかもしれません。

…と、細かい話を書いてしまいましたが、、最低限資産保全が崩れていない時点でこれらのイレギュラーケースについて今深く考える必要はないと思うので、引き続き以下を頑張ります :wink:


#9

「『Operatorによる署名のあるTx』が返ってこなかったとき」のシナリオとして

A. 『Operatorによる署名のないTx』が返ってくる
B. 何も返ってこない

という二つが考えられると思っていて、シナリオAの場合はpapp開発者がこのシナリオを想定していなかった場合、ユーザーはfinalityのないTxに対して操作を続けてしまう可能性があるかもしれません。

シナリオBの場合はただのwithholdなので割愛します。

P.S. これがうまく設計できればガスもsubmitBlock頻度を落として安くできますし、Snappもproof生成時間の長さをカバーできそうで、楽しみです。


#10

元のアイデアで、複数の受取手に対して同じブロックでdouble spendされまくると供託がdeposit総額*2でも破綻するのではないかと思いました。

そこで、fast finalityの受取主体をn人と限定して、かつ流量Tを使って、供託をT*(n+1)にする方法を @kazuya-tanuma と考えました。基本的には受取手がn人の時、あるブロックでdouble spendが起こり得る回数はn+1だと思います。Tはあるブロックに含まれるamountの合計です。

これはnの店舗に対してfast finalityによる二重支払いを行った後、最終的にはオペレーターの協力者に対して支払い実行する最悪のパターンを想定しているためです。このため必要な供託額はT(n+1)になります。逆にいうと供託額とfast finality contractに登録されている受取手アドレスから、自分が受けとけられるfast finalityの量が決まります。

詳細なcontractの設計は以下にも書いていますが。

  • オペレーター署名つきtxによる異議申し立て
  • それが含まれていることによるchallenge

で成り立ちます。



#11

@syuhei176

Kelvinも受け手をMerchantにしぼるBandwidthモデルを提案しているのを思い出しました。


#12

自分的な最終スペック書きました。

contractもupdateしました。

最終的に「operatorがchallengeに使用したtransaction」がexitできないことを示す方法は、それがdouble spendされていることを示せばよいのかなという結論になりました。

  • そのFF transactionがspent challengeされる可能性は、受取手の署名がないとあり得ないです。
  • そのFF transactionがinvalid history challengeされる可能性は、少なくともFF transactionの入力を生み出すトランザクションまでの履歴を確認後に、商品を渡せばあり得ないです。