SolEVM predicate?

#1

During the implementers call today, there was some discussion around the great work leapDAO has been doing to build out a nested EVM to play out state transitions which exceed the block gas limit.

The predicate construction for our cashflow implementation can point to arbitrary on-chain functions, so it seems like we should be able to point at a solEVM implementation. I wanted to ping @johba and @kosta to hear their thoughts on how hard this sounds and figured this would be a great place to do it :slight_smile:

One concern that I have in our plasma cash variant is that the truebit game being used by leapDAO might break our safety without extra lockup. We enable limbo exits, in which a withheld in-flight transaction can be used to generate a special kind of exit without an inclusion proof for it. The thing being limbo exited is generated by calling the predicate contract’s executeStateTransition(input: StateUpdate, transaction: bytes) which returns a limboStateUpdate: StateUpdate. If the executeStateTransition method could not be called until a truebit game is played, this might be problematic because it would require playing truebit first which requires some extra timeout window.

I’m curious about the time windows leapDAO is using for the truebit game. I think our CHALLENGE_PERIOD would have to equal ONLINE_ASSUMPTION + TRUEBIT_GAME_PERIOD to guarantee enough time to execute a limbo exit safely, whereas now it is just the ONLINE_ASSUMPTION. How much time might that add, and what are folks’ thoughts generally? :slight_smile:

[Retrospective] Plasma Implementers Call #21!
#2

I’m curious about the time windows leapDAO is using for the truebit game

we are using half the Plasma challenge duration, as explained here:

cDance%20at%20Exit%20Party%20(3)
cDance at Exit Party (3).png1053×814 92.1 KB

limbo exit

We don’t have a way to integrate the cDance (computation verification game) into limbo exits yet. still working on just the regular exits.

How much time might that add

Timeout for a single step of the cDance is configurable, but min should be 100 blocks x executionDepth +1.

Let’s say we have a limit of 4096 = 2^12 exec steps, then the cDance is 12 steps long => 6 hours.

predicate construction for our cashflow implementation can point to arbitrary on-chain functions

Given the above information, i’m still unclear how you would integrate solEVM, as it is a crypto-economic challenge game. You can propose computation result, then open it up for challenges. if the economic incentives are well aligned, and result passes the challenge duration, then you take it to be correct. :thinking:

#3

Thanks for these numbers! Very helpful :slight_smile:

Out of curiosity, do you have a plan for how to integrate it with limbo exits? I would be curious how that works with the exit game.

I do think that if we set the solEVM game to half the exit period, this removes the challenge of limbo exits. With that, we could definitely create a solEVM predicate, by simply having a mapping validatedStateTransitions[input, output] -> bool which is set by playing the truebit games, and referenced by the predicate contract during the exit game-relevant function calls.