# Practical I-Voting on Stellar Blockchain
## 2 Blockchain Technology for I-Voting
### Stellar Consensus Protocol  
Blockchains, like all distributed systems, have to solve certain kinds of problems to work properly. The core problem is how to reach consensus among all network participants, assuming that some of them can fail-stop or even be Byzantine-faulty [22]. Classical vote-based consensus mechanisms like Paxos [23,24], Raft [25] or PBFT [26] are not suitable for decentralized global scale systems. They do not promote easy decentralization and often introduce a lot of network overhead. Bitcoin proof-of-work consensus protocol initiated a new category of consensus mechanisms called Nakamoto Consensus, in which the leader--capable of updating the ledger--is elected in the form of a lottery, where the chance of winning is proportional to the amount of spent resources. In proof-of-work, this resource is computational power, in proof-of-stake [27] it is staked cryptocurrency, in proof-of-burn [28] it is burned cryptocurrency, in proof-of-importance [29] it is the reputation of the node. Continuously new types of resources are being proposed as well as hybrids of them. Nodes are incentivized to honest behavior by the reward system and discouraged from cheating by the punishment system. Stellar Consensus Protocol (SCP) uses its unique Federated Byzantine Agreement (FBA) consensus protocol that gives the best of both categories. It is a fast vote-based consensus protocol similar to Practical Byzantine Fault Tolerance (PBFT), but instead of a static list of network participants, it allows open membership. In SCP, all nodes select their trusted set of nodes called quorum slice. The quorum slice may, and should, differ for each node. Transitive trust for all node's quorum slice members forms a quorum. There must be at least one node overlap for any two quorums to prevent network partitioning, namely, the quorum-intersection requirement. In case of lack of quorum-intersection, the network halts until it gets reconfigured by nodes' administrators. When the nodes attend to agree on one version of the ledger, they start the voting process inside their quorum, ultimately reaching consensus. Furthermore, SCP does not introduce the concept of mining; therefore, the incentive of joining the network as a validator is much smaller than joining as a miner, so the Stellar network is not as decentralized as, e.g., Bitcoin or Ethereum. In the paper [30], the authors show that the whole Stellar public network can stop if only two nodes controlled by Stellar Foundation fail. [PERSON], who designed the SCP, addressed this issue [31], and claims that the problem was caused by network misconfiguration rather than protocol flaw. Stellar solved this by introducing multiple improvements: (1) validators managed by a single organization are grouped together so that no single organization should be able to reach the consensus threshold alone (2) introducing node tiers (high, medium, low), so that agreement among all low tier nodes equals one vote in medium node tier, and agreement among all medium tier nodes equals one vote in high node tier (3) adding automatic quorum configuration, which facilitates the process of choosing correct quorum slices [32] (4) adding quorum intersection checker [33] for identifying misconfigurations. In the Figure 1.  
We can see the Stellar public network graph. Nodes represent the validators (servers running Stellar Core software), and edges represent their quorum slices. At the time of writing, the network consists of 59 Node validators held by 18 organizations, most of them located in the USA, Europe, and East Asia. Figure 1: Stellar public network structure. Source: [[https://stellarbeat.io](https://stellarbeat.io)]([https://stellarbeat.io](https://stellarbeat.io)). According to FLP impossibility [34], all of those consensus protocols face the trilemma, where only two of three properties can be achieved. Those properties are Fault tolerance, Safety, and Liveness. Fault tolerance is defined as the ability to survive node failure.