凍結Exit(Frozen Exit)


#1

問い

Plasma Exitしたあと、Exit実行者に対して、その提出したUTXOをPlasma内で使用不可にする制約を課すことは妥当か?

動機

「裏書きExit」(Endorsed Exit)を使えるようにしたい。
通常のPlasmaの要領でExitを2週間待つ代わりに、そのExit Txの受け取り権利をP2P Lending Contractに引き渡してしまう。その代わりに一定の割引率をかけた金額を即時でRootchain側で受け取れるようにしたい。
しかし、Exitしたあとの2週間の期間にそのUTXOを使用できる設計/実装しか現状提案されていなかったはずなので、制約を課したい。

方針

KarlのExit 3分類に照らして網羅的にコーナーケースが起きないか検証したい

余談

出金希望者からIdentity情報をとることについて:

  • Exit実行者の信用を測るためにIndentity情報やソーシャルグラフを用いるとする
  • Identity貸与コストが1ヶ月間で10万円と仮定する
  • 10万円以下の金額のExitに関しては、Identity不正による期待利益がマイナスなので、攻撃しにくいはず
  • プロトコルレイヤに駆け引き余地を増やすことの是非もある
  • 貸金Exit利用者の任意利用に限定すれば悪い筋ではないかもしれない

#2

子チェーン内の取引実績をある程度信用情報として使える気がしました


#3

信用情報は親チェーンでためておいた方が取り扱いが楽なんじゃないかなぁと何となく考えてました。
でもtoken価値は子チェーンの活動で変動するので親チェーンの信用がそのまま扱えないんだろうなとも思っています。

あー。信用ためていけばexit時間が減っていく的な感じにしたらいろいろうまいこといけるのかな?


#4

信用情報は親チェーンでためておいた方が取り扱いが楽

雑に考えると通常のPlasmaが要求するblockheader commitに各ユーザーの信用情報も載せる感じでよさそう. 全Tx載せると本末転倒なのでRootchainに保存するデータ量は限定的にしたいので

信用ためていけばexit時間が減っていく

break-even pointがありそうですよね。信用をevilにこしらえてexitするコストに対して、高速出金に許されたexit金額(つまり詐欺の期待収益)が大きすぎなければ、成り立つレンジはありそう。


#5

子チェーン側のロック制御の実装が悩みどころ。トランザクションに署名してもロック状態なら正当なTxとみなさない実装とか?DoS耐性つけるためにロック時でも要Gas?

P.S. 子チェーン側でもルートチェーンと同様の残高ロックをすれば良いと一瞬思ったが、子チェーンでのTxを要するExitになってしまうので、子チェーンfraud耐性が低いアイデア。Mass Exitセキュリティモデルの良さを潰す。


#6

凍結Exit要件

1. 子チェーンのTxに依存しない

  • 子チェーンコントラクトによる資金ロックはBlock Withholding耐性がないので不可
    • Mass Exitがセキュリティモデルの一環として定義されている理由は子チェーンTxに依存しない資産退避が可能だから

2. 子チェーンの残高をExit以降変動できなくする

  1. ExitStartedイベントがルートチェーンで発行され、子チェーンからListenできる
  • 該当UTXO_IDの持ち主がTxを作成できないようロックする
    • ロックとは具体的に何をする?
      • preset escrow-started contractへのTxを1block 1txで実行できないか
        • 結局リーダー選出者がそのブロックを止めることはできちゃうので、上記要件1を違反している
        • コントラクトだとコンセンサスが必要(※要考察)。埋め込み関数だと全ノード同一処理なのでブロック伝播もなくコンセンサスが不要。
    • ロック後にルートチェーンのP2P lendingコントラクトを叩く。与信チェックの後に金を貸し、exit権を移転する
      • 与信とは具体的に何で、どう渡される?
      • exit権の移転はどうやる?
  1. ExitがChallenge成立してしまったあとのロック解除
  • ChallengeSucceededイベントを子チェーンからListen
    • 該当UTXO_IDの持ち主のロック解除
  1. Exit成功したユーザーが再度子チェーンに入ってきたら?
  • #1 のExitコントラクトExitFinalizedイベントを子チェーンからListenする
    • finalizeExit() がどうやらイベントをemitしてない。(あと子チェーンメインプロセスでブロック生成時に叩く処理がまだ実装されてない)。ちょっと続報を待ちたいが、イベントはあってしかるべき。
    • 該当UTXO_IDの持ち主のロック解除
      • preset escrow-end contractへのTxを1block 1txで実行できないか
      • Exitが成功しているので残高はBurnされているはず
        • このBurnが上記ロックでできなくなっていると問題なので、例外を用意する必要がある(例外条件:子チェーンがExitFinalizedをlistenしてメインプロセスから実行する資金移動は可能(deposit callback同様1block 1txなら子チェーンでのwithholdには耐性あり))
  1. 親チェーンのblktime 15sec, 子チェーンのblktime 1secのとき
  • クライアントサイドでコントラクト実行RPCを発行したタイミングでは、まだUTXOだったIDだが、これが親チェーンで1confされて子チェーンがExitStartedログを受け取りロックを取るまでの間、子チェーンはまだTxを15秒だけ作るチャンスがある。
  1. 使用済UTXOが提出されたとき
  • 通常通りChallengeされて取り下げられるのはそう
  • 金を貸す側が子チェーンに問い合わせて、貸す前に使用済かどうかチェックする必要がある
  • 貸せるタイミングとしてはExitStartedを確認したあと(つまり子チェーンがExitStartedをlistenしてロックを取ったあと)なので、Endorsed Exitは親チェーンでの1confは最低でも必要になる