Fraud proof for arbitary state transitions

#1

I was reading the whitepaper and the Medium articles on Matic’s architecture. You guys mentioned that you have an account based plasma model and that you can use smart contracts on the Matic sidechain as well. However, I don’t understand fully how this is feasible.

Suppose I deposit some Dai to the Matic contract on the mainchain and get the equivalent Matic tokens. Now suppose I send these tokens to a smart contract A deployed on the Matic chain. Now its the rules of the contract A that effectively control my tokens.

Now if I want to take my coins in the smart contract and exit to the main chain for some reason, how do we generate the fraud proofs to prove that I indeed hold the coins that are locked in contract A on Matic chain?
Would you have to exit the entire contract? If so, what about the other accounts that hold tokens in A? Can anyone initiate the exit?
Can you somehow prove that x number of arbitary state transitions finally led to me being holder of those tokens. But how would we verify that on mainchain?!

1 Like
#2

Hey Pawan,
Great set of questions. Exiting from generalised state transitions on the plasma chain is a hard problem and a topic of research among the community. That said, we do have some ideas in mind and are working on those.
Currently our implementation supports exiting from a limited set of state transitions, one of them being ERC20/ERC721 token transfers. We are using the plasma predicates design pattern for the same. Here is our specification and you can find the code in our contracts repository. Next up we are working on the predicate for atomic token swaps!

1 Like
#3

Thanks for the reply.

The predicates pattern looks interesting. A couple of questions though

  1. Is the aim to build a standard library of frequently used predicates (ERC20/721 transfers, atomic swaps etc) which developers on the plasma chain can plug into their contracts?
  2. A non standard functionality like changing the color of a cryptokitty (the example used in the link) would require the application developer to come up with the implementation for the predicate interface as well as deploying the predicate contract to main chain. Are there plans for abstracting away this process?
  3. Also since deploying a contract on main chain for every predicate might be expensive, would it make sense to deploy these predicate contracts only in the case of dispute/exit (counterfactual instantiation of predicate contracts)?
#4
  1. Yes, that’s the idea. Moreover, the way we are developing ERC20/721, swap predicates is such that developers don’t explicitly need to “plug” it into their contracts. The predicates will work for any token.
  2. Yes, a developer who wants plasma guarantees on their contract, should implement the predicate interface and deploy it to the main chain. I don’t see how it would be possible to abstract out this process.
  3. It’s possible. But like any other ethereum based application, users are confident about interacting with a Dapp when it’s possible to audit the code. Similarly, users will interact with a dapp on sidechain when they know how exit games will play out - otherwise, if and when the need for dispute resolution arises, whom will you trust to deploy the right predicate contract?
1 Like
#5

Ohh so essentially one predicate contract on main chain would work for all contracts using that predicate on the plasma chain. That makes it much clearer now!

Regarding the 3rd point, I was suggesting having the bytecode of the predicate contract stored onchain to be eventually deployed in case of dispute instead of directly deploying the contract onchain. But now I see it won’t make any practical difference.

Thanks for the clarifications :slight_smile: