Date   
#minifab #miniFabric #hyperledger-fabric #network #Centos #minifabric #hyperledger-fabric #network #centos #minifab

zilich@...
 

If you try to install miniFabric to centos,
you will see that cant work under published condition, i.e. Docker version  (18.03 or newer)...

 

 

Re: The return value in Fabric gateway java SDK submitTransaction method

Mark.S.Lewis@...
 

If the transaction has been committed (i.e. the submit() call returns successfully) then it has satisfied the endorsement policy. If the endorsement policy wasn't satisfied then the transaction would be unsuccessful.

Regardless, if all you want to do is inspect a previously committed transaction then you do have several options using the fabric-gateway-java API, two of which I think you already understand:
  1. Look through block events received from peers for the required transaction event. This can be done realtime (in which case you would want to attach your listener before submitting the transaction), or you can replay previous blocks. Your listener will receive one block event for each block, and these will be received in block order.
  2. Use a commit listener to listen in realtime only for a specific transaction event from all specified peers. You will receive at most one transaction event from each peer.
  3. Use Network.evaluateTransaction() to retrieve a specific transaction directly from the Query system chaincode (qscc) GetTransactionByID transaction function. Just be aware that the response payload will be a serialized protobuf that you will need to deserialize. Compiled protobufs are in the org.hyperledger.fabric.protos package within the fabric-sdk-java JAR. The source repository for those protobuf definitions is https://github.com/hyperledger/fabric-protos.

Be aware that, while you can access the parent transaction for a given contract event, a contract event listener will only be invoked if:
  1. The transaction function emitted a chaincode event.
  2. The transaction committed successfully.

There is no guarantee on whether event delivery to different listeners is serial or parallel. The only guarantee is that each block (or contract) listener will receive events in block order and without duplication. From memory, the current implementation does deliver events to all realtime listeners sequentially, but the order of invocation of those realtime listeners is non-deterministic. Since this in an implementation detail, you shouldn't rely on this behaviour remaining the same across releases.

looking for sponsor for hyperledger labs blockchain-carbon-accounting project

Si Chen
 

Hello everybody,

I'm from the Climate Accounting and Neutrality Working Group, and we'd like to ask for a sponsor to open a repository in hyperledger-lab.

This repository will be used for developing code for CO2 emissions accounting, to support emissions trading and other applications related to climate change.

I've written a proposal for this project.  If you'd like to learn more, please take a look at our ideas for the architecture and the initial project.

If any of the maintainers of the Fabric project could sponsor us, please let me know.  

Also we're looking for experienced advisors to our project, so if you could help us, please let me know too!

Thank you.

-----
Si Chen
Open Source Strategies, Inc.

Join our Hyperledger Open Source Carbon Neutral Certification Working Group

Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 08/14/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 14 August 2020
4:00pm to 5:00pm
(GMT+01:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Re: The return value in Fabric gateway java SDK submitTransaction method

grapebaba
 

No, I need a commited transaction. The blocklistener can be used. I am only curious if the blocklistener and contractlistener execute parallel or serial as I use both.

<Mark.S.Lewis@...>于2020年8月14日 周五下午6:38写道:

If you have some off-chain mechanism to check endorsement is satisfied before submitting the transaction to the orderer then it sounds like the Gateway API is not going to work for you. By the time the submit() returns, the transaction has already been submitted to the orderer. Similarly, block events are only produced after the transaction is committed in a block on the ledger. So in both cases it is too late for you to avoid submitting the transaction if your off-chain endorsement check is not satisfied.







Re: Removed Databases, can't reset #fabric #couchdb

Brett T Logan
 

Did you remove the volumes listed in "docker volume ls", this is where the couch data is stored

mario.schwaiger@... --- [EXTERNAL] Re: [Hyperledger Fabric] Removed Databases, can't reset #fabric #couchdb ---

From:mario.schwaiger@...
To:fabric@...
Date:Fri, Aug 14, 2020 09:50
Subject:[EXTERNAL] Re: [Hyperledger Fabric] Removed Databases, can't reset #fabric #couchdb


Even more confusing, by default in the core.yaml I had:
    stateDatabase: goleveldb

How had there ever been data in the couchdb - and why is there none now after a complete reset? And where is the LevelDB running? Can it be accessed somehow?
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8856) | Reply To Sender | Reply To Group | Mute This Topic | New Topic

Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 08/14/2020 4:00pm-5:00pm #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 14 August 2020, 4:00pm to 5:00pm, (GMT+01:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Re: Removed Databases, can't reset #fabric #couchdb

