Why does the Ordering Consensus Work?


Trevor Lee Oakley <trevor@...>
 

 
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
 
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
 
 
Trevor
 


Brett T Logan <brett.t.logan@...>
 

The ordering services job is to assemble blocks from transactions and determine the final order of the transactions. It doesn't participate in the validation of the endorsed transactions.
 
Once the orderer disseminates the block to the peer, the peer validates the signatures, verifies that its endorsements match their expected origin, and that the state of the transaction matches the current state given the current values in the ledger (the state of a key hasn't changed since the proposal was submitted for endorsement as the result of an in-flight transaction).
 
Your transaction has (assuming it was valid) already passed your endorsement policy, the result of the smart contracts doesn't have to match for all proposals. This is why we write deterministic chaincode, to prevent chaincode from arriving at different results.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Trevor Lee Oakley" <trevor@...>
Sent by: fabric@...
To: <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work?
Date: Wed, Feb 5, 2020 10:30 PM
 
 
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
 
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
 
 
Trevor
 
 


Gari Singh <garis@...>
 

Transaction consensus and validity in Fabric is not the same thing as the consensus mechanism used to build a fault tolerant ordering service.

Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.0/txflow.html which describes the entire Fabric transaction flow ... this would be considered consensus for Fabric transactions. At a high-level, it is comprised of:

- execute chaincode and collect endorsements
- submit for ordering
- ordering service orders and batches into blocks
- ordering service pushes blocks to peers on a per channel basis
- peers validate and commit transactions
- check that endorsement policy has been satisfied (which means that enough peers executed chaincode with the same results based on policy)
- check for collisions using an MVCC-like model (aka double-spend)
- if valid, update state


The ordering service itself uses a consensus algorithm itself to make sure that all ordering nodes produce batches/blocks with the same transactions in the same order.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: <fabric@...>
From: "Trevor Lee Oakley"
Sent by: fabric@...
Date: 02/06/2020 03:30AM
Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work?


From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?

Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?


Trevor


Nikhil Gupta
 

Want to jump in to clear up something Brett said. If the chaincode is non-deterministic, then the read write sets will not match and will not pass the endorsement policy, and proposals will be rejected at the last stage of the transaction flow. The endorsement itself prevents non-deterministic chaincode from leading to divergent results.

Nik



-----fabric@... wrote: -----
To: trevor@...
From: "Gari Singh"
Sent by: fabric@...
Date: 02/05/2020 11:29PM
Cc: <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Why does the Ordering Consensus Work?

Transaction consensus and validity in Fabric is not the same thing as the consensus mechanism used to build a fault tolerant ordering service.

Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.0/txflow.html  which describes the entire Fabric transaction flow ... this would be considered consensus for Fabric transactions.  At a high-level, it is comprised of:

- execute chaincode and collect endorsements
- submit for ordering
- ordering service orders and batches into blocks
- ordering service pushes blocks to peers on a per channel basis
- peers validate and commit transactions
  - check that endorsement policy has been satisfied (which means that enough peers executed chaincode with the same results based on policy)
  - check for collisions using an MVCC-like model (aka double-spend)
  - if valid, update state


The ordering service itself uses a consensus algorithm itself to make sure that all ordering nodes produce batches/blocks with the same transactions in the same order.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: <fabric@...>
From: "Trevor Lee Oakley"
Sent by: fabric@...
Date: 02/06/2020 03:30AM
Subject: [EXTERNAL] [Hyperledger Fabric] Why does the Ordering Consensus Work?

  
From what I know, the orderer is just assembling blocks from application transactions composed of the endorser responses to proposals. Then sending the blocks to committing peers. How is that a consensus process?
  
Surely we have to somehow compare the outcomes of the smart contracts and check that they all agree? Is that done in validation somehow?
  
  
Trevor