Plasma Chamber is a DApps development framework that guarantees security, scalability, and usability utilizing Plasma technology.

IMPORTANT NOTICE:

• This is an experimental software, does not run in a production yet.

• Vyper contracts are here.

Table of Contents

• Introduction

• Overview

• Getting Started

• Architecture

  • Root Chain Contracts

    • Deposit
    • Exit
    • Challenge

  • Child Chain

    • Tx Verification
    • Plasma Block Generation and Submission

  • Wallet

    • History Verification
    • Guard Feature
    • Wallet SDK

• Plasma Chamber Implementation Design

  • Key Features

    • Defragmentation
    • Fast Finality
    • Checkpoint
    • Custom Transaction

  • Security Guarantees

    • Simple Exit Game
    • Specific Exit Game for Custom Transactions
    • Longer Online Requirement

• Implementation Schedule

  • Demo Gadgets
  • User Generated Contracts

Introduction

Plasma Chamber is Cryptoeconomics Lab's first product that enables to generate General Purpose Plasma. Our implementation used Plasma Cashflow design as its basis, but support more complex transactions for each decentralized application without sacrificing its security.

Overview

Plasma is often times expected to be applied to several kinds of Dapps such as games, asset exchanges, etc. However, it requires production teams to employ expert Plasma researchers for careful security analysis in order to prepare their infrastructure. This causes duplicated research for each project, and security insights would not be shared sufficiently and efficiently amongst the projects. Hence, in order to solve this problem, Plasma Chamber is implemented to be a DApp development framework without requiring domain-specific Plasma for each project.

Getting Started

Requirements

You need to install them before deploying Plasma Chamber contracts.

• Node.js v8.11.3 or v8.15.1
  • You can install Node.js from here; https://nodejs.org/en/
• ganache-cli latest version
  • You need to install npm or Yarn first
  • how to install ganache-cli; https://github.com/trufflesuite/ganache-cli#installation
