Announcing Tezos Integration to Plasma Chamber

Hi guys! We’re thrilled to announce that we received a grant from the Tezos Foundation to develop a Plasma layer on Tezos and integrate Tezos to Plasma Chamber!

This project definitely introduces a new paradigm for L2 development, and we hope many more people will recognize and think about this L2-centered development paradigm going forward!

Who we are

We’re Cryptoeconomics Lab, founded in Japan in July 2018. We’ve been contributing to the Plasma community and recently met with Gabriel Alfour of The Marigold Project (Marigold, a layer-2 scaling technique for Tezos, and LIGO, a statically typed high-level smart-contract language for Tezos). He’s a very talented developer and we are excited to collaborate with his team!

What we build

We build Plasma with the Optimistic Virtual Machine (OVM) compatible spec. There are so many Plasma variants and zk-S[NT]ARKs applied solutions, and the OVM is a common spec for all of these variants. This OVM specification was introduced by the Plasma Group, and we’re focusing on building Plasma from their spec. You may be confused why we think such a long explanation is necessary! But this design choice is quite effective for building a strong L2 ecosystem. We will elaborate in the sections below.

Why we build

1. Problem of L1 and paradigm shift of L2

1–1. Problem of L1 and earlier L2 constructions
1–1–1. The security and capacity of sidechains

Sidechains usually employ staking for their security models. So, in order to attack a sidechain, an attacker is required to control as much funds as are staked for that sidechain, rather than a Layer-1 (L1) staking (“baking” in Tezos) sum amount. This ease of attack limits the capacity of an ecosystem. It’s okay for gaming usage but it won’t work for international/industrial usage.

1–1–2. TPS limitation of sidechains

As normal sidechains rely on staking, network latency is the main bottleneck for its throughput. Even Hyperledger or a private Ethereum network could only process 300–700 TPS. This is not really enough for international/industrial usage.

1–2. Properties of Plasma
1–2–1. Gas-Less

Plasma doesn’t require end-users to pay tx fees in a native token. A Plasma operator pays this when it compresses txs into a Merkle hash. So, non-expert users can handle security tokens or stablecoins more easily. (The operator will take some fee from a chosen token, rather than a native token.)

1–2–2. High Throughput

Plasma is just like PayPal or Alipay with its off-chain design. It uses a blockchain-style specification as a security model, but it doesn’t broadcast blocks or txs to other nodes. This eliminates network latency. We’re assuming a primary performance bottleneck is CPU (Merkle Tree Calculation) and we expect very large room of tuning, yay!

1–2–3. Instant Finality

A state channel on Plasma or NOCUST-ish protocol on Plasma enables instant finality. A normal Plasma tx requires 2~6min to finalize the tx, but we can design ~300ms finality for special use-cases.

1–2–4. Value Centered Contract

Unlike an L1 smart contract (Data Centered Contract), L2 contracts have to use a “Value Centered Contract” paradigm. We call it a Predicate. It can look like the UTXO model of Bitcoin, but we can design several applications which use multisig, state channel, escrow, atomic swap, CDP, and so on.

1–3. “L1 agnostic L2”

We’d like to introduce the “Layer-1 agnostic Layer-2” concept. This is the reason why we could adopt our Plasma implementation to Tezos. And Tezos brings Plasma several improvements!

1–3–1. Smoother dev experience on Tezos

Tezos has a built-in feature-toggle system. When a change to the core protocol is proposed, we first have to implement the proposal, and then only the election-winning proposal can go to the production environment. This election cycle currently occurs once a quarter (approximately every 3 months). Without this feature, we sometimes have to wait extended periods of time for new opcodes and other innovations to be introduced, or we need bypassing temporal implementation. This is very helpful when we deal with new cryptography, etc.

1–3–2. Ease of value exchange between the same spec L2

Interoperability is cumbersome and sometimes insecure. But a cross-chain atomic swap between Plasmas via an HTLC contract would enable much safer interoperability between Tezos and other chains. We could see a DEX with all kinds of tokens from other blockchains.

1–3–3. Open source doesn’t make a Silo, and so L2 first development methodology helps developers a lot!

What if we build Plasmas, State Channels, and zk-S[NT]ARKs solutions on their own, for each blockchain? The learning curve of developers is to be O(N²) and developers will stick to their favorite implementations. It is helpful for all parties to consolidate the spec of L2 implementations and make them easier to switch ecosystems as they require.

2. Industrial Adoption and Production Usage

Having a chance to adopt Plasma in the real world is very important to get insights of devops and business usage of Plasma. Tezos is gaining adoption and momentum in several industries and so we love that challenge.

2–1. Voting

You know, 500+ people died in an Indonesian presidential election due to a manpower-dependent operation that lasted 48 hours. Building e-voting systems is usually closed source and not developed transparently in order to keep an implementation secret (security of obscurity). But Plasma-based voting systems can be implemented in an OSS way, it’s much cheaper and safer to do so. And this time 180M Indonesians voted in that election. It requires more than 5000 TPS for this type of application. We love high throughput projects.

2–2. Narrow Bank

Plasma can be seen as a narrow bank if we use a stablecoin. Even that narrow bank could be integrated with a DEX of security tokens, other cryptocurrencies, and foreign currencies. Is an operator of Plasma required to obtain a banking license? No, Plasma doesn’t hold customers’ funds at all (non-custodial). So even an electricity giant, a mobile carrier, or e-commerce corps. can easily be a bank!

2–3. Non fossil fuel certificate exchange

A non-fossil fuel certificate can be a token. And it is not regulated as a security in many countries. This area is also very close to real-world adoption!

3. Challenge for Seamless User/Dev Experience

3–1. State Channel integrated Wallet

A state channel and Plasma must share an app in order to avoid redundant source codes.

3–2. Universal Login

This “Sign in” experience enabler can be migrated to Plasma.

See also: https://universallogin.io

3–3. Lost Fund Restoration

A Plasma operator can restore funds in a secure way by using exit-game magic.

3–4. Multi runtimes

Plasma has to share several modules between various runtimes such as a mobile app and IoT device. So we chose Rust as our implementation language. WASM enables us to run the same code everywhere.

Roadmap

Aug~: Android Wallet
Oct~: Plasma in OCaml
Dec~Feb: Child-chain Integration

About Next Iteration

We will prototype an Android wallet specifically focusing on Tezos tx creation, Tezos pooling, and Plasma tx creation. A main difficulty is how to run Rust code on Android runtime, and how to abstract Tezos pooling adaptor.

We’re very happy to introduce the latest spec of Plasma to the Tezos community, and are excited to open a new path to the L1 agnostic abstract implementation of Plasma!