mario.schwaiger@...
 

Even more confusing, by default in the core.yaml I had:
    stateDatabase: goleveldb

How had there ever been data in the couchdb - and why is there none now after a complete reset? And where is the LevelDB running? Can it be accessed somehow?

Removed Databases, can't reset #fabric #couchdb

mario.schwaiger@...
 

Hi!
I was testing out the database capabilities and effects on changes in the fabric-samples. (fabcar)
In a trial run I've removed all databases and all data from both couchdb-Docker instances. Everything was still fine - yet I could still query my data. (which brings me to my first question, what's the purpose of both couchdb-Dockers if even, if everything is removed everything seems to still work fine)

Strangely, by itself it wouldn't reset the data, also no warning in logspout. Also not after a restart of the containers.

So I've removed all Docker-Images of all Hyperleder and couchdb I had (docker rmi ...) and rebuild it from scratch. Strangely both couchdb databases are still empty. Deleted the firefox-cache, same

I wonder if the data is stored somewhere else by default? According to the core.yaml and the docker-compose-couch.yaml it shouldn't be the case. Is there something else to reset or remove?

Thank you
Mario

Re: The return value in Fabric gateway java SDK submitTransaction method

Mark.S.Lewis@...
 

To have a successful submit() return both the transaction responses and would mean a breaking API change, which would make everyone currently using the API very unhappy. I guess there could be an alternative submit-type function that does return proposal responses but, as mentioned in a previous response, I don't see how this is going to help achieve off-chain enforcement of endorsement when using the Gateway API.

The lower level fabric-sdk-java package should allow you to do what you want. It is not a very friendly API to use for application development and so is not recommended, but this may be your best option.

Re: The return value in Fabric gateway java SDK submitTransaction method

Mark.S.Lewis@...
 

If you have some off-chain mechanism to check endorsement is satisfied before submitting the transaction to the orderer then it sounds like the Gateway API is not going to work for you. By the time the submit() returns, the transaction has already been submitted to the orderer. Similarly, block events are only produced after the transaction is committed in a block on the ledger. So in both cases it is too late for you to avoid submitting the transaction if your off-chain endorsement check is not satisfied.

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 08/14/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 14 August 2020
6:00am to 7:00am
(GMT+01:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Re: The return value in Fabric gateway java SDK submitTransaction method

grapebaba
 

Hi Lewis,
Currently I use both blocklistener and contractlistener, I put all transactions in a global map and I want to get corresponding event in contractlistener logic. Does blocklisterner will be triggered and executed earlier than contractlistener? If not, maybe I need to wait the transaction event in the global map in contractlistener code.

On Fri, Aug 7, 2020 at 9:33 PM grapebaba via lists.hyperledger.org <281165273grape=gmail.com@...> wrote:
I feel the blocklistener is not good for this case, i just need a transaction event listener. I checked the code, it seems I need use the createTransaction method to get a transaction instance, and set a customize commithandler with a commiterlistener. But could you consider the case which I describe, actually when the transaction commit failed, it return all the proposalResponses in exception, so why we not use same behavior for both success and failed case?

On Fri, Aug 7, 2020 at 6:36 PM grapebaba via lists.hyperledger.org <281165273grape=gmail.com@...> wrote:
The case is an off chain or cross chain verify for the transaction, the verifier off chain or on another chain has the knowledge which can verify the endorsement policy if is satisfied. 
 I will check the blocklistener later, however i feel it's more straightforward if the submittransaction method can return the proposalResponse.

<Mark.S.Lewis@...>于2020年8月7日 周五下午6:05写道:
I would really like to understand the motivation for this requirement better. What additional information does you application code need to see and (most importantly) why?

Once the transaction is committed by peers, all of the information associated with that transaction (including endorsement) is written to the ledger. The ledger is the proof of the transaction. You can view all of the transaction information within the block events emitted by peers by attaching a block listener and iterating over the contained transations:

If the endorsements for the proposal do not meet the endorsement requirements, the transaction will not be committed.

Re: Re. CouchDB - Performance Optimization Best Practices for indexing and searching in the context of HLF solution - V2.2.0 & CouchDB 3.1.0

David Enyeart
 

There is indeed an automated performance test that runs nightly that would catch any performance regressions.
We saw a small perf improvement (~10%) when going from Fabric v1.4 to Fabric v2.0, due to the new CouchDB cache in the peer that services key-based reads (not JSON queries).
We saw no change when going from CouchDB 2.3.1 to CouchDB 3.1.0.

Note however that while these performance tests utilize CouchDB JSON data, they do not perform rich JSON queries, for a few reasons:
- The JSON query performance is extremely sensitive to the data and query, and therefore users will need to test with their own data and queries.
- The JSON query performance drivers are entirely within CouchDB, not Fabric. This is something the CouchDB community already regression tests.
- JSON query is not meant to be used in update transactions. It is meant to be used for read-only queries against the ledger. If you have a high load of queries that you expect will impact the transactional workload, you should consider off-loading those queries to another peer or downstream data store.

I believe some people are working to socialize the performance results each release, they may be able to speak to the current progress...


Dave Enyeart

"Bharg Pvr" ---08/13/2020 12:56:49 PM---Dear Dave and community, My apologies for coming out with this question - this bad:

From: "Bharg Pvr" <pvrbharg@...>
To: fabric@...
Date: 08/13/2020 12:56 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Re. CouchDB - Performance Optimization Best Practices for indexing and searching in the context of HLF solution - V2.2.0 & CouchDB 3.1.0
Sent by: fabric@...





Dear Dave and community,

My apologies for coming out with this question - this bad:

>>> You are asking an impossible question, and to the wrong community :-)

