github.com/osdi23p228/fabric@v0.0.0-20221218062954-77808885f5db/docs/source/whatsnew.rst (about)

     1  What's new in Hyperledger Fabric v2.x
     2  =====================================
     3  
     4  The first Hyperledger Fabric major release since v1.0, Fabric v2.0
     5  delivers important new features and changes for users and operators alike,
     6  including support for new application and privacy patterns, enhanced
     7  governance around smart contracts, and new options for operating nodes.
     8  
     9  Each v2.x minor release builds on the v2.0 release with minor features,
    10  improvements, and bug fixes.
    11  
    12  v2.2 is the first long-term support (LTS) release of Fabric v2.x.
    13  Fixes will be provided on the v2.2.x release stream until after the next LTS release is announced.
    14  
    15  Let's take a look at some of the highlights of the Fabric v2.0 release...
    16  
    17  Decentralized governance for smart contracts
    18  --------------------------------------------
    19  
    20  Fabric v2.0 introduces decentralized governance for smart contracts, with a new
    21  process for installing a chaincode on your peers and starting it on a channel.
    22  The new Fabric chaincode lifecycle allows multiple organizations to come to
    23  agreement on the parameters of a chaincode, such as the chaincode endorsement
    24  policy, before it can be used to interact with the ledger. The new model
    25  offers several improvements over the previous lifecycle:
    26  
    27  * **Multiple organizations must agree to the parameters of a chaincode**
    28    In the release 1.x versions of Fabric, one organization had the ability to
    29    set parameters of a chaincode (for instance the endorsement policy) for all
    30    other channel members, who only had the power to refuse to install the chaincode
    31    and therefore not take part in transactions invoking it. The new Fabric
    32    chaincode lifecycle is more flexible since it supports both centralized
    33    trust models (such as that of the previous lifecycle model) as well as
    34    decentralized models requiring a sufficient number of organizations to
    35    agree on an endorsement policy and other details before the chaincode
    36    becomes active on a channel.
    37  
    38  * **More deliberate chaincode upgrade process** In the previous chaincode
    39    lifecycle, the upgrade transaction could be issued by a single organization,
    40    creating a risk for a channel member that had not yet installed the new
    41    chaincode. The new model allows for a chaincode to be upgraded only after
    42    a sufficient number of organizations have approved the upgrade.
    43  
    44  * **Simpler endorsement policy and private data collection updates**
    45    Fabric lifecycle allows you to change an endorsement policy or private
    46    data collection configuration without having to repackage or reinstall
    47    the chaincode. Users can also take advantage of a new default endorsement
    48    policy that requires endorsement from a majority of organizations on the
    49    channel. This policy is updated automatically when organizations are
    50    added or removed from the channel.
    51  
    52  * **Inspectable chaincode packages** The Fabric lifecycle packages chaincode
    53    in easily readable tar files. This makes it easier to inspect the chaincode
    54    package and coordinate installation across multiple organizations.
    55  
    56  * **Start multiple chaincodes on a channel using one package** The previous
    57    lifecycle defined each chaincode on the channel using a name and version
    58    that was specified when the chaincode package was installed. You can now
    59    use a single chaincode package and deploy it multiple times with different
    60    names on the same channel or on different channels. For example, if you’d
    61    like to track different types of assets in their own ‘copy’ of the chaincode.
    62  
    63  * **Chaincode packages do not need to be identical across channel members**
    64    Organizations can extend a chaincode for their own use case, for example
    65    to perform different validations in the interest of their organization.
    66    As long as the required number of organizations endorse chaincode transactions
    67    with matching results, the transaction will be validated and committed to the
    68    ledger.  This also allows organizations to individually roll out minor fixes
    69    on their own schedules without requiring the entire network to proceed in lock-step.
    70  
    71  Using the new chaincode lifecycle
    72  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    73  
    74  For existing Fabric deployments, you can continue to use the prior chaincode
    75  lifecycle with Fabric v2.x. The new chaincode lifecycle will become effective
    76  only when the channel application capability is updated to v2.0.
    77  See the :doc:`chaincode_lifecycle` concept topic for an overview of the new
    78  chaincode lifecycle.
    79  
    80  New chaincode application patterns for collaboration and consensus
    81  ------------------------------------------------------------------
    82  
    83  The same decentralized methods of coming to agreement that underpin the
    84  new chaincode lifecycle management can also be used in your own chaincode
    85  applications to ensure organizations consent to data transactions before
    86  they are committed to the ledger.
    87  
    88  * **Automated checks** As mentioned above, organizations can add automated
    89    checks to chaincode functions to validate additional information before
    90    endorsing a transaction proposal.
    91  
    92  * **Decentralized agreement** Human decisions can be modeled into a chaincode process
    93    that spans multiple transactions. The chaincode may require actors from
    94    various organizations to indicate their terms and conditions of agreement
    95    in a ledger transaction. Then, a final chaincode proposal can
    96    verify that the conditions from all the individual transactors are met,
    97    and "settle" the business transaction with finality across all channel
    98    members. For a concrete example of indicating terms and conditions in private,
    99    see the asset transfer scenario in the :doc:`private-data/private-data` documentation.
   100  
   101  Private data enhancements
   102  -------------------------
   103  
   104  Fabric v2.0 also enables new patterns for working with and sharing private data,
   105  without the requirement of creating private data collections for all
   106  combinations of channel members that may want to transact. Specifically,
   107  instead of sharing private data within a collection of multiple members,
   108  you may want to share private data across collections, where each collection
   109  may include a single organization, or perhaps a single organization along
   110  with a regulator or auditor.
   111  
   112  Several enhancements in Fabric v2.x make these new private data patterns possible:
   113  
   114  * **Sharing and verifying private data** When private data is shared with a
   115    channel member who is not a member of a collection, or shared with another
   116    private data collection that contains one or more channel members (by writing
   117    a key to that collection), the receiving parties can utilize the
   118    GetPrivateDataHash() chaincode API to verify that the private data matches the
   119    on-chain hashes that were created from private data in previous transactions.
   120  
   121  * **Collection-level endorsement policies** Private data collections can now
   122    optionally be defined with an endorsement policy that overrides the
   123    chaincode-level endorsement policy for keys within the collection. This
   124    feature can be used to restrict which organizations can write data to a
   125    collection, and is what enables the new chaincode lifecycle and chaincode
   126    application patterns mentioned earlier. For example, you may have a chaincode
   127    endorsement policy that requires a majority of organizations to endorse,
   128    but for any given transaction, you may need two transacting organizations
   129    to individually endorse their agreement in their own private data collections.
   130  
   131  * **Implicit per-organization collections** If you’d like to utilize
   132    per-organization private data patterns, you don’t even need to define the
   133    collections when deploying chaincode in Fabric v2.x.  Implicit
   134    organization-specific collections can be used without any upfront definition.
   135  
   136  To learn more about the new private data patterns, see the :doc:`private-data/private-data` (conceptual
   137  documentation). For details about private data collection configuration and
   138  implicit collections, see the :doc:`private-data-arch` (reference documentation).
   139  
   140  External chaincode launcher
   141  ---------------------------
   142  
   143  The external chaincode launcher feature empowers operators to build and launch
   144  chaincode with the technology of their choice. Use of external builders and launchers
   145  is not required as the default behavior builds and runs chaincode in the same manner
   146  as prior releases using the Docker API.
   147  
   148  * **Eliminate Docker daemon dependency** Prior releases of Fabric required
   149    peers to have access to a Docker daemon in order to build and launch
   150    chaincode - something that may not be desirable in production environments
   151    due to the privileges required by the peer process.
   152  
   153  * **Alternatives to containers** Chaincode is no longer required to be run
   154    in Docker containers, and may be executed in the operator’s choice of
   155    environment (including containers).
   156  
   157  * **External builder executables** An operator can provide a set of external
   158    builder executables to override how the peer builds and launches chaincode.
   159  
   160  * **Chaincode as an external service** Traditionally, chaincodes are launched
   161    by the peer, and then connect back to the peer. It is now possible to run chaincode as
   162    an external service, for example in a Kubernetes pod, which a peer can
   163    connect to and utilize for chaincode execution. See :doc:`cc_service` for more
   164    information.
   165  
   166  See :doc:`cc_launcher` to learn more about the external chaincode launcher feature.
   167  
   168  State database cache for improved performance on CouchDB
   169  --------------------------------------------------------
   170  
   171  * When using external CouchDB state database, read delays during endorsement
   172    and validation phases have historically been a performance bottleneck.
   173  
   174  * With Fabric v2.0, a new peer cache replaces many of these expensive lookups
   175    with fast local cache reads. The cache size can be configured by using the
   176    core.yaml property ``cacheSize``.
   177  
   178  Alpine-based docker images
   179  --------------------------
   180  
   181  Starting with v2.0, Hyperledger Fabric Docker images will use Alpine Linux,
   182  a security-oriented, lightweight Linux distribution. This means that Docker
   183  images are now much smaller, providing faster download and startup times,
   184  as well as taking up less disk space on host systems. Alpine Linux is designed
   185  from the ground up with security in mind, and the minimalist nature of the Alpine
   186  distribution greatly reduces the risk of security vulnerabilities.
   187  
   188  Sample test network
   189  -------------------
   190  
   191  The fabric-samples repository now includes a new Fabric test network. The test
   192  network is built to be a modular and user friendly sample Fabric network that
   193  makes it easy to test your applications and smart contracts. The network also
   194  supports the ability to deploy your network using Certificate Authorities,
   195  in addition to cryptogen.
   196  
   197  For more information about this network, check out :doc:`test_network`.
   198  
   199  Upgrading to Fabric v2.x
   200  ------------------------
   201  
   202  A major new release brings some additional upgrade considerations. Rest assured
   203  though, that rolling upgrades from v1.4.x to v2.0 are supported, so that network
   204  components can be upgraded one at a time with no downtime.
   205  
   206  The upgrade docs have been significantly expanded and reworked, and now have a
   207  standalone home in the documentation: :doc:`upgrade`. Here you'll find documentation on
   208  :doc:`upgrading_your_components` and :doc:`updating_capabilities`, as well as a
   209  specific look  at the considerations for upgrading to v2.x, :doc:`upgrade_to_newest_version`.
   210  
   211  Release notes
   212  =============
   213  
   214  The release notes provide more details for users moving to the new release.
   215  Specifically, take a look at the changes and deprecations
   216  announced in each of the v2.x releases.
   217  
   218  * `Fabric v2.0.0 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.0.0>`_.
   219  * `Fabric v2.0.1 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.0.1>`_.
   220  * `Fabric v2.1.0 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.1.0>`_.
   221  * `Fabric v2.1.1 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.1.1>`_.
   222  * `Fabric v2.2.0 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.2.0>`_.
   223  * `Fabric v2.2.1 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.2.1>`_.
   224  * `Fabric v2.2.2 release notes <https://github.com/osdi23p228/fabric/releases/tag/v2.2.2>`_.
   225  
   226  .. Licensed under Creative Commons Attribution 4.0 International License
   227     https://creativecommons.org/licenses/by/4.0/