26 Feb 22:12

lindluni

1cfa5da

v2.0.1

v2.0.1 Release Notes - February 26, 2020

Fixes

FAB-17458: Rolling upgrade: Different endorsement results on v1.4.x and v2.0.0 peers

In a rolling upgrade scenario where V2_0 channel application capability is not yet set,
and proposals are sent to v1.4.x peers and v2.0.0 peers,
the endorsed read sets did not exactly match in the proposal response between
the v1.4.x peers and v2.0.0 peers. A client would therefore have to get
endorsements from only v1.4.x peers, or only from v2.0.0 peers, making it difficult
to get sufficient number of matching endorsements to meet the endorsement policy.
If a transaction is submitted with insufficient matching endorsements, the
transaction will be invalidated at commit time with error message
"marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]".
The proposal response is fixed in v2.0.1 so that the read sets will exactly
match read sets on v1.4.x peers, enabling transactions to be endorsed across
peers of different versions.

FAB-17479: Migrated Kafka cluster can be safely expanded later

When a new ordering service node was added to a migrated Kafka cluster,
but was not added to all channels, the ordering service node would crash.
The fix ensures that new ordering nodes can be added to a subset of channels.

FAB-17453: 'peer lifecycle chaincode package' required an MSP configured

'peer lifecycle chaincode package' is for local packaging of chaincode only,
and therefore no longer requires a MSP to be configured.

FAB-17059: Change collection membership eligibility checks to only compare mspID

When a new CA root cert was added to an organization in the channel configuration,
new peers with an identity from the new CA would not receive private data for
blocks prior to the channel configuration change. This is because the peer didn't
realize it was a member of the private data collection, even though it was
based on the collection's mspid. The fix ensures that the peer evaluates
private data collection membership based on its mspid. The fix is important
when rotating CA root or intermediate certs, for example in a side-by-side
migration scenario that uses new CA certs and new peers.

FAB-17519: Improve Discovery endorsement policy performance

Fix peer CPU spikes during evaluation of endorsement policy
combinations, due to expensive reflection.

FAB-17523: Endorsing peer was not honoring private data RequiredPeerCount

If there were not enough known eligible peers to meet the private data collection RequiredPeerCount
dissemination requirement, endorsement was succeeding rather than returning an error.

[FAB-17491] Do not disseminate private data for other organization's implicit collection

When using the new implicit private data collections in v2.0.0, in some use cases
private data needs to be written to each of multiple organization's implicit
private data collections in the same transaction. In these cases the endorsing peers were
disseminating the private data to each of the respective organization's peers.
Although not a security problem (each organization is authorized to receive its
own implicit collection private data), dissemination should be managed by the endorsing
peers of the implicit collection organization only. This fix ensures that only peers
of the implicit collection organization disseminate the private data to their own
organization's other peers.

[FAB-17515] Support configuring BlockValidation policy for orderer group

Prior to the fix, a configured BlockValidation policy (e.g. defined in configtx.yaml)
would be ignored. The policy is now applied in the channel creation transaction, and
must be specified.

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 changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-2.0/CHANGELOG.md#v201

Changes:

