HyperLedger: Hyperledger project
From https://www.cnblogs.com/kaixinyufeng/p/9290682.html
One. Nodes in Fabric
1. Node term
【1】。Orderers:
Network nodes that provide consensus services, for example, using Kafka or PBFT
【2】。Peers:
The network node that maintains the ledger usually plays the role of endorsement or bookkeeping in Hyperledger Fabric.
【3】。Comitter:
Check the legitimacy of the transaction, and finally submit the transaction to the blockchain.
2. Orderers & Peers & Comitter node relationship
The relationship between Orderers & Peers & Comitter is shown in the figure below:
Processing process of transactions in Fabric
In the entire transaction process, the main functions of each component are as follows:
【1】. Client (APP):
The client application uses the SDK to interact with the Fabric network.
First, the client obtains a legal identity certificate from the CA to join the application channel in the network.
Then, send the transaction proposal to the endorsement node (Endorser node) specified in the configuration file
【2】. Endorser node:
Complete the endorsement of the transaction proposal (currently mainly signature).
Check whether it is legal, run the transaction simulation if passed, endorse the status change caused by the transaction and return the result to the client
【3】. Orderer node:
Only responsible for sorting.
Globally sort all legal transactions in the network, and combine a batch of sorted transactions to generate a block structure.
Orderer generally does not need to deal directly with the ledger and transaction content.
【4】. Committer node
Responsible for maintaining the blockchain and ledger structure.
The node will periodically obtain the sorted batch transaction block structure from the Orderer, and perform a final check on these transactions before placing the order.
After the check is passed, a legal transaction is executed, the result is written into the ledger, and a new block is constructed.
note! The same physical node can run only as Committer, or it can serve both Endorser and Committer roles at the same time.
【5】 .the:
Responsible for the management (distribution, revocation, etc.) of all certificates in the network, and realize the standard PKI (Public Key Infrastructure) architecture.
two. Channels in Fabric
The above is just in a transaction, from the point of view of the node, look at the processing process of the transaction. However, how many nodes participate in the endorsement? How many nodes do consensus sorting? In Fabric, the concept of channels is introduced.
In general, the sub-chain of a blockchain network is based on the basic composition of "1 channel + 1 ledger + N members".
A channel is a private "subnet" of communication between two or more specific network members, used for transactions that require data confidentiality. In Fabric, establishing a channel is equivalent to establishing a sub-chain.
The channel is created to limit the scope of information dissemination and is associated with a certain ledger. Each transaction is associated with a unique channel. This will clearly define which entities (organizations and their members) will follow the transaction.
1. Channel term
【1】. aisle:
The Order service provides topics to which Peer nodes can subscribe, and each topic is a channel.
A peer can subscribe to multiple channels and can only access transactions on the subscribed channel. About "subscribe-publish topic", we will introduce in detail later.
【2】. Ledger:
The ledger stores the transaction records submitted by Orders and confirmed by the node.
【3】. member:
Network nodes that access and use the ledger.
【4】. chain:
Basically, a chain consists of 1 channel + 1 ledger + N members. Non-chain members cannot access transactions on the chain. The members of the chain can be dynamically specified by the application.
From the keyword "1 channel + 1 ledger + N members", we can know that to build a sub-chain in the Fabric blockchain network, you need to create a channel, use the channel to add members, and N members maintain one Ledger, thereby realizing a blockchain.
note:
The consensus service receives all transactions on all chains, so confidentiality is only related to peers, not Orderers.
When the consensus service is composed of trusted parties and regulators in the licensed network, this is reasonable, that is, these transactions are only visible to them as business needs.
On the other hand, if the application does not want Orderers to know the content of the transaction, it must use other techniques to hide sensitive data, such as hashing or encryption.
The consensus service exists as a relying party. If it is implemented by the Byzantine Fault Tolerance (BFT) consensus protocol (such as PBFT), it can prevent untrusted Orderers from destroying the consistency of the ledger and hindering system availability.
However, there is currently no agreement that can provide multi-channel design while providing data confidentiality in the presence of untrusted Orderers.
three. Fabric topology
Fabric network-sub-chain topology diagram
The explanation of the above figure is as follows:
【1】. Three lines, the blue solid line, the red solid line, and the orange dashed line, represent the three channels respectively.
【2】. All channels are connected to the Ordering Service description, and the consensus service receives all transactions on all chains. This point also shows that HyperLedger Fabric is not completely decentralized, but multi-centralized.
【3】. Nodes such as peer1.1 have access to multiple channels, indicating that a peer node can also participate in multiple channels. Each Channel is isolated from each other and runs in parallel. This feature greatly improves the throughput of the system.
You can know from the above picture:
【1】. A chain consists of 1 channel + 1 ledger + N members.
【2】. The consensus is provided by the Ordering Service.
【3】. The application specifies a subset of Peer nodes to set up channels. These peers constitute the set of related parties submitted to the channel transaction, and only these peers can receive the block containing the related transaction, completely isolated from other transactions.
four. Fabric sub-chain diagram
The following figure shows the relationship between multi-channel message subscription and consensus service, and the ledger:
As shown in FIG:
Peer 1, 2 and N subscribe to the red channel and jointly maintain the red ledger;
Peer 1 and N subscribe to the blue channel and maintain the blue ledger;
Similarly, peer 2 and peer N are on the black channel and maintain the black ledger.
In this example, peer N is subscribing to all channels, and we see that each channel has a related ledger.
Generally speaking, we call the ledgers that do not involve all peers as subledgers, and the other type of ledgers involving all peers is the system ledgers, that is, the full ledgers.
to sum up
Here, we understand an important concept in Fabric, channel. And an important relationship, the relationship between the channel and the Peer node.
The Hyperledger Fabric architecture uses a guaranteed publish-subscribe model message delivery channel (such as topic partition in Kafka) . This publish-subscribe model effectively separates the consensus service from the transaction log (ledger) .
Consensus services are provided by network nodes called Orderers, and the ledger is managed by Peer nodes .
From the point of view of the node, each Peer node is connected to one or more channels of the consensus service, just like a client in a publish-subscribe communication system.
The transactions broadcast on the channel are arranged in the order of consensus (for example, PBFT, kafka), and the Peer node that subscribes to the channel receives the encrypted block.
Each peer node verifies the block and submits it to the ledger, and then provides other services using the ledger to the application.
From the perspective of the nodes of the channel, the channel selects N nodes among many nodes and joins them to maintain the ledger together.
A sub-chain with basic elements of "1 channel + 1 ledger + N members"!