Intro to Private Blockchains

Transaction Flow



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 can be required to 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.

NOTE: You can find the full docs here.

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 // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

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... // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

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 // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

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... // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

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... // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

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... // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

A: Appending Transaction; B: App.

The full flow is seen in the figure below:

FULL FLOW // https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

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.