Deserialising channel configuration

[Breina]

Currently it's possible to get the channel configuration binary through Channel#getChannelConfigurationBytes, with the javadoc pointing to the configtxlator binary.

Is there a clean solution to deserialise directly?

Was looking into creating a CommitHandler that matches a Channel's endorsement policy, but that would require having the channel config.

[bestbeforetoday]

There are two parts to consider here: dealing with the channel configuration programmatically, and creating a CommitHandler matching channel endorsement policy.

Deserialising channel configuration

There is some description of the config block structure in the Fabric documentation. The block and configuration itself are protocol buffer (protobuf) messages. The Fabric-specific protobuf messages (and gRPC services used by the SDKs to interact with Fabric) are defined in the hyperledger/fabric-protos repository. There are also language specific bindings for Go, Node.js and Java, built and published from these protobuf definitions. These language bindings can be used to programmatically create, manipulate, serialise and deserialise Fabric protobuf messages. Information on those packages and also some documentation built from the protobuf definitions can be found here:

https://hyperledger.github.io/fabric-protos/

An example of deserialising a Block structure using the Fabric protobuf bindings can be found in the Fabric off_chain_data sample. The entry point to the parser contained here is the BlockParser, but the piece of interest for channel configuration is the ParsedBlock, which demonstrates how to extract the transaction envelope payloads from the block.

For a config block there is a single transaction envelope, and its payload data is a serialised ConfigEnvelope. It looks like what you get back from Channel#getChannelConfigurationBytes is the serialized bytes of the config property of that ConfigEnvelope.

CommitHandler matching channel endorsement policy

The endorsement policy is used for endorsement, and the endorsements for a transaction are checked against the effective endorsement policy during validation phase of the transaction submit flow. The effective endorsement policy considers channel, chaincode, private data collection, and key-/state-based endorsement policies that apply to the interactions made with the ledger by the transaction. Depending on the transaction, it can be much more complex than just the channel endorsement policy. The SDK deals with this to some extent by making use of service discovery to determine an appropriate endorsement plan for a given transaction, although you can still end up having to manually specify endorsers for complex scenarios. The Fabric Gateway client API (for Fabric v2.4 and later) does a much better job of automagically identifying the correct endorsement requirements for a specific transaction invocation - see its migration guide for details.

The key point is that all of the endorsement policy considerations are dealt with before the CommitHandler takes care of checking the commit status of a transaction. The job of the CommitHandler is just to:

1. Find out whether your transaction successfully updated the ledger.
2. Check this on enough peers that subsequent transaction invocations will see the updated ledger state.

To check the commit status, just getting a response from a single peer is sufficient, since all peers must produce the same result to maintain a consistent ledger. To ensure subsequent transaction see the updated ledger state, you may want to wait for more peers to ensure that their ledgers have been updated before they are used to evaluate or endorse submitted transactions. Again the Fabric Gateway client API does a more efficient job here by always picking the most up-to-date peers for endorsement so that it only needs to wait for transaction commit status at the Gateway peer to ensure consistent results for subsequent transactions.

[Breina]

Beautiful! Thanks a lot!

[bestbeforetoday]

I'll leave the discussion thread open so other people can more easily find it.