Why do/don’t we need two phase sends plus confirmation
---.icon
m0t0k1ch1.icon 前提
Plasma MVP において、Alice から Bob にトランザクションを送信するとする
そのトランザクションが含まれるブロックが子チェーンのオペレータによって親チェーンに登録された後、それを確認した Alice が Bob に confirm sig を送信してはじめてそのトランザクションが承認されたことになる
このとき、なぜ confirm sig が必要なのか？
---.icon
vbuterin の説明
The problem is, what if the Plasma chain attacks while A->B is inflight? Then, the Plasma chain could include a series of fake withdraws between A and B, and A cannot withdraw because B exists, but B also cannot withdraw because it’s lower priority than all the fake outputs. In Plasma Cash this problem does not exist because of how each coin is separate from all the other coins.
vbuterin：そのトランザクションが親チェーンに登録されるよりも先に子チェーンで先に承認されてしまっていた場合、承認されてから親チェーンに登録されるまでの間（：inflight な間）に攻撃されてしまうのは問題だよね、と。まず、Alice が Bob に送った output はすでに使用済みになっているので exit 不可（オペレータが単純に challenge して止めれる）。ここで、オペレータが不正なトランザクションを生成し、このトランザクションよりも exit の priority が高くなるようにブロックに含ませた場合、Bob が正常な UTXO を exit するよりも先に不正な UTXO を exit することができてしまう。端的に言うと、オペレータが親チェーンのデポジットをパクれてしまうことが問題。なお、Plasma Cash の場合は non-fungible なので大丈夫とのこと。
---.icon
kfichter の説明
Generally, there are two major reasons why it’s necessary to have the two-phase send + conf in Plasma.
kfichter：Plasma において、2 フェーズで送金とその確認を行う必要がある理由は大きく 2 つある。
The first reason is specific to Plasma MVP and arises because Plasma MVP allows for fungible coins/tokens. Basically, if we don’t have confirmations, then an operator can place a user’s valid transactions after the operator’s invalid transactions in a block. This is a problem because exits in Plasma MVP are processed in time order. I published a brief write-up on why this time-order processing is necessary here. kfichter：1 つ目の理由は Plasma MVP 特有のものであり、Plasma MVP が fungible なトークンを扱っているから。もし confirm sig がなければ、オペレータは、あるブロックの中において、ユーザーの正当なトランザクションを自身の不正なトランザクションの後ろに置くことができる。Plasma MVP における exit は時系列で処理されるので、これは問題である。なぜ時系列での処理が必要なのかについては ここ に簡単に記載した。 1 つ目の理由：オペレータの不正な exit が割り込めないようにするため
m0t0k1ch1.icon 10 ETH が親チェーンにデポジットされているとする
1. Alice broadcasts a transaction spending 10 ETH to Bob.
2. The operator creates an invalid transaction creating 10 ETH for themselves “out of nowhere” and places it at the first index in a block
3. The operator places Alice’s transaction at the second index in the block
4. The operator publishes this block.
5. Bob sees the invalid transaction and submits his exit.
6. The operator submits an exit for the invalid transaction.
7. The operator’s exit processes before Bob’s exit, so the contract is now empty.
8. Bob’s exit cannot be processed because the contract has no funds remaining.
kfichter：
1. Alice が Bob に 10 ETH を送るトランザクション（txAB とする）をブロードキャストする
2. オペレータが自身に 10 ETH を送る不正なトランザクション（txO とする）をどこからともなく生み出し、ブロックの最初に置く
3. オペレータが txAB をブロックに含め、txO の後ろに置く
4. オペレータがブロックを公開する
5. Bob が txO を発見し、txAB の output の exit を申請する
6. オペレータが txO の output の exit を申請する
7. オペレータの exit が Bob の exit よりも早く処理され、デポジットは空になる
8. デポジットが空なので、Bob の exit は処理されない
m0t0k1ch1.icon confirm sig があると以下のようになる
1. Alice broadcasts a transaction spending 10 ETH to Bob.
2. The operator creates an invalid transaction creating 10 ETH for themselves “out of nowhere” and places it at the first index in a block
3. The operator places Alice’s transaction at the second index in the block
4. The operator publishes this block.
5. Alice sees the invalid transaction and refuses to sign a confirmation on her transaction to Bob.
6. The operator submits an exit for the invalid transaction.
7. Alice exits from her (still technically unspent) 10 ETH UTXO which existed before the operator’s invalid UTXO.
8. The operator’s exit cannot be processed because the contract has no funds remaining.
kfichter：
1 〜 4 までは同じなので省略。
5. Alice は txO を発見したので、txAB の confirm sig を生成しない
6. オペレータが txO の output の exit を申請する
7. Alice が txAB の input として使用した output の exit を申請する
txAB はまだ承認されていないので exit できる（誰も txAB の confirm sig を知らないので challenge もできない）
この exit はオペレータの exit よりも早く処理される
8. デポジットが空なので、オペレータの exit は処理されない
2 つ目の理由：block withholding に起因する面倒な状態の発生を防ぐため
m0t0k1ch1.icon 10 ETH が親チェーンにデポジットされているとする
1. Alice broadcasts a transaction spending 10 ETH to Bob.
2. The operator places Alice’s transaction somewhere in the block.
3. The operator publishes the root of this block to the root chain but withholds the actual block information.
4. Alice doesn’t know if her transaction to Bob was actually included in the block or not. Bob doesn’t have enough information to exit because he doesn’t know the index of the transaction in the block.
5. Alice must attempt to exit from her old UTXO.
6. The operator knows that Alice’s old UTXO is spent, so they challenge Alice’s exit with her transaction to Bob (revealing the index).
7. Bob now knows the transaction index, so Bob can exit.
kfichter：
1. Alice が Bob に 10 ETH を送るトランザクション（txAB とする）をブロードキャストする
2. オペレータが txAB をブロックのどこかに含める
3. オペレータがこのブロックの root を親チェーンに公開する、が、ブロックの情報は公開しない
4. Alice は txAB がブロックに含まれたか分からないし、Bob も txAB の output を exit するために必要な情報が分からない
5. Alice が txAB の input として使用した output の exit を申請する
どうしようもないのでこうするしかない
6. txAB の情報を知っているオペレータは、Alice の exit に challenge する
challenge の過程で txAB の情報も公開される（Bob もここで知る）
7. Bob は txAB の情報を手に入れたので、txAB の output を exit できる
This doesn’t change anything security-wise, but it’s not particularly convenient to have this exit-challenge-exit process. Additionally, Alice will always lose her bond for her original exit.
kfichter：これはセキュリティ上は何の変化もないが、このような exit-challenge-exit プロセスが発生してしまうのは不便だし、Alice は exit のための担保を常に失うことになる。
m0t0k1ch1.icon confirm sig があると以下のようになる
1. Alice broadcasts a transaction spending 10 ETH to Bob.
2. The operator places Alice’s transaction somewhere in the block.
3. The operator publishes the root of this block to the root chain but withholds the actual block information.
4. Alice doesn’t know if her transaction to Bob was actually included in the block or not. Alice doesn’t broadcast a confirmation signature.
5. Alice exits from her old UTXO.
6. The operator cannot challenge with Alice’s spend to Bob because the operator doesn’t have the required confirmation signature.
kfichter：
1 〜 3 までは同じなので省略
4. Alice は txAB がブロックに含まれたか分からないので、txAB の confirm sig をブロードキャストしない
5. Alice が txAB の input として使用した output の exit を申請する
6. オペレータは txAB の confirm sig を持っていないので Alice の exit に challenge できない
---.icon
m0t0k1ch1.icon memo
ethresearch 上の議論を読む前の自分が理解できていなかったポイント
confirm sig を生成するのは sender
上記の例で言えば Alice
confirm sig の利用シーン
exit
上記の例で言えば、Bob が Alice から受け取った UTXO を exit する際に提出する
Bob が提出するのは Alice の confirm sig
challenge
上記の例で言えば、Bob が Alice の double spent に challenge する際に提出する