# Funding Request for Plasma Leap

[LeapDAO](https://github.com/leapdao) (previously [Parsec Labs](https://parseclabs.org/)) has [delivered](https://parseclabs.org/blog/Announcing-Plasma-Leap-Testnet/) an EF [research grant](https://blog.ethereum.org/2018/05/02/announcing-may-2018-cohort-ef-grants/). The main product of the research has been [Plasma Leap](https://ethresear.ch/t/plasma-leap-a-state-enabled-computing-model-for-plasma/3539), a design that allows the secure execution of smart contracts on Plasma. Allowing smart contract to run on layer-2 scaling solutions like Plasma holds the promise to increase the capacity of the Ethereum network from ~15 txns/sec to many thousand transactions per second.

In this write-up we want to describe two different approaches to use the technology to create a global, public utility that enables scalability of the Ethereum network. The options that we see are the following:
- **Single-Operator Plasma Leap Chain -** This is the purest deployment of the Plasma technology, where only one party operates the chain and aggregates all the transactions. This party, the operator is bonded with a fidelity bond. Users are safe to use the chain, as the design of Plasma restricts the operator's access over the funds. If the operator misbehaves, users are free to exit their funds to the main-net at any time.
- **Proof of Stake Plasma Leap Chain -** In this setup the role of the operator is distributed amongst many validator-nodes that take turn to submit blocks. They operate the chain collectively and are bonded and rewarded with a dedicated token.

## Single-Operator Plasma Chain

This section will describe the efforts and costs required to launch a single-operator Plasma Leap chain. We'll estimate bottom up from open development work needed to launch the network. It consists of research work that needs completion as well as core development which encompasses the node software and related tooling.

### Research

Some parts of the Plasma Leap protocol have only been partially implemented or implemented as PoCs during the grant delivery. These aspects of the protocol are most experimental and carry the most risk.

| Item | Duration in days |
| -------- | -------- |
| SolEVM Runtime | 40 |
| EVM-JS Runtime | 30 |
|Computation Verification game | 20 |

**SolEVM Runtime -** This is a partial implementation of the Ethereum runtime in Solidity. When given a transaction and it's inputs, it is able to verify that a transaction has been executed correctly. It does so through an interactive game with the solver and verifier. From the result of the computation the SolEVM is able to verify the correct outputs of a transaction.
**EVM-JS Runtime -** The Javascript runtime is the workhorse of execution. As part of the node this runtime processes all transactions that hit the memory-pool and the final blocks. It needs to be tuned for performance and delivers the inputs for verification games with the SolEVM.
**Computation Verification Game -** This is the protocol that compresses the verification of transaction execution to only one step of computation on-chain.

### Core Development

Core development encompasses many tasks on the node software that the operator runs to progress the network. The products of the research work are implemented within the node, to enable communication with the contracts and execution of crypto-economic games. Users may download the node and sync up with the operator to validate the correct state of the chain.

Beyond that, the node software needs to be tested for stability and performance, which are very tedious and often complex tasks which require the coordination of many developers or the simulation of actors.

Lastly, tooling is needed to enable a secure operation of the network, like block explorer, wallet libraries, and watch-towers, that help users to exit the chain if invalid or missing blocks are detected.

| Item | Duration in days |
| -------- | -------- |
| Plasma Leap Node - ||
| - Non-Fungible Storage Tokens |5 |
| - Clustering / Failover | 20 |
| - Stability / testing | 45 |
| - Storage | 10 |
| - Performance | 30 |
| Wallet Signer Library | 15 |
| Mobile Wallet Example | 15 |
| Watch Tower | 40 |
| | --- |
| **Core Dev efforts** | 180 |
| **Research efforts** | 90 |
| **50% risk buffer** | 135 |
| **TOTAL** | 405 |

**Plasma Leap Node -** the node is software used by the operator to run the chain. In addition to supporting the full set of features defined by the design, the node needs to be tested for stability, optimized for performance and hardened against potential DDoS attacks.

**Wallet Signer Library -** the UTXO model requires a special signing module that is able to select current unspent outputs to be able to generate a valid transaction. This library is created as a plugin to Web3.js and other frameworks.

**Watch Tower -** this is a node-like software that is able to validate the chain and initialize challenges against the operator or users that exit invalid funds.

Even though the [LeapDAO](https://leapdao.org) team (formerly Parsec Labs)itself does not operate on salaries, but rather pays for bounties, we estimate an average developer salary at USD 6,000 per month.
This gives a final development budget of `405 days @ USD 6,000 / month (21 days) = USD 116,000`.

### Disadvantages of Single-Operator Setup

The single-operator setup requires the following assumptions to make it viable:
- An egalitarian operator that will never censor transactions other than by fee paid.
- An operator ready to bring a sizeable fidelity bond in Ether.
- An operator ready to shoulder infrastructure and networking cost.
- Users ready to challenge the operator in a multi-step game to enforce correct custody of their funds.

From a user's perspective, there is a considerable risk to participate in such a setup due to two main reasons:
- **Censorship:** For example, as a team developing a Dapp the censorship by the operator can mean that the Dapp's contracts need to exit to the main-net at any time. While no funds will be lost, the interruption of service and the higher fees on the main-net might take a toll on the customer experience.
- **Continuation of Service:** While the bond prevents the operator from creating an invalid chain, there is no penalty for the operator to simply stop operating. For projects and teams this might pose a risk that will force them to choose another platform to operate their Dapps.

## Proof of Stake Plasma Leap Chain

A naive PoS setup can be imagined with a dedicated token of initially 0 supply. Any proposed block to the Plasma chain will mint new tokens and transfer to the validators for the operation of the chain. The use of the token as fee-token on the Plasma chain will eventually establish a market value for the token. Validators will compete with stake size over a limited amount of slots to propose blocks and earn block rewards. This competition will drive up the value staked and enforce the continuation of the chain.

### Advantages

``“While fidelity bonds ensure accuracy towards the chain, we need to create further incentives around data availability and discourage halting. By only allowing staking using a token specific to the Plasma chain, one is able to ensure that there is incentive to continue operating, as the value of the token is derived from the net present discounted value of all future returns from staking. Consequently, network failures reduce the value of the tokens being held and individual actors have heavy incentive to act in the best interest towards the network' s continued operation.”`` page 37 - plasma.io by Vitalik and Joseph (https://plasma.io/plasma.pdf)

- **Continuation -** Vitalik and Joseph describe in their Plasma paper how a dedicated token can incentive an operator to continue the operation of a Plasma chain and disincentivize data withholding.
- **Censorship Resistance -** The risk of censorship can be mitigated by Proof of Stake setups with multiple validators, where censorship is less likely across all nodes in the network.

The requirement for a dedicated token also complicates the launch of the chain. The above naive scenario would lead most likely to an oligopoly of validators. A fairer distribution could be achieved with a [merkle-mine](https://github.com/livepeer/merkle-mine)-like construct. However, efforts regarding the launch and operation of the chain are beyond the scope of this write-up.

### Development

The PoS Plasma Leap design would require all the efforts from the Single-Operator model to be completed. In addition, it would require the efforts listed in the table below.

| Item | Duration in days |
| -------- | -------- |
| Node - ||
| - CAS aggregation | 25 |
| - Consensus | 20 |
| Contracts - ||
| - token | 5 |
| - CAS validator | 5 |
| - Staking | 35 |
| Staking interface | 10 |
| | --- |
| **PoS efforts** | 100 |
| **Single-Operator efforts** | 270 |
| **50% risk buffer** | 185 |
| **TOTAL** | 555 |

`555 days @ USD 6,000 / month (21 days) = USD 159,000`.

**Crypto-Economic Aggregate Signatures -** Aggregate Signatures are used to enable efficient notarization of block data by the PoS validators. The protocol collects signatures off-chain and only submits a bitmap of all signatures on-chain.

**Staking -** This encompasses the contract and interfaces needed to for validators to join the chain and manage their stake.

## Conclusion

The completion of either of the above models would deliver a code-base ready to launch on main-net. This would not only substantially extend the capacity of the Ethereum main-net for transfers but also with the ability to run Dapps. In informal measurements we have been able to validate 2000 to 4000 transactions per second in our PoC. As described, we see advantages to complement the Plasma design with a tokenized PoS setup, and hence request the following budget. We estimate that we can deliver both milestones within 4 months.

| Item | Estimated Budget |
| -------- | -------- |
|Single-Operator Plasma chain | USD 116,000|
|Extension with tokenized PoS | USD 43,000|
| -------- | -------- |
|Total: | **USD 159,000** |