The design of a generic Hyperledger Fabric application presented in Chapter 5, Exposing Network Assets and Transactions, offers hints about the types of upgrades that may be required during its lifetime. Let us examine the various ways in which the requirements of a Fabric network and its users change over time:

• Software updates: Changes and upgrades are an integral part of software maintenance. More frequently, modifications are required to fix bugs, performance inefficiencies, and security flaws (for example, think of the Windows Update Service). Less frequently, though almost equally inevitably, major design changes must be made to software to handle unanticipated challenges. Also, given that most applications depend on other (third-party) software, any upgrades in the latter trigger corresponding changes in the former. Think of Windows Service Packs as an analogy.
  In the Hyperledger Fabric world, you as an application developer or system administrator must support both application-level upgrades and platform-level upgrades. The former involves bug fixes and changes in application logic and bug fixes, and the latter involves changes to the underlying Fabric software. Software update processes are well known, and some of the techniques are discussed in Chapter 5, Exposing Network Assets and Transactions; for testing and reliable failover apply to bug fixing and general maintenance as well.

If you recall the 3-layer architecture of our canonical Fabric application, the upper layers, which consist of the middleware (exercising the Fabric SDK), the web servers, and user interfaces, are typically under the control of a single organization, and they can therefore be updated through processes instituted within that organization. But, as we have seen in Chapter 8, Agility in a Blockchain Network, the smart contract, or the chaincode, is a special case as it is a piece of software that is collectively agreed upon and developed by all the participating organizations. Therefore, any update to chaincode must also be consensus-driven, and it is not as straightforward as just pushing through an update after testing. We will describe the chaincode upgrade process through examples later in this section.
Finally, upgrades to the Fabric software have the potential to impact functionality and data and therefore must be done with care. We will describe the mechanisms and the pitfalls later in this section.

• Changing resource requirements: The resources you allocate to run an application in the beginning of its life cycle, just like the application code, are unlikely to satisfy changing user requirements. It is very likely that your application receives increasing user traffic as time goes by, and no software improvement can make up for limits in hardware. Similarly, if we recall the requirements for RAS (see Chapter 5, Exposing Network Assets and Transactions), proper functioning of a distributed application requires redundancy, failover, and load balancing across your system resources.
  In Fabric terms, what this translates to is that you may have to add more nodes to your network. You may need more peers to serve transaction endorsement requests, and the network as a whole may need more orderer nodes to handle and balance the load of a currently bottlenecked ordering service (on the flipside, nodes can be removed to save on cost if traffic is too light). Otherwise, you may need extra peer nodes in an organization just for endorsement corroboration or extra orderer nodes for more reliable distributed consensus (though this may come at a performance cost). Regardless of the reason for additions and removals of nodes in your network, you as a Fabric developer or administrator must support upgrades of this nature, and we will see how this can be done later in this section.
• Changing user memberships: Besides variations in user traffic, one must be prepared for changes in user memberships for system access over time. In Fabric terms, this implies adding or removing users or clients who are permitted to send requests to the application and view application state. Within an organization, there will always be a need to add or remove users who are permitted to access the blockchain and to elevate or decrease privileges granted to existing users. We have already discussed examples of membership creations and authorizations in Chapter 5, Exposing Network Assets and Transactions, and later in this section, we will see how channel policies can be updated using runtime configurations.
• Changing application policies: Transactions (chaincode invocations) in a Hyperledger Fabric application must satisfy endorsement policies, which are collectively decided on by the participants. It is possible, and even expected, that such policies will change over time for a variety of different reasons, including performance (which we will discuss in the latter part of this chapter.) For example, an endorsement policy for the approval of a member of every organization may be relaxed to a requirement that requires just two organizational endorsements. On the flipside, the policy can be made more stringent to overcome the lack of trust among the blockchain participants. The mechanisms Fabric offer to modify endorsement policies will be discussed through examples later in this section.
• Changing network configurations: Finally, there will always be a need to modify the blockchain network itself to meet enhanced expectations. More organizations may want to participate in the application as time goes by, especially if the initial versions of the application prove their worth. Some organizations may want to leave too, for several reasons. Even within a given organization, there may be a need to expand or rebalance the resources devoted to the application in question. Now, even though most distributed applications face these situations requiring enhancements and resource reconfigurations, blockchain applications have special needs because of their unique nature. Recall that a blockchain is a shared ledger that must be validated and accepted by every participating network peer using common, agreed-upon rules. Therefore, the structure and properties of the network themselves must be commonly agreed upon and recorded on the ledger. In Hyperledger Fabric terms, an application is built on one or more channels (blockchain instance) whose rules and contents are private to application participants. Therefore, any changes in the network requires configuration changes being applied to a channel. The addition of a new organization with its own peer set or the removal of an organization will require a channel reconfiguration, as would changes in peer or orderer addresses, and the selection of anchor peers within organizations. Other examples include core properties of the channel, such as block size and timeouts; channel access policies for reads, writes, and administration operations; hashing mechanisms; and consensus mode for ordering service. Although a comprehensive coverage of channel configuration use cases is beyond the scope of this chapter, we will see how to push a reconfiguration in a Fabric network through examples later in this section.

To summarize, changes to a Fabric application require not just the usual software maintenance procedures of code and configuration changes, tests and updates, but consensus-driven operations that are specific to blockchains. In the remainder of this section, we will focus on the two main modes of application updates supported by Hyperledger Fabric.

• Channel configuration updates: This covers addition and removal of organizations, resource changes (addition, removal, or modifications to peer and orderer nodes), changes in channel properties (policy and block creation rules, hashing, and consensus mechanisms).
• Smart contract updates: This covers changes to chaincode and transaction endorsement policy.

Later, we will briefly touch on upgrades to the Fabric platform software.

To implement such upgrades, we will need to augment the application and set of tools that we created from chapters 3 to 7, with suitable mechanisms. Fortunately, the designers of the Fabric platform anticipated the kinds of evolutions we have discussed in this chapter, and the SDK we used to build the initial version of our trade application (see Chapter 5, Exposing Network Assets and Transactions) offers the capabilities necessary to build these mechanisms. Before we turn to implementation details, let us revisit the Fabric transaction pipeline and modify it to incorporate updates.