1cfa5da Updates for fabric release v2.0.1
7282895 [FAB-17515] Support configuring BlockValidation policy for orderer group
618a4ce [FAB-17491] Do not disseminate pvtdata for other org's implicit collection
727327d [FAB-17523] Endorsing peer was not honoring RequiredPeerCount (#716) (#729)
371c435 Optimize inquire.IsSubset (#714)
bb46909 [FAB-17059] Extend private data integration tests to cover case when a
0885c2f [FAB-17059] Change collection membership eligibility checks to
f4e4a95 [FAB-17472] Clarify doc and samples for NodeOU Certificate
c742dd6 [FAB-17453] 'peer lifecycle chaincode package' mandates does not need to init crypto
4665ec5 [FAB-17479] Migrated Kafka cluster can be safely expanded later (#645)

See More

61f5706 [FAB-14679] Update commercial paper tutorial for new
c63e674 Explicitly enumerate orderer and peer metrics
2daa2b0 Add link to policies topic to chaincode for operators (#659) (#660)
dc8071c Update Copyright for 2020
f8b21b1 fix typo
4961395 Fix typo in package error message
993b7a0 [FAB-17458] check LifecycleV20 capability before getting cc info (#608)
7a1d517 Remove 1.x video from 2.0 docs
5bf6583 Remove Fabric functionalities doc
361edb6 [FAB-17267] Move add an org to a channel tutorial to test network
b96f178 [FAB-17381] Update policy concept for test network
c987e77 Update branch to dynamic variable
5fe6530 Add support for placeholder replacement in doc builds
13d12e5 [FABCN-378] Update links to chaincode JSDoc
721a6e7 Remove link for node SDK tutorial
913d770 [FAB-17424] Fix broken link in DevApps connection profile
a521d2a Fix conditional_packages processing in UT script
0432c3e Add changelog for v2.0.0
77ff3d2 Install doc and script updates for v2.0.0
324d2d1 Add release notes for v2.0.0
5eec23d What's New updates for v2.0.0 release
7f772f9 Add Core Maintainers to /docs in CODEOWNERS
63228ea Revert "FAB-14693 Vendor updated fabric-amcl package"
a04d430 [FAB-17439] Add integration test for verifying fabric-chaincode-go
ac2f490 [FAB-17421] Reword links to contract APIs and documentation
94eeecf Enable service discovery querying _lifecycle endorsers
3777652 Validate label when packaging _lifecycle chaincode
419690a [FAB-17431] Use two digit version for chaincode images
d25d2a5 Create a new Documentation Maintainers sub-group
e7fb9c7 [FAB-17303] Set RequiredPeerCount and MaxPeerCount defaults for implicit
9bd0a95 [FAB-17439] Expose peer's MSPID to chaincode as an env var (#549)
be23695 Bump fabric-chaincode-go (#564)
666a5b7 FAB-17410 Updated doc links to latest levels
2777611 [FAB-17428] Deprecate --outputAnchorPeersUpdate flag in configtxgen
ded1729 Updating chaincode document.
da131ec Stop _lifecycle ccs that are no longer referenced
5c6bdda No need to explicitly deregister handler from registry
0f18fc9 FAB-16033 Update channel_artifacts location in doc.
0da8233 Update resources in enable _lifecycle doc
5131473 Update _lifecycle resources in configtx.yaml
868da99 Improve chaincode lifecycle peer log messages (#530)
dbac8a5 Add disclaimer for commercial paper tutorial
f94d3b1 Remove references to instantiating a chaincode
5cadc61 [FAB-17411] Update Fabric versions where necessary
8556a43...

Assets 5

25 Feb 21:00

lindluni

v1.4.6

635fa7b

v1.4.6

v1.4.6 Release Notes - February 25, 2020

Fixes

FAB-17519: Improve Discovery endorsement policy performance

Fix peer CPU spikes during evaluation of endorsement policy
combinations, due to expensive reflection.
Fix nil dereference in etcdraft config parsing

The etcdraft config parsing code was failing to check that the consensus
metadata options are not nil.
FAB-17523: Endorsing peer was not honoring private data RequiredPeerCount

In Fabric v1.4.4 and v1.4.5, if there were not enough known eligible
peers to meet the private data collection RequiredPeerCount dissemination
requirement, endorsement was succeeding rather than returning an error.

FAB-17431: Decouple javaenv version from Fabric version

By default Fabric peer core.yaml was configured to use the following javaenv
image for java chaincode:

runtime: $(DOCKER_NS)/fabric-javaenv:$(ARCH)-$(PROJECT_VERSION)

Since javaenv versioning may deviate from Fabric versioning,
the javaenv reference is updated to use the latest two digit version:

runtime: $(DOCKER_NS)/fabric-javaenv:$(TWO_DIGIT_VERSION)

For example, Fabric v1.4.6 would utilize fabric-javaenv:1.4.

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#v146

Changes:

635fa7b Update release notes for v1.4.6
af2b462 Release fabric v1.4.6
87df051 [FAB-17515] Support configuring BlockValidation policy for orderer group
29c58ac [FAB-17431] Decouple javaenv from Fabric version
ac6305e [FAB-17523] Endorsing peer was not honoring RequiredPeerCount (#716) (#733)
0c421c8 Fix nil dereference in etcdraft config parsing (#724)
9072299 Add ending braces to ReadWrite set.
a0b7584 Optimize inquire.IsSubset (#713)
60c8ab9 Prepare for next fabric rel v1.4.6

This list of changes was auto generated.

Assets 5

19 Feb 21:26

lindluni

v1.4.5

11ff991

v1.4.5

v1.4.5 Release Notes - February 19, 2020

What's New in Hyperledger Fabric v1.4.5

The following enhancements are included in this release:

FAB-15648: Allow separate TLS config for Raft cluster and client

When intra-cluster Raft communication is configured to use separate
listener, allow TLS to be disabled for the client-facing listener,
and assume TLS is always enabled for the cluster listener.

Fixes

FAB-17261: Add HostConfig to chaincode image builder

Prior to the fix, the Docker HostConfig configured in peer was only used
when creating a chaincode container. The configured Docker HostConfig is
now used when building a chaincode image and when creating a chaincode container.
FAB-17220: Dynamically build TLS config in Raft client handshake

This fix ensures that the latest TLS CA certificates are used by Raft ordering
service nodes when certificates are updated in the channel config.
FAB-17289: Fix gossip goroutine memory leak when reading msg

A peer gossip memory leak observed in stress tests is fixed.
FAB-17327: Static leader should not give up retrieving blocks

When a peer is configured as a static org leader for gossip, it will
not give up on retrieving blocks in the event that the ordering
service goes down for an extended period of time (i.e. longer than the
peer.deliveryclient.reconnectTotalTimeThreshold). Prior to the fix,
the peer had to be restarted before it would retrieve blocks again.
FAB-17277: Fix too many TCP connections between peer and CouchDB

The peer created a large number of TCP connections to CouchDB because the
default reusable connection pool size is 2 per host while the max pool size
is 100 (combining all hosts). Thus only 2 TCP connections could be reused
by the peer when it accessed CouchDB. When more than two goroutines in the
peer tried to simultaneously access CouchDB, it resulted in new non-reusable
connections (i.e., creation of new TCP connection outside the pool).
The fix sets MaxIdleConns and MaxIdleConnsPerHost to 2000. This creates 2000
TCP connections in the pool which are reused whenever the peer accesses CouchDB.
FAB-17479: Migrated Kafka cluster can be safely expanded later

When a new ordering service node was added to a migrated Kafka cluster,
but was not added to all channels, the ordering service node would crash.
The fix ensures that new ordering nodes can be added to a subset of channels.
FAB-17059: Change collection membership eligibility checks to only compare mspID

When a new CA root cert was added to an organization in the channel configuration,
new peers with an identity from the new CA would not receive private data for
blocks prior to the channel configuration change. This is because the peer didn't
realize it was a member of the private data collection, even though it was
based on the collection's mspid. The fix ensures that the peer evaluates
private data collection membership based on its mspid. The fix is important
when rotating CA root or intermediate certs, for example in a side-by-side
migration scenario that uses new CA certs and new peers.

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#v145

Changes:

11ff991 Release fabric v1.4.5 (#695)
1893808 Remove rollback code from private data store
f354c81 [FAB-17472] Clarify doc and samples for NodeOU Certificate
d45bac4 Add release notes for Fabric v1.4.5
a9a1d07 [FAB-17059] Extend private data integration tests to cover case when a
ca1ae38 [FAB-17059] Change collection membership eligibility checks to
e75bc71 [FAB-17479] Migrated Kafka cluster can be safely expanded later (#642)
5eaae3a Explicitly enumerate orderer and peer metrics
9faad9e define couchDB connection pool size
b27a7c7 [FAB-16681] Fix inconsistencies in the fabcar tutorial

See More

46daf02 [FAB-16508] Update commercial paper tutorial to match code
0a6993d Add Documentation Maintainers to CODEOWNERS file
52e5155 Point to Artifactory for chaintool downloads
1786f10 [FABCN-378] Update links to chaincode JSDoc
bc3bb1a [FAB-15578] Fix typos on the endorser metric name
975cc00 FAB-16033 Update channel_artifacts location in doc.
cae8b55 Static leader should not give up retrieving blocks
f0ea825 [FAB-17169] Add AZP Status Badge (#511)
3ad450d Go SDK link should point to 1.4 release [ #476 ]
1b6bea7 Update dead link to Go Chaincode SDK
9ec196b Add CODEOWNERS group
a8639ba Allow seperate TLS config for cluster and client (#393)
d4dca95 [FAB-17235] Fixed broken links in Chaincode for Operators release-1.4
835cae3 [FAB-15900] Add pkcs11 section to orderer.yaml
3bae50c [FAB-17289] Fix gossip goroutine leak when reading msg (#439)
24d418d [FAB-17128] Add single quote to channel name env var (#437)
f627b88 Wrong protobuf import in etcdarft
778f87b FAB-17177] Config block shouldn't verify itself in block replication
0ce6685 [FAB-17220] Dynamically build TLS config in Raft client handshake
eea42cb Increase open file limit to address Gossip flakes
3a9b5e3 Fix flaky etcdraft test by installing chaincode serially
b4b0191 Deliver can send multiple blocks when seeking newest
634e14b Attempt to fix flak...

Assets 5

29 Jan 22:21

lindluni

v2.0.0

0432c3e

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...

Assets 5

12 Dec 20:28

lindluni

v2.0.0-beta

242b1e3

v2.0.0-beta Pre-release

Pre-release

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.