Table of Contents

Build a simulated plasma-like Layer 2 network on an existing Hyperledger Fabric Layer 1 setup to achieve scalable transaction processing. This simplified simulation focuses on enhancing scalability without implementing features like challenge periods or Merkle trees.

1. Channels & Peers Design

1.1. Current Layer 1 Behavior

Lower BatchTimeouts are more stable and more beneficial at lower TPS; smaller block sizes excel at higher TPS levels. For more, see Layer 1 Benchmarking Results.

1.2. Channels

1.2.1. Plasma Chain (plaschains):

Optimized for high TPS with smaller block sizes to reduce latency.

1.2.2. Main Chain (chains):

Optimized for low TPS with minimal latency using a lower BatchTimeout.

1.3. Peers

1.3.1. Plasma Chain (plaschains):

Two peers – one operational and another that also participates in the main chain channel for chaincode invocation but does not endorse transactions.

  1. 1. Mainchain Peer (Similar to the Plasma Chain)
  2. 2. Operational Peer

1.3.2. Mainchain (chains):

  1. 1. Mainchain Peer
    1. Requirements for Cross-Channel Chaincode Calls (Design Choice):
      1. Membership in Both Channels

        The peer making the InvokeChaincode call must be a member of both the source (calling) and the target channels. This ensures that the peer has the necessary permissions and access to interact with the chaincodes on both channels.

      2. Chaincode Installation
        1. Cross-Channel Peers:

          Peers that are part of multiple channels where chaincode invocations will occur across these channels must have the relevant chaincode installed for all involved channels.

        2. Channel-Specific Peers:

          Peers that only belong to a single channel need to have only the chaincode specific to that channel installed. They do not need chaincode for other channels.

      3. Necessary Certs, TLS etc,.

2. Bring Up the Mainchain & Plaschain

2.1. 1. Generating Certificates

Do not enable TLS

2.2. 2. Bring up two networks together (Scripts)

