Additionally the agreed upon chaincode definition specifies the endorsement policy which defines the set of organizations that must endorse a transaction before it can be validated. This way OrgA cann

#fabric

�

#fabric

Hyperledger Fabric Contributor Meeting When: Every other Wednesday 9am US Eastern, 13:00 UTC Where: https
://zoom.us/j/51849
47650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Agendas and Recordings: https://

And here's my standard suggestion: You will get this if the gossip layer can't find any other peers in the network that have access to this collection. Check the peer logs for the gossip "Membership v

#fabric-peer

Thank you to those that responded or discussed on the contributor call last week. We have incorporated feedback and produced an anonymous survey that can be completed by any community member through O

You can use chaincode API GetHistoryForKey() to retrieve all historical transactions associated with a key. Therefore if you make your key the number plate, or number plate and user id concatenated as

400MB is fairly typical after peer has completed processing a load. Does the peer continue to grow unbounded beyond 400MB? That would indeed be concerning but I have not seen that in the past. Dave En

#fabric

Hyperledger Fabric Contributor Meeting Where: https
://zoom.us/j/51849
47650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetin

The instructions for setting up dev environment and building Fabric binaries can be found here: https://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html And if you do have enhancements

#fabric-peer

I'll add node configuration to the list. No need to vote now by mail... once we settle on a list I'll put out a survey so that we can gather community rankings, probably next week.

The SmartBFT fork is indeed a great starting point but on an out-of-date version of Fabric. Fabric maintainers provided feedback in the SmartBFT RFC https://github.com/hyperledger/fabric-rfcs/pull/33

There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year. There is also work ongoin

There are two patterns to consider here. As David said you can have your clients target specific peers. But many people utilize Service Discovery, where the client application working together with th

#fabric

Chaincode lifecycle commands must be executed from an org's admin user against the org's own peer. If the org doesn't have a peer, then they can't approve the chaincode for their org. Dave Enyeart "Da

The answer needs to be corrected. After becoming a member of the channel, Org3 client can indeed query chaincode on Org1 peer. And Org3 client can invoke chaincode and submit transactions, but they wi

The Fabric contributor meeting today is CANCELLED. The main presenter for the GitHub Actions CI discussion needs to re-schedule.

Hyperledger Fabric fix releases v2.2.4, v2.3.3, and Fabric CA v1.5.2 are now available. See details of the fixes in the release notes: https://github.com/hyperledger/fabric/releases/tag/v2.2.4 https:/

Answers inline below. Also please take a look at the Key Concepts documentation that includes many of these answers - https://hyperledger-fabric.readthedocs.io/en/latest/key_concepts.html 1. Every Ord

You could do a post-check in the client application side, before submitting the transaction for ordering. For example open up the proposal response returned from the chaincode invocation and inspect t

To resolve this, you can first query the chaincode to find the keys that need to be updated, and then pass those keys to a 2nd chaincode invocation that does the updates. Just be aware that in the int