Consider the trade scenario that we have realized as a Fabric application, with the stages illustrated in Figure 5.3: The stages in the creation and operation of a blockchain application (see Chapter 5, Exposing Network Assets and Transactions), when modified to incorporate channel and chaincode updates, is illustrated in Figure 9.1: The stages in the lifecycle of a blockchain application (we omit the ledger and event emissions in the diagram for convenience, as they are not required to explain the application stages):
As we can see, some types of updates require many more operations than others. Any additions of endorsing peer nodes, either within existing organizations or in newly added ones, requires the explicit joining of those peers to the channel and the subsequent installation of the current version of chaincode on those peers. No explicit instantiation is needed on those peers; the gossip protocol among the network peers will eventually sync the latest copy of the shared ledger on the newly added ones. The smart contract modification process though will require an explicit channel-wide upgrade following the installation of the new version of the chaincode on the peers. This upgrade step is equivalent to the original instantiation though it acts on the current state rather than on a blank ledger. In some scenarios, the upgrade of chaincode and endorsement policies may immediately follow a channel reconfiguration for the addition of a new organization; in this case, the installation of the current version of chaincode on the new peers may be skipped and the upgraded chaincode version will be installed directly. We will describe how to augment our trade application to implement such a system upgrade in the next subsection.
Before we proceed, let us understand what the blockchain looks like when the system undergoes different kinds of changes. Figure 9.2 illustrates the sections of a blockchain with different kinds of blocks added for different application operations:
As we can see, our blockchain (or in other words, the shared ledger transaction log) begins with a genesis block (the first configuration block on the channel), which contains the initial configuration of the channel. The next step is the deployment and instantiation of the initial version of the chaincode and subsequently regular operation (chaincode invocations) ensues. At some point, a new organization with peers can be added, which results in another configuration block being added to the chain, overriding the previous configuration block. Similarly, a new version of chaincode can be created and upgraded, with the upgrade being recorded in a block. In between these configuration and deployment blocks, regular chaincode transactions can occur, and depending on the configured block size, one or more transactions can be bundled in a block and appended to the chain. Let us now see how to augment our trade application to implement the features we have discussed in this chapter thus far.