First the question is always in the context of Hyperledger Fabric and not a CouchDB performance or scaling question.
I understand - this is not what we do in this forum and in our community.
I already have an answer for your concern.

A correctly designed solution that scales and performs using CouchDB can be learnt from CouchDB community or books - such as:
https://learning.oreilly.com/library/view/couchdb-the-definitive/9780596158156/ch23.html
https://docs.couchdb.org/en/3.1.0/maintenance/performance.html?highlight=performance#


Regarding your comments:

>>> It is impossible to answer because there are too many variables. Only you can answer this question based on trials using your specific data schema, data volume, hardware, indexes, queries, and query load.
>>> And it is a CouchDB performance question, not a Fabric performance question. Test against CouchDB without Fabric

I could agree and understand the above response.
So the question becomes - is this more CouchDB capability to support KV versioned object store for rich queries role/scaling needs or are we dealing with a BigData and/or BigQuery kind of ask.
This is a good point and I would not know unless I further qualify the domain use case and context.

I can also accept and understand - experiment, fail fast and adjust response - perhaps Caliper may play a role and we can suggest this concept [basically we can not provide ready answers and need investigation].

If you look at my last referenced URL - Senthil's paper - that actually has a focused guidance and insights gained - when using CouchDB versus LevelDB.

This is what I was wondering in the context of my question - especially moving from v2.3.1 to 3.1.0 - have we seen performance improvements [by replication or with caching or by exploiting newer capabilities], etc.

So - a better way to ask perhaps - do we have a performance regression harness - that shows some understanding of how CouchDB performs - between releases with newer features and between CouchDB and LEVELDB.

Do we have a follow-up to Senthil's paper - that features current release insights?

Thank you for your offchain DB design pointer and I am aware of it - but did not bring it in since it is a valid proposition.

Best wishes.











Re: Re. CouchDB - Performance Optimization Best Practices for indexing and searching in the context of HLF solution - V2.2.0 & CouchDB 3.1.0

Bharg Pvr
 

Dear Dave and community,

My apologies for coming out with this question - this bad:

>>>   You are asking an impossible question, and to the wrong community :-)
 
First the question is always in the context of Hyperledger Fabric and not a CouchDB performance or scaling question.
I understand - this is not what we do in this forum and in our community.
I already have an answer for your concern. 

