fabric 标签 - Gitee.com

v2.2.2

bebb75f

2021-01-28 07:06

下载

v1.4.10

7d1ee82

2021-01-28 07:22

下载

v2.3.0

ec81f3e

2020-11-19 03:19

下载

v1.4.9

da55272

2020-10-01 02:02

下载

v2.2.1

344fda6

2020-10-01 01:50

下载

v1.4.8

29e1e77

2020-07-22 23:24

下载

v2.2.0

5ea85bc

2020-07-09 20:25

下载

v2.1.1

6393adb

2020-06-01 19:52

下载

v1.4.7

e0afaa7

2020-05-15 01:05

下载

v2.1.0

1bdf975

2020-04-16 04:16

下载

v2.0.1

1cfa5da

2020-02-27 03:20

下载

v1.4.6

635fa7b

2020-02-25 18:15

下载

v1.4.5

11ff991

2020-02-20 03:47

下载

v2.0.0

0432c3e

2020-01-30 06:00

下载

v2.0.0-beta

242b1e3

2019-12-13 03:14

下载

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

7917a40

2019-11-13 20:45

下载

v1.4.3

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

b8c4a6a

2019-08-27 03:07

下载

v1.4.2

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.