Skip to content

Instantly share code, notes, and snippets.

Last active August 26, 2021 21:02
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?


Trustless verification of a Plasma sidechain from the Ethereum mainnet using TrueBit-like binary searches and a mainchain contract that evaluates EVM state transitions.


At Decentraland, we want to scale the number of transactions per second for different in-world contracts, we don't want to compromise on verifiability, and want to keep the system trustless. We are exploring the idea of running a PoA blockchain, but we would like to have strong assurances that the operator of this blockchain is behaving correctly. We want to keep the properties of being censorship resistant, and we can compromise on the decentralization of block producing, as long as the consensus rules are being followed. Also, Plasma MVP, Plasma Cash and Plasma XT are all aiming at cross-chain token transfers but not really at general purpose contracts.


The idea behind PlasmaBits is to run geth/parity with minor modifications (PoA) and have a Plasma contract on the main chain verifiying that secondary blockchain. In order to verify correct state transitions, we use TrueBit to challenge potentially consensus breakage/censuring behavior of the authority issuing the blocks.

In order to achieve this, we propose the following system that includes enough mechanisms to provide a fully validated Plasma sidechain based on proof of authority:

  • A Plasma Contract that keeps track of the last checkpoint of the sidechain
  • A contract dubbed "EVM Stepper" that takes as input: the state of a EVM runtime environment, an instruction (opcode with its arguments), any witness data needed to resolve storage lookups; and outputs a hash of the EVM runtime state after executing the instruction.
  • Several challenge contracts that keep the authority on check:
    • Block-level consensus challenges (signatures, previous blocks, time elapsed, no duplicated blocks, etc)
    • State transition challenges
      • TrueBit binary search on the state after each transaction (might need witness data on accounts)
      • Transaction-level state transitions (using TrueBit binary searches and a EVM-native EVM Stepper)
    • Censorship resistance and availability insurance contracts
      • Any participant can challenge the authority to include a transaction as possible in its next checkpoint, otherwise the authority looses a security deposit.
      • Availability contracts: challenge the authority to present the preimage of transactions and blocks, also based on a security deposit.
      • SLA on the time between header commitments
  • Parameters so checkpoints/header commitment can be considered final need to be picked carefully, compromising finality for liveness.
  • Transference of tokens from one chain to the other is left to each application to implement (other contracts that execute atomic swaps or manage state channels against "twin" contracts on the sidechain).
  • In case of consensus failure, the exit from one Plasma sidechain can be made by executing state queries to the defunct sidechain.
  • A consensus failure can be solved by creating a similar Plasma chain with a different consensus (or authority) picks up from the last valid state.
  • The fact that the EVM Stepper must include the code to do EVM execution and trie state retrieval allows for the main chain to execute state queries to the last checkpoint of the sidechain, so the main chain can retrieve the state from the defunct sidechain. This has uses in sharding as well.


  • Attempts to reuse software that already exists (no need to create a plasma client and server)
  • Complete verification of the sidechain
  • No hard fork needed
  • Simplified entrance/exit mechanisms


  • Complexity of the TrueBit incentives, code of the EVM Stepper and other contracts
  • Availability challenges should slow down the sidechain to achieve security, and disincentivizing challenges is a risky endeavor.

Previous Work

  • EIP 726: Execute EVM inside EVM. This proposal differs in that we introduce an interactive game instead of executing the whole transaction.
  • solevm: Solidity EVM and Runtime PoC. It's a very early implementation.
  • patricia-trie: Implementation of Patricia Trees in Solidity. Needed for storage queries.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment