2.1.1. contractapi

1. contractapi.ContractInterface
   

   All contracts for use in chaincode must implement the contractapi.ContractInterface.

2. contractapi.TransactionContext
   

   The default transaction context provided by contractapi (contractapi.TransactionContext) provides all the necessary functions for interacting with the world state. However, taking directly contractapi.TransactionContext does pose some problems: what if we were to write unit tests for our contract? We would have to create an instance of that type which would then require a stub instance and would end up making our tests complex. In the context of Hyperledger Fabric, a "stub" refers to an object that acts as an intermediary between chaincode and the ledger itself.

   1. Testing and Mocking
      

      By using an interface like TransactionContextInterface, you can easily create mock objects for testing without having to deal with the complexities of the actual ledger. TransactionContext objects are complex because they encapsulate information and behaviors related to the transaction and the ledger state. Manually creating these objects for different scenarios or ledgers would not only be error-prone but also require a deep understanding of the internals of TransactionContext.

   2. Decopling and Maintainability
      

      Interfaces help in decoupling the chaincode logic from the underlying ledger API. This decoupling is beneficial because it makes the chaincode more modular, easier to read, and maintain. If the implementation of TransactionContext or the underlying ledger API changes, the chaincode itself may not need any modifications as long as it adheres to the interface.

      Fabric's ledger fundamentally operates on a key-value store model, where the key is a string and the value is a byte array ([]byte). This design is intentionally agnostic about the contents of the value, giving developers the flexibility to store and interpret the data in a way that best suits their application's needs.

2.1.2. Types

2.1.3. i. Package currency

1. 1). Exchanging real-world currency to in-game balance
   
   1. USD Deposit to Blockchain:
      
      1. User Action: The user sends USD to a designated banking system.
         
      2. Bank Action: Upon receiving USD, the banking system records the transaction on the blockchain ledger.
         

         This record includes essential details like transactionID, userID, time, and USD amount.

      3. Feedback to User: The banking system then provides the transaction ID back to the user as confirmation.
         
   2. USD to In-Game Currency Exchange:
      
      1. User Action: With the transaction ID, the user initiates an exchange request to convert the deposited USD into in-game currency.
         

         The user must verify their identity by proving ownership of the userID associated with the transaction ID.

      2. Blockchain Process: Once the user's identity is verified and the transaction ID is validated, the blockchain ledger updates to reflect the exchange.
         

         The USD transaction record is marked as "used", and the user's in-game balance is increased accordingly.

   3. Scaling Approach: Plasma
      
      1. Child Chain Transactions:
         

         Initial USD deposits and transaction records by the bank are processed in a child chain, which handles high-volume transactions efficiently.

      2. Main Chain Commitments: Periodically, the child chain commits its state to the main chain.
         
      3. Exchange on Main Chain: Users perform the currency exchange on the main chain by providing their transaction ID and proving their identity.
         

         This ensures the finality and security of the currency exchange process.

   4. Safety Approach: Merkle Root for Fraud Proofs
      

      Merkle root in this context serves a crucial role in proving that a specific transaction record is included in the set of transactions committed to the mainchain from the child chain.

      1. Merkle Trees:
         

         A Merkle tree is a binary tree in which each leaf node contains a hash of a transaction record, and each non-leaf node contains a hash of the concatenation of its two child nodes. The root of this tree (the Merkle root) is a single hash that effectively represents all transactions in the tree.

         1. Verification Process:
            

            To prove that a specific transaction is included in a commitment, you don't need to present the entire set of transactions. Instead, you provide:

            1. The transaction of interest.
               
            2. A Merkle proof, which is a list of hashes from the transaction to the root.
               

               This list is much smaller than the full set of transactions and allows anyone to independently compute the Merkle root by hashing the provided information together in the correct order.

      2. Challenge Process:
         

         Let's say Alice controls majority of nodes of the child chain, and wants to fake a fake $3000 deposit to the gaming platform's banking account.

         1. 1. Transaction Commitment:
            

            The child chain, where Alice's fraudulent transaction resides, periodically commits the state to the mainchain. This state is summarized in a Merkle root, which represents all transactions (including the fraudulent one) in the child chain's current state. The child chain submits this Merkle root to the mainchain, effectively claiming that all transactions it represents are valid.

         2. 2. Bob Notices the Fraudulent Transaction:
            

            Bob, vigilant and monitoring the chain, identifies Alice's fraudulent transaction. He decides to challenge it during the challenge period.

         3. 3. Gathering Evidence:
            

            To challenge the transaction, Bob needs to construct a fraud proof. This proof consists of:

            1. 1) The fraudulent transaction's details:
               

               Including its unique identifier (e.g., transaction hash), Alice's account details, and the amount ($3000).

            2. 2) A Merkle proof:
               

               A sequence of hashes that, starting from Alice's transaction, allows anyone to reconstruct the path up to the submitted Merkle root, proving the transaction's inclusion in the child chain's committed state.

         4. 4. Submitting the Challenge:
            

            Bob submits the fraud proof to a smart contract on the mainchain designed to handle such challenges. This submission includes the fraudulent transaction details and the Merkle proof.

         5. 5. Smart Contract Verification:
            

            The smart contract then performs the following checks:

            1. 1) Verifying the transaction is part of the committed state.
               

               It verifies the Merkle proof by recalculating the Merkle root using the provided path (the series of hashes Bob submitted) and comparing it with the committed Merkle root. If they match, it proves the transaction is part of the committed state.

            2. 2) Valuates the validity of the transaction based on predefined rules
               

               (e.g., whether Alice had a legitimate claim to the $3000).

         6. 6. Outcome of the Challenge:
            

            If Bob's challenge is successful (i.e., the smart contract verifies the fraud and rules the transaction invalid), several actions occur:

            1. Alice's fraudulent transaction is marked invalid/revoked.
               
            2. The withdrawal or exchange request based on this transaction is canceled.
               
            3. Depending on the platform's governance, Alice may face additional penalties.
               

               If the challenge fails (due to insufficient proof or if the challenge period has expired), Alice's fraudulent transaction would remain unchallenged.

2.2.1. Computing Resources

1. 4 Endorsement Nodes: Each Assign 4 CPUs 4GB
   
2. 2 Orderer Nodes: Each Assign 1 CPU 2GB
   

   lower BatchTimeouts are favorable for lower TPS ranges, whereas smaller block sizes gain efficiency at higher TPS levels.

4.1.1. layer1 chain (chains) (org01)

./fabric -e

4.1.2. plasma chain (chains) (org02)

./fabric -d

4.3.1. DONE Familiar with client side code

4.3.2. DONE Benchmarking Plasma

1. main chain: 0.2 100
   
2. plasma chain: 0.5 20
   

4.4.1. 1. Meaningness to just compare layer 1 with any single layer 2 solutions.

4.4.2. 2. Plasma is not design to reduce latency, it is designed to increase throughput & reduce transaction fees.

4.4.3. 3. Not just latency & throughput, also use cases.

1. A Standard on this framework
   
2. Wrappers: Flexibility
   
3. Materialize Layer 2 Solutions