Hello , I am trying to implement multiple contracts in a single chaincode in Go lang. Ref:(https://hyperledger-fabric.readthedocs.io/en/release-2.3/smartcontract/smartcontract.html#terminology) We have a method called `InvokeChaincode(chaincodeName ZjQcmQRYFpfptBannerStart

ZjQcmQRYFpfptBannerEnd

Hello ,

I am trying to implement multiple contracts in a single chaincode in Go lang.

Ref:(https://hyperledger-fabric.readthedocs.io/en/release-2.3/smartcontract/smartcontract.html#terminology)
We have a method called `InvokeChaincode(chaincodeName string, args [][]byte, channel string)` where we will  invoke a method ,from one chaincode to another  method of another chaincode.,

Do we have any methods where a contract will call another contract in a same chaincode in Fabric Go-SDK.

Eg:

Vehicle chaincode{
       Car contract{
           create car,
           query car
        }
       boat contract{
           create boat,
           query boat
        }
       person contract{
           updatevehicles vehicles,
           queryvehicles vehicles
        }
}

Call create car(car contract) and create boat(Boat contract) in person contract 

Thanks in-advance.

Thanks,
Dinesh. A

Hey Fabric Community,

 

Thanks for everyone for their suggestions so far, but I’m still seeing issues with my read/write sets being malformed within the endorsement responses when a single peer is trying to endorse multiple non-conflicting transactions at once.

 

Here’s my situation (with updated information that I’ve figured out so far):

• 4 organizations, each with one (endorsing) peer
  
• Nodejs chaincode running in an external container (1 chaincode container per org)
  
• MAJORITY endorsement policy (so three endorsements required for each transaction)
  
• 5 Fabric client instances (each running in a Kubernetes pod) that are all executing in parallel
  
• Each pod pulls a job off a queue and attempts to execute a simple Chaincode transaction that reads/updates one object and creates another (i.e. there should be 2 reads and 2 writes in the read/write set within each endorsement response)
  
• When each transaction is executed, 3 endorsement proposals are requested and received from 3 different orgs / peers
  
• Unfortunately, some of the read/write sets within the endorsement responses from various org peers are incorrect, leading to ENDORSEMENT_POLICY_FAILURE errors when the transaction is submitted to the orderer and processed in the block by the peers.
  
• Some endorsement responses have read/write sets that only contain 1 read and no writes, some contain 3 reads and 1 write, some have other combinations, and some are just fine.
  
• None of the data touched by the chaincode transactions executed by these 5 client instances overlap – i.e. there are no MVCC_READ_CONFLICTs
  
• All endorsing peers randomly exhibit this same behaviour, so it’s not a problem with one particular org’s peer
  
• If I run only one client instance (i.e. 1 kubernetes pod) and process the transactions sequentially, waiting for the block to be delivered before running the next transaction, everything works fine.  But that obviously results in debilitatingly poor performance.
  

 

So I guess my question is: Are there any known limitations/issues in terms of a single peer responding to multiple (non-conflicting) endorsement requests concurrently?

 

Thanks so much for your help!

Curtis.

 

From: Marcos Sarres <marcos.sarres@...>
Date: Thursday, April 7, 2022 at 10:40 AM
To: 'David Faulstich Diniz Reis' <davidfdr@...>, 'Curtis Miles' <curtis@...>
Cc: 'fabric' <fabric@...>
Subject: RES: [Hyperledger Fabric] Transaction read/write sets are bleeding into each other

Good point David,

 

Please also check for MVCC (Multi Version Concurrent Control) CONFLICT errors at your client and orderer logs.

 

Regards,

 

Marcos Sarres | CEO | +55 61 98116 7866

 

 

De: fabric@... <fabric@...> Em nome de David Faulstich Diniz Reis
Enviada em: quinta-feira, 7 de abril de 2022 08:31
Para: Curtis Miles <curtis@...>
Cc: fabric <fabric@...>
Assunto: Re: [Hyperledger Fabric] Transaction read/write sets are bleeding into each other

 

Just as a complement to Marcos and Tsvetan,

 

I got similar errors due to concurrency control when doing stress tests with the same asset keys.

 

You may check why the transaction fails using QSCC chaincode:

 

1 - Evaluate Transaction Method:

 

/*
 * Evaluate a transaction and handle any errors
 */
export const evaluateTransaction = async (contract: Contract, transactionName: string, ...transactionArgs: string[]): Promise<Buffer> => {
  const transaction = contract.createTransaction(transactionName);
  const transactionId = transaction.getTransactionId();
  logger.trace({ transaction }, 'Evaluating transaction');

  try {
    const payload = await transaction.evaluate(...transactionArgs);
    logger.trace(
      {
        transactionId: transactionId,
        payload: payload.toString(),
      },
      'Evaluate transaction response received',
    );
    return payload;
  } catch (err) {
    throw handleTXError(transactionId, err);
  }
};

 

 

2 - Check status transaction:

 

/*
 * Get the validation code of the specified transaction
 */
export const getTransactionValidationCode = async (qsccContract: Contract, transactionId: string): Promise<string> => {
  const data = await evaluateTransaction(qsccContract, 'GetTransactionByID', config.channelName, transactionId);

  const processedTransaction = protos.protos.ProcessedTransaction.decode(data);
  const validationCode = protos.protos.TxValidationCode[processedTransaction.validationCode];

  logger.debug({ transactionId }, 'Validation code: %s', validationCode);
  return validationCode;
};

 

--

 

I use this as part of my retry logic implemented by Event Source and Saga patterns.

 

Best regards.

 

David

 

Em qua., 6 de abr. de 2022 às 20:29, Tsvetan Georgiev <tsvetan@...> escreveu:

Hi Curtis,

 

Marcos has a good point and you should check your client logic.

 

To better understand could you share also how many peers participate in the transaction endorsement? Are those failed/bad transactions part of the block built by the Ordering Service and marked as invalid due to concurrency control version check?

 

If your transactions don't contain the read/write sets you expect then you definitely have to re-check your chaincode and what your client is actually sending to the peers during the endorsement step.

 

Regards,

 

Tsvetan Georgiev Director, Senofi Inc. 438-494-7854 | tsvetan@... www.senofi.ca www.consortia.io

 

 

 

---- On Wed, 06 Apr 2022 18:54:10 -0400 Marcos Sarres <marcos.sarres@...> wrote ----

 

Please check your Hyperledger Fabric client.

 

The endorsement policy should be fulfilled at your API sending the message proposals the the endorsement peers further receiving and packaging the signed proposals to be transmitted to the orderer.

 

I think your API (HLF Client) is not getting the correct signed proposals from the chaincode endorsing policy orgs.

 

Regards,

 

Marcos Sarres | CEO | +55 61 98116 7866

 

 

De: fabric@... <fabric@...> Em nome de Curtis Miles
Enviada em: sexta-feira, 1 de abril de 2022 10:32
Para: fabric@...
Assunto: [Hyperledger Fabric] Transaction read/write sets are bleeding into each other

 

Hello world!

 

I’ve hit what appears to be a strange situation when testing my soon-to-be production network under a bit of (very light) load.  I have a very simple chaincode function that is doing two things within a single transaction:
1. Retrieving a document of type A by id, updating it, and storing it back (using its same id)

2. Storing a new object of type B by id (the object is passed in a parameter to the chaincode function)

 

When I try to execute a number of these transactions in parallel (e.g. 5) such that they are included in the same block, I’m *randomly* getting a ENDORSEMENT_POLICY_FAILURE error.  This didn’t make any sense to me because each transaction is dealing with distinct objects of type A and B and nothing else is going on in the network at the time.  So I look into the blocks that had the transactions that were failing and noticed something very strange.  It looks like the items in the read/write sets in the transactions are bleeding into each other.  For example, a single block includes the following read/write sets within three different transactions:

 

Transaction 1 (which looks correct to me):

{

    "namespace": "projectXYZ",

    "rwset": {

"reads": [

        {

             "key": "A1",

             "version": {

                 "block_num": "79389",

                 "tx_num": "0"

              }

               },

             {

                     "key": "B1",

             "version": null

             }

       ],

       "range_queries_info": [],

       "writes": [

             {

        "key": "A1",

        "is_delete": false,

        "value": "{\"id\":\"1\”, \"type\":\"A\”}"}"

             },

             {

        "key": "B1",

        "is_delete": false,

        "value": "{\"id\":\"1\”, \"type\":\"B\”}"}"

             }

       ],

       "metadata_writes": []

    },

    "collection_hashed_rwset": []

}

 

Transaction 2 (has an extra read/write of A3, which I would have expected to be in a different transaction):

{

    "namespace": "projectXYZ",

    "rwset": {

"reads": [

        {

             "key": "A2",

             "version": {

                 "block_num": "79389",

                 "tx_num": "0"

              }

               },

               {

                     "key": "A3",

             "version": {

                 "block_num": "79389",

                 "tx_num": "0"

               }

             },

             {

                     "key": "B2",

             "version": null

             }

       ],

       "range_queries_info": [],

       "writes": [

             {

        "key": "A2",

        "is_delete": false,

        "value": "{\"id\":\"2\”, \"type\":\"A\”}"}"

             },

             {

        "key": "A3",

        "is_delete": false,

               "value": "{\"id\":\"3\”, \"type\":\"A\”}"}"

             },

             {

        "key": "B2",

        "is_delete": false,

        "value": "{\"id\":\"2\”, \"type\":\"B\”}"}"

             }

       ],

       "metadata_writes": []

    },

    "collection_hashed_rwset": []

}

 

Transaction 3 (has only a read of A3, with no write of A3 or B3):

{

    "namespace": "projectXYZ",

    "rwset": {

"reads": [

        {

             "key": "A3",

             "version": {

                 "block_num": "79389",

                 "tx_num": "0"

              }

               }

       ],

       "range_queries_info": [],

       "writes": [],

       "metadata_writes": []

    },

    "collection_hashed_rwset": []

}

 

If I only submit one transaction per block, everything is fine (although for performance reasons, that isn’t going to work for me). 

 

Does anyone have any ideas why this might be happening?  Shouldn’t it be fundamentally impossible for these transactions to bleed into each other?  Can you think of anything I might be doing wrong that is causing this?

 

Thanks for any help you can offer!

Curtis.

 

 

 

 

 

 

--

David Reis

https://openprofile.dev/profile/davidfdr

@davidfdr (Github)

@davidfaulstich (Instagram)

https://www.linkedin.com/in/david-faulstich-reis/

Certified Hyperledger Fabric Administrator

Certified Hyperledger Fabric Developer

Professional Scrum Master