A  correctly designed solution that scales and performs using CouchDB can be learnt from CouchDB community or books - such as:
https://learning.oreilly.com/library/view/couchdb-the-definitive/9780596158156/ch23.html 
https://docs.couchdb.org/en/3.1.0/maintenance/performance.html?highlight=performance#


Regarding your comments:

>>> It is impossible to answer because there are too many variables. Only you can answer this question based on trials using your specific data schema, data volume, hardware, indexes, queries, and query load.
>>> And it is a CouchDB performance question, not a Fabric performance question. Test against CouchDB without Fabric

I could agree and understand the above response.
So the question becomes - is this more CouchDB capability to support KV versioned object store for rich queries role/scaling needs  or are we dealing with a BigData and/or BigQuery kind of ask.
This is a good point and I would not know unless I further qualify the domain use case and context.

I can also accept and understand - experiment, fail fast and adjust response - perhaps Caliper may play a role and we can suggest this concept [basically we can not provide ready answers and need investigation].

If you look at my last referenced URL - Senthil's paper - that actually has a focused guidance and insights gained - when using CouchDB versus LevelDB.

This is what I was wondering in the context of my question - especially moving from v2.3.1 to 3.1.0 - have we seen performance improvements [by replication or with caching or by exploiting newer capabilities], etc.

So - a better way to ask perhaps - do we have a performance regression harness - that shows some understanding of how CouchDB performs - between releases with newer features and between CouchDB and LEVELDB.

Do we have a follow-up to Senthil's paper - that features current release insights?

Thank you for your offchain DB design pointer and I am aware of it - but did not bring it in since it is a valid proposition.

Best wishes.






   

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 08/14/2020 6:00am-7:00am #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 14 August 2020, 6:00am to 7:00am, (GMT+01:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Re: Fabric Samples update

Pancham Singh
 

Thanks David. The asset transfer samples are very helpful. 

I noticed that javascript chaincodes did not have unit tests and have raised a PR with chaincode unit test for asset-transfer-basic:

Pancham

On Wed, Aug 12, 2020 at 7:16 AM David Enyeart <enyeart@...> wrote:

Hi, there is not a proposal for native token support yet, but there is a design for the prereq validation/commit refactoring: https://jira.hyperledger.org/browse/FAB-12221. It has a linked google doc with detailed design (it was written before the RFC process started, and will need to be submitted as an RFC before work resumes).

The sample token chaincodes work will begin soon in the samples workgroup. I'll post back to this mailing list when there is something to review.


Dave Enyeart

