|
Java chaincode 1.4.4 failed to submit task for processing
#fabric-questions
#fabric-chaincode
#fabric
Mattia Bolzonella
After upgrading to 1.4.4 i receive the following error in my chaincode logs: `
transaction returned with failure: Failed to submit task for processing` I'm sending transactions in a multithread envirorment, it's not supported anymore?I've tested both with Fabric 1.4.3 and 1.4.4 but the result is the same.
|
|||
|
|
|||
|
回复: [Hyperledger Fabric] Hyperledger Fabric Vs Composer ACLs
david liu <david-khala@...>
1. It might leak sensitive information of the user inside the certificate
For concern of sensitive information in certificate, you could consider use idemix as a ZKP
2. It is hard to handle the provenance of the attributes, as administrator could add any attributes as he want to an identity
That is why he is admin of his organization.
3. Each time Updating the attributes need to update the Certificate too, so there might be many versions of certificate if we manage to keep it as archive
Instead of rotate the certificate, you could consider upgrade the chaincode who identifies certificate and behaves.
发件人: fabric@... <fabric@...> 代表 Kimheng SOK <sok.kimheng@...>
发送时间: 2019年11月18日 18:13 收件人: Brett T Logan <Brett.T.Logan@...> 抄送: fabric@... <fabric@...> 主题: Re: [Hyperledger Fabric] Hyperledger Fabric Vs Composer ACLs Dear Brett Logan,
Thank for your answer, related to fine-grained access control by adding attributes to identity of the user
I found that:
1. It might leak sensitive information of the user inside the certificate
2. It is hard to handle the provenance of the attributes, as administrator could add any attributes as he want to an identity
3. Each time Updating the attributes need to update the Certificate too, so there might be many versions of certificate if we manage to keep it as archive
What do you think?
Bests,
On Mon, Nov 18, 2019 at 4:53 PM Brett T Logan <Brett.T.Logan@...> wrote:
|
|||
|
|
|||
|
How to update anchor peer after adding a new org to a channel?
Yueming Xu
I followed the tutorial “Adding an Org to a channel”. The new org works, but it does not seem to have an anchor peer defined. How should I update it to include definition of an anchor peer for the new org? Thanks.
|
|||
|
|
|||
|
Re: Extremely strange behavior with Fabric - modifying ledger out of band
David Enyeart
Remember that blockchains are decentralized ledgers. What you've done here is essentially tampered/corrupted your own local peer's state database so that it is not in sync with the blockchain blocks. This would be similar to tampering/corrupting a bitcoin node's chainstate database of unspent transactions. You won't be able to convince other nodes in the network that your data is correct. In fact they will detect the bad data upon the next endorsement request, and choose never to do business with you again, which was why you'd want to join a Fabric network consortium in the first place. see this video: https://youtu.be/KOS5CeP-mNY
the resolution is very poor but it contains the steps to repro the issue.
From: David Enyeart <enyeart@...>
Sent: Saturday, November 16, 2019 6:52 AM To: Siddharth Jain <siddjain@...> Cc: fabric@... <fabric@...> Subject: Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect you'll discovery something else going on. Use a logging string when starting peer such as: FABRIC_LOGGING_SPEC=info:kvledger,statecouchdb,couchdb=debug Dave Enyeart  "Siddharth Jain" ---11/15/2019 08:35:29 PM---Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CoFrom: "Siddharth Jain" <siddjain@...> To: "fabric@..." <fabric@...> Date: 11/15/2019 08:35 PM Subject: [EXTERNAL] [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band Sent by: fabric@... Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils. Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up! Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre. Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true. Can anyone explain this? e.g., we start with this:  we click on this record which gives  we change createdBy to david and click on save changes button  when we stop and re-start the network the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!
|
|||
|
|
|||
|
Re: Hyperledger Fabric Vs Composer ACLs
Kimheng SOK
Dear Brett Logan, Thank for your answer, related to fine-grained access control by adding attributes to identity of the user I found that: 1. It might leak sensitive information of the user inside the certificate 2. It is hard to handle the provenance of the attributes, as administrator could add any attributes as he want to an identity 3. Each time Updating the attributes need to update the Certificate too, so there might be many versions of certificate if we manage to keep it as archive What do you think? Bests,
On Mon, Nov 18, 2019 at 4:53 PM Brett T Logan <Brett.T.Logan@...> wrote:
|
|||
|
|
|||
|
Re: Wrong world state
#fabric
#fabric-questions
Joao Antunes
Hi Tong, I'll give an update when I reach a conclusion.
|
|||
|
|
|||
|
Re: Extremely strange behavior with Fabric - modifying ledger out of band
Joao Antunes
Hi, Are you storing the database locally (through a volume)? If yes, then the container is reloading CouchDB dataset And if you reset the peer (there is a new command in 1.4.3 for this), what is the value that it returns?
|
|||
|
|
|||
|
Re: Hyperledger Fabric Vs Composer ACLs
Brett T Logan <brett.t.logan@...>
There is a finite set of resources you can place an ACL on using the following documentation:
To create more fine-grained control you can do Attribute-based Access Control by specify attributes in the x590 identity which can then be used in chaincode to determine if a user should have access to a specific operation at invocation. You can find that doc here:
----- Original message -----
|
|||
|
|
|||
|
Re: Fabric SDK resource usage spike issue
Michael Wang
If you have more info, eg. version, it would be easier to get more useful info from community.
On Mon, Nov 18, 2019 at 2:46 PM Adhav Pavan <adhavpavan@...> wrote:
--
This is my life,but world of us~~
|
|||
|
|
|||
|
Hyperledger Fabric Vs Composer ACLs
Kimheng SOK
Dear all, In Hyperledger Composer Access Control List is define in a file.acl, Where is the equivalent access control list in Hyperledger Fabric to the one in Composer? Bests,
|
|||
|
|
|||
|
Fabric SDK resource usage spike issue
Adhav Pavan
Hello Team, We have containerized an express app using fabric node SDK to interact with the blockchain network. We have deployed this alongside the fabric network on a single VM. While testing with a certain load, we are observing that express app (fabric SDK) is consuming a lot of CPU and memory resources compared to other fabric components. What I have observed is that, generating client object and channel object inside invoke-chaincode.js taking 50ms to 200ms collectively(fluctuating). Could be this reason we have a spike in CPU and memory usage? Machine Specification: 4 core, 8GB RAM, 256GB SSD Network Spec: Two ORG having two peers each, Two CA, one couch DB for each peer, solo orderer. Thank you. Cell Phone:+91-8390114357 E-Mail: adhavpavan@...
|
|||
|
|
|||
|
Re: Extremely strange behavior with Fabric - modifying ledger out of band
Siddharth Jain
see this video: https://youtu.be/KOS5CeP-mNY
the resolution is very poor but it contains the steps to repro the issue.
From: David Enyeart <enyeart@...>
Sent: Saturday, November 16, 2019 6:52 AM To: Siddharth Jain <siddjain@...> Cc: fabric@... <fabric@...> Subject: Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect
you'll discovery something else going on. Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils. Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up! Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre. Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true. Can anyone explain this? e.g., we start with this:  we click on this record which gives  we change createdBy to david and click on save changes button  when we stop and re-start the network the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!
|
|||
|
|
|||
|
Re: Extremely strange behavior with Fabric - modifying ledger out of band
David Enyeart
Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect you'll discovery something else going on. Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils. Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up! Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre. Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true. Can anyone explain this? e.g., we start with this:  we click on this record which gives  we change createdBy to david and click on save changes button  when we stop and re-start the network the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!
|
|||
|
|
|||
|
Extremely strange behavior with Fabric - modifying ledger out of band
Siddharth Jain
Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from
the CouchDB web based UI (Fauxton) which can be accessed at
http://localhost:17055/_utils.
Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up!
Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation
of a Fabric transaction? This is truly bizarre.
Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying
records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData
folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true.
Can anyone explain this?
e.g., we start with this:
we click on this record which gives
we change createdBy to david and click on save changes button
when we stop and re-start the network
the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!
|
|||
|
|
|||
|
Re: Python 3 support for
#fabric-sdk-node
Gari Singh <garis@...>
It was not really a Node SDK limitation but rather a node-gyp issue. We require node-gyp as we use native modules. The latest versions of npm ship with versions of node-gyp which support Python 3.5, 3.6 and 3.7.
toggle quoted messageShow quoted text
Can you file a JIRA requesting doc update? Or of course you can submit the change as well. / G Gari Singh garis@... 978-846-7499
On Nov 15, 2019, at 3:54 PM, manojkumar.ragupathi@... wrote:
|
|||
|
|
|||
|
Re: please create repo
On Fri, Nov 15, 2019 at 6:01 AM Christopher Ferris <chris.ferris@...> wrote:
|
|||
|
|
|||
|
Python 3 support for
#fabric-sdk-node
manojkumar.ragupathi@...
As per the Official Hyperledger Fabric Doc, "The Fabric Node.js SDK requires an iteration of Python 2.7 in order for npm install operations to complete successfully."
As per the https://pythonclock.org/ , "Python 2.7 will not be maintained past 2020. Originally, there was no official date. Recently, that date has been updated to January 1, 2020." So, Hyperledger Fabric Node SDK, has to support Python 3 soon? Better to go with latest Python version, 3.8.0 for long run.
|
|||
|
|
|||
|
ANNOUNCEMENT: Hyperledger Fabric v1.4.4 is now available!
David Enyeart
The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v1.4.4!
|
|||
|
|
|||
|
Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY
#fabric-chaincode
Faisal
Yes we have tried packaging, signing and then installing on each peer. We also confirmed by listing the chaincodes on both the peers and the IDs matched. The IDs also matched in the previous case as we did a "peer chaincode list --installed" on each peer and compared the IDs of chaincodes.
|
|||
|
|
|||
|
Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY
#fabric-chaincode
Gari Singh <garis@...>
If you run "install" with the package option on two different machines then instantiation can fail due to the mismatch issue.
Did you try packaging first and then installing the same package on both peers prior to instantiating? ----------------------------------------- Gari Singh Distinguished Engineer, CTO - IBM Blockchain IBM Middleware 550 King St Littleton, MA 01460 Cell: 978-846-7499 garis@... ----------------------------------------- -----fabric@... wrote: ----- To: fabric@... From: "Desktop Dev" Sent by: fabric@... Date: 11/15/2019 09:48AM Subject: [EXTERNAL] Re: [Hyperledger Fabric] COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode I can see how that is a problem when we are upgrading the chaincode (Hash might have changed due to the timestamp) but we tried installing and instantiating a chaincode with a different name first on the same channel and then on a different channel and even then we got the same Policy Violation error.
|
|||
|
|
"Siddharth
Jain" ---11/15/2019 08:35:29 PM---Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses Co
"Siddharth Jain" ---11/15/2019 08:35:29 PM---Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses Co