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.
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
No comments:
Post a Comment