Brian Behlendorf ---08/11/2020 11:27:39 AM---Perfect, thank you for the crystal clear explanation. Is there a good sink (a draft RFC somewhere,

From: Brian Behlendorf <bbehlendorf@...>
To: David Enyeart <enyeart@...>
Cc: fabric@...
Date: 08/11/2020 11:27 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric Samples update





Perfect, thank you for the crystal clear explanation. Is there a good sink (a draft RFC somewhere, a Jra ticket) for either core token support or example chaincode that we can direct interested parties to, in the hopes of getting dev resources to apply?

Brian

On 8/11/20 6:31 AM, David Enyeart wrote:
      The recent RFCs and development work have been in the areas of operations improvements required for large production deployments (config library, managing ordering service without a system channel, ledger checkpoint). The conclusion from the FabToken prototype was that the validation/commit part of Fabric needs to be re-written in a more extensible way in order to support native tokens and other new transaction types. That is still the intent although the large sizing has pushed it out in favor of some of the other immediate requirements.

      Now that the asset transfer series sample work is concluding, we are intending to add some token chaincode samples in the near future. We'll investigate the areas you mentioned, as well as a basic UTXO and ERC20 chaincode sample. Any other suggestions in this space are welcome.

      Thanks,

      Dave Enyeart

      "Brian Behlendorf" ---08/10/2020 05:41:16 PM---This is really great. Also, anyone out there looking for a pathway to becoming a contributor into F

      From:
      "Brian Behlendorf" <bbehlendorf@...>
      To:
      fabric@...
      Date:
      08/10/2020 05:41 PM
      Subject:
      [EXTERNAL] Re: [Hyperledger Fabric] Fabric Samples update
      Sent by:
      fabric@...





      This is really great. Also, anyone out there looking for a pathway to becoming a contributor into Fabric, working on examples (or perhaps creating some new ones) could be a good approach.

      One question, Dave or anyone else - I tried looking in the Fabric RFCs repo for anything related to "token", to see if there'd been any work on a successor to FabToken. We keep fielding interest from companies and journalists, particularly around CBDC usage, and there's quite a few news reports of late regarding stablecoin efforts involving Fabric. I know it's long been possible to accomplish this with chaincode; do any of these new samples represent an approach to implementing stablecoins? Or is there further work on a next gen to FabToken that hasn't yet been proposed as an RFC?

      Relatedly, have you or has anyone else heard of any moves to implement a compiler (or otherwise support) the Token Taxonomy Framework's token lifecycle descriptions in chaincode?

      Brian

      On 8/10/20 2:25 PM, David Enyeart wrote:
              The Fabric samples have recently had a big overhaul with the introduction of the asset transfer samples and tutorials series. The Samples Workgroup is finishing out some of the tutorials and client applications, but they are far enough along that it is a good time to check out the new materials and provide any feedback.

              Overview from the README:

              The asset transfer series provides a series of sample smart contracts and applications to demonstrate how to store and transfer assets using Hyperledger Fabric. Each sample and associated tutorial in the series demonstrates a different core capability in Hyperledger Fabric.
              The Basic sample provides an introduction on how to write smart contracts and how to interact with a Fabric network using the Fabric SDKs.
              The Ledger queries, Private data, and State-based endorsement samples demonstrate these additional capabilities.
              Finally, the Secured agreement sample demonstrates how to bring all the capabilities together to securely transfer an asset in a more realistic transfer scenario.

              More information in the README including links to each of the samples and tutorials:
              https://github.com/hyperledger/fabric-samples/blob/master/README.md

              We welcome your feedback here or in a Samples Workgroup meeting:

              Hyperledger Fabric Samples Workgroup

              When: Tuesdays 10am US Eastern / 14:00 UTC

              Where: https://zoom.us/my/hyperledger.community.3

              Thanks,

              Dave Enyeart

      --
      Brian Behlendorf
      Executive Director, Hyperledger

      bbehlendorf@...
      Twitter: @brianbehlendorf


--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Fabric support for ECDSA certificates with brainpool curves

Ashutosh Kumar
 

It is pretty much what Go supports


From: fabric@... <fabric@...> on behalf of Carlos Eduardo Matos Ellery <carlos.ellery@...>
Sent: Wednesday, August 12, 2020 11:05:31 AM
To: Siddharth Jain <siddjain@...>; fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] Fabric support for ECDSA certificates with brainpool curves
 
No, we are successfully using RSA for TLS certificates with Fabric 1.4.x

ECDSA is only required for sign certs. Even the CA cert that issued this sign cert can use RSA.

Carlos Eduardo Matos Ellery
Em 11/08/2020 21:10, Siddharth Jain escreveu:
Does Fabric require ECDSA for TLS certs as well?

Re: Re. CouchDB - Performance Optimization Best Practices for indexing and searching in the context of HLF solution - V2.2.0 & CouchDB 3.1.0

David Enyeart
 

You are asking an impossible question, and to the wrong community :-)

It is impossible to answer because there are too many variables. Only you can answer this question based on trials using your specific data schema, data volume, hardware, indexes, queries, and query load.

And it is a CouchDB performance question, not a Fabric performance question. Test against CouchDB without Fabric. Once you get comfortable with the CouchDB performance, then consider whether it makes sense in the context of Fabric.

If you are doing more advanced searching, reporting, analytics, etc, you probably want to use a downstream data store rather than query from Fabric peer. See this pattern:
https://github.com/hyperledger/fabric-samples/tree/master/off_chain_data


Dave Enyeart

"Bharg Pvr" ---08/12/2020 12:42:32 PM---What are the boundary conditions for CouchDB indexing and search operations using the array type for

From: "Bharg Pvr" <pvrbharg@...>
To: fabric@...
Date: 08/12/2020 12:42 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Re. CouchDB - Performance Optimization Best Practices for indexing and searching in the context of HLF solution - V2.2.0 & CouchDB 3.1.0
Sent by: fabric@...







