Plasma for Tezos

Current Situation

There is focus on Tezos on assets. Given intrinsic scaling limitations of blockchains, the regular smart-contract based solutions can’t scale.

Proposed Improvement

Intro

Plasma is a layer-2 solution that has been developed on Ethereum. The underlying idea is that an " operator " (which could be the current baker, or an external actor) aggregates transactions and regularly posts commitments to those on Tezos. People can then make claim on assets, which can be refuted by others thanks to the commitments to the transaction history. What allows it to scale is that only claims and commitments to a transaction history are posted on the blockchain.

Content

The content is not fixed yet, and this is part of the reason of this post. There are multiple ways to go about it:

  • Simple Smart-Contract. This is the standard solution.
  • Amendment to the protocol. Whether it is a new kind of operation of new instructions to Michelson.

Comparison

The smart-contract approach and the amendment are complementary.

The advantages of doing it through a smart-contract are the following:

  • It doesn’t require adding parts to the protocol of Tezos.
  • There is no need to wait for the amendment process.
  • It is easier to prototype (no need to set-up a whole new test-chain).

The benefits of using an amendment instead of a Smart-Contract based approach are the following:

  • It is much more gas efficient and clear than some Michelson code.
  • It yields a focal point as a way to avoid competition between implementations .
  • It enables much more advanced consensus features for the operator (based on the current baker, for instance). This is especially important with regard to resistance to censorship.

This suggests a natural complementary relationship, where the smart-contract are used to prototype new systems, and where once they are battle-tested and studied in depth, can then be integrated into the protocol.

Plan for Plasma on Tezos

Because of this, a plan for Plasma in Tezos might be:

  • Implementing Plasma for assets on the base layer
  • Implementing more recent and more powerful Plasma flavors (such as the OVM) through Smart-Contracts
  • Once such flavors are more understood and formalized, moving them back to the base layer

It is important to notice that if there is any problem with the base layer implementation (misaligned incentives, for instance), it is possible to simply use the smart-contracts while it is being fixed or even deleted. Even though using the smart-contracts be less efficient, it precludes long discontinuities of service.

Concrete Steps

Assets in the base layer

Currently, I’m adding Plasma on the base layer through new operations. For a number of reasons, it seems better to use Michelson instructions instead, but there are some added complexities that makes it harder as a prototype. I’d gladly discuss those here if there are expressions of interest.

I will push to a branch once I have working tests, the way I did it with views.

OVM

CEL is working on implementing the OVM with LIGO smart-contracts. They have extensive experience with Plasma, as can be witnessed by their work on their Github repository. The biggest benefit of supporting the OVM is where we will soon be able to use many other L2 construction such as State Channel and Optimistic Rollup as soon as their implementation is released. And so we don’t need duplicated work for them. The LIGO team is helping them for LIGO and Tezos matters.

11 Likes

Generally the features you need in the L1 smart contract language are:

  • Merkle Proof Verification (i.e. hashing and concatenation of 2 strings/byte-arrays)
  • Signature verification (recover pubkey from eddsa signature)
  • Some state which can be used to publish data if using on-chain data availability schemes

I do not think that there should be a need to add operations on the base layer other than the aforementioned ones. Which operations did you have in mind?

4 Likes
  • For Merkle Proof Verification, the one you suggested is important. I would also add Merkle Sum/Interval Trees verification.
  • For Signature Verification, you’re right too. I believe we can’t get a pub key yet from an address in Michelson.
  • Holding state is basic Michelson. Views can make accessing this state easier.

On top of this, I would add stuff related to consensus. Like, it’d be nice if it was possible to have bakers offer to be Plasma operators, and be slashed in case they do but post an incorrect block / don’t post. Given there is reputation associated to big bakers (they bake for others), it would be an additional incentive to not do block withholding too.

5 Likes