Block chain Basic Knowledge Series 5th lesson transaction generation and circulation process in Hyperledger fabric1.0 network

I. Initiation of Transaction

When the client wants to initiate a transaction, it will first send a propose message to a set of endorser nodes it chooses, the message mode has the following two kinds, the node is free to choose (may have more kinds): The client will first <propose, The tx> message is sent to a single endorser, which produces the appropriate version-dependent (anchor) to be sent to the other endorser node later as an argument for the propose message, and the client directly < Propose, the tx> message is sent to the set of endorser nodes it chooses.

The format of the propose message is <propose, TX, [Anchor]&gt, where the anchor parameter is optional, which means read version dependency, usually refers to the key-version pair, and the required TX parameter represents the contents of the transaction. Includes the ClientID of the client unique identifier initiating the transaction, pointing to the Chaincodeid of the chaincode involved in the transaction, including the transaction of the originating Txpayload itself, A monotonically incremented integer timestamp maintained by the client and a client's signature clientsig. The txpayload is divided into two different types according to the transaction: Wake-up Service (Invoke transaction): Txpayload=<operation, Metadata> Where operation represents the Chaincode operation and the parameters passed to the Chaincode, metadata represents the property associated with the call; Deployment transaction (Deploy Transaction): Txpayload=<source, metadata, Policies&gt, where source represents Chaincode's source code, metadata represents the attributes associated with Chaincode and application, policies represents policies related to Chaincode, including the provisioning strategy.second, simulate transaction When Endorser receives a propose message, it verifies the clientsig in it first, and then simulates the transaction after validation. If the propose message contains the Anchor field, endorser obtains the version value of the current local state for the value of the key that is based on the key in the anchor, resulting in a readset (read set), such as the current endorser locally saved state is S. The key k, (K, S (k). version) in any one of the transaction is added to the read set, such as s= (K1,1,V1), (K2,1,V2), (K3,1,v3), (K4,1,V4), (K5,1,V5), Anchor contains the key value of K1, K2, then Readset={k1:v1, k2:v2}, only if the anchor and Readset match exactly equal, endorser will simulate the transaction. The mock transaction generates a state update called a writeset (write set) based on a endorser locally saved state copy, which invokes the corresponding chaincode to tentatively execute the transaction. If the value of key k in any transaction is modified to V, then (K, v) is added to the write set. endorser internal forwarding tran-proposal to the logical part of its preparation transaction--The preparation logic, by default, the preparation logic accepts the Tran-proposal and adds a signature to it, and, of course, the decision whether or not to prepare the book by any function. If endorser decides to give a TRANSACTION, it will send a <transaction-endorsed, TID, tran-proposal,epsig> message to the client who submitted it, Where Tid is generated by hashing the TX in the propose message to point to a transaction,epsig is the signature of the reserve book node, tran-proposal = (Epid,tid,chaincodeid, Txcontentblob,readset,writeset), where Epid is the node of the backup node Id,txcontentblob is the specific information of the chaincode/transaction, used as a form of TX, such as Txcontentblob = Tx.txpayload. If Endorser refuses to give a transThe action preparation, which only needs to be sent directly to the client that initiated the TRANSACTION (Transaction-invalid, TID, rejected) message. Throughout the process, endorser does not modify its local state, but simulates transaction.third, the receipt of information on the preparation of booksThe client that initiates the transaction sends propose message and waits to receive the standby message, whether the preparation is successful depends on the current preparation policy, such as the current client-selected collection of spare books for {Alice, Bob, Charlie, Dave, Eve, Frank, George}, the current provisioning strategy for the 5-pass-through node, then the client after collecting 5 transaction-endorsed messages that the current transaction is successful, The received transaction-endorsed message set is called endorsement. After that, the client sends the broadcast (BLOB) (the BLOB is endorsement) message to Orderer system channel. The orderer is used to synchronize the transaction to the nodes within the entire channel. Orderer sorts all the transaction over a period of time and packs it into blocks and sends the block to all nodes through deliver (Seqno, Prevhash, BLOB) messages, where seqno represents a non-negative ordinal number. Prevhash represents the hash value of the most recent block, and a blob represents a block chunk.four, synchronous transactionWhen a node receives a deliver message, it checks to see if the blob.endorsement is valid according to the Chaincode policy, and then checks to see if Readset is consistent with the local state of the current node. If all the validations are passed, the transaction is considered valid. At this point, the node marks the transaction as 1 in the Peerledger bitmask, modifying the local ledger state by Blob.endorsement.tran-proposal.writeset. If the blob.endorsement policy validation fails, the transaction is considered invalid and the node marks the transaction as 0 in the Peerledger bitmask. It is important to note that invalid transactions will be placed in chunks but will not change the local ledger status.

An example is given to explain how a node can determine the validity of a transaction by a read-write set:

Assuming the current local state is s= (K1,1,V1), (K2,1,V2), (K3,1,v3), (K4,1,V4), (K5,1,V5), the node receives a block containing 5 transaction, T1, T2, T3, T4, and T5, respectively.

T1-> Write (K1, v1 '), write (K2, V2 '), T2-> Read (K1), Write (K3, V3 '), T3-> write (K2, V2 '), T4-> write (K2, v2 ' " '), read (K2), T5-> write (K6, V6 '), read (K5), was judged to be valid because T1 did not perform any read operations, and K1 and K1 corresponding values were written as V1 ' and V2 '. T2 is judged to be invalid because it reads the value of the K1 that has been modified. Therefore, the value of K3 does not change, T3 does not perform any read operations, so it is valid, the K2 value is modified to V2 ', and T4 is invalid because it attempts to read the value of the K2 that has been modified. The T5 read K5 is judged to be valid without any modification, and the K6 value is written as V6 '.