The fraction of malicious or faulty nodes that the consensus protocol can tolerate (i.e., it will operate correctly despite the presence of such nodes).
Whether the code implementing the system is publicly available.
How the participants work together to participate in the consensus protocol; either they all work together (single committee), or they are divided in multiple subgroups (multiple committees).
How the members of the committee are chosen, for example via proof-of-work, proof-of stake, trusted hardware etc.
The likelihood that the system will reach consensus on a proposed value; it can be either strong or weak.
Resilience of the node(s) involved in consensus to denial-of-service (DoS) attacks. If the participants of the consensus protocol are known in advance, an adversary may launch a DoS attack against them.
The mechanisms that keep nodes motivated to participate in the system and follow its rules. • Inter-committee Configuration: How the members are assigned to the committee in a single committee setting; either members serve on the committee permanently (static), or they are changed at regular intervals (rolling, or full swap).
The time it takes from when a transaction is proposed until consensus has been reached on it.
The leader of the consensus protocol, which can be either elected among the current committee (internally), externally, or flexibly (e.g., through arbitrary smart contracts).
The nodes that participate in the consensus protocol.
Only participants selected by the appropriate authorities can participate in the consensus protocol.
Anyone can join the system and participate in the consensus protocol.
The system’s ability to achieve greater throughput when consensus involves a larger number of nodes.
Sharding aims to split (shard) state information across nodes, without requiring any node to have a full picture of the network. Therefore no validator will validate all shards.
The maximum rate at which transactions can be agreed upon by the consensus protocol (transactions per second/hour).
The system’s resilience to proposed transactions being suppressed (i.e., censored) by malicious node(s) involved in consensus.
A Zero Knowledge Proof (ZKP) is a method by which one party (the prover) can prove to another party (the verifier) that she knows a value X, without revealing the value itself.