Concurrent branches are common practices to handle both latest and stable code. And I guess many are curious if the release v2.5 will become the new LTS? Thanks!

True, as long as the policy is guaranteed.

#fabric #policies

If you're looking for the endorse phase of peer, it's at "core/endorser/endorser.go#Endorser.ProcessProposal(ctx context.Context, signedProp *pb.SignedProposal) (*pb.ProposalResponse, error)". And for

#fabric-peer

One potential item is to get and set the node configuration at runtime, which helps a lot in monitoring and debugging. And about the priority, I would like to vote BFT and ledger pruning as top two. T

Hi zhuxy Please see my comments inline. Thanks! Different sections are convenient to have corresponding policy controls on orderer orgs and app orgs. For example, you can set one default policy for or

#fabric-orderer #fabric

This one focuses on Go chaincode: https://github.com/sivachokkapu/revive-cc.

#fabric-chaincode

If you are using 2.3+, you can try the new osnadmin tool: https://hlf.readthedocs.io/en/latest/create_channel/create_channel_participation.html. The legacy way using peer channel cmd is at https://hlf

Yes, any identity that is signed by the org root cert. a.k.a., can be of client, peer, admin, orderer role, or no role.

#fabric #policies

I think senthil made a good point here. Setting the default policies to a more restricted value (e..g, "memberOnlyRead/Write=true") will help reduce the anxiety. This reminds me of the well-known mong

Hi PechimuthuIn channel config, there're BatchSize/* items to control the message numbers in a block (with BatchTimeout to control the interval between blocks).

Thanks, Troy! IMHO, this is a big advantage compared with the latest Node SDK, which deprecated the lifecycle APIs.

Great work, Troy and the team! And is there any plan to bring back the chaincode lifecycle APIs into the Go SDK? I feel it will be very convenient to operate the chaincode with SDK .

Yes, that's the chunk file, which combines numbers of block data together.

As long as the OSNs can continue to vote for the new update change, it can be fixed. But if your change make the channel service unavailable, there will be no easy way to fix. And you actually touched

Migrating to go mod is correct and aligns with Golang well, at least in v2.0 release. Besides, fabric-ca has no v2.0 branch yet (fabric v2.1 is out), we should consider to move it forward soon.

Correct, i made that change, because the genesis means exactly the first block (also a config block) in the network. And it is highly recommended to use the latest config block for the bootstrap.

Fabric supports ECDSA for signature currently. There're several non-official work to let it support other crypto standards. For chaincode/client encryption, you can choose whatever type.

#hyperledger-fabric #fabric-ca

Adhav The number of assets in a single transaction depends on several factors, e.g., the key-value size. Putting many large data in one transaction may consume heavy CPU and memory at the peer, and ha

You only needs to change the orderer section in the channel configuration. That will require the majority of the orderer orgs's admins to sign by default. You may refer to the tutorial at https://hlf.

There's a known goroutine leakage in 1.4.4. You may need to apply this patchset. https://github.com/hyperledger/fabric/commit/3bae50c872e9f6a4539cf5524039511fb68b289a. Besides, would suggest use the l