Question regarding abilities and limitations of Plasma Predicates

#1

What are the limitations to writing apps/smart contracts using Plasma Predicates or is almost any kind of smart contract possible? Any examples/use cases for the limitations?

#2

Think of predicates as separating the exit logic from the actual contract that stores the assets.

When making a transaction, you specify a predicate. That predicate defines some spending conditions. The simplest spending condition would be “return true”, which would mean anybody could exit such coin. That’s obviously broken.

You can define a predicate that checks a signature and a merkle proof. That’s basically equivalent to the current spending condition in Plasma Cash. If you defined a predicate that checks for the existence of 2 signatures out of 3 allowed ones instead of just one, you now have a 2o3 multisig!

So the logic you can implement within predicates is still limited to items that have clear “ownership model”, i.e. assets. Predicates simply allow you to expand the design space for how complex spending conditions you want your coins to have.

#3

@gakonst that was useful and quite clear.

I understand this as, the spending condition has a contract logic and an exit logic. The contract logic is programmed into the child chain and the exit logic is programmed into the plasma predicate. Is this correct?

It seems like every time a new spending condition needs to be added, it requires modification of the child chain code. If the code has shipped and the network is running, it could be cumbersome and quite difficult to quickly add spending conditions. Is it possible to make the spending conditions scriptable?

#4

Yep, absolutely! One way to get this sort of modularity is to use “predicate plugins” on the client. Instead of hardcoding the predicate logic into the client, you’d have a plugin system where anyone can easily add new client-side code to support new predicates, no massive upgrade required. This is what Plasma Group is currently doing in our client architecture.

#5

@kelvin , predicate plugins on the client side looks like a really useful method towards easily extensible spending conditions. Can’t wait to read the details of Plasma Group’s work on it.

#6

@kelvin , is it possible to use predicate contracts and predicate plugins to implement a limited EVM for spending conditions. This could make app development much easier as app developers can just write the contract logic and not worry about the exit logic.

I imagine multiple implementation paths of predicate contracts/predicate plugins to support the complete spectrum of efficiency and generalization for various use cases. Eg.
. Value Transfer
. DEX
. Multi signature
. Nested chains
. State channels
. Generalized limited EVM for spending conditions
. Etc.
Is something like this possible?

#7

Yes, this is exactly the model we are going for at PG! So far we think all of the things you listed are possible to build with predicates.

Notably the additional exit games for more advanced predicates do require some custom logic for guarding by playing out that particular exit game. But a huge class of these predicates will have very similar if not identical exit logic which can be played out which should make the development process more feasible :slight_smile:

#8

@ben-chain that’s great to know. Using predicate contracts and predicate plugins to support multiple implementation paths for DEX, Limited EVM for spending conditions, etc. would be amazing. That I think will make Plasma attractive to developers to build apps. On top of this if the developer tooling is done, the developer experience would be great. Looking forward to PG making available a working version of this model.

#9

One of the things I’m personally interested in is a “general purpose” predicate plugin for simple predicates that don’t need access to external Ethereum data. Would make building these predicates easier since you wouldn’t also need to build a corresponding plugin. Definitely not an immediate priority, but something I’m hoping to work on in the future :+1: