Remove references to instantiating a chaincode

Signed-off-by: NIKHIL E GUPTA <negupta@us.ibm.com>

docs/source/cc_launcher.md

@@ -1,6 +1,6 @@
 # External Builders and Launchers
 
-Prior to Hyperledger Fabric 2.0, the process used to build and launch chaincode was part of the peer implementation and could not be easily customized. All chaincode instantiated on the peer would be "built" using language specific logic hard coded in the peer. This build process would generate a Docker container image that would be launched to execute chaincode that connected as a client to the peer.
+Prior to Hyperledger Fabric 2.0, the process used to build and launch chaincode was part of the peer implementation and could not be easily customized. All chaincode installed on the peer would be "built" using language specific logic hard coded in the peer. This build process would generate a Docker container image that would be launched to execute chaincode that connected as a client to the peer.
 
 This approach limited chaincode implementations to a handful of languages, required Docker to be part of the deployment environment, and prevented running chaincode as a long running server process.
 

docs/source/cc_service.md

@@ -261,7 +261,8 @@ When the GO chaincode is ready for deployment, you can package the chaincode as
 
 Create the chaincode as specified in the [Writing chaincode to run as an external service](#writing-chaincode-to-run-as-an-external-service) section. Run the built executable in your environment of choice, such as Kubernetes or directly as a process on the peer machine.
 
-Using this chaincode as an external service model, installing chaincode on each peer is no longer required. With the chaincode endpoint deployed to the peer instead and the chaincode running, you can continue to instantiate and invoke chaincode normally.
+Using this chaincode as an external service model, installing the chaincode on each peer is no longer required. With the chaincode endpoint deployed to the peer instead and the chaincode running, you can continue the normal process of committing the
+chaincode definition to the channel and invoking the chaincode.
 
 <!---
 Licensed under Creative Commons Attribution 4.0 International License https://creativecommons.org/licenses/by/4.0/

docs/source/chaincode.rst

@@ -74,7 +74,7 @@ To learn how more about the new Fabric Lifecycle, visit :doc:`chaincode4noah`.
 
 You can use the Fabric chaincode lifecycle by creating a new channel and setting
 the channel capabilities to V2_0. You will not be able to use the old lifecycle
-to install, instantiate, or update a chaincode on a channels with V2_0 capabilities
+to install, instantiate, or update a chaincode on channels with V2_0 capabilities
 enabled. However, you can still invoke chaincode installed using the previous
 lifecycle model after you enable V2_0 capabilities.
 

docs/source/couchdb_tutorial.rst

@@ -16,7 +16,7 @@ The tutorial will take you through the following steps:
 #. :ref:`cdb-enable-couch`
 #. :ref:`cdb-create-index`
 #. :ref:`cdb-add-index`
-#. :ref:`cdb-install-instantiate`
+#. :ref:`cdb-install-deploy`
 #. :ref:`cdb-query`
 #. :ref:`cdb-best`
 #. :ref:`cdb-pagination`
@@ -303,7 +303,7 @@ This will create two fabric peer nodes that use CouchDB as the state database.
 It will also create one ordering node and a single channel named
 ``mychannel``.
 
-.. _cdb-install-instantiate:
+.. _cdb-install-deploy:
 
 Install and define the Chaincode
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/source/developapps/application.md

@@ -250,9 +250,9 @@ Note how the application provides a name -- `papercontract` -- and an explicit
 contract name: `org.papernet.commercialpaper`! We see how a [contract
 name](./contractname.html) picks out one contract from the `papercontract.js`
 chaincode file that contains many contracts. In PaperNet, `papercontract.js` was
-installed and instantiated with the name `papercontract`, and if you're
-interested, read [how](../chaincode4noah.html) to install and instantiate a
-chaincode containing multiple smart contracts.
+installed and deployed to the channel with the name `papercontract`, and if you're
+interested, read [how](../chaincode4noah.html) to deploy a chaincode containing
+multiple smart contracts.
 
 If our application simultaneously required access to another contract in
 PaperNet or BondNet this would be easy:

docs/source/developapps/chaincodenamespace.md

@@ -126,16 +126,16 @@ separate, or share all commercial papers and bonds?
 ## Channels
 
 If a peer is joined to multiple channels, then a new blockchain is created
-and managed for each channel. Moreover, every time a chaincode is instantiated
-in a new channel, a new world state database is created for it. It means that
+and managed for each channel. Moreover, every time a chaincode is deployed to
+a new channel, a new world state database is created for it. It means that
 the channel also forms a kind of namespace alongside that of the chaincode for
 the world state.
 
 However, the same peer and chaincode container processes can be simultaneously
 joined to multiple channels -- unlike blockchains, and world state databases,
 these processes do not increase with the number of channels joined.
 
-For example, if the `papers` and `bonds` chaincodes were instantiated on a new
+For example, if you deployed the `papers` and `bonds` chaincode to a new
 channel, there would a totally separate blockchain created, and two new world
 state databases created. However, the peer and chaincode containers would not
 increase; each would just be connected to multiple channels.

docs/source/developapps/contractname.md

@@ -6,8 +6,8 @@ administrators
 A chaincode is a generic container for deploying code to a Hyperledger Fabric
 blockchain network. One or more related smart contracts are defined within a
 chaincode. Every smart contract has a name that uniquely identifies it within a
-chaincode. Applications access a particular smart contract within an
-instantiated chaincode using its contract name.
+chaincode. Applications access a particular smart contract within a chaincode
+using its contract name.
 
 In this topic, we're going to cover:
 * [How a chaincode contains multiple smart contracts](#chaincode)
@@ -24,8 +24,8 @@ rather than the low level details of how to interact with a Fabric network.
 
 Smart contracts are one example of a high level programming abstraction, and it
 is possible to define smart contracts within in a chaincode container. When a
-chaincode is installed and instantiated, all the smart contracts within it are
-made available to the corresponding channel.
+chaincode is installed on your peer and deployed to a channel, all the smart
+contracts within it are made available to your applications.
 
 ![contract.chaincode](./develop.diagram.20.png) *Multiple smart contracts can be
 defined within a chaincode. Each is uniquely identified by their name within a
@@ -94,7 +94,7 @@ name are explicitly or implicitly specified.
 
 ## Application
 
-Once a chaincode has been installed on a peer and instantiated on a channel, the
+Once a chaincode has been installed on a peer and deployed to a channel, the
 smart contracts in it are accessible to an application:
 
 ```javascript
@@ -151,4 +151,4 @@ for applications to find a particular smart contract and use it to access the
 ledger.
 
 <!--- Licensed under Creative Commons Attribution 4.0 International License
-https://creativecommons.org/licenses/by/4.0/ -->
+https://creativecommons.org/licenses/by/4.0/ -->

docs/source/developapps/gateway.md

@@ -50,7 +50,7 @@ A gateway can be used by an application in two different ways:
   profile. Typically, one or two peers from the application's organization are
   specified, and they use [service discovery](../discovery-overview.html) to
   discover the available network topology. This includes peers, orderers,
-  channels, instantiated smart contracts and their endorsement policies. (In
+  channels, deployed smart contracts and their endorsement policies. (In
   production environments, a gateway configuration should specify at least two
   peers for availability.)
 
@@ -186,4 +186,4 @@ It can be helpful to have multiple gateways. Here are a few reasons:
   with an existing configuration.
 
 <!--- Licensed under Creative Commons Attribution 4.0 International License
-https://creativecommons.org/licenses/by/4.0/ -->
+https://creativecommons.org/licenses/by/4.0/ -->

docs/source/developapps/transactioncontext.md

@@ -10,7 +10,7 @@ processing. These range from querying or updating the ledger, both the immutable
 blockchain and the modifiable world state, to retrieving the
 transaction-submitting application's digital identity.
 
-A transaction context is created when a smart contract is instantiated, and
+A transaction context is created when a smart contract is deployed to a channel and
 made available to every subsequent transaction invocation. A transaction context
 helps smart contract developers write programs that are powerful, efficient and
 easy to reason about.
@@ -279,4 +279,4 @@ case.
   identity. See interaction point **(15)** or **(16)**.
 
 <!--- Licensed under Creative Commons Attribution 4.0 International License
-https://creativecommons.org/licenses/by/4.0/ -->
+https://creativecommons.org/licenses/by/4.0/ -->

docs/source/enable_tls.rst

@@ -108,7 +108,7 @@ must to be set in addition to those above:
 * ``CORE_PEER_TLS_CLIENTKEY_FILE`` = fully qualified path of the client private key
 
 When running a command that connects to orderer service, like `peer channel <create|update|fetch>`
-or `peer chaincode <invoke|instantiate>`, following command line arguments must also be specified
+or `peer chaincode <invoke>`, following command line arguments must also be specified
 if TLS is enabled on the orderer:
 
 * --tls

docs/source/membership/membership.md

@@ -119,15 +119,15 @@ both ORG1 and ORG2. Similar principles apply for the network, orderers, and user
 but these are not shown here for simplicity.*
 
 You may find it helpful to see how local and channel MSPs are used by seeing
-what happens when a blockchain administrator installs and instantiates a smart
+what happens when a blockchain administrator installs and deploys a smart
 contract, as shown in the [diagram above](#msp2img).
 
 An administrator `B` connects to the peer with an identity issued by `RCA1`
 and stored in their local MSP. When `B` tries to install a smart contract on
 the peer, the peer checks its local MSP, `ORG1-MSP`, to verify that the identity
 of `B` is indeed a member of `ORG1`. A successful verification will allow the
 install command to complete successfully. Subsequently, `B` wishes
-to instantiate the smart contract on the channel. Because this is a channel
+to deploy the smart contract on the channel. Because this is a channel
 operation, all organizations on the channel must agree to it. Therefore, the
 peer must check the MSPs of the channel before it can successfully commit this
 command. (Other things must happen too, but concentrate on the above for now.)

docs/source/txflow.rst

@@ -16,7 +16,7 @@ received back necessary cryptographic material, which is used to authenticate to
 the network.
 
 The chaincode (containing a set of key value pairs representing the initial
-state of the radish market) is installed on the peers and instantiated on the
+state of the radish market) is installed on the peers and deployed to the
 channel. The chaincode contains logic defining a set of transaction instructions
 and the agreed upon price for a radish. An endorsement policy has also been set
 for this chaincode, stating that both ``peerA`` and ``peerB`` must endorse any