Collect Predicate Isolation Idea

[boolafish]

This is use as a placeholder issue to collect Predicate isolation idea (no matter it works or not). Would move it to some docs at certain point.

[boolafish]

One idea: To add new predicate B to an existing output type A, instead of binding them directly, we create a output type A' that would be bonded instead. For all old tx holding A, it would need to sign-off a tx that change A --> A'.

In fact, the tx of A --> A' can be pre-defined. So whenever we are creating a new output type A, we also preserve a A' type in the future. We can add another function on contract to lock the registry for adding new predicate to A to protect output A. So once locked, the output type A is protected to be isolated.

[paulperegud]

So, this creates a set of sets of possible output types. Where utxo can transition from type to type within one set via predicates. And jumping from set to set is possible only via special 'upgrade' transaction.

What I see here as a problem - is a problem of set of sets. Imagine actor A adding predicate A and actor B adding predicate B. This creates 4 possible sets. [{},{A},{B},{A,B}]. So we have an explosion of possibilities.

[boolafish]

So we have an explosion of possibilities.

How is this a problem though? If operator code does support all possibility and all sets are what we want it's totally fine. Otherwise operator code would just support what we need to provide the service. Even there might be a path to go forward all possibility, user would just not go (?). Even they went, they are only losing their own money as long as we check sum(input) >= sum(output).

BTW, currently I am only seeing this as a solution for easier and safer upgrade. With this isolation, I think cooperation with operator (at least server code level need to support) is still needed. I guess your goal is to eventually get this burden out from operator?

[paulperegud]

So we have an explosion of possibilities.

How is this a problem though?

It's a problem if we treat predicate isolation as a open system feature. If we treat it only as a safer upgrade mechanism, than it's alright.

[boolafish]

@paulperegud BTW, since this issue is used as a placeholder to put all ideas, do you mind to write down some of your previous thinkings here too?

[paulperegud]

(notes from call with @boolafish )

re: explosion of possibilities. This problem will not affect end users. It might give some headache to developers of particular dapps. This means that this approach can be treated as a open system feature.

re: re-implementation of arbitrary predicate code by operator (see also #79). We can do eth_call to predicate on ethereum node instead. That would require some abstraction around utxopos <-> inclusion_proof relation. We would need inclusion proofs on Ethereum chain but not on plasma chain.

[boolafish]

[Note with Pepesza] ah....Pepesza comment the note above first lol

1. For the problem of not able to embed logic to operator/watcher server code, a possible solution is for them to run whole tx verification logic in EVM. A naive possibility is DAPP providers write their predicate contracts and deploy both to the server EVM and ETH. Note that the functionalities requirement of predicates on Ethereum and on server EVM might be different.

2. Regarding previous comment on "we have an explosion of possibilities." This in practice might be fine because it will be the DAPP provider to create the set and try to convince user to opt-in to their sets. User don't need to be exposed to whole possibility. User would be more likely to see a UI provided by DAPP asking them to opt-in their set.

Some remaining issues I can think of

1. Even running whole verification in EVM, how do we make sure predicate provides the correct logic? To be more clear, I think we would need another type of predicate that is checking on transaction level instead of output/state level. As a minimum requirement, we needs to make sure the predicate checking "sum of inputs >= sum of outputs" is build correctly. The isolation Idea on output predicate would not work for this because whenever this fails, it can take money from those who does not even opt-in.

[boolafish]

Moved current comments to doc in wiki: link here

Closing this first as it is not prioritized for Cinnabon and got some draft idea already.

[boolafish]

(reopen this to hold notes)

[Note with Pepesza 06.04] Pepesza mentioned that predicate for starting exit might be different from predicate used in challenge. Challenge might be lighter. (eg. IFE, when starts it checks everything. However, in challenge, the competing tx only checks sig.)