CryptoeconomcisLab team(@sg @yuriko ) implemented another simple exit game for Plasma cashflow construction. If you have a similar implementation or idea, I hope discussion.
I think our implementation is different from @danrobinson 's proposal but similar to priority increase game(Plasma Prime design proposal - #9 by snjax) and MoreVP.
A description and vyper contract are here.
The methods for exit-game are only 3. “exit”, “challenge” and “requestHigherPriorityExit”.
Overview
This proposal is simple exit-game for Plasma cashflow construction supporting edge case. When a user exit with the transaction and the transaction was used as a challenge in the past, the priority of exit is Plasma block number of the parent transaction. Exiting users can request higher priority exit to the lower exit. (This is similar to invalid history challenge or priority queue) The lower priority exit is never finalized unless the higher priority exit is challenged.
Proposal
exit(segment, exitTx, proof, sigs)
- start exit procedure
- each exit has priority
- Normally, the priority of the exit is it’s block number
- If the tx used for exit was used as a challenge, priority of this exit is previous exit’s block number.
- Register this exit as
childExitof the previous exit
challenge(exitId, segment, challengeTx, proof, sigs)
- Spent challenge and Double spent challenge
- If there is parentExit(in case of that
exitIdis childExit of some exit), users can prove spent of parentExit(This is double spent challenge) - If there is
lowerExitof theexitId, lowerExit’s challenge counter is decremented.- And also exit period will be extended
requestHigherPriorityExit(higherPriorityExitId, lowerExitId)
- This is an alternative of invalid history challenge and priority queue
- The priority of higherPriorityExit should be higher than exit
- Segments should be overlapped
- lowerExitId’s challenge counter is incremented
- lowerExit can’t be exited until higherPriorityExit is challenged
finalizeExit
- challenge counter should be 0
- after exit period
Other important points
- Challenger should prove spent of exit state
- verify spent is application specific logic in UTXO programming
- The valid transaction which has multiple inputs require confirmation signature
Attack scenarios
Exit spent segment
Precondition
- In block 1, Alice sent segment A to Bob.
- In block 2, Bob sent segment A to Carol
- Bob attempts exit segment A with the transaction in block 1
How Carol save money
Anyone can challenge Bob’s exit by the transaction in block 2.
Exit with double spending segment
Precondition
- Alice sent segment A to Bob in block 1
- Alice sent segment A to Carol in block 2(The operator allowed Alice’s invalid behavior)
How Bob save money
- Carol attempts to exit with block 2
- Bob exit with block 1
- Bob do requestHigherPriorityExit(his exit in block1, Carol’s exit in block 2)
- The operator can’t finalize the exit in block 2
- Bob can withdraw his money
Exit with invalid history segment
Precondition
- Alice sent segment A to Bob in block 1
- The operator puts an invalid state transition in block 2
How Bob save money
- The operator attempts to exit with block 2
- Bob attempts exit with block 1
- Bob do requestHigherPriorityExit(his exit in block1, operator’s exit in block 2)
- The operator can’t finalize the exit in block 2
- Bob can withdraw his money
Edge case: with double spending
Precondition
- Adam sent segment A to Alice in block 1
- Alice sent segment A to Bob in block 2
- Alice sent segment A to Carol in block 3(The operator allowed Alice’s invalid behavior)
(Alice and Carol and operator were a malicious party)
How Bob save money
- Alice attempts to exit with block 1
- Carol challenge Alice’s exit with block 3
- Carol attempts to exit with block 3(The priority of his exit is “1”. This is an important note.)
- Bob attempts exit with block 1
- Bob do requestHigherPriorityExit(his exit in block2, Carol’s exit in block 3), but he can’t because the priority of Carol’s exit is “1”!
- Bob challenge Carol’s exit showing double spending with block 2(block 3 is double spending!)
- Bob can withdraw his money with block 1
Edge case: exit with invalid history and withholding
Suppose Alice owns a coin at block 1 and submits a spend to Bob, but the operator puts an invalid state transition in block 2 and then includes Alice’s transaction in block 3 (without making any of the data available). Alice can use the following protocol to exit her coin (cooperatively with Bob):
In our exit game, Bob can exit his coin cooperatively with Alice. Alice already signed off on transfer transaction.
- Alice attempts to exit with block 1
- Within the exit period, operator challenge Alice’s exit by block 3
- Bob attempts to exit with block 3.Priority of this exit is block1 because the tx was used for the challenge.
- Within the exit period, operator exit with block 2
- Operator may requestHigherPriorityExit(block 2 exit, Bob’s block 3 exit). But the priority of Bob’s exit is block1, so this request will be failed.
- Bob can finalizeExit of his exit with block 3