Fabric v1.x Orderer broadcast atoms (per sort)

First, the implementation - Sort - validation (Execute-Order-Validate)

Fabric used is first executed, after sorting, the final verification of the consensus model (Execute-Order-Validate), as shown below:

After first proposed transaction by the client, peer distributed simulation execution, set to read and write and sign it back to the client , client will read the signature set (proposal response) package sent to orderer, orderer will all be from the received proposal response client sorted and packaged into blocks, and then sends to peer blocks, each of the last opened by the peer blocks, and verify the version number and signature set of read and write, you can write data to meet the conditions of local books. peer client will be sent to the event description of the transaction has been submitted to the books in the. These are the life-cycle Fabric transactions.

Two, Orderer full sorting

Orderer role is to carry out a full sort Fabric network transactions. Orderer is a cluster, each node in the cluster receives all transactions total ordering, then by certain rules will be packaged into trading blocks, as shown below:

in Fabric Not everyone can participate in ordering, by the league run orderer node core business, thus allowing only a few organizations in the sort of work.

Orderer total ordering needs meet the following requirements:

2.1 generating the same block (Produce identical blocks)

Orderer each node needs to generate a block by identical consensus algorithm, each peer node receiving this block will be exactly the same, as shown, each block orderer generated hash are the same as shown below:

2.2 crash fault-tolerant (Crash Fault Tolerance)

Orderer a node in the cluster to stop the service, the remaining nodes are still able to complete the sorting function, such as raft algorithm as long as more than half of the nodes to work, will be able to complete the normal sort.

After Orderer node goes down, isolated orderer node may continue to run, then will generate network partition (Network Partition), isolated orderer node to be able to sniff that they have been quarantined, rejected a new block.

2.3 strong consistency (Strong Consistency)

"Po" series of consensus algorithms for the chain can only be reached on the probability of consistency, and Fabric will need strong consistency, the transaction is rolled back has been submitted can not be accepted, so there is no temporary bifurcation, each block is deterministic (finality).

2.4 Byzantine Fault Tolerant (Byzantine Fault Tolerance)

Byzantine fault tolerance refers to more than just one node out of service, you can also do evil, malicious submit some requests transaction or reject the response of others. Fabric1.4 version of the Orderer itself is not supported by Byzantine fault-tolerant (BFT), the only support for the collapse of fault-tolerant (CFT), but Fabric mechanisms exist endorsement and validation of the entire Fabric Byzantine fault-tolerant (BFT), even though there are some not prevent attacks , making it impossible to block out the transaction peer node submitted not written in books, but in the Fabric where you can view the log of another orderer can be diagnosed at an orderer evil, then most of the network had an impact, but will not resulting peer data loss or tampering, because there is no peer endorsement, the transaction will never be submitted to its books.

Third, the cutting block (Block Cutting)

After sorting Orderer transaction, each node also needs to Orderer cutting block, wherein a long BatchTimeout BatchSize and conditions will produce blocks.

3.1 BatchSize

• The maximum number of blocks of a transaction MaxMessageCount
• AbsoluteMaxBytes limit the size of individual transactions
• PreferredMaxBytes expected block size

Orderer have been accumulating in the transaction, when the total size reaches PreferredMaxBytes can block out, or the number of transactions reached MaxMessageCount can also block out.
But the last trading bytes may be larger, can not guarantee the total size must be smaller than PreferredMaxBytes, then the transaction can still be included into the block. By AbsoluteMaxBytes size limit, exceeding the limit of a single transaction is denied fair swap.

3.2 BatchTimeout

• Timeout

After less than a block size may have been set up, to the "Timeout" the time set, the transaction will be out as long as there is a block.