Further technical details for the protocol can be found in Protocol Terminology.
in
to a transaction tx
must prove that:tx
along with each of the input_tx1, input_tx2, ... , input_txn
that created the inputs to the transaction, a Merkle proof of inclusion for each input_tx
, and a signature over tx
from the newowner
of each input_tx
.exit bond
.Other methods exist to prove a transaction is exitable. And there may be further ways to optimize the two methods described here. Further research is required to provide a deterministic ordering of exits by some priority. MoreVP exits are assigned a priority based on the position in the Plasma chain of the most recently included (newest) input to that transaction. Unlike the MVP protocol, each input and output to a transaction is assigned the same priority. This should be implemented by inserting a single “exit” object into a priority queue of exits and tracking a list of inputs or outputs to be paid out once the exit is processed.
exit bond
that was placed by the user who started the exit. Otherwise, the exiting transaction is considered non-canonical, and the challenger receives an exit bond
.This challenge means an honest user can lose theexit bond
if they're not aware their transaction is non-canonical. If an in-flight exit is opened where some inputs were referenced in a standard exit, and these standard exits were finalized, the in-flight exit is flagged as non-canonical and further canonicity games can't change its status.
Important! You must piggyback an exit within the first period. While piggybacking an exit is not mandatory, users who choose not to piggyback an exit are choosing not to attempt a withdrawal of their funds. If the chain is byzantine and you don't piggyback, you could potentially lose your funds.
UTXO1
in TX1
to Bob, creating UTXO2
.TX1
is in-flight.TX1
is still in-flight. Neither Alice nor Bob knows if the transaction has been included in a block.TX1
(Alice, Bob, or otherwise) starts an exit referencing TX1
and places exit bond
.piggyback bond
.UTXO1
in any transaction other than TX1
.UTXO2
.UTXO1
in TX1
to Mallory, creating UTXO2
.TX1
is included in block N
.UTXO2
in TX2
.TX1
and places exit bond
.piggyback bond
.TX2
spending UTXO2
. This challenger receives Mallory’s piggyback bond
.UTXO1
in any transaction other than TX1
.exit bond
is refunded, no one exits any UTXOs.UTXO1
in TX1
to Bob, creating UTXO2
.TX1
is in-flight.TX1
is still in-flight. Neither Mallory nor Bob knows whether the transaction has been included in a block.UTXO1
in TX2
.TX2
is included in a withheld block. TX1
is not included in a block.TX1
and places exit bond
.piggyback bond
.TX1
by revealing TX2
.TX1
is determined to be non-canonical.piggyback bond
is refunded, no one exits any UTXOs. The challenger receives Bob’s exit bond
.UTXO1
in TX1
to Bob, creating UTXO2
.TX1
is included in block N
.UTXO1
in TX2
.TX2
is included in block N+M
.TX1
and places exit bond
.TX1
by revealing TX2
.TX1
was included before TX2
.exit bond
, no one exits any UTXOs.UTXO1
and UTXO2
in TX1
.UTXO1
in TX2
.TX1
and TX2
are in-flight.TX1
and places exit bond
.TX2
and places exit bond
.TX1
, someone challenges the canonicity of TX1
by revealing TX2
.TX2
, someone challenges the canonicity of TX2
by revealing TX1
.TX1
, the challenger receives exit bond
, no one exits any UTXOs.TX2
, the challenger receives exit bond
, no one exits any UTXOs.UTXO1
in TX1
to Bob, creating UTXO2
.TX1
is included in (valid) block N
.UTXO3
.UTXO3
in TX3
, creating UTXO4
.TX3
and places exit bond
.piggyback bond
.UTXO2
.UTXO3
. Bob’s exit will have priority of position of UTXO2
.UTXO2
first, Operator receives the value of UTXO4
second (ideally contract is empty by this point). All bonds are refunded.UTXO1
in TX1
to Bob, creating UTXO2
.TX1
is in-flight.UTXO3
.UTXO3
in TX3
, creating UTXO4
.TX3
and places exit bond
.piggyback bond
.TX1
and places exit bond
.piggyback bond
.UTXO1
in any transaction other than TX1
.UTXO3
. Bob’s exit will have priority of position of UTXO1
.UTXO2
first, Operator receives the value of UTXO4
second (ideally contract is empty by this point). All bonds are refunded.UTXO1a
, Malory spends UTXO1m
in TX1
to Bob, creating UTXO2
.TX1
is in-flight.UTXO3
.UTXO3
in TX3
, creating UTXO4
.TX3
and places exit bond
.piggyback bond
TX1
and places exit bond
.piggyback bond
.piggyback bond
.UTXO1m
in TX2
and broadcasts.TX2
and submits as a competitor to TX1
rendering it non-canonicalTX3
will have priority of position of UTXO3
. Alice-Mallory exit will have priority of position of UTXO1
.UTXO1a
first, Operator receives the value of UTXO4
second (ideally contract is empty by this point). Bob receives nothing. Mallory's exit bond
goes to the Operator. Mallory's TX2
is canonical and owners of outputs can attempt to exit them.UTXO1
in TX1
to Bob, creating UTXO2
.TX1
is in-flight.TX1
is still in-flight.TX1
and places exit bond
.UTXO1
in TX2
.TX1
, Mallory challenges the canonicity of TX1
by revealing TX2
.TX1
is determined to be non-canonical.exit bond
, no one exits any UTXOs.exit bond
, even though Bob was acting honestly.UTXO1m
and Alice spends UTXO1a
in TX1
to Bob, creating UTXO2
.TX1
is in-flight.TX1
is still in-flight.TX1
and places exit bond
.piggyback bond
.UTXO1m
in TX2
.TX1
, Mallory challenges the canonicity of TX1
by revealing TX2
.TX1
is determined to be non-canonical.exit bond
, Alice receives UTXO1a
and piggyback bond
.exit bond
, even though Alice was acting honestly. We want to mitigate the impact of this attack as much as possible so that this does not prevent users from receiving funds.In the scenarios where Mallory double-spends her input, she doesn't get to successfully piggyback, unless the operator includes and makes canonical her double-spending transaction. In this case, she may lose more than she's getting from stolenexit bonds
.
tx1
.tx1
doesn't get included in a block.tx2
, then she opens an attack on her funds:tx2
is included in a valid, non-withheld block, and all is well.tx1
or tx2
.See section Timeouts for details about one more possible mitigation. However, due to the uncertainty of timeouts in MoreVP, other mitigations for the retry problem might be necessary.
exit bond
. This cuts the per-person value of the exit bond
proportionally to the number of users who have piggybacked. Note that this is stronger mitigation the more users are piggybacking on the exit and would not have any impact if only a single user starts the exit/piggybacks.exit bond
is greater than the value of their input or output. We can reduce the impact of this attack by minimizing the gas cost of exiting and the value of an exit bond
. Gas cost should be highly optimized in any case, so the value of exit bond
is of more importance.Exit bond
is necessary to incentivize challenges. However, we believe that challenges can be sufficiently incentivized if the exit bond
simply covers the gas cost of challenging. Observations from the Bitcoin and Ethereum ecosystems suggest that sufficiently many nodes will verify transactions without a direct in-protocol incentive to do so. Our system requires only a single node to be properly incentivized to challenge, and it’s likely that many node operators will have strong external incentives. Modeling the “correct” size of the exit bond is an ongoing area of research.Note: It is unconfirmed how the timeouts scheme would modify MoreVP and whether it's feasible at all.