📑About Hyperledger Fabric
💡Hyperledger Fabric
Hyperledger is an open-source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration including leaders in banking, finance, Internet of Things, manufacturing, supply chain, and technology. The Linux Foundation hosts Hyperledger under the foundation.
CONSENSUS - Participants will collectively agree that each transaction is valid and the order of the transaction in relation to others. (ex: 2 of 6 or 3 of 6)
PROVENANCE - Participants know the history of the asset, for example, how its ownership has changed over time, the lifecycle, the history of the asset.
IMMUTABILITY - No participant can tamper with a transaction once it's agreed.
FINALITY - Once a transaction is committed, it cannot be reversed, in other words, the data cannot be rolled back to the previous state. If a transaction was in error then a NEW transaction must be used to reverse the error, with both transactions visible.
Hyperledger Fabric Architectural Model
Hyperledger Fabric (HLF) Components
Hyperledger Fabric Architecture
Application interaction with HLF
Requirements for an enterprise blockchain use case
Blockchains for business generally prioritize – Assets over cryptocurrency; Identity over anonymity; Selective endorsement over proof of work.
Assets are anything of value, on the blockchain, these are represented digitally using a pre-agreed format.
Transactions change the state of an asset and are provably recorded on the blockchain ( e.g.transfer ownership, change colour) they are underpinned by smart contracts, verifiable business rules that cause the asset to change state
Identity is used to ensure business networks are kept private and individual transactions confidential with transparency for the regulator
Endorsement is the process in which a transaction is verified as “good”. Ensures that participants are happy to accept the transaction and prevents (e.g.) double-spending. In the real world, transactions are endorsed by a small number of participants (e.g. sender bank, receiver bank, payments provider) and must be completed in an appropriate timeframe.
The architecture of a Fabric’s solution
To achieve consensus, and given that there is an assumption of partial trust in a Hyperledger Fabric network, Fabric uses a permissioned voting-based scheme, which achieves low-latency.
The endorsement policy defines the voting-based scheme to be used by peers and, consequently, the weight of each peer regarding the validity of a transaction.
The transaction flow, which follows the execute-order-validate paradigm, is as it follows:
1.
Transaction proposal. A blockchain client, which represents an organization, creates a transaction proposal, and sends it to endorsement peers, as defined in the endorsement policy. The proposal contains information regarding the identity of the proposer, the transaction payload, a nonce, and a transaction identifier.
2.
Execute (endorsement): the endorsement consists of the simulation of the transaction. The endorsers produce a write-set, containing the keys and their modified values, and a read-set. The endorsement peers also check the correctness of transaction execution. The endorsement is sent as the proposal response and contains the write-set, read-set, the transaction ID, endorser’s ID, and the endorser’s signature. When the client collects enough endorsements (which need to have the same execution result), it creates the transaction and sends it to the ordering service. The endorsement phase eliminates any eventual non-determinism.
3.
Order: after the endorsement, there is the ordering phase, performed by orderers. The ordering service checks if the blockchain client that submitted the transaction proposal has appropriate permissions (broadcast and receiving permissions), on a given channel. Ordering produces blocks containing endorsed transactions, in an ordered sequence, per channel. The ordering allows the network to achieve consensus. The orderer broadcasts the transaction’s outputs to all the peers.
4.
Validate. Firstly, each peer validates the received transactions by checking if a transaction follows the correspondent endorsement policy. After that, a read-write conflict check is run against all transactions in the block, sequentially. For each transaction, it compares the versions of the keys in the read-set with those currently on the ledger. It checks if the values are the same. In case they do not match, the peers discard the transaction. Finally, the ledger is updated, in which the ledger appends the created block to its head. The ledger appends the results of the validity checks, including the invalid transactions.
Last updated
