Date
1 - 4 of 4
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.
----- Original message -----
|
|
|
|
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
|
|
|
