All New Changes in Hyperledger Fabric v2.3

Hyperledger fabric is one of the fastest evolving community and it is very difficult to keep a track of all the latest developments. Here is a quick summary of new updates in Fabric v2.3.

Fabric v2.3.0 — Released on Nov 19, 2020

Hyperledger Fabric v2.3 introduces two new features for improved orderer and peer operations:

• Orderer channel management without a system channel
• Ledger snapshot

Orderer channel management without a system channel

To simplify the channel creation process and enhance the privacy and scalability of channels, it is now possible to create application channels without first creating a “system channel” managed by the ordering service. This process allows ordering nodes to join (or leave) any number of channels as needed, similar to how peers can participate in multiple channels.

Benefits of the new process:

Increased privacy: Because all ordering nodes used to be joined to the system channel, every ordering node in a network knew about the existence of every channel on that ordering service. Now, an ordering node only knows about the channels it is joined to.

Scalability: When there is a large number of ordering nodes and channels defined on the system channel, it can take a long time for ordering nodes to reach consensus on the membership of all the channels. Now, an ordering service can scale horizontally in a decentralized fashion by independently joining ordering nodes to specific channels.

Operational benefits

• Simple process to join an ordering node to a channel.
• Ability to list the channels that the ordering node is a consenter on.
• Simple process to remove a channel from an ordering node, which automatically cleans up the blocks associated with that channel.
• Peer organizations do not need to coordinate with an admin of the system channel to create or update its MSP.

Ledger snapshot

It is now possible to take a snapshot of a peer’s channel information, including its state database, and join new peers (in the same organization or different organizations) to the channel based on the snapshot.

Using ledger snapshots has the following advantages:

• Peers don’t need to process all blocks since genesis block: Peers can join a channel without processing all previous blocks since the genesis block, greatly reducing the time it takes to join a peer to an existing channel.
• Peers can join channels using latest channel configuration: Because snapshots include the latest channel configuration, peers can now join a channel using the latest channel configuration. This is especially important if critical channel configuration such as orderer endpoints or TLS CA certificates have been updated since the genesis block.
• Reduced storage costs: Peers that join by snapshot do not incur the storage cost of maintaining all blocks since the genesis block.
• State checkpoints: Peer administrators can snapshot current channel state and compare with other peers, in the same organization or different organizations, to verify the consistency and integrity of the ledger on each peer. Agreed upon snapshots can be used as a checkpoint and basis for newly joining peers.

Fixes

All fixes as of v2.2.1 have also been applied to v2.3.0. Additionally the following fixes have been made.

FAB-18244: orderer — Single node orderer will not start due to inconsistent state

If using a single node orderer, it was possible to get into an inconsistent state where a Raft WAL snapshot was taken but an in-flight block at the associated height is not yet written. This fix resolves the inconsistent state by writing the last block, so that the single node orderer can start.

FAB-18192: orderer — Consenter certificate validation fails when MSP is not part of existing configuration

If adding an organization MSP and a Raft consenter in the same configuration update transaction, validation fails with error “consensus metadata update for channel config update is invalid” “certificate signed by unknown authority”.
This fix adds logic to verify consenters based on the updated set of organization MSP root CAs.

FAB-18308: peer and orderer — Restore support for MSPs that contain RSA certificate authorities

While Fabric has never supported RSA for transaction signatures or validation, certificate authorities included in MSP definitions could be associated with RSA keys. This ability was inadvertently removed during the development of release 2.0 and prevented migration of some networks to a 2.x version. With these changes, version 2.x components will no longer panic when attempting to initialize MSPs that include CA certificates associated with RSA keys.

peer and orderer PKCS#11 — Always Finalize the PKCS#11 FindObject Operation

In certain error paths, a PKCS#11 session was not finalized, leaving the session in a locked state so that it could not be reused. This fix finalizes session handles even in error paths, so that the session can be reused
by subsequent calls.

orderer — Allow tick interval override via orderer.yaml

If a raft network becomes unstable, sometimes, adjusting the tick
interval duration can be effective to restore it. However, the tick interval is
stored in the channel configuration, so if the network is not operational,
modifying it is very challenging. This fix adds Consensus.TickIntervalOverride
option to orderer.yaml configuration, allowing the channel configuration parameter to be overridden from the local configuration.

Changes

Require orderer file ledger location to be set

The Orderer.FileLedger.Location must now be set. Utilizing the
Orderer.FileLedger.Prefix to generate a new temporary directory with the specified prefix every time the orderer is restarted is no longer supported. The orderer will panic if a location is not provided.

FAB-18298: orderer — Default values for General.Cluster.ClientCertificate and General.Cluster.ClientPrivateKey

If orderer.yaml configuration options General.Cluster.ClientCertificate and General.Cluster.ClientPrivateKey are not set, default them to the server General.TLS.Certificate and General.TLS.PrivateKey values when the orderer is not configured to use a separate cluster port. This change simplifies orderer node configuration by not requiring the client certificates to be explicitly set.

Dependency Updates

Bump Go to 1.14.12.

CouchDB 3.1.1 is now the tested CouchDB version.

Fabric v2.3.1 — Released on Feb 3, 2021

Fixes

peer — incorrect handling of values set to empty byte array in node chaincode

