Fabric Chaincode Overview

The fabric is a ledger of events(transactions), shared among different participants, each having a state in the system. The ledger can only be updated by consensus of the participants, once recorded, information can never be altered.

Transactions are secured, private, and confidential. Each participant registers with proof of identity to the network membership services to gain access to the system. Transactions are issued with derived certificates unlinkable to the individual participant, offering a complete anonymity on the network.

Transaction: a request to the blockchain to execute a function on the ledger, which is implemented by a chaincode. Each invocation of a chaincode is a transaction.

Ledger: a sequence of cryptographically linked blocks, containing transactions and current world state. Blockchain holds historic sequence of all chaincode transactions.

World State: the collection of variables containing the results of executed transactions(deployed chaincode), like a key-value database.

Validating Peer: A node is responsible for running consensus, validating transactions, and maintaining the ledger.

Non-validating Peer: A node functions as proxy connecting clients to the neighboring validating peers. It hosts the event stream server and the REST service.

Chaincode: an application-level code stored on the ledger as a part of a transaction to be distributed to the network and managed by each validating peer as isolated sandbox. Chaincode runs transactions that may modify the world state.


Chaincode Mechanism

There are 3 types of transactions. A deploy transaction installs the specified chaincode on the chain,
while invoke and query transactions call a function of a deployed chaincode.

The fabric instantiates the VM when it processes a Deploy transaction. Once the chaincode container is up, it makes a gRPC connection back to the validating peer that started the chaincode, and that establishes the channel for Invoke and Query transactions on the chaincode.

There is a shim layer on the chaincode container to handle the message protocol between the chaincode and the validating peer using protobuf message.

1. Deploy


Upon deploy(chaincode container is started), the shim layer sends a one time REGISTER message to the validating peer with the payload containing the ChaincodeID.

After registration, the validating peer sends INIT with the payload containing a ChaincodeInput object. The shim calls the Init function with the parameters from the ChaincodeInput, enabling the chaincode to perform any initialization.

Init is called when you first deploy your chaincode. This function should be used to do any initialization your chaincode needs.

2. Invoke

When processing an invoke transaction, the validating peer sends a TRANSACTION message to the chaincode container shim, which in turn calls the chaincode Invoke function, passing the parameters from the ChaincodeInput object. The shim responds to the validating peer with RESPONSE message.

Invoke is called when you want to call chaincode functions to do real work. Invocations will be captured as a transactions, which get grouped into blocks on the chain. When you need to update the ledger, you will do so by invoking your chaincode.

3. Query

When processing a query, the validating peer sends a QUERY message to the chaincode container shim, which in turen calls the chaincode Query function, passing the parameters from the ChaincodeInput object. The Query function may return a state value, which the shim forwards to the validating peer using RESPONSE message.

Query doesn't affect the state of the chaincode, and thus there is no need for the state to be retrieved(decrypted) or updated(encryped) after the execution of the chaincode completes.
Use Query to read the value of your chaincode state's key/value pairs.

All you need to do is implement the chaincode shim interface. The three functions you have to implement are Init, Invoke, and Query. They take in a 'stub', which is what you use to read from and write to the ledger, a function name, and an array of strings. 

Finally, you need to create a short main function that will execute when each peer deploys their instance of the chaincode. It just calls shim.Start(), which sets up the communication between this chaincode and the peer that deployed it.


Integrate with External Systems

If each smart contract calls out to external system to receive information or uses a non-deterministic variable, it will prevent consensus being achieved.
All external data sources should return the same result for the same calls and variables must be deterministic, any non-deterministic values must be defines as part of the transaction

PBFT Consensus Protocol

Defines non-validating peers, validating peers, with 1 validating leader.
Leader receives transactions submitted from the connected applications.
Leader orders and distributes transactions with validator network to cope with malicious validators..
Each v-peer executes transactions to bring local ledger copy up-to-date.
Non-validating-peers' ledgers are maintained from their connected v-peers.

Reference:

https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md
https://github.com/ibm-blockchain/learn-chaincode/tree/v2.0
https://www.ibm.com/developerworks/community/blogs/8d277a63-4204-4fd3-8cb8-b7cb222cd522/entry/Steps_to_setup_Blockchain_Hyperledger_Fabric_0_6_development_environment_on_Ubuntu?lang=en