To Simplify MoreVp
Closed this issue · 3 comments
Background
Currently, the interaction between Standard Exit and In Flight Exit is crazy complex. And we found out several implementation bugs due to that complexity.
Proposal
If the main sale point of MoreVp is to remove confirm signature of Plasma MVP, not really allowing an in-flight transaction to exit, I think we can simplify the protocol a lot by adding a restriction: All exit and challenge can only use tx that is included in plasma chain.
AFAIK, the reason of having confirm signature is to avoid the following situation:
Operator submit a block and put an invalid tx in the middle, for example:
[ tx1, tx2, bad_tx, tx3...]
Now input of tx3 cannot exit because they are used in tx3 and submitted in chain, so standard exit would be challenged. However, using standard exit tx3 would get lower priority then bad_tx.
With In Flight Exit, tx3 would be safe as it is using priority of input.
Impact
- No piggyback on IFE input. All competing transaction can decide their position now. We would not have the case that "because we cannot decide the order of two competing tx so we claim both non-canonical".
- An output can only be in one kind of exit at a time. Simply block another type of exit/piggyback from happening avoids all interaction between SE and IFE.
- Not able to exit a transaction not included in a block. Before this, it is possible if all input owners are good people (lol) and don't make the IFE non-canonical on purpose, output owner can successfully exit even the tx is not inside any block. However, any input owner of the in-flight transaction has the power to make such IFE non-canonical. There is generally no security promise for the output owner before the tx is included in block.
- When user feels operator is withholding, instead of start an IFE, use standard exit on input tx to force operator react.
I believe this would solve this issue: omgnetwork/plasma-contracts#92 and timeout issue on PT
But At the same time, I feel I might be missing something really important lol
(Moving chats from Slack for visibility)
piotr [22 hours ago]
hey, I think I don't understand the proposition there. I see that we're trying to save tx3 (or tx2) there, but how would we do that without IFE/MoreVP?
All exit and challenge can only use tx that is included in plasma chain.
for standard exits this is understood. For standard exit challenges this doesn't work, because inclusion (and publishing this inclusion) is up to operator's sole discretion. So both tx2 and tx3 are lost - tx3 because it has lower priority than bad_tx and tx2 because it has been spent
boolafish [21 hours ago]
ah, sorry tx1, tx2, tx3 are independent txs. they all use UTXO from some previous blocks. I believe tx2 can SE without issue (?)
I am not proposing to remove inflghtexit/MoreVP. tx3 still uses InflightExit to exit with input priority. However, if there exists a tx4 that is not inside the block, we simply don’t allow any exit on that.
piotr [21 hours ago]
ah, sorry
tx1,tx2,tx3are independent txs. they all use UTXO from some previous blocks. I believetx2can SE without issue (?)
ah this clarifies a lot. And yes tx2 SEs normally
tx4 that is not inside the block, we simply don’t allow any exit on that.
but tx4 being or not inside a block is unknown, from the POV of tx4 "actors", due to the possibility of withholding attack from the operator.
IFE protocol is in fact giving the possibility to exit funds "in-flight from a subjective POV of their owners". This is the reason why piggybacking is always owner-based and opt-in
boolafish [20 hours ago]
but
tx4being or not inside a block is unknown, from the POV oftx4“actors”, due to the possibility of withholding attack from the operator.
Worse case scenario, user can always use SE to force data disclosure. I think users should leave the network if not getting the data availability from operator they need anyway. And it is operator’s duty to provide data availability.
Downside for this is the cost of exit-bond. But it is one-time cost as they should leave the network as the operator is not trusted anymore.
IFE protocol is in fact giving the possibility to exit funds “in-flight from a subjective POV of their owners”.
I agree. IFE on truly in-flight tx gives the benefit of:
if output owner trusts input owner, the exit can still go through.
and on top of that, there is de-incentive on the input owner to fraud (double spend) as that input cannot exit anymore.
My first challenge point is that do we really need this? From the MoreVp doc’s introduction part, it only states about removing second signature. Nothing much there states this benefit. Also, this feels like something good-to-have but not must-have. But it explode the code complexity to a level that I am concerned. Especially on smart contract where it is hard to make any changes.
Also, I can easy come up with some situation input owner still likes to fraud on IFE. eg. Tx using two input of same owner, one input with amount 1 and another with amount 1000000. Input owner can always make IFE non-canonical with a small lost of 1 to safe his 1000000. I have a feeling (might be wrong ><) this can be totally practical in dex tx, especially after some market price change and input owner starts to regret about previous tx.
I think my main point is that are we comfortable with the complexity of smart contract? If yes, then everything’s all good.
If not, here’s an option that can simplify things with some possibly acceptable tradeoff.
piotr [19 hours ago]
👍 on the challenging. But are you basically saying that it's better to have the in-flight-tx-input-owners just do Standard Exit, risking forfeiture of their bonds, in exchange for ditching MoreVP (In flight exits) altogether?
piotr [19 hours ago]
wow, either I'm missing something big time (I searched old ethresearch threads and own notes, but nothing came up) or one of the following is true
1/ considering forfeiture of the exit bond breaks the economics of the bonds, i.e. it introduces a downward drive to the size of the bond, which in turn makes it too easy to grieve the users. In other words: either invalid exits get too cheap or honest exits under a withholding attack get too expensive
2/ confirmation sigs/morevp and all of this has been a red herring from the very beginning, and its just easier to forfeit the exit bond, in an emergency situation
piotr [18 hours ago]
.
hm. I think it's probably the "missing something"+1/. (Sorry to extend the convo on slack, we'll migrate takeaways to gh issue, when we're past the clarifications):
The "block withholding" part is subjective. So suppose we have users forfeit exit bonds and force them to force the operator to disclose the inclusion proofs in the challenge and have the users then start a secure exit using the disclosed info; like you proposed.
What then is possible is:
1/ Alice sends tx1, which gets included in a block b1
2/ Operator selectively withholds b1 to Alice
3/ Alices is forced to exit and forfeits exit bond
4/ Bob sends tx2 (unrelated), and same story again
Operator can effectively milk exit_bond_size*number_of_utxos this way, which might be too large a loss to consider the protocol secure.
Regardless, I still think it's worth challenging the prior requirement, let's call it "strict exit bond retrievability", and see how could the protocol and economics work like
boolafish [17 hours ago]
Haha, from a plasma cash background, exit is the only way as far as I know to force data availability, which is not ideal actually.
An ideal bond size is: challenge gas cost + really tiny amount. (TBH, I don’t know how to setup this in practice)
So even operator tries so hard to steal bond, it would get really little per tx. Also, in your scenario, all other might compete the challenge so it might not end up going to operator as well.
One way to make this whole thing less of an issue is the tx explicit states which block it must must be included. So the only way for operator to withhold and challenge afterward is to not submit the whole block, and then this would be obvious.
boolafish [17 hours ago]
ah, the last part of the previous comment does not solve your scenario.
But if operator does provide data to other users, from a “network” point of view the data availability might be good enough. Just an user probably need to check multiple watchers before submit exit?
As there's a thread mentioning Plasma chamber team did the fast finality, that might actually be the solution here. Instead of exiting input to force data availability, output owner can start fast finality. This provide better protection to the output owner than in-flight exit in the same time.
Meanwhile, if it is not practical for operator to lock all the fund for fast finality bandwidth, alternative is to have a challenge data availability contract to slash bond from operator. In this case, it will only be a lose-lose (both need to pay gas or some bond) scenario whoever is trying to attack. So nobody would be motivated to start unless something bad really happens.
Another thought on this.
We can have a trie data structure with fixed size depth to represent the entire tx id set with the tx position in a block in the end of the trie. The trie data would be bound by a constant size: O(char_num^2 * trie_depth). (Each layer there are char_num slots, and you can have at most char_num^2 links from one layer to another). The trie would become the constant size inclusion proof for all txs in a block.
The trie is submit to root chain for each block. With the assumption that the user has his/her own tx data and can generate txId, the user can immediately check whether a tx is in a block or not without the need of asking extra data. In other word, there is no data availability issue as long as the user has the origin tx data.