Plasma Debit

[gluk64]

Proposal

Implement an account model with arbitrary-denominated balances and Plasma-Cash-like exit guarantees (originally proposed here).

Rationale

No sidechain solution has been proposed yet which doesn't require a fall-back on the normal Plasma exit (individual exits on the root chain) in the worst case. In such an exit scenario, the system must be designed to protect against an attack vector in which an operator attempts to exit with more money than they actually own, while withholding data in order to prevent others from challenging the illigitimate exits.

Plasma Cash offers such protection by having the value split into descrete leaves in the Merkle tree and only allowing to change the ownership of a leaf, but not its value. Each leaf can only be exited once, enforced by a requirement to publish a nullifier to a root chain contract, along with a proof of ownership at some state S. The current leaf owner can always cancel an attempted exit by publishing the proof of ownership at a later state S'.

Security of this scheme is based on the following idea: current money owners affected by a attempted attack by previous owners of this money always posses succint data sufficient to easily detect and stop the attack. It's difficult to adapt this scheme to the arbitrary denominated accounts, because with arbitrary money flows everyone quickly becomes dependent on everybody's else previous account states.

Plasma Debit solves this problem, but it comes at a cost of additional capital requirement on the operator side.

The Idea

• Each leaf in the Merkle tree represents a value.
• Creating new leafs requires locking additional capital into the sidechain contract.
• The ownership of the value is split between the leaf owner and the operator in some proportion.
• Leaves can change owners.
• A transfer of value V to a leave in which operator ownes more value than V can be performed without locking extra capital.
• In case of the Plasma exit, the value is split on the root chain between the operator and the owner.
• Plasma exit is governed by the Plasma Cash rules (single exit per leaf, challenge period, etc.).

Optimizations

To minimize extra capital requirements and equip the operator with a lot of flexibility, we can introduce a few simple optimizations.

Top-ups

The value of a leaf can always be increased by the operator (a top-up). It is safe to increase the value, because if somebody exits the leaf at an earlier state, they can only steal less than the full value locked for this leaf.

Top-ups, like new leafs, require locking additional capital.

In-Circuit Capital Locks: Non-Exitable Operator Balanace Leaf

Creating new leaves or topping-up existing ones requires locking additional captial. To avoid the need to do this on the root chain for every leaf, we can introduce special non-exitable leaf for operator balance. An operator can lock funds into this leaf on chain once and use it later to create or top-up multiple other leafs in-circuit.

The value of this leaf can safely be decreased because it will never be exited.

We could create such leaves for other users too, not only for the operator. But this requires absolute trust in the operator from these users, because in case of data unavailability non-exitable leaves can not be recovered.

Leaf Splitting

We can introduce a 253 bit leaf-id, which will allow splitting the leaves in two up to 221 times with small nullifier check overhead on chain.

For example, if an operator holds 50% of the leaf with 8 tokens, it can be split into 2 leaves of 4 tokens each, one owned entirely by the original owner and the other one assigned to a new owner.

The benefit of leaf-splitting is that it doesn't require additional capital.

Atomic Swaps

If owners of two leaves cooperate with the operator, they can atomically swap ownership of their leaves. Operator can use it for defragmenting undercapitalized leaves.

Leaf Data Model

We can have several different Merkle trees for records with different update frequency:

Accounts (height: 24):

• owner_pub_key (253 bit)

Leaf_IDs (height: 32):

• id (253 bit)

Values (shares structure with Lead_IDs tree):

• account (24 bit): reference to the Accounts tree
• balance (32 bit)
• balance_operator (32 bit)
• nonce (16 bit)

Maybe it's better to merge Leaf_IDs and Values into one tree.

Operations

Onchain

tbd

In-Circuit

tbd

[barryWhiteHat]

@gluk64 can we close this? To focus on on chain data availability?