-
Notifications
You must be signed in to change notification settings - Fork 8.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add What's New documentation for Fabric v2.0 Beta Signed-off-by: David Enyeart <enyeart@us.ibm.com>
- Loading branch information
Showing
1 changed file
with
170 additions
and
106 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,126 +1,190 @@ | ||
| What's new in the v2.0 Alpha | ||
| ============================ | ||
|
|
||
| A word about the Alpha release | ||
| ------------------------------ | ||
|
|
||
| The Alpha release of Hyperledger Fabric v2.0 allows users to try out two exciting | ||
| new features --- the new Fabric chaincode lifecycle and FabToken. The Alpha release | ||
| is being offered to provide users a preview of new capabilities and is not meant | ||
| to be used in production. Additionally there is no upgrade support to the v2.0 | ||
| Alpha release, and no intended upgrade support from the the Alpha release | ||
| to future versions of v2.x. | ||
|
|
||
| Fabric 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. The new model offers several improvements over the previous | ||
| lifecycle: | ||
|
|
||
| * **Multiple organizations must agree to the parameters of a chaincode:** In | ||
| the release 1.x versions of Fabric, one organization had the ability to set | ||
| parameters of a chaincode (for instance the endorsement policy) for all other | ||
| channel members. The new Fabric chaincode lifecycle is more flexible since | ||
| it supports both centralized trust models (such as that of the previous | ||
| lifecycle model) as well as decentralized models requiring a sufficient number | ||
| of organizations to agree on an endorsement policy before it goes into effect. | ||
|
|
||
| * **Safer chaincode upgrade process:** In the previous chaincode lifecycle, | ||
| the upgrade transaction could be issued by a single organization, creating a | ||
| risk for a channel member that had not yet installed the new chaincode. The | ||
| new model allows for a chaincode to be upgraded only after a sufficient | ||
| number of organizations have approved the upgrade. | ||
|
|
||
| * **Easier endorsement policy updates:** Fabric lifecycle allows you to change | ||
| an endorsement policy without having to repackage or reinstall the chaincode. | ||
| Users can also take advantage of a new default policy that requires endorsement | ||
| from a majority of members on the channel. This policy is updated automatically | ||
| when organizations are added or removed from the channel. | ||
|
|
||
| * **Inspectable chaincode packages:** The Fabric lifecycle packages chaincode in | ||
| easily readable tar files. This makes it easier to inspect the chaincode | ||
| What's new in the v2.0 Beta release | ||
| =================================== | ||
|
|
||
| The Beta release of Hyperledger Fabric v2.0 allows users to try out upcoming | ||
| features of Fabric v2.0. While the v2.0 release is not yet production ready, | ||
| the Beta is feature complete, meaning it includes all the features that are | ||
| expected to be delivered in the final v2.0 release. | ||
|
|
||
| Let’s take a peek at some of the highlights of Fabric v2.0... | ||
|
|
||
| Decentralized chaincode lifecycle | ||
| --------------------------------- | ||
|
|
||
| Fabric v2.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. The new model | ||
| offers several improvements over the previous lifecycle: | ||
|
|
||
| * **Multiple organizations must agree to the parameters of a chaincode** | ||
| In the release 1.x versions of Fabric, one organization had the ability to | ||
| set parameters of a chaincode (for instance the endorsement policy) for all | ||
| other channel members, who only had the power to refuse to install the chaincode | ||
| and therefore not take part in transactions invoking it. The new Fabric | ||
| chaincode lifecycle is more flexible since it supports both centralized | ||
| trust models (such as that of the previous lifecycle model) as well as | ||
| decentralized models requiring a sufficient number of organizations to | ||
| agree on an endorsement policy and other details before the chaincode | ||
| ecomes active on a channel. | ||
|
|
||
| * **More deliberate chaincode upgrade process** In the previous chaincode | ||
| lifecycle, the upgrade transaction could be issued by a single organization, | ||
| creating a risk for a channel member that had not yet installed the new | ||
| chaincode. The new model allows for a chaincode to be upgraded only after | ||
| a sufficient number of organizations have approved the upgrade. | ||
|
|
||
| * **Simpler endorsement policy and private data collection updates** | ||
| Fabric lifecycle allows you to change an endorsement policy or private | ||
| data collection configuration without having to repackage or reinstall | ||
| the chaincode. Users can also take advantage of a new default endorsement | ||
| policy that requires endorsement from a majority of organizations on the | ||
| channel. This policy is updated automatically when organizations are | ||
| added or removed from the channel. | ||
|
|
||
| * **Inspectable chaincode packages** The Fabric lifecycle packages chaincode | ||
| in easily readable tar files. This makes it easier to inspect the chaincode | ||
| package and coordinate installation across multiple organizations. | ||
|
|
||
| * **Start multiple chaincodes on a channel using one package:** The previous | ||
| lifecycle defined each chaincode on the channel using a name and version that | ||
| was specified when the chaincode package was installed. You can now use a | ||
| single chaincode package and deploy it multiple times with different names | ||
| on the same or different channel. | ||
| * **Start multiple chaincodes on a channel using one package** The previous | ||
| lifecycle defined each chaincode on the channel using a name and version | ||
| that was specified when the chaincode package was installed. You can now | ||
| use a single chaincode package and deploy it multiple times with different | ||
| names on the same channel or on different channels. For example, if you’d | ||
| like to track different types of assets in their own ‘copy’ of the chaincode. | ||
|
|
||
| * **Chaincode packages do not need to be identical across channel members** | ||
| Organizations can customize a chaincode for their own use case, for example | ||
| to perform different validations in the interest of their organization. | ||
| As long as the required number of organizations endorse chaincode transactions | ||
| with matching results, the transaction will be validated and committed to the | ||
| ledger. This also allows organizations to individually roll out minor fixes | ||
| on their own schedules without requiring the entire network to proceed in lock-step. | ||
|
|
||
| Using the new chaincode lifecycle | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| Use the following tutorials to get started with the new chaincode lifecycle: | ||
|
|
||
| * :doc:`chaincode4noah`: | ||
| Provides a detailed overview of the steps required to install and define a | ||
| chaincode, as well as the capabilities available with the new model. | ||
|
|
||
| * :doc:`build_network`: | ||
| If you want to start using the new lifecycle right away, the BYFN tutorial has | ||
| been updated to use the :doc:`commands/peerlifecycle` CLI to install and | ||
| define chaincode on a sample network. | ||
|
|
||
| * :doc:`private_data_tutorial`: | ||
| Has been updated to demonstrate how to use :doc:`private-data/private-data` | ||
| collections with the new chaincode lifecycle. | ||
|
|
||
| * :doc:`endorsement-policies`: | ||
| Learn how the new lifecycle allows you to use policies in the channel | ||
| configuration as chaincode endorsement policies. | ||
|
|
||
|
|
||
| Alpine images | ||
| ------------- | ||
|
|
||
| Starting with v2.0, Hyperledger Fabric Docker images will use Alpine Linux, a | ||
| security-oriented, lightweight Linux distribution. This means that Docker images | ||
| are now much smaller, providing faster download and startup | ||
| times, as well as taking up less disk space on host systems. Alpine Linux | ||
| is designed from the ground up with security in mind, and the | ||
| minimalist nature of the Alpine distribution greatly reduces the risk of | ||
| security vulnerabilities. | ||
| For existing Fabric deployments, you can continue to use the prior chaincode | ||
| lifecycle with Fabric v2.0. The new chaincode lifecycle will become effective | ||
| only when the channel application capability is updated to v2.0. | ||
| See the Chaincode for Operators tutorial for complete details of the new | ||
| chaincode lifecycle. | ||
|
|
||
| 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. | ||
|
|
||
| * **Eliminate Docker daemon dependency** Prior releases of Fabric required | ||
| peers to have access to a Docker daemon in order to build and launch | ||
| chaincode - something that may not be desirable in production environments | ||
| due to the privileges required by the peer process. | ||
|
|
||
| * **Alternatives to containers** Chaincode is no longer required to be run | ||
| in Docker containers, and may be executed in the operator’s choice of | ||
| environment (including containers). | ||
|
|
||
| * **External builder executables** An operator can provide a set of external | ||
| builder executables to override how the peer builds and launches chaincode. | ||
|
|
||
| * **Chaincode as an external service** Traditionally, chaincodes are launched | ||
| by and then connect to the peer. It is now possible to run chaincode as | ||
| an external service, for example in a Kubernetes pod, which a peer can | ||
| connect to and utilize for chaincode execution. | ||
|
|
||
| See the external chaincode documentation to learn more about the | ||
| external chaincode launcher feature. | ||
|
|
||
| Private data enhancements | ||
| ------------------------- | ||
|
|
||
| Fabric v2.0 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 at a transaction or | ||
| state key level with selected channel members. Each private data collection | ||
| may contain a single organization, or perhaps a single organization along | ||
| with a regulator or auditor. | ||
|
|
||
| Several enhancements in Fabric v2.0 make these new private data patterns possible: | ||
|
|
||
| * **Sharing and verifying private data** When private data is shared with a | ||
| channel member who is not a member of a collection, or shared with another | ||
| private data collection that contains one or more channel members (by writing | ||
| a key to that collection), the receiving parties can utilize the | ||
| GetPrivateDataHash() chaincode API to verify that the private data matches the | ||
| on-chain hashes that were created from private data in previous transactions. | ||
|
|
||
| * **Collection-level endorsement policies** Private data collections can now | ||
| optionally be defined with an endorsement policy that overrides the | ||
| chaincode-level endorsement policy for keys within the collection. This | ||
| feature can be used to restrict which organizations can write data to a | ||
| collection. For example, you could utilize organization-specific private | ||
| data collections to allow each organization to individually consent to state | ||
| updates. This pattern is useful for implementing workflows that span individual | ||
| transactions, for example to support voting or approval scenarios with data | ||
| privacy and nonrepudiation. | ||
|
|
||
| * **Implicit per-organization collections** If you’d like to utilize | ||
| per-organization private data patterns, you don’t even need to define the | ||
| collections when deploying chaincode in Fabric v2.0. Implicit | ||
| organization-specific collections can be used without any upfront definition. | ||
|
|
||
| To learn more about the new private data patterns, see the documentation for | ||
| private data sharing, private data collection configuration, and implicit collections. | ||
|
|
||
| State database cache for improved performance on CouchDB | ||
| -------------------------------------------------------- | ||
|
|
||
| * When using external CouchDB state database, read delays during endorsement | ||
| and validation phases have historically been a performance bottleneck. | ||
|
|
||
| * With Fabric v2.0, a new peer cache replaces many of these expensive lookups | ||
| with fast local cache reads. The cache size can be configured by using the | ||
| core.yaml property ``cacheSize``. | ||
|
|
||
| Alpine-based docker images | ||
| -------------------------- | ||
|
|
||
| Raft ordering service | ||
| --------------------- | ||
| Starting with v2.0, Hyperledger Fabric Docker images will use Alpine Linux, | ||
| a security-oriented, lightweight Linux distribution. This means that Docker | ||
| images are now much smaller, providing faster download and startup times, | ||
| as well as taking up less disk space on host systems. Alpine Linux is designed | ||
| from the ground up with security in mind, and the minimalist nature of the Alpine | ||
| distribution greatly reduces the risk of security vulnerabilities. | ||
|
|
||
| Introduced in v1.4.1, `Raft <https://raft.github.io/raft.pdf>`_ is a crash fault | ||
| tolerant (CFT) ordering service based on an implementation of Raft protocol in | ||
| `etcd <https://coreos.com/etcd/>`_. Raft follows a "leader and follower" model, | ||
| where a leader node is elected (per channel) and its decisions are replicated to | ||
| the followers. Raft ordering services should be easier to set up and manage than | ||
| Kafka-based ordering services, and their design allows organizations spread out | ||
| across the world to contribute nodes to a decentralized ordering service. | ||
| Sample test network | ||
| ------------------- | ||
|
|
||
| * :doc:`orderer/ordering_service`: | ||
| Describes the role of an ordering service in Fabric and an overview of the | ||
| two ordering service implementations currently available: Kafka and Raft. | ||
| The fabric-samples repository now includes a new Fabric test network. The test | ||
| network is built to be a modular and user friendly sample Fabric network that | ||
| makes it easy to test your applications and smart contracts. The network also | ||
| supports the ability to deploy your network using Certificate Authorities, | ||
| in addition to cryptogen. | ||
|
|
||
| * :doc:`raft_configuration`: | ||
| Shows the configuration parameters and considerations when deploying a Raft | ||
| ordering service. | ||
| New tutorials are also being written, which may eventually replace the Build | ||
| Your First Network sample and tutorial. | ||
|
|
||
| * :doc:`orderer_deploy`: | ||
| Describes the process for deploying an ordering node, independent of what the | ||
| ordering service implementation will be. | ||
| Upgrading to Fabric v2.0 | ||
| ------------------------ | ||
|
|
||
| * :doc:`build_network`: | ||
| Has been updated to allow you to use a Raft ordering service with a sample | ||
| network. | ||
| While a Beta release is not an intended upgrade target for existing Fabric | ||
| deployments, there is nothing preventing you from testing an upgrade scenario | ||
| to get familiar with the process. Read all about the upgrade process in the | ||
| v2.0 upgrade documentation. | ||
|
|
||
| Release notes | ||
| ============= | ||
|
|
||
| The release notes provide more details for users moving to the new release, along | ||
| with a link to the full release change log. | ||
| The release notes provide more details for users moving to the new release. | ||
| Specifically, take a look at the changes and deprecations that are being | ||
| announced with the new Fabric v2.0 release. | ||
|
|
||
| * `Fabric v2.0.0-alpha release notes <https://github.com/hyperledger/fabric/releases/tag/v2.0.0-alpha>`_. | ||
| * `Fabric CA v2.0.0-alpha release notes <https://github.com/hyperledger/fabric-ca/releases/tag/v2.0.0-alpha>`_. | ||
| * `Fabric v2.0.0-beta release notes <https://github.com/hyperledger/fabric/releases/tag/v2.0.0-beta>`_. | ||
|
|
||
| .. Licensed under Creative Commons Attribution 4.0 International License | ||
| https://creativecommons.org/licenses/by/4.0/ |