1.1.1. State Commitment

1.1.2. Entries and Exits

1. Entering the Plasma Chain
   

   To enter the plasma chain, Alice (the user) will have to deposit ETH in the plasma contract. The plasma operator, who watches contract deposits, recreates an amount equal to Alice's initial deposit and releases it to her address on the plasma chain. Alice is required to attest (certify) to receiving the funds on the child chain and can then use these funds for transactions.

2. Existing the Plasma Chain
   

   Exiting the plasma chain is more complex than entering it for several reasons. The biggest one is that, while Ethereum has information about the plasma chain's state, it cannot verify if the information is true or not. A malicious user could make an incorrect assertion ("I have 1000 ETH") and get away with providing fake proofs to back up the claim by controlling the operator nodes). If the challenge period elapses without anyone providing a fraud-proof, Alice's withdrawal request is considered valid, allowing her to retrieve deposits from the Plasma contract on Ethereum.

3. Example: Dispute Arbitration for Double Spending
   

   The following example provides more details referring to what might be happened during the challenge period to enforce the integrity of transactions in case participants act maliciously:

   An example is if a user (Alice) tries to spend the same funds twice. Perhaps she spent the UTXO in a transaction with Bob and wants to spend the same UTXO (which is now Bob's) in another transaction. To prevent the withdrawal, Bob will construct a fraud-proof by providing evidence of Alice spending the said UTXO in a previous transaction and a Merkle proof of the transaction's inclusion in a block. If Bob's challenge succeeds, Alice's withdrawal request is canceled. However, this approach relies on Bob's ability to watch the chain for withdrawal requests. If Bob is offline, then Alice can process the malicious withdrawal once the challenge period elapses.

4. Mass Exit
   

   "Mass Exit" or "*Massive Exit*a refers to a scenario where a large number of users decide to simultaneously withdraw their funds from the Plasma chain back to the Ethereum mainchain. This typically occurs in response to concerns about the integrity or trustworthiness of the Plasma chain, such as suspecting that the operator is acting maliciously or that the chain is otherwise compromised. Which is like the final safeguard for the user to protect their asset from the malicious operator, require users to post the last valid state of the plasma chain to exit their money.

1.1.3. Limitations of Plasma

1. Execution Path Validation of Smart Contract
   

   In smart contracts, it's not just the final state that matters but also how that state was achieved. Validating the execution path involves understanding the sequence of operations and interactions within the contract, as well as with other contracts. This is critical because the execution path can affect the contract’s behavior and outcomes. (on-chain data) In the context of a Plasma chain, validating these paths using only a Merkle tree root submitted to the main chain is extremely limiting. The Merkle proof can efficiently show that a particular state or transaction was included in a block, but it isn't sufficient to prove the correctness of the sequence of computations that led to that state.

2. Cannot Manage Complex States:
   

   Smart contracts can manipulate and depend on a large number of state variables. Each interaction with a smart contract might change numerous aspects of its state. On a Plasma chain, each of these state changes would need to be correctly executed off-chain, thus any error or malicious act by the chain operator could lead to incorrect state transitions that are non-trivial for users to detect or dispute effectively.

3. User Validation and Data Avalibility:
   

   For complex smart contracts, assembling merkle proofs would require access to much more data than what is typically available in a Plasma framework.

4. Exit Mechanisms (mass exit):
   

   The challenge is further compounded during exit, If users want to exit due to distrust in the Plasma chain's operation, for simple token transfers, they can simply prove their token balance. However, for smart contracts, proving the correct state upon exit could involve complex interactions and histories, making it difficult to exit cleanly and correctly without potentially bringing a large amount of data onto the main chain.

5. Potencial Vulnerability:
   

   The mainchain typically needs to wait until the challenge period elapses before fully trusting a transaction. This is to ensure that enough time is given for any participant to challenge a transaction if it is fraudulent. If Alice controls the operator and knows that Bob will send a fraud proof, she could manipulate the transaction order or timing such that Bob has insufficient time to challenge all related transactions. Alice's strategy of immediately double-spending a UTXO (Unspent Transaction Output) to another account she controls, right after transacting with Bob, is particularly nefarious. This would effectively invalidate Bob's transaction, and if done within a short timeframe, could prevent Bob from challenging the fraud before the challenge window closes. (By Quickly submitting a fraudulent transaction immediately after a legitimate one, the malicious operator can minimize the window for challenges). This strategy involves double-spending an asset in a very short time frame, potentially finalizing the fraudulent transaction before affected parties have the opportunity to respond.

1.2.1. Design Overview

1. Plasma Chains
   

   Users interact with the Plasma chain by sending transactions directly to it. These transactions are recorded in the Plasma chain's ledger.

2. Settlement Agents
   

   If all transactions in the Plasma chain are correct, then we can have a third party called "Settlement Agent" with minimal trust to periodically collect those transactions and then commit the Merkle tree root where all leaf nodes are transactions to the root chain.

   1. Local Correctness Guarantees Global Correctness:
      

      If all transactions within the Plasma chain are valid, then the global state derived from these transactions by SA must also be valid. Many participants can be added and removed without signifiicant root chain state updates and internal state updates are possible without all parties participating, they only need to participate if their balances are being adjusted or if Byzantine behavior is detected.

   2. Minimal trusted:
      

      The system assumes that while the SA plays a crucial role in committing the state to the root chain, it can be monitored and held accountable by the users. The transparency of transactions in the Plasma chain means any attempts to commit fraudulent states by the SA can be detected and challenged.

1.2.2. Enforcement Protocol Flow

1. 1. Contract Setup and Preallocate UTXOs for Settlement
   
   1. User -> Mainchain -> Settlement Agents -> Plasma Chains
      

      The user initiates a transaction on the mainchain to deposit their UTXOs into the Plasma chain. (Typically, the user will also need to speicify the required smart contracts that will run in the plasma chain). This involves sending the UTXOs to a specific smart contract on the mainchain that locks these funds and records the deposit. The SAs, who watches contract deposits, recreates an amount equal to that user's initial deposit and releases it to his/her address on the plasma chain. Ideally, this covers all values and types for all possible state transitions for the contracts.

2. 2. User Submit Transcations
   
   1. User -> Plasma Chains
      

      The user create the transactions, commit to the plasma chains and revoke old corresponding user UTXOs. They are also committing that they have seen all UTXOs in step 1 and fully validated the chainstate up to step 1.

3. 3. Settlement Agents Sign off on the State Transition
   
   1. Settlement Agents -> Mainchain
      

      Periodically, SAs will collect the finalized blocks (with their Merkle roots) in the plasma chain and commit the Merkle roots to the mainchain. The Settlement Agent signs a commitment to:

4. Total funds being exchanged by all parties (ordered by denomination)
   
5. Merkle root containing UTXO root of all committed UTXOs for settlement (irrespective of whether they have signed commitments approving the state transition)
   
6. Commitment to state transition result
   

1.3.1. State Transitions Flow (Page 22-23)

1. 1. Alice wants to spend her output in the Plasma chain to Bob in the same Plasma chain
   

   (Without the full transaction record being submitted on the blockchain). She creates a transaction which spends one of her outputs in the Plasma chain, signs it, and broadcasts the transaction.

2. 2. Processed by the Validators and SAs
   
   1. Validators (Plasma Chain)
      

      The transaction is included in a block by validator(s) of the Plasma chain.

   2. SAs
      

      After that, The header (includes a Merkle root of the transactions or state updates in that Plasma block) is included as part of a block in the parent Plasma chain or root blockchain. Which ultimately being committed and sealed in the root blockchain.

3. 3. (Optional) Alice and Bob observes the transaction and signs an acknowledgement that he has seen the transaction and block.
   

   This acknowledgement gets signed and included in another Plasma block.

1.3.2. Fauld Proofs

1. Root Chain Security:
   

   Even though the Plasma chain operator has the ability to modify or manipulate transactions and hashes within their chain, they CANNOT alter the Merkle root that has already been committed to the root chain without being detected.

2. Hash Function Property:
   

   Because cryptographic hash functions are one-way functions (meaning it’s computationally infeasible to find two different inputs that produce the same hash output, known as collision resistance), it's nearly impossible for the Plasma chain operator to alter a transaction in a way that the modified transaction, when hashed, produces the same Merkle root committed to the root chain.

3. Immutability of the Root Chain:
   

   Once the Merkle root is committed to the root chain and it has passed the challenge period without being disputed (i.e., no valid fraud proof has been submitted), it is considered finalized and secure.

1.3.3. Withdrawals

1. 1. A signed withdrawal transaction is submitted to the root blockchain or parent Plasma chain.
   

   An additional bond is placed as part of the withdrawal to penalize false withdrawal requests.

2. 2. A predefiined timeout period exists to allow for disputes.
   

   In this case, if anyone can prove an output has already been spent in the chain being withdrawn to (i.e., the root chain). then the withdrawal is cancelled and the bonded withdrawal request is lost. Anyone observing the chain can dispute this. If the fraud proof of spent outputs is provided, then the bond is lost and the withdrawal is cancelled.

3. 3. A second time delay exists to wait for timeouts of any other withdrawal requests with a LOWER block confiirmation height.
   

   This is to force ordered withdrawal in a particular Plasma chain or root chain.

4. 4. If the agreed dispute time period defined in the Plasma smart contract has elapsed and no fraud proofs are provided on the root or parent chain, then it is presumed that the withdrawal is correct.
   

   The withdrawer will be able to redeem their funds on the root/parent chain. Withdrawals are processed in the order of old to new in terms of the UTXO/account age.

1.4.1. Merkleized Transactions Details

[blknum1, txindex1, oindex1, sig1, # Input 1
 blknum2, txindex2, oindex2, sig2, # Input 2
 newowner1, denom1,                # Output 1
 newowner2, denom2,                # Output 2
 fee]

1. Two Inputs and Outputs
   

   Plasma uses a UTXO model where each transaction consumes UTXOs and creates new ones. A transaction needs at least one input (UTXO being spent) and can have one or more outputs (new UTXOs being created).

   1. Example: Alice Sending to Bob
      
      1. Input 1: Alice's UTXO (let's say 10 tokens from a specific block and transaction).
         
      2. Input 2: Could be another UTXO of Alice, or it could be zeroed out if not needed.
         
      3. Output 1: Bob's address and the amount Alice wants to send him (e.g., 7 tokens).
         
      4. Output 2: Alice's address and the remaining change (e.g., 2 tokens if a 1-token fee is paid).
         
2. Input Fields
   
   1. blknum: The block number where the input UTXO (Unspent Transaction Output) was created.
      
   2. txindex: The index of the transaction within that block.
      
   3. oindex: The output index within that transaction.
      

      When a transaction occurs on the Plasma chain (or any UTXO-based blockchain), it can create multiple outputs. Each of these outputs can later be used as an input in new transactions

   4. sig: The signature of the owner of the UTXO being spent.
      

      When a user wants to spend a UTXO, they need to prove they own it. This proof is achieved by signing the transaction with their private key. The corresponding public key (derived from the private key) is associated with the UTXO being spent. This public key can be used by anyone to verify the signature.

3. Output Fields
   
   1. newowner: The address of the new owner of the output.
      
   2. denom1: The denomination or amount being transferred to this new owner.