Hyperledger Fabric: Transaction

Transactions

Fabric introduces a new architecture for transactions that we call execute-order-validate. It addresses the resiliency, flexibility, scalability, performance and confidentiality. Hyperledger Fabric introduces a model based on three steps, an endorse-order-validate architecture

1. Endorsement of a transaction and checking its validity (validation step): This step includes members of a channel to inspect and adhere to endorsement policies which define the acceptable agreed upon approach to validate a transaction proposal. Since peers need to update the ledger ( upon transaction finality) the peers ( that are subscribed to a channel) review the proposal and provide their ledgers version of (R)ead and (W)rite set. This validation step is vital as it provides the first step on transaction validation. This check also acts as a gate and prevents form erroneous downstream processing of transaction, which can be computationally expensive.
2. Ordering through an ordering service: This is a consensus protocol which is meant to be pluggable, irrespective of transaction semantics. The pluggability of the consensus provides enterprise and business networks with tremendous flexibility, as there are consensus mechanism considerations for various types of industries, use cases, and interactions between network participants.
3. Validation or transaction commitment: This implies committing a transaction and therefore going through a final set of validations per application-specific trust assumptions.

A Hyperledger Fabric transaction involves three types of nodes:

• The committing peer is the node that maintains the ledger and state. The committing peer is the party that commits transactions and may hold the smart contract or chaincode.
• The endorsing peer is a specialized committing peer that can grant or deny endorsement of a transaction proposal. The endorsing peer has to hold the smart contract.
• The ordering nodes (service) communicate with the committing and peer nodes; their main function is to approve the inclusion of transaction blocks into the ledger. Unlike the committing peer and endorsing peer, the ordering nodes do not hold the smart contract or the ledger.

Designed for the distributed execution of untrusted code in an untrusted environment. This separation not only allows for provisioning at scale, but also ensures security by separation at every layer.

A Hyperledger Fabric transaction involves three types of nodes:

• The committing peer is the node that maintains the ledger and state. The committing peer is the party that commits transactions and may hold the smart contract or chaincode.
• The endorsing peer is a specialized committing peer that can grant or deny endorsement of a transaction proposal. The endorsing peer has to hold the smart contract.
• The ordering nodes (service) communicate with the committing and peer nodes; their main function is to approve the inclusion of transaction blocks into the ledger. Unlike the committing peer and endorsing peer, the ordering nodes do not hold the smart contract or the ledger.

Validation can be divided into two roles, endorsement and ordering:

• Endorsing a transaction means verifying that it obeys a smart contract; endorsers sign the contract to complete this aspect of validation
• Ordering verifies transactions for inclusion in the ledger; this form of validation helps to control what goes in the ledger and ensure its consistency

Records all transactions which have resulted in a the current value of the world state; its the update history of the world state. Not pluggable simply record the before and after values of the ledger database being used by the blockchain network.

Application submit a transaction, each node will have an endorsing policy, defines who can do what. Each endorsing runs the transaction against the smart contract checking to see if rules are being followed. If transaction is valid the it is sent back with a signature. The signature states the the transaction was valid. Read/Write is set what states what I am reading from the database and what I am writing to the database.

Next step transaction is submit to the ordering service parallel, sends out to all peer what will be in the next block. Every committing peer validates against the endorsement policy, validate next block will be added to chain and then send out to the world that this block is being added. Seven step process for consensus, ordering service Kafka

Transaction is a seven step process

1. Client logs in to a CA to obtain ECert
2. Client sends a proposal to an endorser
3. Endorser checks permissions and simulates chaincode transaction, result is yes/no, the returned endorsement is signed.
4. Client receives enough endorsements and checks whether the number of endorsements is valid
5. Client sends the endorsed transactions to Orderers
6. Orderers sort read-write sets and build blocks based on block configuration. Send the block to committer
7. Committer checks block, transaction read-write set, endorsement policies, writes to blockchain and updates World State DB

Refers to an operation in which an authorized end user performs read/write operations against the ledger. There are three unique types of transactions

1. Deploy
2. Invoke
3. Query

Please checkout the below links

Resume website — https://tommarler.org

Linkedin — https://www.linkedin.com/in/tom-m-bb4857112/