The first identified main component is Consensus. It relates to the set of rules and procedures that allow to maintain and update the ledger and to guarantee the trustworthiness of the records in the ledger, i.e., their reliability, authenticity and accuracy. Consensus varies across different blockchain technologies, every consensus mechanism brings advantages and disadvantages based on different characteristics e.g. speed of transactions, energy, efficiency, scalability, censorship-resistant and tamper proof. The set of rules and procedures compose the framework of the validation process necessary to overcane security issues during the validation. Consensus includes the following subcomponents and sub-subcomponents:
- Consensus Network Topology
- Consensus Immutability and Faure Tolerance
- Gossiping
- Consensus Agreement
(a) Latency
(b) Agreement
Those subcomponents are to be jointly considered when design in an active network consensus validation process because not only their indvidual configuration but also their combination determines when and how the overall blockchain agreement is achieved and the ledger updated.
4.1 CONSENSUS NETWORK TOPOLOGY
Consmsus Network Topology describes the type of interconnection between the nodes and the type of information flow between them for transactions and or validation purpose. For efficiency reasons, historically, systems have been designed in a centralised manner. This centralisation lowers dramatically the costs for system configuration, maintenance, adjustment (and the costs of arbitration in case of conflict) as this work has to be performed only once in a central place. While highly efficient in many situations, these kind of systems induce a single (or very limited set of) point(s) of failure and suffers of scalability issues. With respect to the network topology, this hierarchical arrangement is still present in most our techno and socioeconomic systems (one example is the modern electronic payment system).
Enlarged, these centralised arrangements become hierarchical constructs which exhibit larger scalability and more redundancy, while keeping efficient communication. Alternative to those centralised topologies, decentralised solutions have been proposed. Already since the dawn of the Internet, technical system shave evinced a transition towards decentralised arrangements whore all the nodes are equal to each other. For most applications, blockchain based systems with it's federated set of participants is a clear example of this kind Blockchain based systems resort on specific network topologies to create the peer network that ultimately determines how the validation process will evolve.
It is important to mention that Consensus Network Topology is linked to the level of decentralisation in the validation process but it is not the only determinant. Also other factors like for example the rewarding mechanism influence the validation. Take for example Bitcoin where a decentralised validation process may still be accompanied by the concentration of validation power of network participants. Indeed, during the period 2013-2015. the cumulative market share of the largest ten pools relative to the total market hovered in the 70-80% range.
LAYOUTS
We identify three possible layouts for Consensus Network Topology:
Decentralised.
There exist implementations that are decentralised. Bitcoin as the pioneer in digital currencies established a distributed P2P network, which enables direct transactions to every node within the network. The validation process within the Bitcoin network is decentralised through miners and full nodes who validate the transactions within thenetwork. This network illustrates a decentralised Consensus Network Topology. Obviously this layout is independent of the Consensus Immutability layout (Peercoin and NXT also show decentralised network topologies).Hierarchical.
There are other implementations that are not decentralised, and there exists an in homogeneity of the role the nodes have. For example, in Ripple the network topology is divided into tracking and validating nodes. The tracking nodes are the gateway for submitting a transaction or executing queries for the lodger in addition to that the validating nodes have the same functions as tracking nodes, but they can also contribute additional sequences to ledger by validation. This kind of solution yields (or can be extrapolated to) a hierarchical network topology. In the
community of developers these hierarchical topologies are usually referred to as "Consortium blockchains".Centralised.
In some specific implementations, a central authority may need (or wish) to control what is added to the ledger (an example for this are digital versions of fiat currencies: the so called central bank digital currencies). This kind of solution yields a third layer, 'Centralised topology', which is intimately related to private blockchains. It is important to mention that a centralised solution would normally speak of a non-properly working design (ar a non-solution) if implemented in terms of a blockchain, as it would have been implemented otherwise in a more transparent manner. Normally, some level of federation and redundancy are key to blockchain systems.