2.2.1. Main Chain (chains)

  1. MSPID: mainchainsMSP
  • orderer.main.chains
    1. Network: chains
    2. ORDERERGENERALLISTENPORT = 8001
    3. ORDEREROPERATIONSLISTENADDRESS = 8101
    4. ORDERERADMINLISTENADDRESS = 8201
  • peer.main.chains
    1. COREPEERADDRESS = 5001
    2. COREPEERCHAINCODEADDRESS = 5101
    3. COREOPERATIONSLISTENADRESS = 5201

    • 2.2.2. Plasma Chain (plaschains)

    1. MSPID: plaschainsMSP
  • orderer.slim.plaschains
    1. Network: plaschains
    2. ORDERERGENERALLISTENPORT = 7001
    3. ORDEREROPERATIONSLISTENADDRESS = 7101
    4. ORDERERADMINLISTENADDRESS = 7201
  • peer.slim.plaschains
    1. COREPEERADDRESS = 6001
    2. COREPEERCHAINCODEADDRESS = 6101
    3. COREOPERATIONSLISTENADRESS = 6201

    • 2.3. Create Genesis Block (configtx)

    https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#endorsement-policy-syntax

    plasconfig

    anchor

    2.3.1. July Issue: (TLS)

    1. Detailed Logs (Issue Log)

      [lifecycle] ApproveChaincodeDefinitionForOrg -> Successfully endorsed chaincode approval with name 'basic', package ID 'basic1.0:1e8872e25b29e24db45630799acf8b5835e722a19c9a2\ 9a5eb121da40f0cd284', on channel 'chains' with definition {sequence: 1, endorsement info: (version: '1.0', plugin: 'escc', init required: false), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f41\ 70706c69636174696f6e2f456e646f7273656d656e74'), collections: ()} [endorser] callChaincode -> finished chaincode: _lifecycle duration: 0ms channel=chains txID=a3df9a52 [comm.grpc.server] 1 -> unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peeraddress=172.25.0.1:43908 grpc.code=OK grpc.callduration=7.821944ms

      SignatureSetToValidIdentities -> invalid identity error="the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"ca.main.chains\")" identity="(mspid=mainchainsMSP subject=CN=orderer.main.chains,OU=orderer,L=San Francisco,ST=California,C\ =US issuer=CN=ca.main.chains,O=main.chains,L=San Francisco,ST=California,C=US serialnumber=316238832132640519481742821703559526943)" [peer.blocksprovider] eliverBlocks -> Got error while attempting to receive blocks: block from orderer could not be verified: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied channel=chains orderer-address=orderer.main.chains:8001 [peer.blocksprovider] func1 -> Encountered an error reading from deliver stream: rpc error: code = Canceled desc = context canceled channel=chains orderer-address=orderer.main.chains:8001

    2. Detailed Logs (Normal Log)

      [lifecycle] ApproveChaincodeDefinitionForOrg -> Successfully endorsed chaincode approval with name 'basic', package ID 'basic1.0:1e8872e25b29e24db45630799acf8b5835e722a19c9a2\ 9a5eb121da40f0cd284', on channel 'chains' with definition {sequence: 1, endorsement info: (version: '1.0', plugin: 'escc', init required: false), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f41\ 70706c69636174696f6e2f456e646f7273656d656e74'), collections: ()} [endorser] callChaincode -> finished chaincode: _lifecycle duration: 0ms channel=chains txID=fb4d4fad [comm.grpc.server] 1 -> unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peeraddress=172.25.0.1:54224 grpc.code=OK grpc.callduration=3.8430\ 54ms

      [gossip.privdata] StoreBlock -> Received block [5] from buffer channel=chains [committer.txvalidator] Validate -> [chains] Validated block [5] in 0ms [gossip.privdata] RetrievePvtdata -> Successfully fetched (or marked to reconcile later) all 1 eligible collection private write sets for block [5] (0 from local cache, 1 from\ transient store, 0 from other peers) channel=chains [kvledger] commit -> [chains] Committed block [5] with 1 transaction(s) in 3ms (statevalidation=0ms blockandpvtdatacommit=1ms statecommit=0ms) commitHash=[edb76edcb49efcb\ ce5f91e81b6c3acb49552f1ddcfce3fcd07048a52e9b44852]

      Unkown TLS Issue, Leave it later Move to Arch Linux

    3. More Flexible Design Based on Previous L1 Network

    3.1. Layer 1 Network

    3.1.1. slim/single-endorsement

    1. network name: chains

      Design Layer 1 Network orderer1.ord01.chains peer1.org01.chains

    3.2. Plasma Network

    3.2.1. slim/chains02

    1. network name: chains02

      orderer1.ord02.chains peer1.org02.chains The plasma network will have two peers:

    2. peer1.org02.chains
    3. peer1.org01.chains

    3.3. Chaincode

    Make sure the endorsement process is correct:

    1. 1. plasma chain only require peer1.org02.chains for endorsement: YES

      Not both peer1.org01.chains and peer1.org02.chains.

    2. 2. peer1.org01.chains able to call chaincode installed in the plasma chain YES

    4. Design L2 Gateway Code

    4.1. 1. Launch two channels application at the same time

    Same chaincode

    1. bench-basic-wrappers

      10808

    2. bench-l2-wrappers

      10809 Work as expected

    4.2. 2. Survey on Plasma (Implementation Details)

    Notes from plasma.io Plasma White Paper Minimum Viable Plasma

    1. Plasma Chains -> peer1.org02.chains
    2. Settlement Agents -> gateway application
      syscontract := network.GetContract("qscc") // system chaincode
syscontract.EvaluateTransaction("GetBlockByNumber", "chains02", number)

    4.2.1. Focus on the SA (gateway) code

    4.3. 3. Implement the Network based on Plasma MVP

    file:///home/awang/benchains/applications/bench-l2-wrappers/main.go file:///home/awang/benchains/chaincodes/wrappers/currency/currency.go file:///home/awang/benchains/chaincodes/wrappers/types/types.go file:///home/awang/benchains/networks/fabric/scripts/fabric.sh

    4.3.1. DONE Able to fetch the newest block number, also get write sets from each transactions

    4.3.2. DONE Gateway application should also be able to communicate with org01 chains.

    4.3.3. DONE Implement root chain's chaincode, add a merkle root field.

    4.3.4. DONE Gateway application should periodically check the newest block, and compute the merkle tree root to the Plasma Contract in the root chain

    Created: 2024-10-28 Mon 19:34

    Validate