1. Background
At present, the blockchain is in a stage of vigorous development at the bottom and trying to apply it. In terms of business classification, blockchains can be roughly divided into public chains (BTC/ETH/EOS), consortium chains (Hyperledger Fabric) and private chains (for personal use).
The public chain can be understood as linked to the currency circle, and it is also the industry that the author has been working in. The current policy of the Celestial Dynasty on the currency circle can be said to neither encourage nor oppose. In recent years, the country has been encouraging the development of the blockchain, which is actually a great encouragement signal for the alliance chain.
Since the starting point of the alliance chain is to solve the problems of traceability, trustlessness, openness and transparency in some industries, so to some extent, the so-called token (Token) is not needed for system incentives. In particular, the alliance chain introduces a licensing mechanism, so the architecture It is quite different from most public chains. Recently, I have been in contact with and learned about this project because of my own work problems Hyperledger Fabric. Therefore, starting from the existing information and source code, analyze the structure and some details of the project.
2. Data and source code
2.1. hyperledger-fabric Github repository2.2
. hyperledger-fabric developer documentation
3. Overall structure
3.1 System Architecture
4. Code directory structure
The following is the fabric 2.0 code directory structure and function description
wujinquan@wujinquandeMacBook-Pro ~/workspace/gospace/src/github.com/hyperledger/fabric tree -L 1
.
├── CHANGELOG.md
├── CODEOWNERS
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Gopkg.lock
├── Gopkg.toml
├── LICENSE
├── MAINTAINERS.md
├── Makefile
├── README.md
├── SECURITY.md
├── bccsp //密码学相关,用于签名、加密等
├── ci //常用脚本文件
├── ci.properties
├── cmd //项目命令行，可从此目录入手了解整个项目,包含节点的启动、功能配置、停止等操作
├── common //公用代码
├── core //项目的核心代码，包含包括权限控制、 chaincode 、committer、 endorser、 ledger、 等功能 代码实现
├── discovery //为客户端程序提供服务发现的功能
├── docker-env.mk
├── docs
├── go.mod
├── gossip //是 Fabric 在节点间达成最终一致性， 实现的信息传播的模块
├── gotools.mk
├── idemix
├── images
├── integration
├── internal
├── msp //全称为 Membership service provider ，为 Fabric 提供成员服务
├── orderer //进行全局的交易排序以及切块
├── pkg
├── protoutil
├── release_notes
├── sampleconfig//配置示例
├── scripts //常见脚本
├── test-pyramid.png
├── testingInfo.rst
├── tox.ini
├── vagrant
└── vendor //Golang 第三方包管理器
21 directories, 18 files
wujinquan@wujinquandeMacBook-Pro ~/workspace/gospace/src/github.com/hyperledger/fabric
5. Node concept
Node: It is the communication entity of the blockchain and is a logical concept. Multiple nodes of different types can run on the same physical server. There are mainly four types of nodes:
5.1 Client node
The client must connect to a certain peer node or ordering service node to communicate with the blockchain network. The client submits a transaction proposal to the endorser node (endorser), and when enough endorsements are collected, the transaction proposal is broadcast to the sorting service node for sorting and generating blocks.
5.2 Node peers
Peer nodes can be divided into committer, endorser, leader and anchor according to their roles.
5.2.1 Accounting node
All peer nodes are bookkeeping nodes (committers), responsible for verifying transactions in the ordering service node block, maintaining a copy of the state and the ledger (Ledger). The node will periodically obtain blocks containing transactions from the orderer node, and after issuing and verifying these blocks, these blocks will be added to the blockchain. The committer node cannot be configured through the configuration file. It is necessary to manually specify the relevant committer node when the current client or the command line initiates a transaction request. There can be multiple bookkeeping nodes.
5.2.2 Endorsement nodes
Some nodes will also execute transactions and sign and endorse the results, acting as endorsers. Endorsement nodes are dynamic roles that are bound to specific chaincodes. Each chaincode will set an endorsement policy when it is instantiated, specifying which nodes will endorse the transaction before the transaction is valid. And only when the application initiates a transaction endorsement request to it, it is an endorsement node. At other times, it is an ordinary accounting node, which is only responsible for verifying transactions and keeping accounts. The endorsement node cannot be specified through the configuration file, but is specified by the client that initiates the transaction request. There can be multiple endorsement nodes.
5.2.3 Anchor node
A peer node can also be an anchor node (anchor peer), and an anchor node is mainly responsible for exchanging information with other organizations on behalf of the organization. Each organization has an anchor node, which is very important to the organization. If there is a problem with the anchor node, the current organization will lose contact with other organizations. The configuration information of the anchor node is configured in the configuration file configtx.yaml of the configtxgen module. There can only be one anchor node.
5.2.4 Master node
The peer node can also be the master node (leader peer), which can communicate with the sorting service node, and is responsible for obtaining the latest block from the sorting service node and synchronizing it within the organization. There can only be one master node in the entire organization.
5.3 Sorting service node orderer
Receive transactions containing endorsement signatures, sort unpackaged transactions to generate blocks, and broadcast to peer nodes. The ordering service provides atomic broadcast, which ensures that nodes on the same chain receive the same information and have the same logical order.
5.4 CA node
The certificate authority of fabric1.0 consists of server and client. The CA node receives the registration application from the client and returns the registration password for user login to obtain the identity certificate. All operations on the blockchain require verification of user identity.
6. Transaction process
So far, the article has not yet introduced Fabrichow the project works. Whether it is a public chain or an alliance chain, a basic transaction process actually represents most of the overall process. So starting from a transaction to analyze the blockchain is the best way. Looking at the entire chain from this perspective, there will be a fairly clear grasp of the context.
FabricThe normal transaction process is based on the fact that the entire Fabric network has been built and is running normally. The user has registered and registered with the organization certification authority (CA). At the same time, the encrypted material obtained for the network verification chain code is installed on the node and in the network. Instantiated on the channel, the chaincode contains logic that defines the set of transaction instructions and sets an endorsement policy for the chaincode, indicating which nodes need to endorse the transaction.
As shown in the figure above, a transaction can basically be divided into the following eight steps
6.1 Submit a transaction proposal
After the application (client node) constructs a transaction proposal (the transaction proposal includes the contract identifier to be invoked in this transaction, contract method and parameter information, and client signature, etc.), the endorsement node is selected according to the endorsement policy to execute the transaction proposal and proceed Endorsement signature. Endorsing peers are nodes specified by the endorsement policy in the chaincode. Under normal circumstances, the results of the endorsement nodes after execution are consistent, only the signatures of the endorsement nodes on the results are different.
6.2 Simulate the implementation of the proposal and endorse it
The endorsement node will perform some verifications after receiving the transaction proposal. After the verification is passed, the endorsement node will simulate and execute the business logic in the chaincode based on the current ledger data and generate a read-write set (RwSet). Ledger data will not be updated during simulation execution. The endorsement node then signs these read-write sets to generate a proposal response (proposal response), which is then returned to the application.
6.3 Collect the endorsement of the transaction (return the simulation execution result)
After the application receives the proposal response, it will verify the signature of the endorsement node (all nodes need to verify the legitimacy of the message when receiving any message). If the chaincode only performs ledger query operations, the application only needs to check the query response, and will not submit the transaction to the ordering service node. If the chaincode invokes the ledger, it needs to submit the transaction to the ordering service to update the ledger (before submitting, it will judge whether the endorsement policy is satisfied).
6.4 Construct a transaction request and send it to the ordering service node
After the application receives the signatures of all endorsement nodes, it calls the SDK to generate a transaction based on the endorsement signature, and broadcasts it to the ordering service node. The process of generating a transaction is very simple. It only needs to confirm that the execution results of all endorsement nodes are completely consistent, and then package the transaction proposal, proposal response and endorsement signature to generate a transaction.
6.5 Sorting service nodes sort transactions and generate blocks
The sorting service node receives the transaction information sent by all channels in the network, reads the transaction envelope to obtain the channel name, sorts the transaction information according to the order of reception time of transactions on each channel (multi-channel isolation), and generates blocks. (During this process, the sorting service node will not care whether the transaction is correct or not, but is only responsible for sorting and packaging. The validity of the transaction is verified in step 7)
6.6 The ordering service node broadcasts the block to the master node
After the sorting service node generates a block, it will broadcast it to the master nodes of different organizations on the channel.
6.7 The accounting node verifies the content of the block and writes it into the ledger
All peer nodes are accounting nodes, which record the ledger data that the nodes have joined the channel. After the accounting node receives the block generated by the sorting service node, it will verify the validity of the block transaction, then submit it to the local ledger and generate an event to generate a block, and the application program that listens to the block event will perform subsequent processing . (If a configuration block is received, the cached configuration information will be updated)
6.8 The master node synchronizes the latest blocks within the organization
If the transaction is invalid, the block is also updated, but not the world state. (The block stores the operation statement, while the world state stores the processed data)
7. Analysis of source code details
Please see the following
Hyperledger Fabric (2) - Config configuration module design of source code analysis