What are the boundary conditions for CouchDB indexing and search operations using the array type for schema definition in conjunction with Hyperledger Fabric in terms of scalability? The question is in the context of v2.2.0 & CouchDB v3.1.0:
to create a flexible record schema that can support an variable number of fields so that the system can adapt to the specific metadata requirements of different users and applications. 

Here is what I came up with - as recommended practices and the last URL is valuable - however the content may be dated and I am trying to make sure I did not miss anything:

 
https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_tutorial.html
https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_as_state_database.html
https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html
https://hyperledger-fabric.readthedocs.io/en/release-1.4/readwrite.html
http://www.mscs.mu.edu/~mascots/Papers/67.pdf
 
 

Any help or pointers would be greatly appreciated with an advanced and forward thank you to community + Senthil!

Regards.




Re: MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority while posting transaction

David Enyeart
 

The important error here is:
ValidateProposalMessage -> WARN 084 [0m channel [rchannel]: MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority

It means the ca that issued the client identity that submitted the transaction is not a known ca based on the configured channel MSPs (e.g. as specified in configtx.yaml MSPDir).

You can inspect the two certificates as follows:

openssl x509 -in <client MSP dir>/signcerts/*.pem -noout -text

openssl x509 -in <channel MSP dir>/cacerts/*.pem -noout -text

Make sure the Issuer of the former is the Subject of the latter.


Dave Enyeart

"Dinesh Raj" ---08/12/2020 11:18:15 AM---Hi I am facing issues while posting transactions using fabric sdk. The fabric

From: "Dinesh Raj" <dineshrajendran1996@...>
To: hyperledger-fabric@...
Date: 08/12/2020 11:18 AM
Subject: [EXTERNAL] [Hyperledger Fabric] MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority while posting transaction
Sent by: fabric@...





Hi

I am facing issues while posting transactions using fabric sdk. The fabric sdk is returning the below error
[{"code":2,"metadata":{"_internal_repr":{}},"details":"access denied: channel [rchannel] creator org [Org1MSP]"}]
I have tried regenerating the certs from scratch and also deleted hfc-key store folder and tried. I have double checked the environment variable value of FABRIC_CA_SERVER_CA_CERTFILE and the path to the admin pvt key in networkcofig.yaml file. I am calling the CA using the name given in environment variable FABRIC_CA_SERVER_CA_NAME in the docker-compose.yaml. Till instantiate its working fine without any issues. My setup consists of 5 orderers
which is running in a host,peer,couchdb,CA,chaincode containers running in a different host and fabric sdk is running in a different host from where the API calls are happening.
you can find the peer logs below
1597220296761, [34m2020-08-12 08:18:16.761 UTC [cceventmgmt] HandleStateUpdates -> INFO 081 [0m Channel [rchannel]: Handling deploy or update of chaincode [dcode3]
1597220296792, [34m2020-08-12 08:18:16.791 UTC [kvledger] CommitWithPvtData -> INFO 082 [0m [rchannel] Committed block [1] with 1 transaction(s) in 32ms (state_validation=8ms block_and_pvtdata_commit=6ms state_commit=14ms) commitHash=[86e6b7ab1de9659948aa1eeba10d85e086b8d3fe2790704b15839b598ce01ebe]
1597220296794," [34m2020-08-12 08:18:16.794 UTC [comm.grpc.server] 1 -> INFO 083 [0m streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=
192.168.3.172:42002 error=""context finished before block retrieved: context canceled"" grpc.code=Unknown grpc.call_duration=2.05757567s"
1597220324597, [33m2020-08-12 08:18:44.597 UTC [protoutils] ValidateProposalMessage -> WARN 084 [0m channel [rchannel]: MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority
1597220324597," [34m2020-08-12 08:18:44.597 UTC [comm.grpc.server] 1 -> INFO 085 [0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=
192.168.3.172:42008 error=""access denied: channel [rchannel] creator org [Org1MSP]"" grpc.code=Unknown grpc.call_duration=482.305µs"

What am  I missing? Any kind of help is appreciated

Thanks
Dinesh