Basic concept of fabric
Initially, the application will select a group of peers to generate account book update suggestions. Which peer will be selected is based on the signing policy, which determines which organizations need to sign the update proposal before broadcasting the account book update proposal. This will affect the way of understanding. Any organization concerned about whether the update proposal is approved will confirm whether the proposal is approved before it is broadcast to peers and accepted by peers.
Peer's approval of the proposed response is to add his digital signature to the response and sign the whole response with his private key. You can then use the content of the annotation to prove that the response was generated by the organization's peers. In our example, if the peer P 1 belongs to the organization 1(Org 1), then approving E 1 is equivalent to proving that the response R 1 on the transactions T 1 and L 1 is made by the organization/kloc.
When the application gets enough responses to the signature proposal, the first phase ends.
We noticed that peer may return different information, so the same transaction may have inconsistent return information. This may be because the responses are generated at different times, different peers and different books. In most cases, an application can request an update suggestion response multiple times. In addition, it is more serious, but the probability is small because the uncertainty of chain code leads to inconsistent response. Uncertainty is the enemy of chain code and ledger. If this happens, it will be very serious for the proposed transaction, and the inconsistent proposal response will certainly not be submitted to the account book. It is impossible for an independent node to know that the transaction result is a non-deterministic transaction. Before detecting uncertain transactions, it is necessary to summarize and compare the transactions (strictly speaking, even if this is not enough, we will postpone this discussion to the transaction part, which is discussed in detail in the uncertainty part).
At the end of the first phase, if the application wishes, it can safely discard inconsistent responses to end the transaction early. We will see later that if the response submitted by the application to the ledger is inconsistent, it will be rejected.
Process 2 packaging
The second transaction process is packaging. The subscriber node is a key point in this process, and it receives the transaction responses of approved proposals from many applications. The orderer sorts the transactions, packages a large number of transactions into blocks, and prepares to distribute the blocks to all peers connected with the orderer, including endorsement peers.
The first role of the subscriber is to package account book update suggestions. In the above example, the application A 1 sends the transaction T 1 endorsed by E 1 and E2 to the subscriber O 1. Meanwhile, the application A2 sends the transaction T2 endorsed by E 1 to the subscriber O 1. O 1 Packed the transactions from A 1, A2 and other transactions into B2 block. We can see that the transaction sequence in block B2 is T 1, T2, T3, T4, T6, T5, not necessarily in the order of reaching the subscriber node (this example shows a very simple subscriber configuration).
The subscriber node will also receive account book update suggestions sent by different applications in the network channel. The task of the subscriber node is to organize these update suggestions in a predefined order and package them into blocks for the next distribution. These stones will form a blockchain. Once the subscriber node generates a block with the expected size or exceeds the maximum waiting time, the subscriber will send the block to the peer connected to its specific channel. The third process will introduce this process in detail.
There is no direct relationship between the order of transactions in a block and the order in which transactions arrive at the order node. Transactions can be arranged in any order in a block, and this order is the order in which transactions are executed. The point is to have a strict trading ranking, but the ranking is not important.
The strict transaction order in a block makes Fabric different from the case that transactions in a common chain can be packaged into multiple different blocks. In Fabric, this can't happen, and the block generated by multiple orders is the final block, because after the transactions are written into the block, the position order of the transactions is determined. This means that the fabric will not split. Once a transaction is written into a block, it cannot be rewritten later.
We can see that peer stores books and chain codes, and orderer doesn't store them at all. When each transaction arrives at the order, the order just packs the transaction into blocks mechanically, regardless of the value and amount of the transaction. This is an important feature of fabric. All transactions will be sorted in strict order, and no transactions will be discarded.
By the end of the second phase, we can understand that the subscriber's responsibility is to collect necessary and simple transaction update proposals, sort them, package them into blocks and prepare them for distribution.
Process 3 certification
The last transaction workflow is to distribute and verify blocks from the subscriber to the peer. If the verification is successful, it will be submitted to the general ledger.
In particular, in each peer, every transaction in the block is verified before being updated to the account book to ensure that all transactions have been approved by the relevant organizations. Failed transactions will be kept for future review and will not be updated in the books.
In addition to the packaging role in Process 2, Orderer is also responsible for distributing blocks to peer nodes in Process 3. In this example, O 1 distributes blocks to P 1 and P2. P 1 processes Block 2, and then adds it to the account book L 1 of P 1. Meanwhile, P2 processes Block 2, and then adds Block 2 to the account book L 1 of P2. Once the operation is completed, the account book L 1 is updated in P 1 and P2, and each peer can send the processing result to the application connected to them.
The subscriber distributes the blocks to the peers connected to him, which is the beginning of process 3. A peer connected to the channel of the subscriber node will receive a copy of the new block generated by the subscriber. Each peer node will process the received block independently, but all peer nodes will process the block in the same way. In this way, the books of different peers can reach * * * knowledge. Not all peers have to be connected to the orderer node, and blocks can be passed between peers through gossip protocol, so that peers can also handle the same blocks independently.
After receiving the blocks, peer will process the transactions in the order in which they appear. For each transaction, peer will check whether the transaction is approved by relevant organizations according to the chain code approval strategy that generates the transaction. For example, some transactions may require only one organization to endorse, while other transactions require multiple organizations to endorse at the same time. This verification process verifies whether the results or outputs produced by all relevant organizations are consistent. At the same time, please note that the third stage of verification is different from the first stage. In the first stage, the application only receives the response from the endorsement node and judges whether it is necessary to send the transaction proposal. If the application sends the wrong transaction and violates the endorsement policy, the peer can still reject the transaction in the third verification stage.
If the endorsement of the transaction is correct, peer will try to submit the transaction to the ledger. In order to compile the account book, peer must check the consistency of the account book to ensure that the current account book is consistent with the updated account book. This state is not always consistent, even if the transaction has a complete endorsement. For example, another transaction may update the same asset in the ledger, so the transaction we will update will never be written into the ledger. In this case, the account books in each node must be notified through the network, and the verification method of each node is the same.
The ledger will be updated after peer verifies each independent transaction. Failed transactions will be kept as review materials. This means that the block in the peer is the same as the block received from the subscriber except for the flag in the block indicating the success or failure of the transaction.
We should also note that the chain code is not executed in the third stage, and this step will only be completed in the first stage, which is very important. This means that the chain code is only available in the endorsement node, not in the whole network, which ensures the security and privacy of the chain code in the endorsement institution. This is different from receiving the execution result of chain code. The execution result will be shared with all peers in the channel, regardless of whether he can sign the transaction or not. The endorsement node is designed in this way, which is convenient for expansion.
Finally, every time a block is submitted to the peer's account book, the peer will generate a corresponding event. Block events contain all the contents of a block, while block transaction events only contain short information, such as whether the transactions in each block are valid or not. Chain code events generated by chain code execution can also be released at this time. Applications can register these events and receive notifications when they occur. These notifications are completed in the third and final phase of the transaction workflow.
Generally speaking, we can know that the blocks generated by orderer in the third stage are constantly synchronized into the account book. The strict ordering of transactions in the blockchain allows each peer to consistently verify the transactions in the blockchain network and submit them to the ledger.
Subscriber and * * * knowledge
The whole transaction workflow is called * * * knowledge, because all peer agree on the ordering and content of transactions, and the orderer node coordinates the execution process. * * * knowledge is a multi-step process, and the application will be notified only when the * * * knowledge process is finished, but the notification time may be different on different peers.
We will talk more about subscribers later. Now, we just regard orderer as a process of collecting and distributing account book update suggestions from applications to peers, and peers will verify and update the account book.