How are blocks created?
In order to integrate privacy and permissions into the Hyperledger architecture, there are a few additional features which have been added on top of the Bitcoin design pattern. In the Hyperledger context, clients still propose transactions to the network, but the process for validating these transactions is slightly different.
In a Hyperledger app, a transaction must find multiple endorsements from trusted parties within the system before it can be added to the blockchain. Endorsements can be configured to ensure a minimal risk of fraud within the system. An example of this might be to require a business partner to verify certain details of a transaction before it is written to the public ledger. Once all necessary endorsements have been met, the transaction is passed to an ordering node, which will add it to the chain, or Validated Ledger.
GENERAL TRANSACTION FLOW
1. Client Initiates Transactions
To initiate a transaction, the client creates a properly formatted proposal via the Hyperledger Software Development Kit (SDK), and signs it from their identity, and then transmits it to the network for approval.
CLIENT INITIATES TRANSACTIONS // Hyperledger Docs
A: Client A; B: SDK; C: Proposal; D: Peers.2. Endorsing Peers Verify Signature and Execute the Transaction
If an Endorsing Peer receives a transaction with a valid signature from a known peer, they can execute it and sign a Proposal Response, which can be passed to the wider network as a change to the state object.
ENDORSING PEERS... // Hyperledger Docs
A: App; B: Signed Proposal Response; C: Signatures; D: Peers.3. Proposal Responses are Inspected
Proposal Responses are transmitted across the network and inspected by each node independently using the SDK. The nodes can then endorse the proposal as well, or simply act as witnesses.
PROPOSAL RESPONSES ARE INSPECTED // Hyperledger Docs
A: SDK.4. Client Assembles Endorsements into a Transaction
Once a predetermined minimum endorsements is met, the client software can assemble them into a Transaction, or State Transition, which is passed to the Ordering nodes, which will add it to the blockchain.
CLIENT ASSEMBLES... // Hyperledger Docs
A: SDK; B: Channels; C: Ordering Service; D: Ordered Transactions.5. The transaction is Verified and Committed to the Ledger
Ordering nodes accomplish consensus through a complex process known as Proof of Authority, which enables them to determine which order the transactions should fall into based on a predetermined hierarchy between known nodes.
THE TRANSACTION IS... // Hyperledger Docs
A: Ordering Service; B: Peers; C: Transaction.6. The Ledger is updated across all nodes
Once the State Object has been updated, and the Verified Ledger is confirmed by the Ordering Nodes, each client node can now read the new information with confidence.
THE LEDGER IS... // Hyperledger Docs
A: Appending Transaction; B: App.The full flow is seen in the figure below:
FULL FLOW // Hyperledger Docs
A: Collect TRANSACTION-ENDORSED Msgs into a valid endorsement that satisfies endorsementPolicy (chaincodeID) broadcast(endorsement); B: tx=<clientID, chaincodeID, txPayload, timeStamp, clientSig>; C: Simulate/Execute tx Sign TRANSACTION-ENDORSED; D: Verify endorsement, readset if OK, apply writeset to state; E: Ordering service; F: VClient (C); G: Endorsing Peer (EP1); H: Endorsing Peer (EP2); I: Endorsing Peer (EP3); J: Orderers; K: (Committing) Peer (CP1).If this all seems very complicated, don't worry! The SDK takes care of most of the work, as we'll see in the next lesson.
