SmartPlasma Summary
Smart Plasma is a Plasma Cash implementation with checkpoint mechanism and additional “nonce” field in the structure of Plasma Cash transaction. The idea of working with checkpoints was taken from Plasma XT, but implemented differently. Consensus SmartPlasma consensus mechanism like Plasma Cash base on one-operator validation (Proof-of-Authority). But nothing prevents to implement consensus mechanism on the basis of set of validators (Proof-of-Stake). Deposits
Users can start using Smart Plasma chain by placing assets on Mediator smart contract. Before transfer of tokens to the Mediator, user must call ‘IncreaseApproval’ function or approve his/her token in contract to ensure security. Adding of ETH in Smart Plasma is currently not implemented owing to redundancy. But it's easy to implement in the future.
Blocks Block structure in Smart Plasma hasn’t changed remains as block structure in Plasma Cash. Blocks are based on sparse Merkle trees. Transactions Smart Plasma еransactions have undergone some changes compared to Plasma Cash. In the structure of transaction, we’ve included an additional field - nonce. Nonce is a counter for each of the unique deposits. It indicates how many times a deposit was spent (changed the owner).
When a user makes a deposit in Smart Plasma and in Root Chain fields accordance (deposit -> current block number in Child Chain).
In the next steps:
- User must create a "zero transaction" with nonce = 0, where new owner is himself.
- Sign this transaction and transfer it to the operator.
Operator with deposit ID determines block number in the Child chain, when deposit was made. For example: We point this block as S and checks all Child Chain blocks from block S to the current Child Chain block, let's call it L. If at least one transaction was found in blocks S ... L, thenoperator believes that they want to deceive and reject such a transaction.
Rest of transactions with nonce> 0, operator checks by another method.
The operator looks at the child chain number of block where deposit was spent last time.
This block finds transaction you are looking for. If nonce current transactions are not equal to nonce + 1 of previous transaction, then operator believes that current transaction is not valid and doesn’t accept it.
Also, operator checks other fields of current transaction, but these checks don’t differ from checks in Plasma Cash.
In block # 1 users A and E create a "zero transaction", where for coin 2 new and old owner is E and for coin 4 new and old owner is A.
When block # 5 is published, owner of coin 2 will be G, and coin 4 will be C.
How can users prove ownership of a coin? User must pass the proof for all Child chain blocks where coin was spent.
Amount of proofs for units where the coin was spent should be similar with the current nonce.
Unlike Plasma cash, there is an additional way of checking - checkpoints.
Also, unlike Plasma cash user can be owner of the same deposit several times at different times. Smart Plasma protocol supports this scenario and it is not considered a double waste. This is convenient, for example, in a poker game, if you use Smart Plasma for the game, where chips can return to their original owners several times.
Checkpoints Smart Plasma use own checkpoint mechanism. Checkpoints needed to reduce amount proof of ownership for deposit.
Checkpoint block it’s sparse Merkle tree, similar to a tree for transactions in Smart Plasma. Where for each deposit has own place. Value (hash) of the sheet is a 32-byte Keccak256 hash, Hash is inherently unsigned integer of 256 bits.
So, sheet absolutely transparently stores nonce for deposit, since nonce has an unsigned integer of 256 bits type.
How it works: User transmits to operator of Smart Plasma ID of deposit, current nonce for deposit and number of block, where this transaction is present. Operator checks that transaction in the block with number and if everything is ok - includes information about deposit in the next checkpoint. With some periodicity, operator published hash of the current block in Root Chain.
Checkpoints have nothing to do with each other. These are absolutely separate entities. Users don’t need to enter information about their deposits in each checkpoint which operator publishes.
User can use checkpoint to prove possession of deposit after two weeks operator will post checkpoint hash.
Within 2 weeks any checkpoint can be challenged by any user, if his/her proves that nonce for a particular deposit in the checkpoint is not valid.
Not all checkpoints are rejected, but only a specific deposit in it. You can’t refer to this checkpoint for proof of ownership of this particular deposit.
Obligation to publish evidence for the checkpoint is responsibility of operator.
If user wants to prove that he/she is owner of the deposit, then he must provide:
- Proof of deposit inclusion in a certain checkpoint and nonce, which is fixed in this checkpoint.
- Prove for all units, where the deposit was spent, starting with where the nonce is equal to the nonce that is in the checkpoint.
- Prove for all blocks where this deposit is not included, starting from the block where nonce is equal to nonce is in checkpoint.
How does user know from which block he needs to store prove?
He has only prove for blocks, but he doesn’t know about fields of transactions.
User knows that in published checkpoint, since creation of which 2 weeks have passed (let's call it, CH), nonce for his deposit is 100 (let's call it CH.nonce). Checkpoint CH for its deposit is valid, i.e. after two weeks when checkpoint was created and there no open disputes over it.
User has the last transaction whose fields are known to him (let's call it TX). Nonce in this transaction is 200 (we'll give it TX.nonce). It is necessary to take away CH.nonce from TX.nonce - it turns out 100 + 1 transaction.
Therefore, we need to store the proof only: ● For the last 100 blocks where deposit was spent (B1 ... B100); ● For a block where nonce is equal to nonce in checkpoint; ● For all blocks in the gap between block B1 and last block in the child chain, where deposit is not spent;
Operator doesn’t have to keep information about checkpoints forever. To verify validity of transactions, it doesn’t use checkpoints. Sometimes after checkpoint was created, operator must give for users proof of inclusion (or non-inclusion) nonce for their deposits in the checkpoint.
As a result, you can greatly reduce the number of data stored on the user side.
Next scheme is demonstrated differences between data volume to proof deposit owner.
Note: However, it should be noted for the withdrawal of the deposit from Smart Plasma, you need to provide the last two transactions for the deposit.
Withdrawals Process of withdrawing funds from Smart Plasma occurs in 2 stages and a little differs from output in Plasma Cash.
Starting an Exit When a user wants to withdraw deposit, he/she needs to provide last two transactions for the deposit. For example, if C wants to remove token # 4, it must provide a "child" (last) transaction from B to C and a "parent" transaction from A to B. User also needs to provide Merkle evidence to show that both transactions have been included in the Child chain.
Finishing an Exit After a period when exit can be challenged, user can cashed deposit through the Mediator smart contract.
Challenging an Exit We need to support three types of problems to ensure that only true owner of deposit can withdraw this deposit:
- Withdrawal of funds can be immediately blocked if someone proves that user actually spent deposit earlier, i.e. last submitted deposit transaction has a nonce less than the actual nonce for this deposit.
- The withdrawal of funds can also be immediately blocked if someone shows that there were other transactions between the parent and the child transaction, where this deposit was spent.
- Also, someone can dispute withdrawal of funds by providing history of some other transactions in the deposit. This call doesn’t immediately block withdraw. Instead, user who issues funds will be forced to respond with a transaction on deposit that exists in block that was created after transaction was provided by disputer.
User can challenge the dispute:
-
If user provide a valid transaction that is present in one of the blocks in the Child chain and nonce more than nonce in the transaction that disputes checkpoint. Therefore, any checkpoint for any deposit can be unlocked (if desired) with time, because nonce for the deposit is increased with each transaction
-
Any checkpoint can be challenged within two weeks after creation, if user proved that in the checkpoint for a certain deposit a nonce, which is more than a real recorded nonce. After two weeks, checkpoint can no longer open new disputes.
-
With help of a non-blocked in relation to this deposit checkpoint, If two weeks have passed since its inception. Also, the "historical" checkpoint should be older than checkpoint, which was disputed.
-
Future improvements At the moment,we plan to develop method which allows user to provide a valid checkpoint for unlocking dispute on withdrawal of funds. It may happen that user simply doesn’t have necessary transactions to respond to dispute, because user hoped for a checkpoint and didn’t begin to store evidence for transactions, limiting himself only to evidence for the checkpoint.