IT-SDK-Hyperledger-Fabric

Ref.

• https://www.serial-coder.com/post/demystifying-hyperledger-fabric-fabric-architecture/#the-consensus-in-hyperledger-fabric
• https://medium.com/xord/hyperledger-fabric-architecture-a-deep-dive-cea478f39765
• https://www.spydra.app/blog/architecture-of-hyperledger-fabric-an-in-depth-guide
• https://developer.ibm.com/articles/blockchain-basics-hyperledger-fabric/
• https://hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html

Key Components

• Client: is a node that considered to be an application that interacts with Fabric blockchain network.
• Peer: is a node that stores all transactions on a joining channel.
  • Endorsing peer: validate a proposed transaction by executing the associated smart contract (chaincode) and returning the result without updating the ledger.
  • Committing peer: validating and committing transactions to the blockchain ledger.
• Orderer: is node responsible for ordering transactions, creating a new block of ordered transactions, and distributing a newly created block to all peers on a relevant channel.
• CA (Certificate Authority): is responsible for issuing and managing user certificates, such as user registration, user enrollment, user revocation, and etc.
• MSP (Membership Services Provider): is a node that Manages identities and permissions of users and nodes within the network.
• Channels
• Chaincode
• Ledger
• Asset: is a digital or physical values stored on the blockchain, managed, and modified through smart contracts (chaincode).

Key Words

• read-write set: read set (data read from the ledger) and a write set (proposed changes).
• endorse: means to approve, support, or confirm something officially.

Basic workflow v1

1. Client makes a transaction proposal, signs the proposal with User’s certificate, and sends the transaction proposal to a set of pre-determined Endorsing Peers on a specific channel.
2. Each Endorsing Peer verifies User’s identity and authorization from the proposal payload. Endorsing Peer simulates the transaction, generates a response together with a read-write set, and endorses the generated response using its certificate.
3. Client accumulates and checks the endorsed proposal responses from Endorsing Peers.
4. Client sends the transaction attached with the endorsed proposal responses out to Orderer.
5. Orderer orders the received transactions, generates a new block of ordered transactions, and signs the generated block with its certificate.
6. Orderer broadcasts the generated block to all Peers (to both Endorsing Peers and Committing Peers) on the relevant channel.
   1. Then, each Peer ensures that each transaction in the received block was signed by the appropriate Endorsing Peers (i.e., determining from the invoked chaincode’s endorsement policy) and enough endorsements are present.
   2. After that, a versioning check (called the multi-version concurrency control (MVCC) check) will take place to validate the correctness of each transaction in the received block. That is, each Peer will compare each transaction’s readset with its ledger’s world state. If the verification check passes, the transaction is marked as valid and each Peer’s world state is updated. Otherwise, the transaction is marked as invalid without updating the world state. Finally, the received block is appended into each Peer’s local blockchain regardless of whether or not the block contains any invalid transactions.
7. Client receives any subscribed events from EventHub service.

Basic workflow v2

• The submitting client creates a transaction and sends it to endorsing peers of its choice.
• The endorsing peer simulates a transaction and produces an endorsement signature.
• The submitting client collects an endorsement for a transaction and broadcasts it through ordering service.
• The ordering service delivers a transactions (blocks) to the committing peers.
• The committing peers appended transaction to the Ledger.