• Vyper 0.1.0b9
  • You need to install Python v3 or higher into your OS first (make sure to check the prerequisites on the official installation doc; https://vyper.readthedocs.io/en/latest/installing-vyper.html#prerequisites)
  • how to install Vyper; https://vyper.readthedocs.io/en/latest/installing-vyper.html#installation
• Other package management tools / Ethereum testing framework
  • npm
  • lerna
  • yarn
  • lerna bootstrap
  • truffle

Deploy contracts

Run ganache with test mnemonic

ganache-cli --mnemonic 'candy maple cake sugar pudding cream honey rich smooth crumble sweet treat'

deploy contracts.

npm i lerna yarn -g
git clone https://github.com/cryptoeconomicslab/plasma-chamber
cd plasma-chamber 
lerna bootstrap
cd packages/contracts
# switch python3.x
yarn build
truffle migrate --network local

Run plasma chain

cd packages/operator
cp ../../.env.sample ./.env
npm install
node -r dotenv/config lib/entry

Or you can install global module.

npm i @layer2/operator -g
ROOTCHAIN_ENDPOINT=http://127.0.0.1:8545 ROOTCHAIN_ADDRESS=0xb9A219631Aed55eBC3D998f17C3840B7eC39C0cc OPERATOR_PRIVATE_KEY=0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3 layer2-operator

Or use docker image.

docker run -e 'ROOTCHAIN_ADDRESS='{root chain address}' -e 'OPERATOR_PRIVATE_KEY={private key}' -e 'ROOTCHAIN_ENDPOINT='{endpoint}' -v /path/to/db:/var/plasmadb  -itd -u node cryptoeconomicslab/plasma-chamber:development

You need envs described here

Run wallet

git clone https://github.com/cryptoeconomicslab/wallet.git
cd wallet
yarn install
cp .env.sample .env
yarn start

Open http://localhost:8080 in browser.

Use docker compose(for operation check)

$ docker-compose up

Architecture

Plasma Chamber's architecture enables service providers and its users to take advantage of lower transaction costs and higher throughput without sacrificing security derived from the rootchain. This is accomplished by process of compacting multiple transaction data on a child chain block and submitting it to a root chain (Ethereum blockchain in our case). The diagram below illustrates the connection between the wallets of service provider/ users and Plasma Chamber on top of Ethereum blockchain as its root chain.

Root Chain Contracts

Deposit

Any Ethereum address may deposit Eth or other fungible token into the root chain contract. Then such deposits send the equivalent amount of pseudo Eth/ERC20 to the child chain contract. Those deposited funds are recognized as a single UTXO on the child chain. Such UTXO can then be both spent on the child chain or exited to the root chain by users after a challenge period ends without a successful challenge completion.

Exit

As users request to withdraw their funds deposited on the root chain, child chain gives the equivalent amount of pseudo coins deposited on the child to the root chain, submitting the existence proof of the transaction to the root chain. This procedure is called ‘exit.’ Existence proof is consists of 3 different piece of information; Merkle Hash of Merkle Tree, in which the exiting transaction was included, Merkle proof, and the block height of the transaction.

Please see Simple Exit Game section for the details of our Exit and Challenge design, including Exit games.

Challenge

When transactions are in the process of exit requested by a user, another user can invalidate the transaction by "Challenge" action, presenting other transaction with true ownership. When the challenge was approved by the contract, then the exit get blocked.

Child Chain

1. Uses UTXO model to transfer pseudo fungible coins with a unique id.
   
2. Enables a PoA network, which is centrally controlled by a single party or entity called ‘operator.’ This enables high transaction throughput, while deriving the security robustness from the root chain.
   

Tx Verification

In the Child Chain network, the state of UTXO gets updated to the latest status everytime Child Chain receives Deposited, BlockSubmitted, ExitStarted events. This single party operation enables faster transactions verification and it returns the response to the client wallets faster.

Plasma Block Generation and Submission

In the Child Chain network, an operator assembles transactions initiated by end users hash them into Merkle Root. Sum Merkle Tree gets constructed, defining transaction hash as its leaf and the output of transaction hash as its range. Then, Merkle Root is submitted to Root Chain contract. In short, utilizing Sum Merkle Tree, thousands of transaction data can be reduced in to 32 bytes Merkle Root and get processed on the Main Chain as 1 transaction, resulting in the gas cost reduction.

Wallet

History Verification

• Client wallet conducts inspection of UTXO history data referring to events on the Root Chain contract and Merkle Proof submited by the Child Chain. This inspection is conducted whenever the wallet receives and uses new UTXOs. This is a distinct design which diffirenciates Plasma Chamber from any other sidechains as a trustless sidechain, inheritating main chain security from the first layer.
• Compared to Plasma full nodes, Plasma Chamber significantly reduces the size of the history data that clients have to inspect with range chunking and checkpoint functions. The size of the history data with one UTXO is expected to be not more than a few mega bytes utmost. Also, with the defragmentation feature, data size that each client has to hold will not be more than a few mega bytes either since UTXOs will be chunk up into one UTXO.

Guard Feature

Client wallet can detect invalid exit of a transaction which is related to some UTXO that the wallet owns while it becomes online at a regular interval.

Wallet SDK

Client wallet can handle and generate not only transfer transactions, but also more complex transactions. We provide our wallet SDK, which include functions of history verification, guard feature, and syncronization of Root Chain and Child Chain data here.

Plasma Chamber Implementation Design

This section describes the feature of Plasma Chamber's protocol design. Plasma Cash model is the basis for our implementation, but several modifications proposed later in Plasma Cashflow and Plasma Prime design are incorporated.

Plasma Chamber has 4 key features and 3 security guarantees listed below.

Key Features

Defragmentation

Plasma Chamber has intra-chain atomic swap and force inclusion property. These properties are implemented for the fragmentation of the segment of the coins. Defragmentation requires the intra-chain atomic swap first, then securing the safety of the exit game. The Force Inclusionfunction is required to mitigate newly introduced atomic swap feature. You can refer to our docs for more details of Force Inclusion function. Current limitation requires of the end users who are swapping the segments of the coins to be online simultaneously for atomic swap. By making the operator as the broker of swap request matching, end users' online requirement would be mitigated. This update doesn't lower the fund security of Plasma, and incentivize the operator to maintain the chain defragmented.
Please also see more of our documents on Defragmentation form here.

Fast Finality

Allows customers to have better user experience of transaction confirmation. The fast finality bandwidth is sold via Merchant PoS wallet.

Finality
Finality means that once a transaction has been processed in a certain block, it will forever stay in history and nothing can revert that operation.

Fast Finality function will only be available to limited third party service providers who hold wallets and authority to control trasferring token values to users' wallets. End-users of the service can get confirmation on their transaction's finality faster when the service provider buy Fast Finality Token from the operator (in this case, service providers are independent from the operator) and make a deal with the operator to include the transaction in a timely manner. In other words, the fast finality bandwidth is sold via merchandiser-wallet. If anything goes wrong within the network, service providers can challenge operators on the Fast Finality contract, claiming that the transaction was not included in the corresponding block.
See Fast Finality wiki page for the source code of this Fast Finality contract. The rough specification is in Learn Plasma - Research.

Checkpoint

Reduces the transaction history that each end user has to hold.
Checkpoint reduces the amount of history data that each user need to keep on wallet, inheriting from Plasma XT. Adding this to fungible Plasma Cash require careful analysis in order not to remain chain-wide mass exit probability. Via this checkpointing, we don't need to wait for the implementation of trusted setup RSA Accumulator nor trustless setup zk-STARKs.
See Checkpoint section for the source code.

Custom Transaction

Enables plapps-developers to build decentralized application that has more function than just a transfer transaction.
The operator is able to set adhoc transaction verifiers and state verifiers. By this immutably appendable modules, Chamber is to be #plapps framework in order to develop more than simple payment.

Security Guarantees

These properties are implemented as a Plasma Cash variant which supports fungibility of coins with range feature implemented by Sum Merkle Tree. At the same time, this design focuses on to utilize the security of original Plasma Cash design's robost security model to the maximum level.

Simple Exit Game

Our simple exit game, a non-intereactive security model was implemented inspired by simpler-exit-game-for-plasma-cash, which does not allow any random pattern of malicious exit and Mass Exit problem. It makes Plasma Chamber resilient to rearrangement+Withholding attacks. Since multi round challenge-response is not required for full security anymore, coin-wise priority queue guarantees each end user's fund from the operator. Also, our Simple Exit Game can be compatible with our Range Chunking feature.
See Simple Exit Game section for the source code.

Specific Exit Game for Custom Transactions

Since various UTXO contracts are permitted on this Plasma childchain, the inputs and outputs of a tx can be more than one set unlike the original Plasma Cash design. For instance, swap, multisig, or escrow functions are the popular example of UTXO contracts. How to develop these contracts will be described in Custom transaction and state verifier.

Longer Online Requirement

Developers can choose to implement longer exit period. Even with a longer exit period, end users can withdraw their funds immediately as long as they can provide the history of the asset by the Simple Fast Withdrawals function and verify themselves. On the other hand, clients will have to hold their history incrementing in proportion to the longer exit period.

Implementation Schedule

Demo Gadgets

Those are outer-protocol inventions to be implemented Q2~Q3 of 2019 to improve the usability of Plasma Chamber.

• Escrow with Trusted Third Party with repeated game enforcement
  
• Escrow SDK, Tx format verifier, and extended exit game
  
• Cloud Keystore as email-passphrase import enabler
  
• DAI and LCJPY(LCNEM Inc.'s pseudo-hard-peg JPY Stablecoin) integration
  
• Instant deposit from traditional mobile banking app
• Fee Model
  
  • head-body Tx structure for enabling exit-game-safe fee model for both operator and contract developer
  • Only merge&swapTx can be ZeroFee in order to disincentivice fragmentation.
  • GasToken based one year locked fee model to deal with the volatility of ETH price

User Generated Contracts

After we release our first demo, we would like ask Dapps developers across the world to implement these functions through open-source contribution here.

• MerchantWallet
  
• BlockExplorer
  
• Deployer: must return SDK and Documentation
  
• UserExperienceTarget: 5 days for deploy
  

Contribution

• plasma-chamber is a Commitizen-friendly repository.
• yarn commit enforces commit message patterns to keep release notes and monorepo versioning organized.
• lerna is running on independent-mode, so each package has semver-based version.
• yarn bump automatically increments the version of each package. This incrementation rule is supported by lerna-semantic-release. Flags mentioned below are interactively asked via yarn commit; breaking flag increments major version. feat flag increments minor version. fix flag increments major version.
• Also, yarn bump additionally generates CHANGELOG.md under each package without commits to Git. Please make sure to paste them on Github release.
• yarn publish will publish each package to npm.