github.com/hechain20/hechain@v0.0.0-20220316014945-b544036ba106/release_notes/v2.4.0.md (about) 1 v2.4.0 Release Notes - November 29, 2021 2 ======================================== 3 4 New features 5 ------------ 6 7 **Fabric Gateway** 8 9 Fabric Gateway is a new service running on peer nodes that manages transaction submission and processing for client applications, with the following benefits: 10 11 * Simplifies client applications and SDKs - Your client application can simply delegate transaction submission to a trusted peer. There is no need for your application to open connections to peer nodes and ordering service nodes from other organizations. 12 * Fabric Gateway manages collection of transaction endorsements from other organizations and submission to ordering service on behalf of client applications. 13 * Fabric Gateway has intelligence to determine what endorsements are required for a given transaction, even if your solution utilizes a combination of chaincode-level endorsement policies, private data collection endorsement policies, and state-based endorsement policies. 14 15 New lightweight Gateway SDKs (v1.0.0) are available for Node, Java, and Go. The SDKs support flexible application patterns: 16 17 * You can utilize the high level programming model similar to prior SDK versions, allowing your application to simply call a single SubmitTransaction() function. 18 * More advanced applications can leverage the gateway's individual Endorse, Submit, and CommitStatus services for transaction submission, and the Evaluate service for queries. 19 * You can delegate transaction endorsement entirely to the gateway, or if needed, specify the endorsing organizations and the gateway will utilize a peer from each organization. 20 21 For more information, see the [Fabric Gateway documentation topic](https://hyperledger-fabric.readthedocs.io/en/latest/gateway.html). 22 23 **Unjoin a channel from a peer** 24 25 The new command `peer node unjoin` enables an administrator to remove (unjoin) a channel from a peer. 26 The peer must be stopped when the command is executed so that channel artifacts can be cleaned up. 27 The channel's blockchain, state database, and associated entries will be removed from the peer. 28 When the peer is restarted it will no longer receive blocks for the channel. 29 30 For more information, see the [peer node command reference](https://hyperledger-fabric.readthedocs.io/en/latest/commands/peernode.html#peer-node-unjoin). 31 32 **Calculate package ID of a packaged chaincode** 33 34 You can calculate the package ID from a packaged chaincode without installing the chaincode on peers using the new `peer lifecycle chaincode calculatepackageid` command. 35 This command will be useful, for example, in the following cases: 36 * When multiple chaincode packages with the same label name are installed, it is possible to identify which ID corresponds to which package later. 37 * To check whether a particular chaincode package is installed or not without installing that package. 38 39 For more information, see the [peer lifecycle command reference](https://hyperledger-fabric.readthedocs.io/en/latest/commands/peerlifecycle.html#peer-lifecycle-chaincode-calculatepackageid). 40 41 42 Improvements 43 ------------ 44 45 **peer and orderer - Implement legacy name constraints verification for Go 1.15 and above** 46 47 These changes reproduce the Go 1.14 name constraint verification in the MSP. 48 Without these changes, certificate chains that would fail verification in Go 1.14 would 49 successfully validate in Go 1.15 and above due to the change mentioned in the [Go 1.15 release notes](https://golang.org/doc/go1.15#commonname). 50 Specifically, if a signing certificate contains a name constraint, the leaf certificate 51 does not include SAN extensions, and the leaf's common name looks like a host name, 52 then the additional verification is performed to ensure deterministic behavior relative 53 to prior Fabric releases. 54 55 **peer and orderer - Default log record format improvements** 56 57 Expanded the width of the log record sequence number to a minimum of four characters, 58 moved the log sequence number and log level to the left, 59 and added bold formatting to the function name. 60 These changes keep the fixed-width columns together at the left 61 and add a visual break between the logging module name and log message text. 62 63 **peer - New configuration option to disable gossip block forwarding** 64 65 If all peers in an organization explicitly set "peer.deliveryclient.blockGossipEnabled" to false, 66 no peer in the organization gossips blocks to any other peer in that organization. 67 Use this setting when all peers pull blocks from ordering service. For more 68 information see deprecation announcement below: **FAB-15317: Block dissemination via gossip is deprecated**. 69 70 **orderer - Return transaction forwarding result back to the client synchronously** 71 72 With this improvement a Raft follower waits for the transaction to be forwarded to the Raft leader, 73 and returns the result (success or failure) back to the client accordingly. 74 Prior to this improvement, the Raft follower returned success after enqueueing it into the message queue, 75 which might have resulted in the transaction being dropped but a success being returned to the client. 76 Application clients should still monitor transaction commit events, since the Raft leader is not guaranteed 77 to deliver the transaction into a block in exception scenarios, but this improvement avoids 78 transactions from being dropped when there are connection issues between a Raft follower and Raft leader. 79 80 **peer - Ability to override core.yaml chaincode.externalBuilders via environment variable** 81 82 Since chaincode.externalBuilders is an array, it previously was not possible to set via environment variable override. 83 It is now possible to override chaincode.externalBuilders using an environment variable 84 using the format `CORE_CHAINCODE_EXTERNALBUILDERS=[{name: x, path: dir1}, {name: y, path: dir2}]`. 85 86 **peer and orderer - Make gRPC maximum message size configurable** 87 88 This improvement makes gRPC maximum message size configurable in peer and orderer. 89 Previously the maximum message size was hardcoded to 100 megabytes. 90 Since all nodes should be consistent it is recommended to keep 91 the default value of 100 megabytes for MaxRecvMsgSize & MaxSendMsgSize. 92 The value can be configured if needed however. 93 Configure in peer core.yaml with `peer.maxRecvMsgSize` and `peer.maxSendMsgSize`. 94 Configure in orderer orderer.yaml with `General.MaxRecvMsgSize` and `General.MaxSendMsgSize`. 95 96 97 Fixes 98 ----- 99 All fixes as of v2.3.3 are included in v2.4.0. Additionally, the following fix is made in v2.4.0. 100 101 **orderer - Fix bug when an orderer crashes at channel creation** 102 103 This fix handles a scenario where an ordering service node crashes during channel creation. 104 Previously the ordering service node would attempt to re-create the channel upon next startup, 105 resulting in a panic with the following error: 106 "Error creating chain support: error creating consenter for channel: failed to restore persisted raft data: failed to create or read WAL: failed to open WAL: fileutil: file already locked". 107 108 109 Dependencies 110 ------------ 111 Fabric v2.4.0 has been tested with the following dependencies: 112 * Go 1.16.7 113 * CouchDB v3.1.1 114 115 Fabric docker images on dockerhub utilize Alpine 3.14. 116 117 Deprecations (new) 118 ----------------------- 119 120 **Ordering service system channel is deprecated** 121 122 v2.3 introduced the ability to manage an ordering service without a system channel. 123 Managing an ordering service without a system channel has privacy, scalability, 124 and operational benefits. The use of a system channel is deprecated and may be removed in a future release. 125 For information about removal of the system channel, see the [Create a channel without system channel documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.3/create_channel/create_channel_participation.html). 126 127 Deprecations (existing) 128 ----------------------- 129 130 **FAB-15754: The 'Solo' consensus type is deprecated.** 131 132 The 'Solo' consensus type has always been marked non-production and should be in 133 use only in test environments, however for compatibility it is still available, 134 but may be removed entirely in a future release. 135 136 **FAB-16408: The 'Kafka' consensus type is deprecated.** 137 138 The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred 139 production consensus type. There is a documented and tested migration path from 140 Kafka to Raft, and existing users should migrate to the newer Raft consensus type. 141 For compatibility with existing deployments, Kafka is still supported, 142 but may be removed entirely in a future release. 143 Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published. 144 145 **Fabric CouchDB image is deprecated** 146 147 v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB. 148 If prior versions are utilized, a Warning will appear in peer log. 149 Note that CouchDB 3.1.0 requires that an admin username and password be set, 150 while this was optional in CouchDB v2.x. See the 151 [Fabric CouchDB documentation](https://hyperledger-fabric.readthedocs.io/en/v2.2.0/couchdb_as_state_database.html#couchdb-configuration) 152 for configuration details. 153 Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment. 154 Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published. 155 Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead. 156 157 **FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.** 158 159 Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead. 160 Configuring orderer endpoints at the organization level accommodates 161 scenarios where orderers are run by different organizations. Using 162 this configuration ensures that only the TLS CA certificates of that organization 163 are used for orderer communications, in contrast to the global channel level endpoints which 164 would cause an aggregation of all orderer TLS CA certificates across 165 all orderer organizations to be used for orderer communications. 166 167 **FAB-17428: Support for configtxgen flag `--outputAnchorPeersUpdate` is deprecated.** 168 169 The `--outputAnchorPeersUpdate` mechanism for updating anchor peers has always had 170 limitations (for instance, it only works the first time anchor peers are updated). 171 Instead, anchor peer updates should be performed through the normal config update flow. 172 173 **FAB-15406: The fabric-tools docker image is deprecated** 174 175 The fabric-tools docker image will not be published in future Fabric releases. 176 Instead of using the fabric-tools docker image, users should utilize the 177 published Fabric binaries. The Fabric binaries can be used to make client calls 178 to Fabric runtime components, regardless of where the Fabric components are running. 179 180 **FAB-15317: Block dissemination via gossip is deprecated** 181 182 Block dissemination via gossip is deprecated and may be removed in a future release. 183 Fabric peers can be configured to receive blocks directly from an ordering service 184 node and not gossip blocks by using the following configuration: 185 ``` 186 peer.gossip.orgLeader: true 187 peer.gossip.useLeaderElection: false 188 peer.gossip.state.enabled: false 189 peer.deliveryclient.blockGossipEnabled: false 190 ``` 191 192 **FAB-15061: Legacy chaincode lifecycle is deprecated** 193 194 The legacy chaincode lifecycle from v1.x is deprecated and will be removed 195 in a future release. To prepare for the eventual removal, utilize the v2.x 196 chaincode lifecycle instead, by enabling V2_0 application capability on all 197 channels, and redeploying all chaincodes using the v2.x lifecycle. The new 198 chaincode lifecycle provides a more flexible and robust governance model 199 for chaincodes. For more details see the 200 [documentation for enabling the new lifecycle](https://hyperledger-fabric.readthedocs.io/en/release-2.2/enable_cc_lifecycle.html).