Creating a channel

To create our trade channel, we first need to instantiate a fabric-client instance and a handle to the orderer using the configuration in config.json (see the createChannel function in create-channel.js):

var client = new Client();
var orderer = client.newOrderer(
  ORGS.orderer.url,
  {
    'pem': caroots,
    'ssl-target-name-override': ORGS.orderer['server-hostname']
  }
);

We use a file-based key-value store to save the ledger world state as follows (it is left as an exercise to the reader to try out other types of store, such as CouchDB, using CouchDBKeyValueStore.js):

utils.setConfigSetting('key-value-store', 'fabric-client/lib/impl/FileKeyValueStore.js'),

Next, we must enroll an administrator user for the orderer (using the mechanisms discussed in the previous segment). After a successful enrollment, the channel configuration that we created using the configtxgen tool (see network/channel-artifacts/channel.tx) must be extracted. The path to this configuration file is set in constants.js:

let envelope_bytes = fs.readFileSync(path.join(__dirname, Constants.networkLocation, Constants.channelConfig));
config = client.extractChannelConfig(envelope_bytes);

We now need to enroll an administrator user for each of our four organizations. Each of these four admins, as well as the orderer admin, must sign the channel configuration, and the signatures collected as follows:

ClientUtils.getSubmitter(client, true /*get the org admin*/, org)
.then((admin) => {
  var signature = client.signChannelConfig(config);
  signatures.push(signature);
});

The getSubmitter function is defined in clientUtils.js, and is an indirect way of associating a member (either ordinary or administrator) of a given organization with the client object. In other words, it associates the client object with the signing identity (credentials and MSP identifications) of a user. Underneath, getSubmitter uses the functions getAdmin, getUserMember, and getMember, which we described in an earlier section.

getOrderAdminSubmitter is analogous to getSubmitter and returns a handle to an admin user of the orderer’s organization.

Finally, we are ready to build a channel creation request and submit it to the orderer:

let tx_id = client.newTransactionID();
var request = {
  config: config,
  signatures : signatures,
  name : channel_name,
  orderer : orderer,
  txId : tx_id
};
return client.createChannel(request);

The actual creation of the channel may take a few seconds, so the application logic should wait for a while before returning a successful result. The channel_name parameter is set in clientUtils.js to tradechannel, which is what we set it to when we launched our network (see network/trade.sh).

The channel creation step involves initializing the blockchain with the genesis block we created earlier in this chapter using configtxgen. The genesis block is just the first configuration block that is appended to the chain. A configuration block consists a specification of the channel and the organizations that are part of it, among other things; such a block contains no chaincode transactions. We will deal with configuration blocks again in Chapter 9, Life in a Blockchain Network, when we discuss how to augment networks.

Now, all we need to do to create a channel is call the createChannel('tradechannel') function and wait for the result. This is the first step in our test code, createTradeApp.js, which executes the basic sequence of operations illustrated in Figure 5.3: The stages in the creation and operation of a blockchain application:

var Constants = require('./constants.js'),
var createChannel = require('./create-channel.js'),
createChannel.createChannel(Constants.CHANNEL_NAME).then(() => { ...... })

The code we use to associate different signing identities with a common client object, and then sign a channel configuration, all in a single process, is purely for demonstrative purposes. In a real-life production application, the signing identities of different users belonging to different organizations are private and must be guarded; hence there is no question of pooling them together in a common location. Instead, the channel configuration must be signed independently by different organizations’ administrators and passed around using some out-of-band mechanism to accumulate the signatures (and also verify them.) Similar mechanisms must be employed when a configuration is updated (see Chapter 9, Life in a Blockchain Network) Independent, decentralized procedures must also be followed for channel joining and chaincode installation, though we demonstrate the basic mechanisms using centralized processes for convenience.

Table of Contents for Creating a channel

Create new playlist

Sign In

Sign Up

Table of Contents for
Creating a channel