|
| 1 | +v2.0.0-beta Release Notes - December 12, 2019 |
| 2 | +============================================= |
| 3 | + |
| 4 | +What's New in Hyperledger Fabric v2.0 |
| 5 | +------------------------------------- |
| 6 | + |
| 7 | +The following new major features are included in the v2.0.0 Beta release. |
| 8 | +For additional details, see the What's New documentation. |
| 9 | + |
| 10 | +**FAB-11237: Decentralized chaincode governance** |
| 11 | + |
| 12 | +Fabric 2.0 introduces decentralized governance for chaincode, with a |
| 13 | +new process for installing a chaincode on your peers and starting it on a |
| 14 | +channel. The new Fabric chaincode lifecycle allows multiple organizations to |
| 15 | +come to agreement on the parameters of a chaincode, such as the chaincode |
| 16 | +endorsement policy, before it can be used to interact with the ledger. |
| 17 | + |
| 18 | +**FAB-13584: External chaincode launcher** |
| 19 | + |
| 20 | +While chaincode is still run in a docker container by default in Fabric v2.0, |
| 21 | +the external chaincode launcher feature empowers operators to build and launch |
| 22 | +chaincode with the technology of their choice. |
| 23 | + |
| 24 | +**Private data enhancements** |
| 25 | +- **FAB-10889: Implicit org-specific collections** |
| 26 | +- **FAB-15066: Endorsement policies for collections** |
| 27 | +- **FAB-13581: memberOnlyWrite collection configuration option** |
| 28 | +- **FAB-13527: GetPrivateDataHash chaincode API** |
| 29 | +- **FAB-12043: Option to include private data in block events** |
| 30 | + |
| 31 | +The private data enhancements enable new private data application patterns. |
| 32 | + |
| 33 | +**FAB-103: State database cache for CouchDB** |
| 34 | + |
| 35 | +A new peer cache improves performance when using CouchDB state database. |
| 36 | + |
| 37 | + |
| 38 | +Fixes |
| 39 | +----- |
| 40 | +All fixes as of release v1.4.4 are also included in v2.0.0-beta. |
| 41 | + |
| 42 | +For the full list of fixes, refer to the release change log. |
| 43 | + |
| 44 | + |
| 45 | +Changes |
| 46 | +------- |
| 47 | +**FAB-11144: Removal of native token support** |
| 48 | + |
| 49 | +The native token support included in v2.0.0-alpha has been removed. |
| 50 | +An improved implementation is being evaluated for future releases. |
| 51 | + |
| 52 | +**FAB-5177: The ccenv build image no longer includes the shim** |
| 53 | + |
| 54 | +The shim package and dependencies for go chaincode are no longer included in |
| 55 | +the chaincode build environment. Chaincode packages that do not include their |
| 56 | +own dependencies will no longer successfully build on the peer. We strongly |
| 57 | +recommend that existing go chaincode be updated to vendor the |
| 58 | +github.com/hyperledger/fabric-chaincode-go/shim package and its dependencies. |
| 59 | +While there are many tools for managing vendored dependencies, we recommend |
| 60 | +moving directly to go modules and vendoring with `go mod vendor`. |
| 61 | + |
| 62 | +**FAB-15366: Logger removed from chaincode shim** |
| 63 | + |
| 64 | +Chaincode that used the shim's NewLogger() will need to shift to a new |
| 65 | +logging mechanism. Chaincode logging is intended to be the responsibility |
| 66 | +of the application developer. As such it should be handled using tools and |
| 67 | +libraries that make the most sense to the chaincode developer and the |
| 68 | +application in general. Chaincode developers can forward STDOUT and STDERR |
| 69 | +from the chaincode container to the peer container by setting |
| 70 | +`CORE_VM_DOCKER_ATTACHSTDOUT=true`. While not recommended for production, |
| 71 | +once enabled, each chaincode will receive its own logging channel and |
| 72 | +STDOUT and STDERR will be integrated in the peers log on a per-line basis. |
| 73 | +A production grade approach would be to run a log aggregation service and |
| 74 | +forward your logs to the aggregation service. |
| 75 | + |
| 76 | +**FAB-16213: The go chaincode entities extension has been removed** |
| 77 | + |
| 78 | +Chaincode implementations that used the entities extension package from an |
| 79 | +earlier version of Fabric will need to vendor a 1.x version of the package |
| 80 | +for as part of their chaincode package. |
| 81 | + |
| 82 | +**FAB-14720: Support for CAR chaincode package format removed** |
| 83 | + |
| 84 | +**FAB-15285: Support for invoking system chaincodes from user chaincodes |
| 85 | +has been removed.** |
| 86 | + |
| 87 | +System chaincodes, for example QSCC, are intended to be |
| 88 | +invoked by a client rather than by a user chaincode. Invoking from a user |
| 89 | +chaincode caused deadlocks in prior releases. |
| 90 | + |
| 91 | +**FAB-15390: Support for peer's Admin service has been removed.** |
| 92 | + |
| 93 | +The peer's Admin service exposed APIs such as GetLogSpec() and SetLogSpec(). |
| 94 | +Instead of using these services, utilize the HTTP operations service that was |
| 95 | +introduced in v1.4.0. |
| 96 | + |
| 97 | +**FAB-16303: GetHistoryForKey returns results from newest to oldest** |
| 98 | + |
| 99 | +In prior releases, the GetHistoryForKey chaincode API had no |
| 100 | +guarantees on the order of returned results. |
| 101 | +Starting in Fabric v2.0, the GetHistoryForKey chaincode API |
| 102 | +will return results from newest to oldest in terms of ordered transaction |
| 103 | +height (block height and transaction height within block). |
| 104 | +This will allow applications to iterate through the top results |
| 105 | +to understand recent changes to a key. |
| 106 | + |
| 107 | +**FAB-16722: The 'provisional' genesis method of generating the system channel |
| 108 | +for orderers has been removed.** |
| 109 | + |
| 110 | +Existing users of the provisional genesis method |
| 111 | +should instead set BootstrapMethod to 'file', and generate a genesis block file |
| 112 | +using configtxgen. Orderer nodes will then use the generated file for the |
| 113 | +orderer system channel. |
| 114 | + |
| 115 | +**FAB-16477 and FAB-17116: New configuration for orderer genesismethod and genesisfile** |
| 116 | + |
| 117 | +The orderer config `general.genesismethod` and `general.genesisfile` are replaced |
| 118 | +by the new `general.bootstrapmethod` and `general.bootstrapfile`. |
| 119 | + |
| 120 | +**FAB-15343: System Chaincode Plugins have been removed.** |
| 121 | + |
| 122 | +As part of a general |
| 123 | +move away from go plugins as an extension mechanism for Fabric, the ability to |
| 124 | +add system chaincodes via go plugins has been removed. Users wishing to extend |
| 125 | +Fabric with custom system chaincodes may rebuild the peer binary with the |
| 126 | +system chaincode built into the binary. This system chaincode should then be |
| 127 | +defined and initialized like any other user chaincode would be. This new model |
| 128 | +is very similar to the plugin model (which required that the plugin to be built |
| 129 | +at the same exact commit of Fabric), and addresses the significant shortcomings |
| 130 | +around the lifecycle and validation of system chaincode transactions. |
| 131 | + |
| 132 | +**FAB-11096: Docker images with Alpine Linux** |
| 133 | + |
| 134 | +Hyperledger Fabric Docker images will now use Alpine Linux, |
| 135 | +a security-oriented, lightweight Linux distribution. |
| 136 | + |
| 137 | +**FAB-11096: Bash not available in Docker images with Alpine Linux** |
| 138 | +Bash is no longer available in Fabric images. Utilize Alpine's built-in |
| 139 | +sh or ash instead. |
| 140 | + |
| 141 | +**FAB-16987: Go version has been updated to 1.13.4.** |
| 142 | + |
| 143 | + |
| 144 | +Deprecations |
| 145 | +------------ |
| 146 | + |
| 147 | +**FAB-15754: The 'Solo' consensus type is deprecated.** |
| 148 | + |
| 149 | +The 'Solo' consensus type has always been marked non-production and should be in |
| 150 | +use only in test environments, however for compatibility it is still available, |
| 151 | +but may be removed entirely in a future release. |
| 152 | + |
| 153 | +**FAB-16408: The 'Kafka' consensus type is deprecated.** |
| 154 | + |
| 155 | +The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred |
| 156 | +production consensus type. There is a documented and tested migration path from |
| 157 | +Kafka to Raft, and existing users should migrate to the newer Raft consensus type. |
| 158 | +For compatibility with existing deployments, Kafka is still supported, |
| 159 | +but may be removed entirely in a future release. |
| 160 | + |
| 161 | +**FAB-7559: Support for specifying orderer endpoints at the global level |
| 162 | +in channel configuration is deprecated.** |
| 163 | + |
| 164 | +Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead. |
| 165 | +Configuring orderer endpoints at the organization level accommodates |
| 166 | +scenarios where orderers are run by different organizations. Using |
| 167 | +this configuration ensures that only the TLS CA certificates of that organization |
| 168 | +are used for orderer communications, in contrast to the global channel level endpoints which |
| 169 | +would cause an aggregation of all orderer TLS CA certificates across |
| 170 | +all orderer organizations to be used for orderer communications. |
| 171 | + |
| 172 | +Known Issues and Workarounds |
| 173 | +---------------------------- |
| 174 | +**FAB-12134: Same chaincode source receiving fingerprint mismatch error** |
| 175 | + |
| 176 | +When using the legacy chaincode lifecycle, chaincode installed in different |
| 177 | +ways may result in "chaincode fingerprint mismatch data mismatch" error |
| 178 | +upon instantiation. This may happen when installing chaincode by using |
| 179 | +different SDKs. To workaround the problem, package the chaincode prior to |
| 180 | +installation and instantiation, by using the "peer chaincode package" command. |
| 181 | + |
| 182 | + |
| 183 | +Known Vulnerabilities |
| 184 | +--------------------- |
| 185 | +**FAB-8664: Peer should detect and react when its org has been removed** |
| 186 | + |
| 187 | +This is a relatively low severity problem, because it requires a significant |
| 188 | +conspiracy of network admins, but it will be addressed in a future release. |
| 189 | + |
| 190 | + |
| 191 | +Resolved Vulnerabilities |
| 192 | +------------------------ |
| 193 | +None. |
| 194 | + |
| 195 | +For the full list of improvements and fixes, refer to the release change log: |
| 196 | +https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v200-beta |
0 commit comments