Consensus Algorithm (Validation & Commit Phase) Questions #consensus #raft


Robert Broeckelmann
 

Hello.

I've been researching details of how the validation phase of the default HyperLedger Fabric consensus algorithm works. We're using the RAFT Orderer. I've got a couple of questions:
 
1. We've found the code (HLF 1.4.2 code base) where each peer individually (and locally) validates each transaction in a block before committing the block to the local copy of the blockchain. Does the HLF 1.4.2 peer validate the hash (DataHash field) on each block before committing the block to the local blockchain? We haven't been able to find where this happens in the code.
2. If there were a difference between the validation phase results of a block between two peers, for whatever reason, what happens? Is there some type of coordination (voting) on what the results should be for block validation between the committing peers (all peers on a channel)?
3.  The HLF Consensus Algorithm is described as a voting-based algorithm. Is that referring to the "voting" that occurs in the Endorsement Phase as to whether an endorsing peer endorses a transaction? Or, does it refer to each peer validating the "block" and "voting" on whether the block is valid?  I'm likely abusing nomenclature in at least one of those sentences:).
4. Are the answers to any of these questions different for the Kafka Orderer?

Thanks ahead of time.

RCBJ


conanoc
 

1. See VerifyBlock() function in internal/peer/gossip/mcs.go 
2. There is no coordination for peer consistency. Document says that only valid transactions are applied to the peer's world state, which means each peer can have different world state. But I could not find the code for that. https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
3. Currently, the voting in HLF is done only in the leader election of RAFT orderer. It's not for block or tx. https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html#how-leader-election-works-in-raft
4. There is no voting in Kafka orderer and orderer does not affect validations in peer side.

-----Original Message-----
From: <robert@...>
To: <fabric@...>;
Cc:
Sent: 2019-09-03 (화) 13:56:06 (GMT+09:00)
Subject: [Hyperledger Fabric] Consensus Algorithm (Validation & Commit Phase) Questions #consensus #raft
 

Hello.

I've been researching details of how the validation phase of the default HyperLedger Fabric consensus algorithm works. We're using the RAFT Orderer. I've got a couple of questions:
 
1. We've found the code (HLF 1.4.2 code base) where each peer individually (and locally) validates each transaction in a block before committing the block to the local copy of the blockchain. Does the HLF 1.4.2 peer validate the hash (DataHash field) on each block before committing the block to the local blockchain? We haven't been able to find where this happens in the code.
2. If there were a difference between the validation phase results of a block between two peers, for whatever reason, what happens? Is there some type of coordination (voting) on what the results should be for block validation between the committing peers (all peers on a channel)?
3.  The HLF Consensus Algorithm is described as a voting-based algorithm. Is that referring to the "voting" that occurs in the Endorsement Phase as to whether an endorsing peer endorses a transaction? Or, does it refer to each peer validating the "block" and "voting" on whether the block is valid?  I'm likely abusing nomenclature in at least one of those sentences:).
4. Are the answers to any of these questions different for the Kafka Orderer?

Thanks ahead of time.

RCBJ


Yacov