From d5ec639588a7a9cf063e7a58dc2fd98d29fc312e Mon Sep 17 00:00:00 2001 From: David Enyeart Date: Mon, 16 Sep 2024 10:00:20 -0400 Subject: [PATCH] v3.0 release notes v3.0 release notes Signed-off-by: David Enyeart --- docs/source/whatsnew.rst | 17 +++-- release_notes/v3.0.0.md | 141 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 152 insertions(+), 6 deletions(-) create mode 100644 release_notes/v3.0.0.md diff --git a/docs/source/whatsnew.rst b/docs/source/whatsnew.rst index e5e051bbb51..db90fc83ee2 100644 --- a/docs/source/whatsnew.rst +++ b/docs/source/whatsnew.rst @@ -14,6 +14,8 @@ Fabric v3.0 is the first release to provide a BFT ordering service based on the 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. + Learn more about the BFT ordering service in the **BFT** section of the :doc:`orderer/ordering_service` documentation. For more details see the :doc:`bft_configuration` topic. @@ -21,12 +23,19 @@ For more details see the :doc:`bft_configuration` topic. Try it out for yourself! Look for the **Bring up the network using BFT ordering service** in the :doc:`test_network` tutorial. Alternatively, you can run the binaries locally by following the steps in the `test-network-nano-bash sample `_. +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. + Hyperledger Fabric v2.5 ----------------------- Hyperledger Fabric v2.5 remains the long-term support (LTS) release for production users. Check out the `What's New in v2.5 topic `_ -to learn about recent features since the prior v2.2 LTS release, including +to learn about features since the prior v2.2 LTS release, including the ability to manage channels without a system channel, the ability to take ledger snapshots and join peers to a channel based on a snapshot, and the new Fabric Gateway and related client application libraries. @@ -46,11 +55,7 @@ Release notes The release notes provide more details about each release. Additionally, take a look at the announcements about changes and deprecations that are copied into each of the latest release notes. -* `Fabric v2.5.0 release notes `_. -* `Fabric v2.5.1 release notes `_. -* `Fabric v2.5.2 release notes `_. -* `Fabric v2.5.3 release notes `_. -* `Fabric v2.5.4 release notes `_. +* `Fabric v3.0.0 release notes `_. .. Licensed under Creative Commons Attribution 4.0 International License https://creativecommons.org/licenses/by/4.0/ diff --git a/release_notes/v3.0.0.md b/release_notes/v3.0.0.md new file mode 100644 index 00000000000..437bb34b041 --- /dev/null +++ b/release_notes/v3.0.0.md @@ -0,0 +1,141 @@ +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](https://arxiv.org/abs/2107.06922) [consensus library](https://github.com/hyperledger-labs/SmartBFT). +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](https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html). + +**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](https://hyperledger-fabric.readthedocs.io/en/release-2.5/create_channel/create_channel_participation.html). + +**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](https://hyperledger-fabric.readthedocs.io/en/latest/test_network.html). + +**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](https://hyperledger-fabric.readthedocs.io/en/release-2.5/kafka_raft_migration.html). + +**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](https://hyperledger-fabric.readthedocs.io/en/release-2.5/enable_cc_lifecycle.html). + +**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 +```