The previous article shared the system logic architecture and network node architecture of Hyperledger. This article mainly shares the typical transaction process of Hyperledger.
1
Typical transaction process
The following figure shows a typical transaction flow diagram of Hyperledger Fabric 1.0.
From the network node architecture in the previous section, we have learned that there are several node roles involved in a blockchain application based on Hyperledger Fabric 1.0: application, endorsement node, ordering service node, and master node. In Figure 3-4, it is assumed that each node has issued a certificate in advance, has been started normally, and joined the created channel. The following steps describe the entire process from initiating a call transaction to final accounting on the chaincode channel that has been instantiated.
1. Create a transaction proposal and send it to the endorsing node
The transaction proposal is constructed using the application, and the structure of the SignedProposal is as follows:
SignedProposal: {
ProposalBytes(Proposal): {
Header: {
ChannelHeader: {
Type: "HeaderType_ENDORSER_TRANSACTION",
TxId: TxId, Timestamp: Timestamp, ChannelId: ChannelId, Extension(ChaincodeHeaderExtension): { PayloadVisibility: PayloadVisibility, ChaincodeId: { Path: Path, Name: Name, Version: Version } }, Epoch: Epoch }, SignatureHeader: { Creator: Creator, Nonce: Nonce } }, Payload: { ChaincodeProposalPayload: { Input(ChaincodeInvocationSpec): { ChaincodeSpec: { Type: Type, ChaincodeId: { Name: Name }, Input(ChaincodeInput): { Args: [] } } }, TransientMap: TransientMap } } }, Signature: Signature }Let's take a look at the above structure. SignedProposal is a structure that encapsulates a Proposal and adds the caller's signature information. The endorsing node will verify whether it is a valid message based on the signature information. Proposal consists of two parts: message header and message structure. Refer to the following chapters for a detailed explanation of the message structure. Here is a brief description of the message header.
The message header (Header) also contains two items.
ChannelHeader : The channel header contains information related to the channel and chaincode invocation, such as which version of the chaincode is invoked on which channel. TxId is a transaction number generated locally by the application, which is related to the caller's identity certificate, which can avoid transaction number conflicts. Both the endorsement node and the accounting node will check whether there are duplicate transactions.
Signature Header (SignatureHeader) : The signature header contains the caller's identity certificate and a random number, which is used to verify the validity of the message.
After the application constructs the transaction proposal request, it selects the endorsement node to execute and endorse and sign it. Endorsing nodes are the nodes specified in the chaincode endorsement policy. Some endorsing nodes are offline, and other endorsing nodes can refuse to endorse the transaction or not. An application can try to satisfy the policy with other available endorsing peers. It does not matter in which order the application sends the endorsement request to the endorsement node. Under normal circumstances, the result of the endorsement node's execution is the same, only the endorsement node's signature on the result is different.
2. The endorsement node simulates the transaction and generates an endorsement signature
Endorsing nodes will perform some verifications after receiving transaction proposals, including:
Whether the transaction proposal is in the correct format;
Whether the transaction has been submitted (duplicate attack protection);
The transaction signature is valid (via MSP);
Whether the submitter of the transaction proposal has been granted write permission on the current channel.
After the verification is passed, the endorsement node will simulate and execute the business logic in the chaincode according to the current ledger data and generate a read-write set (RwSet), which includes the response value, read-write set, etc. Ledger data will not be updated during simulation execution. The back-endorsing node signs these read-write sets as a proposal response (Proposal Response), and then returns it to the application.
The structure of the ProposalResponse is as follows:
ProposalResponse: {
Version: Version,
Timestamp: Timestamp,
Response: {
Status: Status,
Message: Message, Payload: Payload }, Payload(ProposalResponsePayload): { ProposalHash: ProposalHash, Extension(ChaincodeAction): { Results(TxRwSet): { NsRwSets(NsRwSet): [ NameSpace: NameSpace, KvRwSet: { Reads(KVRead): [ Key: Key, Version: { BlockNum: BlockNum, TxNum: TxNum } ], RangeQueriesInfo(RangeQueryInfo): [ StartKey: StartKey, EndKey: EndKey, ItrExhausted: ItrExhausted, ReadsInfo: ReadsInfo ], Writes(KVWrite): [ Key: Key, IsDelete: IsDelete, Value: Value ] } ] }, Events(ChaincodeEvent): { ChaincodeId: ChaincodeId, TxId: TxId, EventName: EventName, Payload: Payload } Response: { Status: Status, Message: Message, Payload: Payload }, ChaincodeId: ChaincodeId } }, Endorsement: { Endorser: Endorser, Signature: Signature } }The returned ProposalResponse contains information such as read-write set, endorsement node signature, and channel name.
3. Collect endorsements of transactions
After the application receives the ProposalResponse, it will verify the signature of the endorsing node. All nodes need to verify the validity of the message after receiving any message. If the chaincode is only doing ledger queries, the application will check the query response, but will not submit the transaction to the ordering service node. If the chaincode performs the Invoke operation on the ledger, the transaction must be submitted to the ordering service to update the ledger, and the application will determine whether the endorsement policy is satisfied before submitting the transaction. If the application submits the transaction without collecting enough endorsements, the accounting node will find that the transaction cannot meet the endorsement policy during the submission and verification stage, and mark it as an invalid transaction.
How to choose an endorsement node? At present, the default implementation of fabric-sdk-go is to add all nodes in the configuration file option channels.mychannel.peers (where mychannel needs to be replaced with the actual channel name) as endorsement nodes, and need to wait for the endorsement signatures of all endorsement nodes. The timeout time that the application waits for each endorsement node to execute is set by the configuration file option client.peer.timeout.connection. The example of the configuration file gives 3 seconds, which can be adjusted according to the actual situation. If not set, the default is 5 seconds. value.
4. Construct a transaction request and send it to the ordering service node
After the application receives the signatures of all the endorsement nodes, it calls the SDK to generate a transaction according to the endorsement signatures, and broadcasts it to the ordering service node. The process of generating a transaction is relatively simple. It is confirmed that the execution results of all endorsement nodes are exactly the same, and then the transaction proposal, proposal response and endorsement signature are packaged to generate a transaction. The structure of the transaction is as follows:
Envelope: {
Payload: {
Header: {
ChannelHeader: {
Type: "HeaderType_ENDORSER_TRANSACTION",
TxId: TxId, Timestamp: Timestamp, ChannelId: ChannelId, Extension(ChaincodeHeaderExtension): { PayloadVisibility: PayloadVisibility, ChaincodeId: { Path: Path, Name: Name, Version: Version } }, Epoch: Epoch }, SignatureHeader: { Creator: Creator, Nonce: Nonce } }, Data(Transaction): { TransactionAction: [ Header(SignatureHeader): { Creator: Creator, Nonce: Nonce }, Payload(ChaincodeActionPayload): { ChaincodeProposalPayload: { Input(ChaincodeInvocationSpec): { ChaincodeSpec: { Type: Type, ChaincodeId: { Name: Name }, Input(ChaincodeInput): { Args: [] } } }, TransientMap: nil }, Action(ChaincodeEndorsedAction): { Payload(ProposalResponsePayload): { ProposalHash: ProposalHash, Extension(ChaincodeAction): { Results(TxRwSet): { NsRwSets(NsRwSet): [ NameSpace: NameSpace, KvRwSet: { Reads(KVRead): [ Key: Key, Version: { BlockNum: BlockNum, TxNum: TxNum } ], RangeQueriesInfo(RangeQueryInfo): [ StartKey: StartKey, EndKey: EndKey, ItrExhausted: ItrExhausted, ReadsInfo: ReadsInfo ], Writes(KVWrite): [ Key: Key, IsDelete: IsDelete, Value: Value ] } ] }, Events(ChaincodeEvent): { ChaincodeId: ChaincodeId, TxId: TxId, EventName: EventName, Payload: Payload } Response: { Status: Status, Message: Message, Payload: Payload }, ChaincodeId: ChaincodeId } }, Endorsement: [ Endorser: Endorser, Signature: Signature ] } } ] } }, Signature: Signature }Let's look at several correspondences of transaction envelopes:
Envelope.Payload.Header is the same as the transaction proposal SignedProposal.Proposal.Header;
Envelope.Payload.Data.TransactionAction.Header is the identity information of the submitter of the transaction proposal, which is redundant with SignedProposal.Proposal.Header.SignatureHeader and Envelope.Payload.Header.SignatureHeader;
Envelope.Payload.Data.TransactionAction.Payload.ChaincodeProposalPayload is the same as SignedProposal.Proposal.Payload.ChaincodeProposalPayload of transaction proposal, the only difference is that TransientMap is forcibly set to nil, the purpose is to avoid some sensitive information in the block;
Envelope.Payload.Data.TransactionAction.Payload.Action.Payload structure, in fact, and Proposal
Response.Payload structure is exactly the same;
Envelope.Payload.Data.TransactionAction.Payload.Action.Endorsement becomes an array, representing the endorsement signatures of multiple endorsing nodes.
The Signature of the entire envelope Envelope is the signature of the transaction submitter to the entire Envelope.Payload. The application can send the content of the generated transaction envelope to several ordering service nodes arbitrarily selected.
5. Ordering service nodes to order transactions and generate blocks
The ordering service does not read the content of the transaction. If the transaction simulation execution result is forged when the content of the transaction envelope is generated, the ordering service node will not find it, but it will be verified and marked as an invalid transaction in the final transaction verification stage. The ordering service is very simple. First, it receives the transaction information sent by all channels in the network, reads the Envelope.Payload.Header.ChannelHeader.ChannelId of the transaction envelope to obtain the channel name, and analyzes the transaction information in the order of the reception time of transactions on each channel. Sort and generate blocks.
6. Ordering service nodes to broadcast to the organization's master node
After the ordering service node generates a block, it will be broadcast to the master nodes of different organizations on the channel.
7. The accounting node verifies the block content and writes the block
The endorsement node is a dynamic role. As long as the endorsement participating in the transaction is the endorsement node, which transaction selects which node as the endorsement node is selected by the application, which needs to satisfy the endorsement policy to take effect. All endorsing nodes belong to accounting nodes. All peer nodes are accounting nodes, which record the ledger data that the node has joined the channel. The accounting node receives the block generated by the ordering service node, verifies the validity of the block transaction, submits it to the local ledger, and then generates a block generation event. The application program that monitors the block event can perform subsequent processing.
If the received block is a configuration block, the cached configuration information is updated. The processing flow of the accounting node is shown in the figure.
Validation of transaction data
The verification of block data is based on transaction verification. Every time the block is verified, a bitmap TxValidationFlags of the transaction number will be generated, which records the transaction verification status of each transaction number. Only the status of TxValidationCode_VALID is valid. . Bitmaps are also written to the block metadata BlockMetadataIndex_TRANSACTIONS_FILTER. The following are checked during transaction validation:
Whether it is a legal transaction: whether the transaction format is correct, whether there is a legal signature, and whether the transaction content has been tampered with;
Whether the accounting node has joined this channel.
After the basic verification is passed, it will be submitted to VSCC for verification of the endorsement policy.
Accounting node and VSCC
Chaincode transactions are isolated, and the read-write set TxRwSet of the simulated execution result of each transaction contains the chaincode to which the transaction belongs. In order to avoid incorrectly updating the chaincode transaction data, the chaincode will also be verified before the transaction is submitted to the system chaincode VSCC to verify the transaction content. The following transactions are illegal:
The name or version of the chaincode is empty;
The chain code name Envelope.Payload.Header.ChannelHeader.Extension.ChaincodeId.Name in the transaction message header is inconsistent with the chain code name Envelope.Payload.Data.TransactionAction.Payload.ChaincodeProposalPayload.Input.ChaincodeSpec.ChaincodeId.Name in the transaction data;
When the chaincode updates the current chaincode data, the chaincode version of the generated read-write set is not the latest version of the LSCC record;
The application chaincode updates the data of the LSCC (Lifecycle Management System Chaincode);
The application chain code updates the data of the system chain code that cannot be called externally;
The application chaincode updates the data of the system chaincode that cannot be called by other chaincodes;
A system chaincode that cannot be called externally is called.
Validation and MVCC checks based on state data
After the transaction passes the VSCC inspection, it enters the accounting process. kvledger also performs MVCC (Multi-Version Concurrency Control) checks on the read-write set TxRwSet.
Kvledger implements a state data model based on key-value pairs. There are 3 operations on keys of state data:
read status data;
write status data;
Delete state data.
There are two forms of read operations on state data:
single-key-based read;
Reads based on key ranges.
The MVCC check only verifies the read data. The basic logic is to compare the version of the state data when the simulation is executed and the version of the state data when the transaction is submitted. If the data version changes or the range data of a key changes, it means that another transaction has changed the state data during this period, and the processing of the current transaction based on the original state is problematic. Since transaction submission is parallel, the final execution order cannot be determined until the transaction is packaged to generate a block. If there is a dependency on the order of transaction execution, the state of the dependency will change during the MVCC check, which is actually a conflict of data. Figure shows a flow chart for state-based data validation.
The write set itself contains the data written and deleted, and there is a status bit that identifies whether the data is deleted. In order to improve efficiency, the submission of the state database is batched, and the state data of the entire block transaction is submitted at the same time, which also ensures that the state data of the entire block is either submitted successfully or failed. At this time, there will only be inconsistency between the recorded ledger data and the state database, and there will be no inconsistency in the state data of the block. When the ledger data is inconsistent with the state database, it can be marked by a checkpoint of the state database.
Handling of invalid transactions
Forged transactions will lead to invalid transactions, and normal transactions may also have invalid transactions. MVCC checks whether the environment of the endorsement node is consistent with the environment when the accounting node submits the transaction. The environment here refers to whether the triples (key, value, version) of the data in the state database are completely consistent. If the data involved in a normally submitted transaction has changed during this process, a check failure will also occur, resulting in an invalid transaction. In this case, there needs to be some compensatory measures in the upper-layer application, such as adjusting the configuration of transaction packaging, resubmitting failed transactions, etc.
In the current version of the implementation, invalid transactions are also retained in the block, which can be determined by the metadata recorded in the block. The read-write set of invalid transactions will not be submitted to the state database, and will not cause the state database to change, but will occupy the size of the block and the hard disk space of the accounting node. Subsequent versions will simplify the ledger and filter out invalid transactions.
8. Sync the latest blocks within the organization
Next preview: In-depth exploration of Hyperledger strategy management of Hyperledger technology and applications
Jingdong has purchases: https://item.jd.com/12279369.html
Deep dive into blockchain
Hyperledger Technology and Application
blockchain
By Zhang Zengjun, Dong Ning, Zhu Xuantong, Chen Jianxiong
This book is recommended by Brian Behlendorf, Executive Director of Hyperledger, and is written by the blockchain first-line practice team and the core group of Hyperleger members. In-depth explanation of Hyperledger Fabric 1.0's architecture, execution logic, core function implementation, and zero-deployment, and taking ticket cases as an example to explain specific development practices, interspersed with best practices required for development and problem solving.
mechanical industry
publishing house
Huazhang Technology is a brand of Machinery Publishing House. It has published nearly 30 classic series such as "Computer Science Series", and is in a leading position in various sub-fields. Among them, "Java Programming Ideas", "Introduction to Algorithms", "Compilation Principles" ", "Data Mining: Concepts and Techniques", "In-depth Understanding of Computer Systems", "In-depth Understanding of Java Virtual Machines" and other works are like bright pearls in the field of computer books, and they are sold for a long time!
HiBlock adheres to the values of openness, collaboration, transparency, linking and sharing, and is committed to building a blockchain developer community. Focus on promoting blockchain among developers, helping developers truly master blockchain technology and applications.
The content of this article is excerpted from Chapter 3 "System Architecture of Hyperledger" in the book "Deep Exploration of Blockchain: Hyperledger Technology and Application".
Authors: Zhang Zengjun, Dong Ning, Zhu Xuantong, Chen Jianxiong
Thanks for the support and sharing of Huazhang Branch of Machinery Industry Press.
The following is the introduction of our community, all kinds of cooperation, exchanges and learning are welcome:)