Re: Why does the Ordering Consensus Work?
|
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
|
|
|