Hyperledger Fabric principle details and actual combat 4

The main content of this article is as follows

Starting in this chapter, we’ll do the actual work of setting up a Fabric base.

There is a concept that runs through the Fabric application layer, something very central, called “Channel”.

In China, it is usually translated as “channel”, but I think “channel” is more appropriate. As a programmer in two, how can you agree with the secular? So, I’m going to call it “Channel” or “Channel”.

What is the Channel

In the previous chapter we looked at the deployment architecture of Fabric (also known as the “runtime architecture”). This is the infrastructure on which the entire Fabric network operates.

Infrastructure is intuitive and easy to understand, but Channel is a logical concept. To understand the meaning of Channel, it is necessary to know the following:

1. A Fabric network has multiple participants (organizations).

2. Each participant can freely form an “alliance” with other participants, just like our wechat friends can freely form groups.

3. Each federation maintains a blockchain. That is, multiple blockchains can run simultaneously in a Fabric network. An organization can participate in the maintenance of multiple blockchains simultaneously.

For example, a candy company forms a Fabric network with upstream ingredient suppliers for food traceability. The diagram below:

Because of the data in the blockchain, members of the consortium are fully accessible. Just like a message in a group, all members of the group can read it.

But milk and chocolate suppliers don’t want others to see their deals with confectionery companies.

They were then split into two consortiums, each maintaining a blockchain.

At this point, there are two blockchains on the Fabric, and the confectioner participates in maintaining both chains.

A Channel can be understood as an “alliance” or group.

Each Channel can have a globally unique name, such as ChannelMilk and ChannelCoco.

All smart contracts, transactions, blockchain operations are for a Channel.

That is, a Channel divides a physical Fabric network into logical partitions. Each application operates on resources in a partition.

It is like a hard disk, which is divided into multiple partitions. Data is stored in one partition, and applications can operate on the data in one partition.

So, why do I say, the translation of “Channel” is more appropriate.

When the radio is tuned to a particular channel, it gets the same signal. When participants join a Channel, they receive the same data.

If “Channel” is changed to “Group”, I think there is no ambiguity here. Of course, I’ll talk about private data later, which allows the value of the data not to be stored on the blockchain. Maybe in time, you will understand Channel differently.

Understand the concept of channel, the following is easy to say. Let’s just build the infrastructure. Of course, there are many other concepts, and we’ll talk about them as we go along.

The implementation of instructions

The examples deployed and demonstrated on the official Fabric documentation are run based on the Docker container.

In order to take care of those who are not familiar with Docker, I will screen the parts related to Docker in the following content, making you seem to be running on virtual machines or physical machines. That’s sweet, isn’t it? Actually I still use the container ^_^.

Of course, if you are not familiar with Docker, if you are engaged in technology, please be sure to fill up this knowledge gap.

By default, Fabric runs in a container environment because it automatically generates another container to run the smart contract.

However, Fabric also provides a way to run smart contracts on separate servers.

By the way, in Fabric, smart contracts are commonly referred to as “chain codes.” I’ll call it that in a future article.

Set up the basic network and implement it in the following steps:

1. Network planning
2. Generating a Certificate File
3. Start node
4. Create a Channel
5. To join the Channel

So let’s get started.

Network planning

Remember the organizations and roles we defined?

• Company M: Bond issuer
• R Corporation: Securities rating agency
• DB and BH: financial institutions that buy and sell bonds

We make the following plans for participating organizations:

organization	The domain name	Peer node	Subordinate to the channel	IP
M co.	m.com	peer0.m.com	channelBond	172.16.0.10
		peer1.m.com	channelBond	172.16.0.11
R company	rate.com	peer0.rate.com	channelBond	192.168.10.10
		peer1.rate.com	channelBond	192.168.10.11
The DB company	db.com	peer0.db.com	channelBond	10.1.1.10
		peer1.db.com	channelBond	10.1.1.11

We haven’t touched on CA yet, but we’ll add it later.

There is another organization, BH, which we will use as a latecomer to show how to add new organizations once the network is built.

There is another organization that manages the Orderer cluster, the middleman. The reason for introducing it was explained in the chapter on Business scenarios.

The organization’s domain name is MID.org. Remember our goal? No middleman makes a difference (meaning, “I am the only middleman” : -d).

The orderer cluster is planned as follows:

organization	The domain name	The order node	IP
mid.org	mid.org	order0.mid.org	172.31.10.10
		order1.mid.org	172.31.10.11
		order2.mid.org	172.31.10.12

The TOP figure is as follows:

❝

“Tips“

If you think the above plan is too complicated (after all, it is for learning and testing purposes), then replace all the IP addresses with the same network segment.

It is not easy to simulate multiple real enterprise network environments completely on the computer, and it requires relevant basic knowledge of network.

But don’t worry, we’re just looking at the Fabric itself. If you are interested in how to simulate the real web, I will write a separate article, stay tuned!

❞

That’s all for today. Next, get ready to roll up your sleeves!

I am a2Stream programmer, we next time again cheap!

This article is formatted using MDNICE