Releases: hyperledger/fabric
v3.1.0
v3.1.0 Release Notes - March 18, 2025
New features
Performance optimization - Batching of chaincode writes
Chaincodes that write large numbers of keys were inefficient since each key write required communication between the chaincode and the peer.
The new feature enables a chaincode developer to batch multiple writes into a single communication between the chaincode and the peer.
A batch can be started by calling StartWriteBatch(). The chaincode can then perform key writes as usual.
Then when FinishWriteBatch() is called or the transaction execution ends the writes will be sent to the peer.
Batches over a configured size will be split into multiple batch segments.
The batching approach significantly improves performance for chaincodes that write to many keys.
Note that the batching only impacts the endorsement phase. The transaction itself, as well as the validation and commit phases, remains the same as previous versions.
The batch writes are configured with the following peer core.yaml chaincode properties:
chaincode.runtimeParams.useWriteBatch- boolean that indicates whether write batching is enabled on peerchaincode.runtimeParams.maxSizeWriteBatch- integer that indicates the maximum number of keys written per batch segment.
The new feature requires chaincode to utilize fabric-chaincode-go v2.1.0 or higher.
Performance optimization - Batching of chaincode reads
Chaincodes that read large numbers of keys were inefficient since each key read required communication between the chaincode and the peer.
The new feature enables a chaincode developer to batch multiple reads into a single communication between the chaincode and the peer.
Utilize the new GetMultipleStates() and GetMultiplePrivateData() chaincode functions to perform the batch reads.
Batches over a configured size will be split into multiple batch segments.
The batch reads are configured with the following peer core.yaml chaincode properties:
chaincode.runtimeParams.useGetMultipleKeys- boolean that indicates whether read batching is enabled on peerchaincode.runtimeParams.maxSizeGetMultipleKeys- integer that indicates the maximum number of keys read per batch segment
The new feature requires chaincode to utilize fabric-chaincode-go v2.2.0 or higher.
Query all composite keys in a chaincode
A new chaincode function GetAllStatesCompositeKeyWithPagination() is available so that all composite keys within a chaincode can be retrieved.
This function is useful when performing bulk operations on all composite keys in a chaincode.
The new feature requires chaincode to utilize fabric-chaincode-go v2.3.0 or higher.
Improvements and Fixes
All improvements and fixes as of v2.5.12 have also been included in v3.1.0.
Dependencies
Fabric v3.1.0 has been tested with the following dependencies:
- Go 1.24.0
- CouchDB v3.4.2
Fabric docker images on docker.io and ghcr.io utilize Ubuntu 22.04.
Changes and Removals
See the v3.0.0 release notes for changes and removals between Fabric v2.x and Fabric v3.x.
Deprecated features
Block dissemination via gossip is deprecated and may be removed
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
v2.5.12
v2.5.12 Release Notes - March 10, 2025
Fixes
Fix peer panic from gossip/gossip/algo
Occasionally a peer may panic due to outdated math/rand dependency with message
panic: runtime error: index out of range [-1].
5170
Fix peer panic from fabric/gossip/util
On an active network with many channels and many peers, a peer may panic with the message
panic: runtime error: invalid memory address or nil pointer dereference.
#5138
Dependencies
Fabric v2.5.12 has been tested with the following dependencies:
- Go 1.23.5
- CouchDB v3.4.2
Go dependencies have also been updated.
Fabric docker images on dockerhub utilize Ubuntu 22.04.
Deprecations (existing)
Ordering service system channel is deprecated
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability,
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
For information about removal of the system channel, see the Create a channel without system channel documentation.
FAB-15754: The 'Solo' consensus type is deprecated.
The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments; however, for compatibility it is still available,
but may be removed entirely in a future release.
FAB-16408: The 'Kafka' consensus type is deprecated.
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
Fabric CouchDB image is deprecated
v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in the peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
FAB-15406: The fabric-tools docker image is deprecated
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
FAB-15317: Block dissemination via gossip is deprecated
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
FAB-15061: Legacy chaincode lifecycle is deprecated
The legacy chaincode lifecycle from v1.x is deprecated and will be removed
in a future release. To prepare for the eventual removal, utilize the v2.x
chaincode lifecycle instead, by enabling V2_0 application capability on all
channels, and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
v2.5.11
v2.5.11 Release Notes - January 31, 2025
Fixes
Gossip handling of expired certificates
If a peer has another peer's expired certificate in memory, it was not able to connect to that peer again
even if the peer has renewed its certificate. This fix ensures that the peer can connect to other
peers once they have renewed their certificate.
#5122
Dependencies
Fabric v2.5.11 has been tested with the following dependencies:
- Go 1.23.5
- CouchDB v3.4.2
Go dependencies have also been updated.
Fabric docker images on dockerhub utilize Ubuntu 22.04.
Deprecations (existing)
Ordering service system channel is deprecated
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability,
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
For information about removal of the system channel, see the Create a channel without system channel documentation.
FAB-15754: The 'Solo' consensus type is deprecated.
The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments; however, for compatibility it is still available,
but may be removed entirely in a future release.
FAB-16408: The 'Kafka' consensus type is deprecated.
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
Fabric CouchDB image is deprecated
v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in the peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
FAB-15406: The fabric-tools docker image is deprecated
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
FAB-15317: Block dissemination via gossip is deprecated
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
FAB-15061: Legacy chaincode lifecycle is deprecated
The legacy chaincode lifecycle from v1.x is deprecated and will be removed
in a future release. To prepare for the eventual removal, utilize the v2.x
chaincode lifecycle instead, by enabling V2_0 application capability on all
channels, and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
v2.5.10
v2.5.10 Release Notes - September 20, 2024
v2.5.10 updates code dependencies.
Dependencies
Fabric v2.5.10 has been tested with the following dependencies:
- Go 1.23.1
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 20.04.
Deprecations (existing)
Ordering service system channel is deprecated
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability,
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
For information about removal of the system channel, see the Create a channel without system channel documentation.
FAB-15754: The 'Solo' consensus type is deprecated.
The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments; however, for compatibility it is still available,
but may be removed entirely in a future release.
FAB-16408: The 'Kafka' consensus type is deprecated.
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
Fabric CouchDB image is deprecated
v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in the peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
FAB-15406: The fabric-tools docker image is deprecated
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
FAB-15317: Block dissemination via gossip is deprecated
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
FAB-15061: Legacy chaincode lifecycle is deprecated
The legacy chaincode lifecycle from v1.x is deprecated and will be removed
in a future release. To prepare for the eventual removal, utilize the v2.x
chaincode lifecycle instead, by enabling V2_0 application capability on all
channels, and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
v3.0.0
v3.0.0 Release Notes - September 17, 2024
New features
Byzantine Fault Tolerant (BFT) ordering service
Hyperledger Fabric has utilized a Raft crash fault tolerant (CFT) ordering service since version v1.4.1.
A Byzantine Fault Tolerant (BFT) ordering service can withstand not only crash failures, but also a subset of nodes behaving maliciously.
Fabric v3.0.0 provides a BFT ordering service based on the SmartBFT consensus library.
Consider using the BFT orderer if true decentralization is required, where up to and not including a third of the parties running the orderers may not be trusted due to malicious intent or being compromised.
Channel capability V3_0 must be enabled to utilize SmartBFT consensus.
For more details of the BFT ordering service and other recent features, see the What's New documentation.
Query all approved chaincodes on a channel
The updated peer lifecycle chaincode queryapproved command allows you to pass only a channel name.
The command will return all approved chaincodes on the channel.
Support for Ed25519
Ed25519 cryptographic algorithm is now supported in addition to ECDSA for MSP functions including transaction signing and verification.
Channel capability V3_0 must be enabled to utilize certificates with Ed25519 keys.
Improvements and Fixes
All improvements and fixes as of v2.5.9 have also been included in v3.0.0.
Dependencies
Fabric v3.0.0 has been tested with the following dependencies:
- Go 1.23.1
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 22.04.
Changes
peer.gossip.pvtData.transientstoreMaxBlockRetention default value increased from 1000 to 20000
peer.gossip.pvtData.transientstoreMaxBlockRetention specifies the number of blocks to keep uncommitted private data
in the transient store before it is purged. Increasing the value provides more tolerance for delayed commits
before the data is purged.
TimeWindowCheck for proposal timestamps
New TimeWindowCheck endorsement authFilter configured at peer.handlers.authFilters.name checks the timestamp of a proposal request against endorsing peer time,
using the time window configured at peer.authentication.timewindow.
This check helps to ensure that the proposal timestamp that eventually gets committed in a transaction is accurate relative to the endorsing peers.
peer.deliveryclient.blockGossipEnabled default value changed to false
Block dissemination via gossip is deprecated and may be removed in a future release,
therefore peer.deliveryclient.blockGossipEnabled now defaults to false.
Fabric peers should be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
Removals
Support for ordering service system channel has been removed
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability, and operational benefits.
The system channel is removed in Fabric v3.0, as well as the concept of a 'consortium' of organizations that can create channels.
If you used the system channel in prior releases, you must remove the system channel and migrate to the channel participation API before upgrading to v3.x.
For information about removal of the system channel, see the Create a channel without system channel documentation.
Support for 'Solo' consensus ordering service has been removed
The 'Solo' consensus type was intended for test environments only in prior releases and has never been supported for production environments.
Support for 'Solo' consensus has been removed in Fabric v3.0.
For trial environments you can utilize a single node Raft ordering service as demonstrated in the test network tutorial.
Support for 'Kafka' consensus ordering service has been removed
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred production Crash Fault Tolerant consensus type.
Support for 'Kafka' consensus has been removed in Fabric v3.0.
If you used Kafka consensus in prior releases, you must migrate to Raft consensus prior to upgrading to v3.x.
For details about the migration process, see the Migrating from Kafka to Raft documentation.
Legacy chaincode lifecycle has been removed
The legacy chaincode lifecycle from Fabric v1.x is removed in v3.x.
Prior to upgrading peers to v3.x, you must update all channels to utilize the v2.x lifecycle
by setting the channel application capability to either V2_0 or V2_5,
and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
Support for specifying orderer endpoints at the OrdererAddresses global level in channel configuration has been removed when using V3_0 channel capability
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
Remove the OrdererAddresses global configuration prior to enabling the V3_0 channel capability.
Support for configtxgen flag --outputAnchorPeersUpdate has been removed
The former --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
The fabric-tools docker image is no longer available
The fabric-tools docker image is no longer published for Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
Deprecated features
Block dissemination via gossip is deprecated and may be removed
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
v3.0.0-rc1
v3.0.0-rc1 Release Notes - September 17, 2024
New features
Byzantine Fault Tolerant (BFT) ordering service
Hyperledger Fabric has utilized a Raft crash fault tolerant (CFT) ordering service since version v1.4.1.
A Byzantine Fault Tolerant (BFT) ordering service can withstand not only crash failures, but also a subset of nodes behaving maliciously.
Fabric v3.0.0 provides a BFT ordering service based on the SmartBFT consensus library.
Consider using the BFT orderer if true decentralization is required, where up to and not including a third of the parties running the orderers may not be trusted due to malicious intent or being compromised.
Channel capability V3_0 must be enabled to utilize SmartBFT consensus.
For more details of the BFT ordering service and other recent features, see the What's New documentation.
Query all approved chaincodes on a channel
The updated peer lifecycle chaincode queryapproved command allows you to pass only a channel name.
The command will return all approved chaincodes on the channel.
Support for Ed25519
Ed25519 cryptographic algorithm is now supported in addition to ECDSA for MSP functions including transaction signing and verification.
Channel capability V3_0 must be enabled to utilize certificates with Ed25519 keys.
Improvements and Fixes
All improvements and fixes as of v2.5.9 have also been included in v3.0.0.
Dependencies
Fabric v3.0.0 has been tested with the following dependencies:
- Go 1.23.1
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 22.04.
Changes
peer.gossip.pvtData.transientstoreMaxBlockRetention default value increased from 1000 to 20000
peer.gossip.pvtData.transientstoreMaxBlockRetention specifies the number of blocks to keep uncommitted private data
in the transient store before it is purged. Increasing the value provides more tolerance for delayed commits
before the data is purged.
TimeWindowCheck for proposal timestamps
New TimeWindowCheck endorsement authFilter configured at peer.handlers.authFilters.name checks the timestamp of a proposal request against endorsing peer time,
using the time window configured at peer.authentication.timewindow.
This check helps to ensure that the proposal timestamp that eventually gets committed in a transaction is accurate relative to the endorsing peers.
peer.deliveryclient.blockGossipEnabled default value changed to false
Block dissemination via gossip is deprecated and may be removed in a future release,
therefore peer.deliveryclient.blockGossipEnabled now defaults to false.
Fabric peers should be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
Removals
Support for ordering service system channel has been removed
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability, and operational benefits.
The system channel is removed in Fabric v3.0, as well as the concept of a 'consortium' of organizations that can create channels.
If you used the system channel in prior releases, you must remove the system channel and migrate to the channel participation API before upgrading to v3.x.
For information about removal of the system channel, see the Create a channel without system channel documentation.
Support for 'Solo' consensus ordering service has been removed
The 'Solo' consensus type was intended for test environments only in prior releases and has never been supported for production environments.
Support for 'Solo' consensus has been removed in Fabric v3.0.
For trial environments you can utilize a single node Raft ordering service as demonstrated in the test network tutorial.
Support for 'Kafka' consensus ordering service has been removed
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred production Crash Fault Tolerant consensus type.
Support for 'Kafka' consensus has been removed in Fabric v3.0.
If you used Kafka consensus in prior releases, you must migrate to Raft consensus prior to upgrading to v3.x.
For details about the migration process, see the Migrating from Kafka to Raft documentation.
Legacy chaincode lifecycle has been removed
The legacy chaincode lifecycle from Fabric v1.x is removed in v3.x.
Prior to upgrading peers to v3.x, you must update all channels to utilize the v2.x lifecycle
by setting the channel application capability to either V2_0 or V2_5,
and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
Support for specifying orderer endpoints at the OrdererAddresses global level in channel configuration has been removed when using V3_0 channel capability
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
Remove the OrdererAddresses global configuration prior to enabling the V3_0 channel capability.
Support for configtxgen flag --outputAnchorPeersUpdate has been removed
The former --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
The fabric-tools docker image is no longer available
The fabric-tools docker image is no longer published for Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
Deprecated features
Block dissemination via gossip is deprecated and may be removed
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
v2.5.9
v2.5.9 Release Notes - June 18, 2024
v2.5.9 updates code dependencies.
Dependencies
Fabric v2.5.9 has been tested with the following dependencies:
- Go 1.22.4
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 20.04.
Deprecations (existing)
Ordering service system channel is deprecated
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability,
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
For information about removal of the system channel, see the Create a channel without system channel documentation.
FAB-15754: The 'Solo' consensus type is deprecated.
The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments; however, for compatibility it is still available,
but may be removed entirely in a future release.
FAB-16408: The 'Kafka' consensus type is deprecated.
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
Fabric CouchDB image is deprecated
v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in the peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
FAB-15406: The fabric-tools docker image is deprecated
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
FAB-15317: Block dissemination via gossip is deprecated
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
FAB-15061: Legacy chaincode lifecycle is deprecated
The legacy chaincode lifecycle from v1.x is deprecated and will be removed
in a future release. To prepare for the eventual removal, utilize the v2.x
chaincode lifecycle instead, by enabling V2_0 application capability on all
channels, and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
v2.5.8
v2.5.8 Release Notes - May 21, 2024
v2.5.8 updates code dependencies.
Dependencies
Fabric v2.5.8 has been tested with the following dependencies:
- Go 1.22.3
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 20.04.
Deprecations (existing)
Ordering service system channel is deprecated
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability,
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
For information about removal of the system channel, see the Create a channel without system channel documentation.
FAB-15754: The 'Solo' consensus type is deprecated.
The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments; however, for compatibility it is still available,
but may be removed entirely in a future release.
FAB-16408: The 'Kafka' consensus type is deprecated.
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
Fabric CouchDB image is deprecated
v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in the peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
FAB-15406: The fabric-tools docker image is deprecated
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
FAB-15317: Block dissemination via gossip is deprecated
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
FAB-15061: Legacy chaincode lifecycle is deprecated
The legacy chaincode lifecycle from v1.x is deprecated and will be removed
in a future release. To prepare for the eventual removal, utilize the v2.x
chaincode lifecycle instead, by enabling V2_0 application capability on all
channels, and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
v2.5.7
v2.5.7 Release Notes - April 15, 2024
v2.5.7 updates code dependencies.
Dependencies
Fabric v2.5.7 has been tested with the following dependencies:
- Go 1.21.9
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 20.04.
Deprecations (existing)
Ordering service system channel is deprecated
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability,
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
For information about removal of the system channel, see the Create a channel without system channel documentation.
FAB-15754: The 'Solo' consensus type is deprecated.
The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments; however, for compatibility it is still available,
but may be removed entirely in a future release.
FAB-16408: The 'Kafka' consensus type is deprecated.
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
Fabric CouchDB image is deprecated
v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in the peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
FAB-15406: The fabric-tools docker image is deprecated
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
FAB-15317: Block dissemination via gossip is deprecated
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false
FAB-15061: Legacy chaincode lifecycle is deprecated
The legacy chaincode lifecycle from v1.x is deprecated and will be removed
in a future release. To prepare for the eventual removal, utilize the v2.x
chaincode lifecycle instead, by enabling V2_0 application capability on all
channels, and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
v3.0.0-beta
v3.0.0-beta Release Notes - March 14, 2024
The v3.0.0-beta release is an early release of Fabric v3.0, specifically to demonstrate and get feedback on the new Byzantine Fault Tolerant (BFT) ordering service.
v3.0.0-beta is not intended to be used in production and is not intended as an upgrade target from prior versions. It can however be used to test the process
for migrating from Raft to SmartBFT consensus.
New features
Byzantine Fault Tolerant (BFT) ordering service
Hyperledger Fabric has utilized a Raft crash fault tolerant (CFT) ordering service since version v1.4.1.
A Byzantine Fault Tolerant (BFT) ordering service can withstand not only crash failures, but also a subset of nodes behaving maliciously.
Fabric v3.0.0-beta provides a BFT ordering service based on the SmartBFT consensus library.
Consider using the BFT orderer if true decentralization is required, where up to and not including a third of the parties running the orderers may not be trusted due to malicious intent or being compromised.
For more details of the BFT ordering service and other recent features, see the What's New documentation.
The v3.0.0-beta release differs from the v3.0.0-preview release by making the peer and orderer block replication resistant to block withholding.
Block withholding is when an orderer receives a request for blocks it possesses, but it delays sending the blocks and by doing so, slows down the requester's block reception.
As described in the RFC, block withholding resistance incurs a bandwidth and CPU cost,
and therefore an operator of an orderer may opt out and use the standard mechanism by specifying ReplicationPolicy: simple in the local configuration.
Query all approved chaincodes on a channel
The updated peer lifecycle chaincode queryapproved command allows you to pass only a channel name.
The command will return all approved chaincodes on the channel.
Improvements and Fixes
All improvements and fixes as of v2.5.6 have also been included in v3.0.0-beta.
Dependencies
Fabric v3.0.0-beta has been tested with the following dependencies:
- Go 1.21.8
- CouchDB v3.3.3
Fabric docker images on dockerhub utilize Ubuntu 20.04.
Changes
peer.gossip.pvtData.transientstoreMaxBlockRetention default value increased from 1000 to 20000
peer.gossip.pvtData.transientstoreMaxBlockRetention specifies the number of blocks to keep uncommitted private data
in the transient store before it is purged. Increasing the value provides more tolerance for delayed commits
before the data is purged.
Removals
Support for ordering service system channel has been removed
v2.3 introduced the ability to manage an ordering service without a system channel.
Managing an ordering service without a system channel has privacy, scalability, and operational benefits.
The system channel is removed in Fabric v3.0, as well as the concept of a 'consortium' of organizations that can create channels.
If you used the system channel in prior releases, you must remove the system channel and migrate to the channel participation API before upgrading to v3.x.
For information about removal of the system channel, see the Create a channel without system channel documentation.
Support for 'Solo' consensus ordering service has been removed
The 'Solo' consensus type was intended for test environments only in prior releases and has never been supported for production environments.
Support for 'Solo' consensus has been removed in Fabric v3.0.
For trial environments you can utilize a single node Raft ordering service as demonstrated in the test network tutorial.
Support for 'Kafka' consensus ordering service has been removed
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred production consensus type.
Support for 'Kafka' consensus has been removed in Fabric v3.0.
If you used Kafka consensus in prior releases, you must migrate to Raft consensus prior to upgrading to v3.x.
For details about the migration process, see the Migrating from Kafka to Raft documentation.
Legacy chaincode lifecycle has been removed
The legacy chaincode lifecycle from v1.x is removed in v3.x.
Prior to upgrading peers to v3.x, you must update all channels to utilize the v2.x lifecycle
by setting the channel application capability to either V2_0 or V2_5,
and redeploying all chaincodes using the v2.x lifecycle. The new
chaincode lifecycle provides a more flexible and robust governance model
for chaincodes. For more details see the
documentation for enabling the new lifecycle.
Deprecated features
Support for specifying orderer endpoints at the global level in channel configuration is deprecated and may be removed.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications; in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for orderer communications.
Support for configtxgen flag --outputAnchorPeersUpdate is deprecated and may be removed.
The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had
limitations (for instance, it only works the first time anchor peers are updated).
Instead, anchor peer updates should be performed through channel configuration updates.
The fabric-tools docker image is deprecated and may be removed
The fabric-tools docker image will not be published in future Fabric releases.
Instead of using the fabric-tools docker image, users should utilize the
published Fabric binaries. The Fabric binaries can be used to make client calls
to Fabric runtime components, regardless of where the Fabric components are running.
Block dissemination via gossip is deprecated and may be removed
Block dissemination via gossip is deprecated and may be removed in a future release.
Fabric peers can be configured to receive blocks directly from an ordering service
node, and not gossip blocks, by using the following configuration:
peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.deliveryclient.blockGossipEnabled: false