Benchmarking Plasma Cash

[gakonst]

Implement a benchmark which illustrates the advantages of using Plasma over transacting on chain. We model the "happy-case" to find the upper bound limits of scalability in terms of throughput and gas costs.

Demo will include:

1. Register 1k players (hereafter referred to as players array)
2. Each player gets 20 coins.
3. Each player deposits 2 of their coins to RootChain.sol
4. Each player gives their 2 coins to the next player in the players array (i.e. 2000 coins change hands per block)
5. This repeats for 300 blocks (finalizeExits period will be adjusted for demo purposes to be every 300 blocks).
6. After 300 transactions happen for each coin, each player initiates an exit. Note that while this may sound like a "mass exit" as defined in the context of Plasma MVP for a malicious operator, this is just many users exiting and is not considered a case which needs to be modelled separately for gas costs etc - (can be optimized by using aggregate signatures?)
7. Exit period time passes, finalizeExits(iters) gets called, until all coins can be exited.
8. All 2000 finalized coins get withdrawn.

We want to obtain data on:

1. how does it scale with number of blocks (linearly? more?)
2. how much memory / storage is used by operator?
3. How much storage will each client need to maintain in proofs? We expect O(t * N) PER COIN RECEIVED, where t the number of blocks in the coin's history and N the depth of the tree, i.e. 64 in our case
4. How much bandwith is required to realistically send a transaction to the receiver along with all the necessary proofs?
5. How much gas is saved? Throughput? With some napkin math, for 300 blocks * 2000 transfers / block = 600k transactions. 1 safeTransferFrom costs ~120k gas, so we get about 72 BILLION gas required for everything to happen on chain.
   • We consider that a block can hold ~8m gas (which is slowly going up). This means that 9000 blocks are required to do that many transactions. The throughput gain for this is ~30 which further scales with the amount of coins that are being transferred.
   • In order for a coin to be transferred on chain 300 times, it requires 300 * 125k gas = 36m gas. In order for a coin to be transferred off-chain, a call to the following functions needs to be made: deposit / startExit / finalizeExit / withdraw, which is ~300k gas (need to check numbers), + the waiting period --> 120fold gas cost reduction. This gets further amortized as the number of coin transfers increases.

Notes: finalizeExits needs to be modified to have a number of iterations, since if many exits are to be initiated, it may require too much gas to finalize them all.

[aupiff]

A Plasma chain operator must maintain information about all blocks submitted to the chain. Storage requirements for the operator increase only as blocks are added to the Plasma chain.

Each Block is simply a signature along with a set of transactions.

Block:
('transaction_set', CountableList(Transaction)),
('sig', binary)

A Plasma chain operator will likely store a Sparse Merkle Tree containing the transaction set, but this tree can be re-created from the transaction set.

Transaction:
('uid', big_endian_int),                -- 8 bytes
('prev_block', big_endian_int),         -- 32 bytes
('denomination', big_endian_int),       -- 8 bytes
('new_owner', ethereum.utils.address),  -- 20 bytes
('sig', binary)                         -- 66 bytes

Each transaction, at best, will require 134 bytes of storage. Therefore, a Plasma chain operator, at the very least, should expect to maintain {# of plasma transactions} * 134 Bytes of data.