Fabric chain code interacts with peer node through gprc
When the peer node receives the input (propsal) requested by the client, it will send a chain code message object (with input information and caller information) to the corresponding chain code.
The chain code calls the invoke method in ChaincodeBase to obtain the ledger status information and send the pre submission status to the peer node by sending the getState and putState messages.
The chain code sends the final output result to the peer node, and the node endorses and signs the input (propsal) and output (propsalreponse) to complete the first signature submission.
After that, the client collects the first segment of the submission information of all peer nodes, assembles the transaction and signs it, sends the transaction to the orderer node for queuing, and finally the orderer generates the block and sends it to each peer node, and puts the input and output on the ledger to complete the second segment of the submission process.
Basis of chain code development:
The foundation of chain code development can be summarized as follows: one base class, two queries, and one write.
A base class: ChaincodeBase
In Java, ChaincodeBase is the contract base class of user-defined chain codes. The run (ChaincodeStub stub, String function, String [] args) method is the entry function for peer to call chain codes. An init method must be customized for contract initialization and upgrade initialization.
Because of its dynamic interface characteristics, GO does not need to specifically declare the implementation of the contract interface. However, two interface methods must be implemented:
▪ Init (stub shim. ChaincodeStubInterface): init is used for contract initialization and upgrade initialization;
▪ Invoke (stub ship. ChaincodeStubInterface): Invoke is the entry function of peer calling chain code; ChaincodeStub contains rich ledger operations, such as getCallerCertificate(), getState (k), putState (k, v), invokeChaincode (...), rangeQueryState (k1, k2), getTxId(), etc.
Two queries: getState (k) and rangeQueryState (k1, k2)
GetState (k) gets the value corresponding to a separate key.
RangeQueryState (k1, k2) gets all k-v objects that start with k1 and end with k2, and returns Map<String, String>objects, where k1 and k2 are sorted lexicographically.
One write: putState (k, v),
Write the data. It should be noted here that putState data will not fall into the ledger immediately. The data will not fall into the ledger until the second transaction submission consensus is reached.
Chain code development experience
- Store the business entity in Json mode and create an index on the key
Because there is only one key val status database, the data whose value is Json can be quickly parsed. The key is added with the value of some simple index fields, such as Pk_ TxId Transaction ID_ A field value to realize range query.
The leveldb used by the k-v library of the fabric, and the lexicographical order used by the inserted key values. Therefore, the index field values must have a fixed length, or call stub. rangeQueryState (k1, k2) for range query, and a heap of incorrect data will be taken out.
- The written data cannot be obtained immediately
The data written through putState will not fall into the ledger immediately. The data will not fall into the ledger until the consensus of all peer nodes in the second transaction is reached. Therefore, it is not possible to immediately obtain the previously written values, such as batch inserting data, using putState to write data, and then using the getState function to determine whether the primary key is repeated.
- Do the methods in the chain code need to be locked
unwanted. The peer node has implemented the message queue. The chain code messages sent to the chain code are executed sequentially, not in parallel.
