Forcing leader election in RAFT-based replication

[chintanr97]

In the initial CCF research paper (here), in section VI, page 12, we can find the below paragraph after BFT configuration section:

This protocol configuration supports robust view changes that guarantee safety and liveness if fewer than 1/3 of the replicas are corrupt. The primary for every view is pre-determined, using the next replica in round-robin according to their ordering in the NODE table. This is important to prevent malicious nodes from being primaries indefinitely.

Now, I am guessing this could be applicable for RAFT-based replication configuration too. But I would like to confirm for the same!

While studying etcd RAFT-based consensus protocol implementation (in different blockchains, e.g., Hyperledger Fabric), I learnt that the leader election happens only while the leader is unable to send heartbeats within specified intervals (either due to network failures or the node itself going down). In this case, it would be very difficult to control the state of the ledger if the leader node goes malicious.

I would like to understand, how the CCF implementation of RAFT replication protocol is guaranteeing a new leader (or primary) election with every view change transaction, if it is supported currently or otherwise, if there is a plan to achieve it in future.

[achamayou]

@chintanr97 this primary selection mechanism is not applicable to CFT/Raft, where election is timeout driven.

The CFT implementation in CCF makes no attempt to "control the state of the ledger if the leader node goes malicious", all it offers is provenance: transactions must be signed by the leader's key for followers to accept them and for them to be valid ledger entries.

CFT implements crash fault tolerance, ie. liveness and persistence in the face of up to f nodes becoming unavailable. It provides no guarantee in the face of malicious nodes. Because the variant of CFT in CCF enforces signatures, the node responsible for the execution can be identified, and blamed in later audit.

The main protection against malicious node behaviour in CCF when using CFT comes from running in enclave and validating node attestation.