1) The client creates a transaction and sends it to endorsing peers of its choice
To invoke a transaction, the client sends a PROPOSE message to a set of endorsing peers of its choice.
Prerequisite: The set of endorsing peers for a given chaincodeId is made available to client via peer, which in turn knows the set of endorsing peers from endorsement policy.
2)The endorsing peer simulates a transaction and produces an endorsement signature
On reception of a PROPOSE message from a client, the endorsing peer first verifies the client’s signature and then simulates a transaction. Simulating a transaction means it tentatively executing a transaction, by invoking the chaincode to which the transaction refers and the copy of the state that the endorsing peer locally holds.
Endorsing peer will either endorse or decline the transaction and send message to the submitting client.
3)The submitting client collects an endorsement for a transaction and broadcasts it through ordering service.
The submitting client waits until it receives “enough” messages to conclude that the transaction proposal is endorsed. The exact number of “enough” depend on the chaincode endorsement policy. The collection of signed TRANSACTION-ENDORSED messages from endorsing peers which establish that a transaction is endorsed is called an endorsement. For transaction with a valid endorsement, we now start using the ordering service. The submitting client invokes ordering service using the broadcast(blob), where blob=endorsement
If the submitting client does not manage to collect an endorsement for a transaction proposal, it abandons this transaction with an option to retry later.
4)The ordering service delivers a transactions to the peers
When a deliver event occurs a peer does the following:
a) It checks if endorsement is valid according to the policy of the chaincode.
b) If all these checks pass, the transaction is deemed valid or committed.
c) If the verification fails, the transaction is invalid and state remains untouched.