Releases: hyperledger/fabric
v2.0.0
v2.0.0 Release Notes - January 29, 2020
What's New in Hyperledger Fabric v2.0
The following new major features are included in the v2.0.0 release.
For additional details including upgrade steps, see the What's New documentation.
FAB-11237: Decentralized smart contract governance
Fabric 2.0 introduces decentralized governance for smart contracts, with a
new process for installing a chaincode on your peers and starting it on a
channel. The new Fabric chaincode lifecycle allows multiple organizations to
come to agreement on the parameters of a chaincode, such as the chaincode
endorsement policy, before it can be used to interact with the ledger.
New application patterns and private data enhancements
The same decentralized methods of coming to agreement that underpin the new chaincode
lifecycle management can also be used in your own chaincode applications to ensure
organizations consent to data transactions before they are committed to the ledger.
Fabric v2.0 also enables new patterns for working with and sharing private data,
without the requirement of creating private data collections for all combinations
of channel members that may want to transact. Specifically, instead of sharing private
data within a collection of multiple members, you may want to share private data
across collections, where each collection may include a single organization,
or perhaps a single organization along with a regulator or auditor.
- FAB-10889: Implicit org-specific collections
- FAB-15066: Endorsement policies for collections
- FAB-13581: memberOnlyWrite collection configuration option
- FAB-13527: GetPrivateDataHash chaincode API
- FAB-12043: Option to include private data in block events
FAB-13584: External chaincode launcher
The external chaincode launcher feature empowers operators to build and launch
chaincode with the technology of their choice. Use of external builders and
launchers is not required as the default behavior builds and runs chaincode
in the same manner as prior releases using the Docker API.
FAB-103: State database cache for CouchDB
A new peer cache improves performance when using CouchDB state database.
Important Changes
FAB-5177: The ccenv build image no longer includes the shim
The shim package and dependencies for go chaincode are no longer included in
the chaincode build environment. Chaincode packages that do not include their
own dependencies will no longer successfully build on the peer. We strongly
recommend that existing go chaincode be updated to vendor the
github.com/hyperledger/fabric-chaincode-go/shim package and its dependencies.
While there are many tools for managing vendored dependencies, we recommend
moving directly to go modules and vendoring with go mod vendor
.
FAB-15366: Logger removed from chaincode shim
Chaincode that used the shim's NewLogger() will need to shift to a new
logging mechanism. Chaincode logging is intended to be the responsibility
of the application developer. As such it should be handled using tools and
libraries that make the most sense to the chaincode developer and the
application in general. Chaincode developers can forward STDOUT and STDERR
from the chaincode container to the peer container by setting
CORE_VM_DOCKER_ATTACHSTDOUT=true
. While not recommended for production,
once enabled, each chaincode will receive its own logging channel and
STDOUT and STDERR will be integrated in the peers log on a per-line basis.
A production grade approach would be to run a log aggregation service and
forward your logs to the aggregation service.
FAB-16213: The go chaincode entities extension has been removed
Chaincode implementations that used the entities extension package from an
earlier version of Fabric will need to vendor a 1.x version of the package
for as part of their chaincode package.
FAB-12075: Client Identity (CID) library has moved
If chaincode uses client identity (CID) library, note that the source
location has moved to fabric-chaincode-go repository at location /pkg/cid.
FAB-14720: Support for CAR chaincode package format removed
FAB-15285: Support for invoking system chaincodes from user chaincodes
has been removed.
System chaincodes, for example QSCC, are intended to be
invoked by a client rather than by a user chaincode. Invoking from a user
chaincode caused deadlocks in prior releases.
FAB-15390: Support for peer's Admin service has been removed.
The peer's Admin service exposed APIs such as GetLogSpec() and SetLogSpec().
Instead of using these services, utilize the HTTP operations service that was
introduced in v1.4.0.
FAB-16303: GetHistoryForKey returns results from newest to oldest
In prior releases, the GetHistoryForKey chaincode API had no
guarantees on the order of returned results.
Starting in Fabric v2.0, the GetHistoryForKey chaincode API
will return results from newest to oldest in terms of ordered transaction
height (block height and transaction height within block).
This will allow applications to iterate through the top results
to understand recent changes to a key.
FAB-16722: The 'provisional' genesis method of generating the system channel
for orderers has been removed.
Existing users of the provisional genesis method
should instead set BootstrapMethod to 'file', and generate a genesis block file
using configtxgen. Orderer nodes will then use the generated file for the
orderer system channel.
FAB-16477 and FAB-17116: New configuration for orderer genesismethod and genesisfile
The orderer config general.genesismethod
and general.genesisfile
are replaced
by the new general.bootstrapmethod
and general.bootstrapfile
.
FAB-15343: System Chaincode Plugins have been removed.
As part of a general
move away from go plugins as an extension mechanism for Fabric, the ability to
add system chaincodes via go plugins has been removed. Users wishing to extend
Fabric with custom system chaincodes may rebuild the peer binary with the
system chaincode built into the binary. This system chaincode should then be
defined and initialized like any other user chaincode would be. This new model
is very similar to the plugin model (which required that the plugin to be built
at the same exact commit of Fabric), and addresses the significant shortcomings
around the lifecycle and validation of system chaincode transactions.
FAB-11096: Docker images with Alpine Linux
Hyperledger Fabric Docker images will now use Alpine Linux,
a security-oriented, lightweight Linux distribution.
FAB-11096: Bash not available in Docker images with Alpine Linux
Bash is no longer available in Fabric images. Utilize Alpine's built-in
sh or ash instead.
FAB-15499: Ledger data format upgrade
The Fabric ledger data structures use a more optimal and extensible
data format in v2.0. The peer node upgrade-dbs
command must be run
on peers to upgrade them to the new v2.0 data format. See the upgrade
documentation for details.
FAB-16866: Chaincode built upon installation on peer
Chaincode images are now built when a chaincode is installed onto a peer,
rather than at instantiation time as in prior releases. The behavior is
common to both the prior chaincode lifecycle and new chaincode lifecycle.
Expect chaincode installation to take longer than in prior releases.
Chaincode installation may time out and return an error to the client, even
though the installation and chaincode image build may ultimately succeed on
the peer.
FAB-15837: Orderer FileLedger location moved if specified with relative path
If FileLedger is specified with a relative path, it will be relative to the
config file, instead of where the binary is being executed.
FAB-14271: Policies must be specified in configtx.yaml
In Fabric v1.x configtxgen would create default policies if they were omitted
in configtx.yaml, but this behavior was deprecated in v1.2. In v2.0, configtxgen
no longer creates default policies, and they must be explicitly defined in configtx.yaml.
FAB-17000: Warn when certificates are about to expire
This change set adds a warning to the peer and orderer
that logs a warning a week before the enrollment certificate
or the server (client) TLS certificate expires.
FAB-16987: Go version has been updated to 1.13.4.
Deprecations
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.
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 ord...
v2.0.0-beta
v2.0.0-beta Release Notes - December 12, 2019
What's New in Hyperledger Fabric v2.0
The following new major features are included in the v2.0.0 Beta release.
For additional details, see the What's New documentation.
FAB-11237: Decentralized chaincode governance
Fabric 2.0 introduces decentralized governance for chaincode, with a
new process for installing a chaincode on your peers and starting it on a
channel. The new Fabric chaincode lifecycle allows multiple organizations to
come to agreement on the parameters of a chaincode, such as the chaincode
endorsement policy, before it can be used to interact with the ledger.
FAB-13584: External chaincode launcher
While chaincode is still run in a docker container by default in Fabric v2.0,
the external chaincode launcher feature empowers operators to build and launch
chaincode with the technology of their choice.
Private data enhancements
- FAB-10889: Implicit org-specific collections
- FAB-15066: Endorsement policies for collections
- FAB-13581: memberOnlyWrite collection configuration option
- FAB-13527: GetPrivateDataHash chaincode API
- FAB-12043: Option to include private data in block events
The private data enhancements enable new private data application patterns.
FAB-103: State database cache for CouchDB
A new peer cache improves performance when using CouchDB state database.
Fixes
All fixes as of release v1.4.4 are also included in v2.0.0-beta.
For the full list of fixes, refer to the release change log.
Changes
FAB-11144: Removal of native token support
The native token support included in v2.0.0-alpha has been removed.
An improved implementation is being evaluated for future releases.
FAB-5177: The ccenv build image no longer includes the shim
The shim package and dependencies for go chaincode are no longer included in
the chaincode build environment. Chaincode packages that do not include their
own dependencies will no longer successfully build on the peer. We strongly
recommend that existing go chaincode be updated to vendor the
github.com/hyperledger/fabric-chaincode-go/shim package and its dependencies.
While there are many tools for managing vendored dependencies, we recommend
moving directly to go modules and vendoring with go mod vendor
.
FAB-15366: Logger removed from chaincode shim
Chaincode that used the shim's NewLogger() will need to shift to a new
logging mechanism. Chaincode logging is intended to be the responsibility
of the application developer. As such it should be handled using tools and
libraries that make the most sense to the chaincode developer and the
application in general. Chaincode developers can forward STDOUT and STDERR
from the chaincode container to the peer container by setting
CORE_VM_DOCKER_ATTACHSTDOUT=true
. While not recommended for production,
once enabled, each chaincode will receive its own logging channel and
STDOUT and STDERR will be integrated in the peers log on a per-line basis.
A production grade approach would be to run a log aggregation service and
forward your logs to the aggregation service.
FAB-16213: The go chaincode entities extension has been removed
Chaincode implementations that used the entities extension package from an
earlier version of Fabric will need to vendor a 1.x version of the package
for as part of their chaincode package.
FAB-14720: Support for CAR chaincode package format removed
FAB-15285: Support for invoking system chaincodes from user chaincodes
has been removed.
System chaincodes, for example QSCC, are intended to be
invoked by a client rather than by a user chaincode. Invoking from a user
chaincode caused deadlocks in prior releases.
FAB-15390: Support for peer's Admin service has been removed.
The peer's Admin service exposed APIs such as GetLogSpec() and SetLogSpec().
Instead of using these services, utilize the HTTP operations service that was
introduced in v1.4.0.
FAB-16303: GetHistoryForKey returns results from newest to oldest
In prior releases, the GetHistoryForKey chaincode API had no
guarantees on the order of returned results.
Starting in Fabric v2.0, the GetHistoryForKey chaincode API
will return results from newest to oldest in terms of ordered transaction
height (block height and transaction height within block).
This will allow applications to iterate through the top results
to understand recent changes to a key.
FAB-16722: The 'provisional' genesis method of generating the system channel
for orderers has been removed.
Existing users of the provisional genesis method
should instead set BootstrapMethod to 'file', and generate a genesis block file
using configtxgen. Orderer nodes will then use the generated file for the
orderer system channel.
FAB-16477 and FAB-17116: New configuration for orderer genesismethod and genesisfile
The orderer config general.genesismethod
and general.genesisfile
are replaced
by the new general.bootstrapmethod
and general.bootstrapfile
.
FAB-15343: System Chaincode Plugins have been removed.
As part of a general
move away from go plugins as an extension mechanism for Fabric, the ability to
add system chaincodes via go plugins has been removed. Users wishing to extend
Fabric with custom system chaincodes may rebuild the peer binary with the
system chaincode built into the binary. This system chaincode should then be
defined and initialized like any other user chaincode would be. This new model
is very similar to the plugin model (which required that the plugin to be built
at the same exact commit of Fabric), and addresses the significant shortcomings
around the lifecycle and validation of system chaincode transactions.
FAB-11096: Docker images with Alpine Linux
Hyperledger Fabric Docker images will now use Alpine Linux,
a security-oriented, lightweight Linux distribution.
FAB-11096: Bash not available in Docker images with Alpine Linux
Bash is no longer available in Fabric images. Utilize Alpine's built-in
sh or ash instead.
FAB-16987: Go version has been updated to 1.13.4.
Deprecations
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.
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.
Known Issues and Workarounds
FAB-12134: Same chaincode source receiving fingerprint mismatch error
When using the legacy chaincode lifecycle, chaincode installed in different
ways may result in "chaincode fingerprint mismatch data mismatch" error
upon instantiation. This may happen when installing chaincode by using
different SDKs. To workaround the problem, package the chaincode prior to
installation and instantiation, by using the "peer chaincode package" command.
Known Vulnerabilities
FAB-8664: Peer should detect and react when its org has been removed
This is a relatively low severity problem, because it requires a significant
conspiracy of network admins, but it will be addressed in a future release.
Resolved Vulnerabilities
None.
For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v200-beta
Changes:
- 242b1e3 [FAB-17247] Release fabric v2.0.0-beta
- 16d8436 Update byfn download command
- 6de9dc2 Change 'node' language to 'javascript'
- 7cd1eda Add release notes for v2.0.0-beta
- 5deab9a Merge pull request #399 from pamandrejko/FAB-14083
- 402a077 [FAB-17199] Add new test network tutorial
- 2420fa5 Merge branch 'master' into FAB-14083
- 1432b66 [FAB-14083] Chaincode as an external service documentation
- f93acfa [FAB-17239] What's new links 2.0 beta
- c37f8cf [FAB-17240] Small fix to upgrade doc
v1.4.4
v1.4.4 Release Notes - November 14, 2019
What's New in Hyperledger Fabric v1.4.4
The following enhancements are included in this release:
-
FAB-16715, FAB-16544: Orderer endpoint override
Ordering networks whose addresses or TLS root certificates change will cause problems for new
peers joining channels because the channel genesis block will contain the outdated orderer
information. A new configuration option for orderer endpoint overrides allows administrators
to configure peers to translate old orderer addresses and certificates to the updated
orderer addresses and certificate pools. -
FAB-17000: Provide notification to users if certs are about to expire
Peers and orderers now log a warning to the log a week before the enrollment certificate or
TLS certificate expire. Example log entries:[certmonitor] trackCertExpiration -> WARN 011 The server TLS certificate expires within one week
[certmonitor] trackCertExpiration -> WARN 011 The enrollment certificate expires within 2 days and 5 hours
-
FAB-15814: Add operations endpoint to expose peer/orderer version
Adds a /version endpoint to the operations server that serves peer/orderer metadata
including Version number and CommitSHA. -
FAB-16852 Bump to Go v1.12.12 and baseimage 0.4.18
-
FABB-128 Bump node.js to 8.16.1 and npm to 6.11.3 in 0.4.18 baseimage
Fixes
-
FAB-13552: Re-addition of a removed OSN in a channel - Prior to the fix, if a Raft orderer was
removed from the consenter set in the channel configuration, it would not check to see if was added
back and a reboot was required. -
FAB-15026: Segmentation violation in peer chaincode install - Prior to the fix, the tar processing
during chaincode package install could trigger a panic while looking up user info when run with
certain versions of libc. The calls to libc are no longer made. -
FAB-15389: Endorsing peer is not honoring maxPeerCount for private data dissemination - Prior
to the fix, there was a chance that peers chosen for private data dissemination at endorsement time
could potentially be counted twice towards maxPeerCount, leading to disseminating private data to
fewer peers than expected. -
FAB-15666: NetworkMode does not get passed to chaincode image build
Prior to the fix, the peer's configured docker NetworkMode was not getting passed
upon chaincode image build. -
FAB-16571: Fix panic in peer chaincode package command - Prior to the fix, the peer
chaincode package command could panic when traversing the chaincode location. -
FAB-16610: Commit block to ledger hang when chaincode crash - Prior to the fix, if a chaincode
terminated abnormally during an invocation, a lock would prevent blocks from committing until the
execution timeout (core.chaincode.executetimeout property) was triggered. The fix ensures that the
lock is released immediately on exit. -
FAB-16643: Nil pointer during reconciliation of deleted private data - Prior to the fix,
if a peer is trying to reconcile missing private data, and the private data key has since been
deleted, the peer will panic with a nil pointer exception. -
FAB-16651: Fix connection leak if certificates renewed - Prior to the fix, peers that have changed
their enrollment certificate without changing their endpoint caused connections to leak over time. -
FAB-16695: Separate listeners causes panic - Prior to the fix, configuring separate
listeners for the peer admin service or for the orderer cluster service would cause a
panic on startup if Prometheus metrics were enabled. -
FAB-16948: Nil pointer exception in CID GetID() when using Idemix - GetID now returns an error
when invoked on a chaincode request from an Idemix identity.
Changes, Known Issues, and Workarounds
- FAB-12134: Same chaincode source receiving fingerprint mismatch error -
Chaincode installed in different ways may result in "chaincode fingerprint
mismatch data mismatch" error upon instantiation. This may happen when
installing chaincode by using different SDKs. To workaround the problem,
package the chaincode prior to installation and instantiation, by using
the "peer chaincode package" command.
Known Vulnerabilities
- FAB-8664: Peer should detect and react when its org has been removed
This is a relatively low severity problem, because it requires a significant
conspiracy of network admins, but it will be addressed in a future release.
Resolved Vulnerabilities
None.
Deprecations
The following functions are deprecated and are targeted for removal in a future release.
-
Support for automatically vendoring the chaincode shim into user chaincodes.
The fabric-ccenv image which is used to build chaincode, currently includes
the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package.
This is convenient, as it provides the ability to package chaincode
without the need to include the "shim". However, this may cause issues in future
releases (and/or when trying to use packages which are included by the "shim").
In order to avoid any issues, users are advised to manually vendor the "shim"
package with their chaincode prior to using the peer CLI for packaging and/or
for installing chaincode.
For more details see FAB-5177. -
Support for CAR chaincode package format
Support for packaging chaincode using the CAR format will be removed in
a future release.
For more details see FAB-14720. -
Support for specifying orderer endpoints at the global level in channel configuration.
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of
an organization instead.
For more details see FAB-7559. -
Support for invoking system chaincodes from user chaincodes.
System chaincodes, for example QSCC, are intended to be invoked by
a client rather than by a user chaincode. Invoking from a user chaincode
may cause deadlocks.
For more details see FAB-15285. -
Support for user chaincodes to utilize the chaincode shim's logger via NewLogger().
Chaincodes that used the shim's NewLogger() will need to shift to their own preferred
logging mechanism.
For more details see FAB-15366. -
Support for peer's Admin service.
The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec().
Instead of using these services, utilize the HTTP operations service that was
introduced in v1.4.0.
For more details see FAB-15390. -
Support for Solo ordering service.
With the introduction of Raft-based ordering service in v1.4.1, it is possible
to deploy a single-node (non-production) or multi-node
Raft-based ordering service with no external dependencies.
For single-node (non-production) ordering services, utilize Raft-based ordering
service with a single node instead of Solo ordering service.
For more details see FAB-15754.
Change log
For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v144
v1.4.3 Release Notes - August 26, 2019
-------------------------------------- What's New in Hyperledger Fabric v1.4.3 --------------------------------------- The following features are included in this release: FAB-15388: Node OU certificate support for admin identities. FAB-12620: Node OU certificate support for orderer nodes. Node OUs are now supported for admin and orderer identity classifications (extending the existing Node OU support for clients and peers). These "organizational units" allow organizations to further classify identities into admins and orderers based on the OUs specified in their x509 certificates. This feature requires v1.4.3 'channel' capability to be enabled so that all orderer and peer nodes identify administrators consistently. Peers need to be updated to version v1.4.3 before channel administrators update a channel to v1.4.3 channel capability. Organizations that wish to take advantage of the new capability will need to update their MSP information in the channel configuration. For more details see: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification Important Fixes --------------- FAB-16292 Fix nil pointer exception upon gossip peer expiration There was an issue introduced in v1.4.2 where peers participating in channels with gossip enabled may crash with a nil pointer exception, if another known peer goes down for several minutes (when using default aliveExpirationTimeout peer configuration of 25 seconds). To work around the problem on v1.4.2, automatically restart the peer process if it goes down, or configure a large value for aliveExpirationTimeout (peer environment variable CORE_PEER_GOSSIP_ALIVEEXPIRATIONTIMEOUT) to completely avoid the problem until peer can be upgraded to v1.4.3. FAB-16114 - v1.4.2 private data application capability enablement requires peer restart Prior to the fix, enablement of the v1.4.2 application capability required a peer restart to become effective. Since the v1.4.2 application capability changes how peers disseminate private data for invalid transactions, peers that have not been restarted after the application capability has been updated on the channel may not disseminate the data to peers that are attempting to pull the private data upon block commit. The pulling peers may therefore get stalled while pulling private data. The remedy on v1.4.2 requires restarting any peer that participates in private data dissemination, after v1.4.2 application capability has been enabled on a channel. Starting in v1.4.3, the application channel capability becomes effective upon processing the configuration block update, without requiring a peer restart. FAB-16327 Fix service discovery with orderer endpoints configured at organization level v1.4.2 introduced orderer endpoint configuration at the organization level ('OrdererEndpoints' stanza). Prior to the fix, if orderer endpoints are configured only at the new organization level, and not at the global 'Orderer.Addresses' level, then service discovery is not able return the channel configuration with the orderer endpoints. With the v1.4.3 fix, service discovery functions correctly even if orderer endpoints are configured only at the organization level. FAB-16089 Use latest npm version of ccenv image In the ccenv image that is used to build node.js chaincode, npm is updated to the latest version. This resolves issues from prior npm versions, such as the ability to include 'prepare' statements in node.js chaincode package.json. Changes, Known Issues, and Workarounds -------------------------------------- FAB-12088 - Java chaincode support on s390x architecture Java chaincode support is not available on s390x architecture. FAB-12134 - Same chaincode source receiving fingerprint mismatch error Chaincode installed in different ways may result in "chaincode fingerprint mismatch data mismatch" error upon instantiation. This may happen when installing chaincode by using different SDKs. To workaround the problem, package the chaincode prior to installation and instantiation, by using the "peer chaincode package" command. Known Vulnerabilities --------------------- FAB-8664 - Peer should detect and react when its org has been removed This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in a future release. Resolved Vulnerabilities ------------------------ None. Deprecations ------------ The following functions are deprecated and are targeted for removal in a future release. Support for automatically vendoring the chaincode shim into user chaincodes. The fabric-ccenv image which is used to build chaincode, currently includes the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package. This is convenient, as it provides the ability to package chaincode without the need to include the "shim". However, this may cause issues in future releases (and/or when trying to use packages which are included by the "shim"). In order to avoid any issues, users are advised to manually vendor the "shim" package with their chaincode prior to using the peer CLI for packaging and/or for installing chaincode. For more details see FAB-5177. Support for CAR chaincode package format Support for packaging chaincode using the CAR format will be removed in a future release. For more details see FAB-14720. Support for specifying orderer endpoints at the global level in channel configuration. Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead. For more details see FAB-7559. Support for invoking system chaincodes from user chaincodes. System chaincodes, for example QSCC, are intended to be invoked by a client rather than by a user chaincode. Invoking from a user chaincode may cause deadlocks. For more details see FAB-15285. Support for user chaincodes to utilize the chaincode shim's logger via NewLogger(). Chaincodes that used the shim's NewLogger() will need to shift to their own preferred logging mechanism. For more details see FAB-15366. Support for peer's Admin service. The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec(). Instead of using these services, utilize the HTTP operations service that was introduced in v1.4.0. For more details see FAB-15390. Support for Solo ordering service. With the introduction of Raft-based ordering service in v1.4.1, it is possible to deploy a single-node (non-production) or multi-node Raft-based ordering service with no external dependencies. For single-node (non-production) ordering services, utilize Raft-based ordering service with a single node instead of Solo ordering service. For more details see FAB-15754. For the full list of improvements and fixes, refer to the release change log: https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v143
v1.4.2 Release Notes - July 17, 2019
------------------------------------ What's New in Hyperledger Fabric v1.4.2 --------------------------------------- The following features are included in this release: FAB-15041 - Kafka to Raft Consensus Migration A Kafka-based ordering service can now be migrated to utilize Raft consensus. For details see the documentation at https://hyperledger-fabric.readthedocs.io/en/latest/kafka_raft_migration.html. This feature requires v1.4.2 'orderer' and 'channel' capabilities to be enabled. FAB-14307 Channel rollback on a peer The new 'peer node rollback' command provides administrative ability to rollback a channel's ledger on a peer to a prior block height in the case a peer's channel data gets into a corrupt state at a later block height. The peer will re-retrieve the rolled back blocks from ordering service or another peer upon the next peer start. Note that during the rollback, the ledger's private data will be preserved, since it cannot be obtained from ordering service at a later time, and may not be available from other peers. Similarly, the command 'peer node reset' command can be used to rollback all of a peer's channel ledgers to the genesis block of each channel. Both commands must be issued from the peer's CLI while the peer process is down. It is recommended to enable v1.4.2 'application' capability to ensure that all private data is stored on the local peer (including for invalidated transactions), in case rollback and reprocessing is required on a peer. FAB-7559 - Ability to specify orderer endpoints at the organization level Starting from version v1.4.2, it is possible and highly recommended to define orderer endpoints at the organization level (new 'OrdererEndpoints' stanza within the channel configuration of an organization) and not at the global 'Orderer.Addresses' section of channel configuration. If at least one organization has an ordering service endpoint defined at an organizational level, all orderers and peers will ignore the channel level endpoints when connecting to ordering nodes. Utilizing organization level orderer endpoints is required when using service discovery with orderer nodes provided by multiple organizations, so that clients can provide the correct organization TLS certificates. This feature requires v1.4.2 'channel' capability to be enabled. Important Fixes --------------- FAB-15450 - History database queries do not return all results Prior to the fix, history database queries excluded transactions from blocks that were multiples of 256 (block 256, 512, 768, etc). FAB-15411 - GetTransactionByID does not return configuration transactions Prior to the fix, GetTransactionByID and GetBlockByTxID did not return configuration transactions, since these transactions were not indexed correctly. To fix indexes for pre-existing configuration transactions on a peer's channel ledgers, stop the peer and delete the index directory, e.g. /var/hyperledger/production/ledgersData/chains/index directory. The peer will rebuild the indexes correctly upon the next restart. FAB-15404 - Orderer Kafka TLS Issue Prior to the fix, orderer nodes could not communicate to kafka if TLS is enabled. FAB-15144 - Assorted orderer serviceability fixes Changes, Known Issues, and Workarounds -------------------------------------- FAB-15031 - ledger.blockstorage_commit_time metric is available on orderer nodes ledger.blockstorage_commit_time is now available on both peer and orderer nodes, but only includes block storage commit time. A new metric, ledger_blockstorage_and_pvtdata_commit_time, is available on peer nodes and includes the total commit time for blockstorage and pvtdata. FAB-15549 - Restrict service discovery endorsement computation If the endorsement policy contains an NoutOf that yields too many combinations (such as - 13 out of 25), service discovery will not return all possible combinations to the application (as that number can be huge), but instead will return a random subset of endorsement combinations. FAB-12088 - Java chaincode support on s390x architecture Java chaincode support is not available on s390x architecture. FAB-12134 - Same chaincode source receiving fingerprint mismatch error Chaincode installed in different ways may result in "chaincode fingerprint mismatch data mismatch" error upon instantiation. This may happen when installing chaincode by using different SDKs. To workaround the problem, package the chaincode prior to installation and instantiation, by using the "peer chaincode package" command. Known Vulnerabilities --------------------- FAB-8664 - Peer should detect and react when its org has been removed This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in a future release. Resolved Vulnerabilities ------------------------ None. Deprecations ------------ The following functions are deprecated and are targeted for removal in a future release. Support for automatically vendoring the chaincode shim into user chaincodes. The fabric-ccenv image which is used to build chaincode, currently includes the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package. This is convenient, as it provides the ability to package chaincode without the need to include the "shim". However, this may cause issues in future releases (and/or when trying to use packages which are included by the "shim"). In order to avoid any issues, users are advised to manually vendor the "shim" package with their chaincode prior to using the peer CLI for packaging and/or for installing chaincode. For more details see FAB-5177. Support for CAR chaincode package format Support for packaging chaincode using the CAR format will be removed in a future release. For more details see FAB-14720. Support for specifying orderer endpoints at the global level in channel configuration. Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead. For more details see FAB-7559. Support for invoking system chaincodes from user chaincodes. System chaincodes, for example QSCC, are intended to be invoked by a client rather than by a user chaincode. Invoking from a user chaincode may cause deadlocks. For more details see FAB-15285. Support for user chaincodes to utilize the chaincode shim's logger via NewLogger(). Chaincodes that used the shim's NewLogger() will need to shift to their own preferred logging mechanism. For more details see FAB-15366. Support for peer's Admin service. The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec(). Instead of using these services, utilize the HTTP operations service that was introduced in v1.4.0. For more details see FAB-15390. Support for Solo ordering service. With the introduction of Raft-based ordering service in v1.4.1, it is possible to deploy a single-node (non-production) or multi-node Raft-based ordering service with no external dependencies. For single-node (non-production) ordering services, utilize Raft-based ordering service with a single node instead of Solo ordering service. For more details see FAB-15754. For the full list of improvements and fixes, refer to the release change log: https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v142
v1.4.1 Release Notes - April 11, 2019
------------------------------------- What's New in Hyperledger Fabric v1.4.1 --------------------------------------- The following features are included in this release: FAB-6135 - Raft Consensus The ordering service now provides an option to use the Raft Consensus algorithm. See https://raft.github.io/ for details on the Raft algorithm. Additional operational metrics and health checks FAB-13088 Endorser metrics FAB-14077 Orderer communication metrics FAB-11937 Raft metrics FAB-13237 Metrics for log records FAB-13341 Kafka health check FAB-12908 CouchDB health check Changes, Known Issues, and Workarounds -------------------------------------- FAB-14723 - Deprecate CAR package format Support for packaging chaincode using the CAR format will be removed in v2.0.0. FAB-12088 - Java chaincode support on s390x architecture Java chaincode support is not yet available on s390x architecture. FAB-12134 - Same chaincode source receiving fingerprint mismatch error Chaincode installed in different ways may result in "chaincode fingerprint mismatch data mismatch" error upon instantiation. This may happen when installing chaincode by using different SDKs. To workaround the problem, package the chaincode prior to installation and instantiation, by using the "peer chaincode package" command. Known Vulnerabilities --------------------- FAB-8664 - Peer should detect and react when its org has been removed This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in a future release. Resolved Vulnerabilities ------------------------ None. Other noteworthy improvements and fixes --------------------------------------- FAB-14420 - Allow statically configured CAs for TLS communication with orderers FAB-13471 - Fix for multiple chaincode upgrades in a single block FAB-14687 - Fix memory leak in gossip message store Updated to Go version 1.11.5 Updated baseimage version to 0.4.15 For the full list of improvements and fixes, refer to the release change log: https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v141
v2.0.0-alpha Release Notes - April 9, 2019
------------------------------------------ What's New in Hyperledger Fabric v2.0 ------------------------------------- The following major features are included in the v2.0.0 Alpha release: FAB-11237 - Improved chaincode lifecycle The Fabric 2.0 Alpha introduces decentralized governance for chaincode, with a new process for installing a chaincode on your peers and starting it on a channel. The new Fabric chaincode lifecycle allows multiple organizations to come to agreement on the parameters of a chaincode, such as the chaincode endorsement policy, before it can be used to interact with the ledger. FAB-11144 - Native token support The Fabric 2.0 Alpha provides users the ability to easily represent assets as tokens on Fabric channels. FabToken is a token management system that uses an Unspent Transaction Output (UTXO) model to issue, transfer, and redeem tokens using the identity and membership infrastructure provided by Hyperledger Fabric. A new 'token' command line interface is included as a way to drive token transactions without an application. FAB-6135 - Raft Consensus Introduced in v1.4.1 and v2.0.0 Alpha, the ordering service now provides an option to use the Raft Consensus algorithm. Raft is a crash fault tolerant (CFT) ordering service based on an implementation of Raft protocol in etcd. FAB-11096 - Docker images with Alpine Linux Hyperledger Fabric Docker images will now use Alpine Linux, a security-oriented, lightweight Linux distribution. New operational metrics and health checks FAB-13088 Endorser metrics FAB-14077 Orderer communication metrics FAB-11937 Raft metrics FAB-13237 Metrics for log records FAB-12727 Gossip metrics FAB-13341 Kafka health check FAB-12908 CouchDB health check Changes, Known Issues, and Workarounds -------------------------------------- FAB-11237 - Improved chaincode lifecycle The new Fabric chaincode lifecycle in the v2.0.0 Alpha release is not yet feature complete. Specifically, be aware of the following limitations in the Alpha release: - CouchDB indexes are not yet supported - Chaincodes defined with the new lifecycle are not yet discoverable via service discovery These limitations will be resolved after the Alpha release. FAB-11096 - Docker images with Alpine Linux Bash is no longer available in Fabric images. Utilize Alpine's built-in sh or ash instead. FAB-12075 - Duplicate Go Client identity library removed If vendoring the Client identity library (CID) in chaincode, import github.com/hyperledger/fabric/core/chaincode/shim/ext/cid rather than github.com/hyperledger/fabriccore/chaincode/lib/cid/cid.go FAB-12088 - Java chaincode support on s390x architecture Java chaincode support is not yet available on s390x architecture. FAB-12134 Same chaincode source receiving fingerprint mismatch error Chaincode installed in different ways may result in "chaincode fingerprint mismatch data mismatch" error upon instantiation. This may happen when installing chaincode by using different SDKs. To workaround the problem, package the chaincode prior to installation and instantiation, by using the "peer chaincode package" command. Known Vulnerabilities --------------------- FAB-8664 - Peer should detect and react when its org has been removed This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in a future release. Resolved Vulnerabilities ------------------------ None. Other improvements and fixes ---------------------------- FAB-13471 - Fix for multiple chaincode upgrades in a single block FAB-14687 - Fix memory leak in gossip message store Updated to Go version 1.11.5 Updated baseimage version to 0.4.15 for third party dependencies. For the full list of improvements and fixes, refer to the release change log: https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v200-alpha
v1.4.0 Release Notes - January 9, 2019
-------------------------------------- What's New in Hyperledger Fabric v1.4 ------------------------------------- The following features are included in this release: Fabric operations service A new HTTP based "operations" endpoint has been implemented on the orderer and the peer. The endpoint exposes APIs to check the server's health, to query and modify the logging level of the process, and, when configured, to expose Fabric metrics. FAB-3388 - Operational metrics for Fabric components The peer and orderer have been instrumented to provide basic operational metrics. The metrics can be surfaced for consumption by Prometheus or StatsD. FAB-10851 - Health check endpoint The orderer and the peer now provide a mechanism to check the health of the process via an HTTP request. Requests to GET /healthz on the operations endpoint will complete with a status 200 OK when the server believes it is healthy. When a health check fails, the server will respond with a 503 Service Unavailable and a JSON payload indicating which component detected an issue. The types of health checks that are performed will be extended over time. FAB-12265 - Dynamic log levels The orderer and the peer now provide a mechanism to get and update the active logging specification of the server. Requests to GET /logspec on the operations endpoint will return with a JSON payload that contains the active spec. When a JSON payload of `{"spec":"the-log-spec"}` is sent as the body of a PUT /logspec request, the active logging spec will be updated. FAB-12357 - Updates to logging In earlier versions of Fabric, loggers were associated with named components and configuration would control the active level of each logger. While this model works in theory, because of the configuration management libraries used by Fabric and the structure of the Fabric code base, in practice it had a number of issues. With 1.4, we're changing the model slightly. Instead of associating loggers with components, we are naming loggers and to help avoid side effects during initialization, the logging configuration is no longer obtained from the fabric configuration system but from environment variables that define the logging specification and log format. The log specification is a single string that consists of colon separated tokens. Each token declares one or more logger name prefixes (separated by commas) and an optional log level. When the logger name prefix ends with a period, it indicates that the log level should only apply to the logger with that exact name without the trailing period. When the logger name pattern is omitted, it specifies the default log level. In cases where multiple entries reference the same name pattern or multiple instances of a default are provided, the last specification takes precedence. FAB-12363 - Logging for gRPC interactions The orderer and the peer now provide logging (INFO level) for each gRPC interaction completed. FAB-12372 - Obtain Go routine stacks without termination When SIGUSR1 is received by the peer or the orderer, the state of all go routines will be captured and logged at the INFO level. This collection activity will not terminate the process. FAB-5093 - Private data reconciliation Allows peers for organizations that are added to private data collections to retrieve the private data for prior transactions to which they now are entitled. This feature is only supported on peers that have joined a channel since v1.4. FAB-11409 - Private data client access control Ability to automatically enforce access control within chaincode based on the client organization collection membership without having to write specific chaincode logic. This feature is configured by using the collection configuration property memberOnlyRead:true. If you have a mixed network of v1.4 peers and prior release peers, the prior release peers will not honor this configuration until they are upgraded to v1.4. Changes, Known Issues, and Workarounds -------------------------------------- FAB-12357 - Updates to logging Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC environment variable to acquire the initial logging specification for the server. Existing logging configuration should be converted to the new model. FAB-12489 - peer logging command updates The `getlevel`, `setlevel`, and `revertlevels` subcommands of the `peer logging` command are deprecated and users should migrate to the operations server. The behavior of `setlevel` has also changed slightly. The previous implementation would treat the `logger` argument as a regular expression and apply the new log level to all loggers that matched the expression. The updated implementation treats the `logger` argument as a logger name and appends it to the active logging spec at the indicated level. FAB-12088 - Java chaincode support on s390 architecture Java chaincode support is not yet available on s390 architecture. FAB-12134 Same chaincode source receiving fingerprint mismatch error Chaincode installed in different ways may result in "chaincode fingerprint mismatch data mismatch" error upon instantiation. This may happen when installing chaincode by using different SDKs. To workaround the problem, package the chaincode prior to installation and instantiation, by using the "peer chaincode package" command. Known Vulnerabilities --------------------- FAB-8664 - Peer should detect and react when its org has been removed This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in a future release. Resolved Vulnerabilities ------------------------ None. Other improvements and fixes ---------------------------- Updated to Go version 1.11.1 Updated baseimage version to 0.4.14 For the full list of improvements and fixes, refer to the release change log: https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v140
v1.3.0 Release Notes - October 10, 2018
--------------------------------------- What's New in Hyperledger Fabric v1.3 ------------------------------------- The following features/epics are included in this release: FAB-10120 - Identity Mixer for anonymous transactions Keep client identities anonymous and unlinkable through the use of zero-knowledge proofs. FAB-8812 - State-based endorsement Allows the default chaincode-level endorsement policy to be overridden by a per-key endorsement policy. FAB-2809 - Chaincode pagination of query results Clients can now page through result sets from chaincode queries, making it feasible to support large result sets with high performance. FAB-8779 - Java chaincode support As an addition to the current Fabric support for chaincode written in Go and Node.js, Java is now supported. Changes, Known Issues, and Workarounds -------------------------------------- FAB-11122 - Removal of event hub The 'old' event hub has been removed in Hyperledger Fabric v1.3. It is replaced by the peer channel-based event service which was introduced in Fabric v1.1. Applications using the old event hub must switch over to the new channel-based event service before upgrading to v1.3 peer or SDKs. FAB-12088 - Java chaincode support on s390 architecture Java chaincode support is not yet available on s390 architecture. FAB-12134 Same chaincode source receiving fingerprint mismatch error Chaincode installed in different ways may result in "chaincode fingerprint mismatch data mismatch" error upon instantiation. This may happen when installing chaincode by using different SDKs. To workaround the problem, package the chaincode prior to installation and instantiation, by using the "peer chaincode package" command. Known Vulnerabilities --------------------- FAB-8664 - Peer should detect and react when its org has been removed This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in a future release. Resolved Vulnerabilities ------------------------ None. Other improvements and fixes ---------------------------- Updated to Go version 1.10.4 Updated baseimage version to 0.4.13 For the full list of improvements and fixes, refer to the release change log: https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v130
v1.2.1 September 27, 2018
------------------------ Release Notes ------------- Bug fixes, documentation and test coverage improvements, UX improvements based on user feedback and changes to address a variety of static scan findings (unused code, static security scanning, spelling, linting and more). Known Vulnerabilities --------------------- FAB-8664 - Peer does not detect his own org ejection This is a relatively low severity problem, because it requires a significant conspiracy of network admins, but it will be addressed in an upcoming release. Resolved Vulnerabilities ------------------------ FAB-11094 - Fix deadlock in block iterator Fixes possible ledger deadlock condition when using the channel event service. FAB-10390 - Set PKCS11 CKA_MODIFIABLE to false More secure default value when generating private keys when using PKCS#11. FAB-10391 - Set CKA_EXTRACTABLE to false More secure default value when generating private keys when using PKCS#11. Known Issues & Workarounds -------------------------- none Change Log ---------- https://github.com/hyperledger/fabric/blob/release-1.2/CHANGELOG.md#v121