Peer should handle key values set to nil or empty byte arrays as a delete of the key. While the behavior worked as expected when using Go chaincode and Java chaincode, if using node chaincode it did not work correctly when setting key values to empty byte arrays. This fix ensures that peer will interpret empty byte arrays as deletes even for node chaincodes. If using node chaincode with private data, if you had set private data values to an empty byte array, the private data hash would have been committed incorrectly to the state database.
To repair the state database, after applying the fix, with the peer stopped, request that the state database be rebuilt by calling “peer node rebuild-dbs” or by deleting the state database. Upon the next start, the peer will rebuild the state database from the already processed block store.

If subsequent transactions had referenced the existence of such a private data hash by calling GetPrivateDataHash, then the subsequent transactions may have been processed incorrectly and the peer will need to additionally reprocess blocks, which can be triggered by calling “peer node reset” instead of “peer node rebuild-dbs”. If the peer joined channels from a snapshot, “peer node rebuild-dbs” and “peer node reset” are not available since the peer does not have all blocks since the genesis block. In these cases the peer will need to be replaced with a new peer that re-joins from the snapshots. If using regular channel data only and not private data, the empty byte array will not have been committed, and therefore no action is required on the peer beyond applying the fix.

orderer — incorrect osnadmin flag — channel-id

The osnadmin CLI introduced in v2.3.0 used an incorrect flag — channel-id.
The flag has been corrected to be — channelID in order to be consistent
with other CLIs.

Fabric v2.3.2 — Released on Apr 24, 2021

Improvements

peer and orderer — Implement legacy name constraints verification for Go 1.15

These changes reproduce the Go 1.14 name constraint verification in the MSP. Without these changes, certificate chains that would fail verification in Go 1.14 would successfully validate in Go 1.15 due to the change mentioned in the Go 1.15 release notes. Specifically, if a signing certificate contains a name constraint, the leaf certificate does not include SAN extensions, and the leaf’s common name looks like a host name, then the additional verification is performed to ensure deterministic behavior relative
to prior Fabric releases.

Fixes

FAB-18427: orderer — Report correct reason of stream abort in orderer cluster

This commit fixes a bug that makes the cluster communication infrastructure always report an “aborted” reason after a stream terminates.

FAB-18424: peer — Ledger snapshot request submission with special value “blockNumber 0”

If a ledger snapshot request is submitted with the special value “blockNumber 0”, peer is expected to translate the request to last committed block.
This patch fixes the issue where, it may happen sometimes that the request is translated to block number 1 instead of last committed block.
This leads to the situation where no snapshot gets generated, including any future snapshot requests. If you have ever used this special value, we encourage you to check the list of pending snapshots requests with peer snapshot listpending. If you notice one or more pending requests that are for the the block numbers lower than the latest committed block, cancel such requests with peer snapshot cancelrequest to enable the further snapshot requests to be processed.

FAB-18304: peer and orderer — Fix leveldb manifest corruption

This fix updates the version of goleveldb. The prior version of goleveldb had a bug which could cause manifest corruption in crash scenarios, especially in disk full crash scenarios. With a corrupted goleveldb database, the peer or orderer would fail to start with error “panic: Error opening leveldb: leveldb: manifest corrupted”.

Dependencies

Fabric v2.3.2 has been tested with the following dependencies:

• Go 1.15.7
• CouchDB v3.1.1

Fabric v2.3.3 — Released on Sep 9, 2021

Improvements

peer — New configuration option to disable gossip block forwarding

If all peers in an organization explicitly set peer.deliveryclient.blockGossipEnabled to false, no peer in the organization gossips blocks to any other peer in that organization. Use this setting when all peers pull blocks from ordering service. For more information see deprecation announcement below: FAB-15317: Block dissemination via gossip is deprecated.

orderer — [FAB-18484] Return transaction forwarding result back to the client synchronously

With this improvement a Raft follower waits for the transaction to be forwarded to the Raft leader, and returns the result (success or failure) back to the client accordingly. Prior to this improvement, the Raft follower returned success after enqueueing it into the message queue,
which might have resulted in the transaction being dropped but a success being returned to the client. Application clients should still monitor transaction commit events, since the Raft leader is not guaranteed
to deliver the transaction into a block in exception scenarios, but this improvement avoids transactions from being dropped when there are connection issues between a Raft follower and Raft leader.

peer and orderer — Make gRPC maximum message size configurable

This improvement makes gRPC maximum message size configurable in peer and orderer. Previously the maximum message size was hardcoded to 100 megabytes. Since all nodes should be consistent it is recommended to keep
the default value of 100 megabytes for MaxRecvMsgSize & MaxSendMsgSize.
The value can be configured if needed however. Configure in peer core.yaml with peer.maxRecvMsgSize and peer.maxSendMsgSize. Configure in orderer orderer.yaml with General.MaxRecvMsgSize and General.MaxSendMsgSize.

Fixes

orderer — [FAB-18521] Consenters’ metadata is not replicated while OSN catches up with snapshot

If an ordering service node crashes while replicating blocks from another ordering service, the consenters metadata will not be available and the ordering service node will not be able to reconnect to the consenter set upon restart. This fix ensures that an ordering service node that is replicating blocks persists the consenters metadata so that it can reconnect to the consenter set.

Dependencies

Fabric v2.3.3 has been tested with the following dependencies:

• Go 1.16.7
• CouchDB v3.1.1