Sybil in the Haystack: A Comprehensive Review of Blockchain Consensus Mechanisms in Search of Strong Sybil Attack Resistance

Abstract

Consensus algorithms are applied in the context of distributed computer systems to improve their fault tolerance. The explosive development of distributed ledger technology following the proposal of ‘Bitcoin’ led to a sharp increase in research activity in this area. Specifically, public and permissionless networks require robust leader selection strategies resistant to Sybil attacks in which malicious attackers present bogus identities to induce byzantine faults. Our goal is to analyse the entire breadth of works in this area systematically, thereby uncovering trends and research directions regarding Sybil attack resistance in today’s blockchain systems to benefit the designs of the future. Through a systematic literature review, we condense an immense set of research records (N = 21,799) to a relevant subset (N = 483). We categorise these mechanisms by their Sybil attack resistance characteristics, leader selection methodology, and incentive scheme. Mechanisms with strong Sybil attack resistance commonly adopt the principles underlying ‘Proof-of-Work’ or ‘Proof-of-Stake’ while mechanisms with limited resistance often use reputation systems or physical world linking. We find that only a few fundamental paradigms exist that can resist Sybil attacks in a permissionless setting but discover numerous innovative mechanisms that can deliver weaker protection in system scenarios with smaller attack surfaces.

1. Introduction

Decentralised systems, such as blockchains underpinning cryptocurrencies, have first introduced the need for Sybil attack resistance (see Section 1.1.5), owing to their openness. As the need for Sybil attack resistance only arises in these truly decentralised systems, research into these attacks is still in its infancy. Many different consensus mechanisms, varying greatly in specification quality, have been proposed after 2008 when Bitcoin [1] set in motion the blockchain era. This environment is particularly conducive to our research: while numerous literature reviews have targeted consensus mechanisms (see Section 3.2), to the best of our knowledge, no previous work focusing on Sybil attack resistance exists. Given the challenging effects the latest ‘crypto winter’ [2] might have on the blockchain industry, academia’s role is to research fit-for-purpose approaches on which mature and useful systems can be built. Providing a classification and taxonomy of Sybil attack resistance schemes is key to this.

1.1. Context

The long and rich history of distributed systems research directly leads up to modern Blockchain consensus: contrary to popular belief [3,4], Nakamoto’s consensus mechanism Proof-of-Work (PoW) [1] is not an isolated stroke of genius but, like many modern developments in the field of distributed systems, dependent on the rigorous work of previous generations of researchers [5]. Nakamoto’s contribution is to combine well-studied ideas to enable a new class of distributed systems, the decentralised systems. This section outlines how researchers contribute to the study of decentralised consensus in creative ways, often combining decades-old findings with modern requirements.

1.1.1. Resilient Distributed Systems

The earliest attempts at remotely controlling computers before the post-war era [6] aside, the concept of geographically distributed computers collaborating was introduced in the 1950s. These early computer systems emerged in the military domain and were coordinated by transmitting generalised digital data over standard phone lines [7]. While issues of reliability were of concern in these early designs, these were met by basic error control techniques, like parity checking of input and output data, only [8]. Notably, these early systems assumed that participating computers were fully trusted and secured via military procedures. Formalisations of computer networks and their failure characteristics were put forward alongside the inception of multi-process computing in the 1960s [9]. Back then, Kleinrock [10] laid the foundation for data networking theory by proposing to research the effects of messaging delays and message prioritisation in ‘large communication nets’. These theoretical foundations led to the practical implementation of formal message protocols for wide-area communication [11] and subsequently to the implementation of the Advanced Research Projects Agency Network (ARPANET) [12], the predecessor of the modern Internet, that brought with it the notion of various autonomous systems clustered in hierarchical layers [13]. These advances, however, focussed mostly on providing stable means of connecting network members in principle and did not govern higher protocol layers.

1.1.2. Byzantine Failures and Malice

Pease et al. [14] describe the problem of complex faults in a distributed system by giving an example of a bad process reporting one value to a given process and a different value to other processes. Such conflicting (and, potentially, malicious) behaviour cannot be controlled via the simple mechanisms outlined before. Instead, more complex approaches, i.e., consensus mechanisms, must be applied. Inconsistent failure modes, later formalised and termed ‘byzantine’ failures by Lamport et al. [15], have been widely researched and upper bounds for the proportion of byzantine participants in distributed systems (depending on the consensus mechanism used) are established.

1.1.3. From Distributed to Decentralised Systems

As

Table 1. A comparison of distributed systems according to Tai et al. [19] (p. 758).

Property	Distributed	Verifiable	Blockchain
Sequential	•	•	•
Agreed			•
Ledgered		•	•
Manipulation-Resistant		•	•
Censorship-Resistant			•

shows, decentralised systems are different from traditional distributed databases, i.e., geographically displaced, loosely coupled, computing facilities [16], since the latter assume a-priori knowledge of participants and their trustworthiness. Furthermore, they fundamentally differ from modern verifiable database systems [17,18] in that they allow cryptographic integrity assurance, but offer no censorship resistance.

Decentralised systems are, therefore, a suitable pattern to address entirely permissionless use cases, intended to be open to the world. While, in practicality, many multi-party use cases do not require this degree of decentralisation [20,21], blockchain systems that aspire to be ‘unstoppable, uncensorable world computer[s]’ [22] do.

1.1.4. Blockchain

The first large-scale implementation of such a system was ‘Bitcoin’ [1], a decentralised payment system introduced in 2008. It famously put forward the concept of decentrally collecting new transactions into blocks and forming a chain of these blocks via an energy-intensive, and often criticised [23], ‘mining’ process to make transactions tamper-proof, thereby coining the term blockchain. Beyond Bitcoin, Blockchain systems share common attributes: They can be characterised as systems that process transactions sequentially based on majority agreement and, ultimately, persist them in a tamper-resistant form on an append-only ledger [19]. For the scope of this work, the majority agreement aspect is of primary interest since the population for such a majority agreement depends on the type of system. Familiarity with the blockchain concept is assumed and this definition is provided for completeness only. (Introductory monographs provide a more comprehensive foundation from the perspectives of practitioners [24], financial technologists [25], and academics [26,27].)

Blockchain systems are most commonly categorised along two dimensions: the trust continuum and the anonymity continuum [28]. On the trust continuum, systems can be categorised as permissioned or permissionless: a permissioned system employs a governance process to determine who can act as a writer, whereas a permissionless system allows anyone to potentially assume this role. On the anonymity continuum, systems can be differentiated by being public or private: a public system provides all data in a publicly inspectable form, whereas a private one applies explicit or implicit access control mechanisms. These two dimensions can be arbitrarily composed (see

Table 2. Four archetypes of Blockchain architectures according to Tezel et al. [28] (p. 549).

	Permissioned	Permissionless
Public	i	ii
Private	iii	iv

). For this study, the write permission dimension is most relevant.

While in permissioned contexts (i.e., i and iii), it can still be necessary to select a leader to orchestrate data replication, trust assumptions are often more relaxed and more akin to those of earlier distributed systems (see Section 1.1.1). This is the case because the group of potential leaders in permissioned systems can be curated, making for an inherently trustworthy population of potential leaders. In permissionless contexts (i.e., ii and iv), however, any member of the public qualifies as a potential leader. This means that entities whose goals do not align with maintaining the stability of a system and adhering to its protocol may make themselves available. This makes permissionless leader selection the harder problem.

1.1.5. Sybil Identities: A New Threat

Distributed systems theory has provided in-depth analyses of numerous system failure modes and has provided mitigations for many of those. Most of the early work, however, assumed a priori knowledge of system participants (see Section 1.1.1). In addition to this, while the abuse of telecommunications infrastructure is documented as early as the 1960s [29] and attacks on computer systems occurred frequently from the 1980s onwards [30], attacks commonly were carried out by intruders who targeted systems in which they were not members from the outside. Putting that in perspective to the categories outlined before (see Table 2), it becomes apparent that research of the pre-Blockchain era is most applicable to type iii (permissioned/private) systems.

It is not always possible to transfer earlier results to majority-based systems where there is no a-priori knowledge of potential leaders (i.e., type ii and iv systems) since those constitute a new phenomenon, popularised with the emergence of blockchain technology. From an attack perspective, such systems are fundamentally different from prior deployments as, in them, malicious entities can operate on the same level as trustworthy ones, for there is no authority to distinguish between those entities. This means that common approaches to mitigating intrusion risks—such as identity management, user authentication, or encryption [31]—are not feasible. Furthermore, common strategies to improve fault tolerance, like increasing redundancy, are futile in a scenario where malicious users can present arbitrarily large numbers of identities. The presentation of arbitrary entities with malice—often referred to as ‘Sybil Attack’ [32]—threatens large-scale peer-to-peer systems in which trusted authorities are absent. This can be attributed to the fact that, when confronted with conflicting information from multiple peers, decentralised systems need to attempt to resolve those conflicts in a way that maintains a correct system state. Determining which piece of information is to be considered correct is the main challenge in such scenarios.

Successful Sybil attacks manifest in different ways, depending on the consensus mechanism deployed and the scale of the attack. While successful small-scale attacks might only introduce forks or stall system operation sporadically, others may irrecoverably disable it, forcing users to abandon it or to seek ‘hard forks’ and the subsequent manual removal of the attacking entities [33], a technique frowned upon due to its economical and ethical ambiguity [34].

1.1.6. Consensus Mechanisms and Sybil Resistance Schemes

More formally, this consensus problem can be defined as one in which ‘each process proposes some initial value, and processes that do not fail must reach an irrevocable decision on exactly one of the proposed values’ [35]. In the context of blockchain, a process can be thought of as any potential writer (see Table 2) in a decentralised system, while values take the form of transaction proposals. Consensus mechanisms provide algorithms to reach a decision on a canonical system state when presented with ambiguous inputs. Often they do so by dynamically selecting a single entity—or leader—to assume the role of validator and adjudicator of inputs for a limited time. This selection is often done pseudorandomly or using voting. The target of such a leader selection process is to select a leader who processes any inputs according to the system protocol while avoiding the selection of adversaries that violate system protocol.

In general, at most m adversaries can be tolerated for systems with $3m+1$ total participants [15]. Therefore, to maintain an operational state, the likelihood of selecting an adversary as a leader in a decentralised system needs to be minimised. This is the purpose of Sybil resistance schemes, many of which will be analysed in this paper. Academic works discussing Sybil resistance schemes come in many different forms, oftentimes as a key component of a consensus mechanism, other times as a standalone proposal. In our work, we focus on extracting any information relevant to Sybil attack resistance from the papers analysed, regardless of which context it is discussed in.

1.2. Motivation

Making sound architectural decisions for decentralised systems is challenging: a variety of different potential designs exist and, apart from usual functional and non-functional requirements, the choice of consensus mechanism shapes decentralised systems in hard-to-revert ways. The choice of consensus mechanism dictates whether a system requires a central admissions process or can be entirely open to the public. Due to the underlying trust assumptions, it furthermore influences the performance of a system, the hardware demands on participants, and the cost of deployment and operation.

Particularly the choice for or against a mechanism with strong Sybil attack resistance properties is decisive: due to being rooted in the blockchain movement, many of the existing consensus mechanisms claim Sybil attack resistance. However, as our analysis will show, many schemes only deliver on that claim under certain, limited, conditions. It is, therefore, necessary to firmly establish a framework that established Sybil attack resistance as one of the key elements of decentralised systems design. This will help the field to focus research efforts on useful areas in which decentralised technology can be applied, rather than reinventing the wheel or making costly design mistakes.

1.3. Organisation

The remainder of this paper is structured as follows: In Section 2, we describe the search strategy applied along with the search systems used to gain the broadest possible exposure to relevant works. In Section 3, we present our results, initially analysing existing secondary literature on consensus mechanisms (see Section 3.2). Subsequently, we analyse the primary literature, i.e., the original works discovered. We group works into mechanisms for democratic processes (see Section 3.3), mechanisms for the education sector (see Section 3.4), mechanisms for the energy sector (see Section 3.5), general purpose mechanisms (see Section 3.6), mechanisms for healthcare (see Section 3.7), mechanisms that seek to improve performance (see Section 3.8), mechanisms for Internet of Things (IoT) (see Section 3.9), mechanisms for media and entertainment (see Section 3.10), mechanisms for supply chain management (see Section 3.11), mechanisms for the telecommunications sector (see Section 3.12), Proof-of-useful-work (PoUW) schemes (see Section 3.13), and mechanisms for vehicles (see Section 3.14). We then conclude with a comment on the current state of literature and avenues for future work (see Section 4).

1.4. Scope

For a comprehensive review, we apply a broad definition of academic works, that includes research papers, technical reports, pre-prints, and theses. We consider any work that describes a consensus mechanism, a leader selection approach, or a Sybil attack resistance scheme reasonably well. This includes many works that describe technologies that do not have Sybil attack resistance as a design goal (including many Byzantine fault tolerance (BFT) schemes). These are included for completeness.

1.5. Contribution

This work offers a comprehensive review of the blockchain consensus mechanism landscape. While many similar efforts have been undertaken (see Section 3.2), this manuscript can be differentiated from those by the method of categorising relevant works: it taxonomises individual contributions using a novel composition of key mechanism attributes (Sybil attack resistance class, reward scheme, and leader selection methodology). This approach allows us to provide an objective and comprehensive overview of the field that clearly describes which Sybil attack resistance class is prevalent in the field. Grouping by industry, furthermore, allows the reader to determine which verticals have seen research interest. Lastly, by analysing the full breadth of the literature, this work shows which technological building blocks are commonly applied within different Sybil attack resistance classes (e.g., PoW in strongly Sybil attack resistant systems). These analyses provide the groundwork for researchers wishing to extend the state of the art in consensus mechanism research.

2. Methods

The goal of this work is to gain an understanding of the full breadth of available leader selection strategies. During the preliminary screening, consensus mechanisms in the context of blockchain were found in various types of academic literature: while many algorithms are published in dedicated papers that are easy to discover based on their title alone, others are discussed as part of wider research works, such as technical papers introducing new system constructs. Thus, to also include manuscripts in which consensus mechanisms are not the central concern, queries need to be broad. The selection of academic search systems to retrieve manuscripts relevant to the research question is informed by the findings of Gusenbauer and Haddaway [36] who categorise academic search systems. All systems that provide the following functions are considered:

• The system focuses on Computer Science or has a multidisciplinary focus
• The system supports Boolean operators (at least AND and OR)
• The system supports parentheses
• The system allows for bulk download of 50 results or more

Seven academic search systems (see

Table 3. Search results returned from targeted search systems.

Operator	Search System	Results
ACM	Guide to Computing Literature	519
Bielefeld University Library	BASE	5890
IEEE	Xplore	1846
Elsevier	ScienceDirect	3186
Elsevier	Scopus	4084
Springer Nature	SpringerLink	3519
Clarivate Analytics	Web of Science	2755

) provide this functionality [36], including the highly relevant offerings by the Association for Computing Machinery (ACM) and the Institute of Electrical and Electronics Engineers (IEEE). For each of the academic search systems, a broad query is formulated. While individual query syntax varies, queries are modelled after the following example search string:

(

Blockchain OR

“Distributed Ledger” OR

“Crypto Currency” OR

Cryptocurrency OR

Cryptocurrencies

)AND (

Consensus OR

“Proof-of-” OR

Membership

)

Since this review targets leader selection strategies in the context of blockchain, the term Blockchain, or the closely related terms Distributed Ledger and Cryptocurrency are required. Similarly, since leader selection is central to consensus mechanisms, the term Consensus, or the related term Membership is required. Furthermore, the commonly used construct Proof-of-* is admissible.

2.1. Search Results

The total number of results returned (21,799) raises confidence in the search queries being sufficiently broad. The queries were executed in the week of 26 April 2021. The number of results reflects the manuscripts indexed at this time. Since the queries do not impose any limitations on the manuscript type, a broad range of scientific works, both peer-reviewed and not peer-reviewed, are returned (see Section 1.4). For this review, all result types, including pre-prints, are considered. These results form the input to the following multi-step manuscript screening process (see Figure 1).

2.2. Duplicate Resolution

“EPPI-Reviewer’, a software suite for research synthesis, is used to manage sources and screen manuscripts. The step in the review process is to apply the built-in ‘Manage Duplicates’ functionality to correlate duplicates automatically. While this functionality was found to be less effective than other de-duplication software [37], a significant number of duplicates (7861) is discovered. Additional instances, however, remain undetected and will be treated manually after this automated step.

2.3. Abstract Screening

Following duplicate resolution, titles and abstracts of results are screened for relevancy. Here, the following questions are answered:

• Is the result published in 2008 or after?
• Is the result written in the English language?
• Does the result describe a primary article (e.g., an original research article) or a secondary article (e.g., a review)?
• Does the article concern the field of computer science?
• Does the article concern decentralised computing?
• Does the article describe a consensus mechanism?

Should either of the questions be answered with no, the manuscript is automatically excluded. Should all of the questions be answered with yes or unclear, the manuscript will be included for further analysis.

The abstract screening process eliminated a large number of manuscripts (9009). However, the remaining candidate list still contained numerous duplicates which were removed manually based on similarities of title, author list, or digital object identifier during abstract screening.

During the manual screening, the full texts of the documents were obtained online. Documents were only considered if digital access was granted to them via King’s College London library subscriptions. Manuscripts that would only have been available in print or via interlibrary loan were not obtained. Still, the vast majority of full texts were obtainable and only a very small number could not be accessed. The full texts were then briefly examined to understand whether they were indeed relevant and, only if found so, were fully analysed. They were then categorised as either primary literature (i.e., works that proposed an individual mechanism) or secondary literature (i.e., surveys and taxonomies).

3. Results

We organise the results by common sectors to gain a better understanding of the needs of particular industry verticals. This also helps us to further analyse which system properties occur together, e.g., we find that many use cases in IoT (see Section 3.9) have no or limited Sybil attack resistance due to the limited computational capabilities of IoT devices.

3.1. Aspects of Interest

We are particularly interested in some key elements of Sybil attack resistance schemes. First, what level of Sybil attack resistance they provide when deployed (see

Table 4. Three categories of Sybil attack resistance.

Category	Cost	Coordination Effort	Time Expenditure
Strong Sybil attack resistance	Excessive	High	Extreme
Limited Sybil attack resistance	High	High	High
No Sybil attack resistance	Negligible	Negligible	Negligible

). We assume that the mechanism in question is deployed to a large-scale system, as many Sybil attack resistance effects only materialise with high usage volume, as can be seen when considering the likelihood of 51% attacks on PoW systems with low popularity [38]. For Sybil attack resistance, we introduce three categories: Strong Sybil attack resistance; meaning a mechanism that, when applied to a sizeable system, could not be attacked, even by an irrational attacker, unless they incur tremendous cost. Limited Sybil attack resistance; meaning an attacker might be successful with an attack if they are ready to incur significant cost and orchestrate an attack over a long time. No Sybil attack resistance, meaning an attacker could easily overwhelm a public/permissionless system using the mechanism in question. The latter category is not to be seen as criticism of the mechanism: it mostly applies to environments in which the mechanism designers do not have to consider Sybil attacks.

Second, whether an incentive scheme is part of the proposed mechanism. Here, we analyse whether participants receive rewards for adherence to the protocol and/or punishment for deviating from it. Third, the application of random/pseudorandom numbers during the execution of the mechanism. Fourth, whether the mechanism is somehow linked to the physical world, e.g., by asserting on messages generated by users having access to a central processing unit (CPU) with a Trusted Execution Environment (TEE). Fifth, whether a reputation system is applied in the context of the mechanism: such a system may be used to inform leader selection based on reputation signals from other participants or from central sources. Sixth, whether the mechanism is intended to be applied in permissioned or permissionless settings. Here we are particularly interested in outlier mechanisms with strong Sybil attack resistance that are applied in permissioned settings or mechanisms with weak Sybil attack resistance being applied in permissionless settings. Last, we outline the leader selection method, foremost by analysing whether the mechanism relies on (pseudo-)randomness, an election, or a pre-formed committee. Many mechanisms combine multiple factors. In such case, we aim to call out the dominant factor.

3.2. Secondary Literature

To gain an overview of the available works and to understand which mechanisms are deemed most relevant by the research community, the secondary literature was analysed (see

Table 5. Secondary literature analysed during manuscript screening.

	PoW (Appendix D.224)	PoS (Appendix D.212)	PBFT (Appendix D.147)	DPoS (Appendix D.72)	PoET (Appendix D.154)	Proof-of-Space (Appendix D.209)	Proof-of-Burn (Appendix D.177)	Proof-of-Activity (Appendix D.168)	Proof-of-Importance (Appendix D.187)	Raft (Appendix D.230)	Proof-of-Authority (Appendix D.157)	dBFT (Appendix D.66)	Proof-of-Luck (Appendix D.157)
Aggarwal and Kumar [39]	●	●	●	●	●	●	●	●	●	◌	◌	◌	◌
Aggarwal et al. [40]	●	●	●	●	●	●	●	◌	◌	◌	●	◌	◌
Ahmad et al. [41]	●	●	●	◌	●	◌	◌	◌	◌	◌	◌	◌	◌
Ali Syed et al. [42]	●	●	●	◌	●	●	◌	◌	◌	◌	◌	◌	◌
Alsaqqa and Almajali [43]	●	◌	●	◌	◌	●	●	●	●	◌	●	◌	◌
Alsunaidi and Alhaidari [44]	●	●	●	●	◌	◌	◌	●	●	●	◌	◌	●
Andoni et al. [45]	●	●	●	●	●	●	●	●	◌	◌	●	◌	◌
Andrey and Petr [46]	●	●	◌	●	◌	●	●	●	●	◌	◌	◌	◌
Antal et al. [47]	●	●	◌	◌	◌	◌	●	●	◌	●	●	◌	◌
Azbeg et al. [48]	●	●	●	●	●	●	●	◌	◌	◌	●	◌	◌
Bach et al. [49]	●	◌	◌	●	◌	◌	◌	◌	●	◌	◌	●	◌
Bamakan et al. [50]	●	●	●	●	●	●	●	●	●	◌	◌	●	◌
Bashar et al. [51]	●	●	◌	◌	●	●	●	●	●	◌	●	◌	●
Belotti et al. [52]	●	●	●	●	●	◌	◌	◌	●	◌	◌	◌	◌
Bhutta et al. [53]	●	●	●	●	●	●	●	◌	●	◌	◌	●	●
Dabbagh et al. [54]	●	●	●	◌	◌	◌	◌	●	◌	●	◌	◌	◌
Dhaiouir and Assar [55]	●	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌
Ferdous et al. [56]	●	●	◌	◌	◌	◌	●	◌	●	◌	◌	◌	◌
Ferrag et al. [57]	●	●	●	●	●	●	●	●	●	◌	●	●	◌
Fournier and Petrillo [58]	●	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌	●
Fu et al. [59]	●	●	●	●	◌	◌	●	●	◌	◌	◌	●	●
Hao et al. [60]	●	◌	●	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌
Hazari and Mahmoud [61]	●	●	●	◌	◌	◌	●	◌	●	◌	◌	◌	◌
He et al. [62]	●	●	◌	●	●	●	●	●	●	◌	◌	◌	●
Hellwig et al. [63]	●	●	●	●	●	●	◌	◌	◌	◌	●	◌	◌
Honnavalli et al. [64]	◌	◌	●	◌	◌	◌	◌	◌	◌	◌	●	◌	◌
Indhuja and Venkatesulu [65]	●	●	●	●	●	●	◌	●	●	◌	◌	●	◌
Ismail and Materwala [66]	●	●	●	●	●	●	●	●	●	●	●	●	◌
Jayabalan and N [67]	●	●	●	◌	●	◌	◌	◌	◌	●	◌	◌	◌
Jennath and Asharaf [68]	●	●	◌	◌	●	●	●	●	●	◌	●	◌	◌
Katarya and Vats [69]	●	●	●	●	◌	◌	◌	◌	◌	●	◌	◌	◌
Kaur et al. [70]	●	●	●	●	●	◌	◌	◌	◌	◌	●	◌	◌
Khamar and Patel [71]	●	●	●	●	●	◌	◌	●	●	●	◌	●	●
Lao et al. [72]	●	●	●	◌	◌	●	●	◌	●	◌	●	◌	◌
Lashkari and Musilek [73]	●	●	●	●	●	●	●	●	◌	●	●	●	●
Lasisi and Hsu [74]	◌	◌	●	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌
Lepore et al. [75]	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌
MacKenzie et al. [76]	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌	●
Maple and Jackson [77]	●	●	●	◌	●	◌	◌	◌	◌	◌	◌	◌	◌
Masood and Faridi [78]	●	●	◌	◌	●	●	●	◌	◌	◌	◌	◌	◌
Masood and Faridi [79]	◌	◌	●	◌	◌	◌	◌	◌	◌	●	◌	◌	◌
Mingxiao et al. [80]	●	●	●	●	◌	◌	◌	◌	◌	●	◌	◌	◌
Monrat et al. [81]	●	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌
Naz and Lee [82]	●	●	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌
Nguyen and Kim [83]	●	●	●	●	●	●	●	●	◌	●	◌	◌	●
Nijsse and Litchfield [84]	●	●	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌
Pahlajani et al. [85]	●	●	◌	◌	●	●	◌	◌	◌	◌	◌	◌	●
Panda et al. [86]	●	●	◌	◌	◌	◌	◌	◌	◌	●	◌	◌	◌
Perez et al. [87]	●	●	◌	◌	◌	◌	◌	◌	●	◌	◌	◌	◌
Praveen et al. [88]	●	●	●	●	●	●	●	●	●	●	◌	●	◌
Ramkumar et al. [89]	●	●	●	◌	●	●	●	●	◌	◌	◌	●	◌
Sharma and Jain [90]	●	●	●	●	●	●	●	●	●	◌	◌	◌	◌
Srivastav et al. [91]	●	●	●	●	◌	●	●	◌	◌	◌	◌	●	◌
Verma et al. [92]	●	●	●	◌	●	●	●	●	●	●	◌	◌	●
Wang et al. [93]	●	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌
Wazid et al. [94]	●	●	●	●	●	●	●	●	●	◌	◌	●	◌
Xiao et al. [95]	●	●	●	◌	●	◌	◌	◌	◌	◌	◌	◌	◌
Xiao et al. [96]	●	●	●	●	●	◌	◌	◌	◌	◌	●	◌	◌
Yin et al. [97]	●	●	●	◌	●	●	●	◌	◌	●	◌	◌	◌
Yousuf et al. [98]	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌	◌
Zhang and Lee [99]	●	●	●	●	◌	◌	◌	◌	◌	◌	◌	◌	◌
Zhao et al. [100]	●	●	◌	◌	●	●	◌	◌	◌	◌	◌	◌	◌

●: Included, ◌: Not included.

). Here, we find that most researchers align on a small number of major mechanisms: in the secondary literature analysed, only PoW (see Appendix D.224), Proof-of-Stake (PoS) (see Appendix D.212), Practical Byzantine Fault Tolerance (PBFT) (see Appendix D.147), Delegated Proof-of-Stake (DPoS) (see Appendix D.72), and Proof of Elapsed Time (PoET) (see Appendix D.154) are mentioned by more than half of the works. This foreshadows the analysis of the primary literature where we find several works that have received hardly any attention so far. These most commonly discussed mechanisms reflect the breadth of the entire field well as they include permissionless mechanisms (e.g., PoW), permissioned mechanisms (e.g., PBFT), and mechanisms that make use of physical world linking (e.g., PoET by using TEE).

3.3. Mechanisms for Democratic Processes

Only five mechanisms were categorised as targeting the facilitation of democratic processes (see

Table 6. Consensus mechanisms in democracy.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Democratic Byzantine Fault Tolerance [107]	Appendix A.2	▽	◌	◌	◌	◌	◌	●	◌	None
Consensus for e-Democracy [106]	Appendix A.1		◌	◌	◌	◌	◌	◌	●
Proof-of-Credibility [102]	Appendix A.4		◌	◌	●	◌	●	◌	●	Elec.
Encointer [104]	Appendix A.3		◌	◌	●	●	◌	◌	●	Rand.
Proof-of-Personhood [105]	Appendix A.5		●	◌	●	●	◌	◌	●	Rand.

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

). A key responsibility for such systems is to orchestrate voting on ledger: to support this, an underlying consensus mechanism should make block producer selection subject to a free election [101] (Figure 12), a pre-requisite that is met in the Proof-of-Credibility mechanism proposed by Abuidris et al. [102]. The majority of the mechanisms target permissionless systems, thereby contributing to the debate about the suitability of consensus mechanisms for public democratic blockchain systems [103]. Some mechanisms approach Sybil attack resistance through personal encounters in the physical world [104,105], while others apply PoS-like mechanics to credibility scores [102,106].

3.4. Mechanisms for Education

Steiu [108] identifies ‘digitalisation and decentralisation of educational certifications’ and ‘lifelong learning’ as key drivers for the deployment of blockchain technology in an educational context. Additionally, Hsu et al. [109] define the main challenges of smart education environments as ‘trust, privacy, and transparency’. Consequently, some researchers suggested the application of blockchain technology to these environments. While, with only three mechanisms, the education category is sparse, some commonalities can be made out: as

Table 7. Consensus mechanisms in education.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Group-Based Consensus for Educational Systems [110]	Appendix B.1	▽	◌	◌	◌	◌	●	●	◌	Elec.
Proof-of-Reputation [111]	Appendix B.3		●	◌	●	◌	●	◌	◌
Improved DPoS [112]	Appendix B.2		◌	◌	◌	◌	◌	◌	◌

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

shows, none of the proposed Sybil attack resistance schemes explicitly assume a permissionless system. The ‘Group-Based Consensus for Educational Systems’ [110], for example, assumes a hierarchical system of educational stakeholders.

3.5. Mechanisms for Energy

The energy sector is seeing a considerable amount of blockchain-related research (see

Table 8. Consensus mechanisms in energy.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Communicate Proof-of-Credit [116]	Appendix C.1	▲	●	◌	●	◌	●	◌	●	Rand.
Decentralised Consensus Decision-Making [117]	Appendix C.7	▲	◌	◌	●	◌	◌	◌	●	Rand.
Consensus Resource Slicing Model [119]	Appendix C.2	▽	◌	◌	●	◌	◌	●	◌	Rand.
Credit-Based PoW [120]	Appendix C.4	▽	●	◌	●	◌	◌	●	◌	Rand.
Dynamic-Reputation Practical Byzantine Fault Tolerance [121]	Appendix C.8	▽	◌	◌	◌	◌	●	●	◌	Elec.
Enhanced Proof-of-Work [132]	Appendix C.9	▽	◌	◌	◌	◌	◌	◌	◌
Fast, Secure and Distributed Consensus Mechanism for Energy Trading Among Vehicles using Hashgraph [133]	Appendix C.10	▽	◌	◌	●	◌	●	◌	◌	None
Hyper Delegation Proof-of-Randomness [122]	Appendix C.11	▽	◌	◌	◌	◌	◌	●	◌
Improved Proof of Work [123]	Appendix C.12	▽	◌	◌	●	◌	◌	●	◌	Rand.
Lightweight DPoS for Energy Transmitters [124]	Appendix C.13	▽	●	●	●	◌	◌	●	◌
Proof-of-Credit-Threshold [125]	Appendix C.15	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Energy-Generation [126]	Appendix C.16	▽	●	◌	◌	◌	◌	●	◌
Proof-of-Cooperation [134]	Appendix C.18	▽	◌	◌	●	◌	●	◌	◌	Elec.
Proof-of-Efficiency [127]	Appendix C.19	▽	◌	◌	◌	◌	●	●	◌
Proof-of-Generation [128]	Appendix C.20	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof-of-Work based on Reputation [129]	Appendix C.21	▽	◌	◌	●	◌	◌	●	◌	Comm.
Credibility Consensus [130]	Appendix C.3		●	◌	◌	◌	◌	●	◌	Elec.
Credit-Based Concurrent Block Building Consensus [135]	Appendix C.5		●	◌	●	◌	●	◌	◌	Elec.
Lightweight Credibility-Based Equity Proof Consensus [136]	Appendix C.14		●	◌	●	◌	◌	◌	◌	Rand.
Cross-Layer Trust-Based Consensus [131]	Appendix C.6		●	◌	●	◌	●	●	◌	Rand.
Proof-of-Benefit [137,138,139,140]	Appendix C.17		◌	◌	◌	◌	●	◌	●

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

). This is not surprising since, as Brilliantova and Thurner [113] attest, relevant requirements are arising in the energy sector as a result of the movement towards peer-to-peer (P2P) energy trading. As Andoni et al. [45] assert, blockchain technology can empower consumers and small electricity generators. While challenges, such as regulatory uncertainty and environmental questions, remain [114], decentralised technology was found to be a good fit for blockchain technology, specifically to combat the existing security issues of smart grid systems [115]. With regards to Sybil attack resistance it is worth mentioning that, apart from two [116,117], all reviewed mechanisms expose limited or no Sybil attack resistance. This can, in most cases, be attributed to the fact that energy trading needs to rely on central entities, like distribution system operators, to provide reliable meter readings [118] both for the consumption and production of electricity. Therefore, permissioned systems [119,120,121,122,123,124,125,126,127,128,129,130,131] are dominating the energy space.

3.6. General Purpose Mechanisms

This catch-all category captures the majority (57%) of all algorithms analysed. It contains all algorithms that are not industry-specific, as well as some targeted at ‘exotic’ domains, such as astronautics [141]. In this category, a large number of schemes with strong Sybil attack resistance are contained, including those with large overall popularity [142,143,144,145,146,147,148,149,150,151,152]. As seen in

Table 9. General consensus mechanisms.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Bitcoin-NG [179]	Appendix D.2	▲	●	◌	●	◌	◌	◌	●	Rand.
ECDLP-based PoW [180]	Appendix D.4	▲	●	◌	●	◌	◌	◌	●	Rand.
PoS Based on Credit Rewards and Punishments [262]	Appendix D.6	▲	◌	◌	◌	◌	●	◌	●	Elec.
PoS Based on Verifiable Random Functions [181]	Appendix D.7	▲	●	◌	●	◌	◌	◌	●	Rand.
PoS for Bitcoin Sidechains [168]	Appendix D.8	▲	●	●	●	◌	◌	◌	●	Rand.
PoS with Behavior Score and Trust Rating [182]	Appendix D.9	▲	●	◌	◌	◌	●	◌	●	Elec.
PoS with Waiting-Time First-Price Auctions [183]	Appendix D.12	▲	●	◌	●	◌	◌	◌	●	Rand.
PoS with Weighted Voting [184,185]	Appendix D.13	▲	●	◌	●	◌	●	◌	●	Rand.
PoW Based on Power Analysis of Low-End Microcontrollers [187]	Appendix D.15	▲	●	◌	●	◌	◌	◌	●	Rand.
PoW on quadratic multivariate equations [263,264]	Appendix D.16	▲	◌	◌	●	◌	◌	◌	●	Rand.
PoW with Early Stage PoS [188]	Appendix D.17	▲	●	◌	●	◌	◌	◌	●	Rand.
PoW with Personalized Difficulty Adjustment [190]	Appendix D.19	▲	●	◌	●	◌	◌	◌	●	Rand.
PoW with Quantum-Resistant Hash Collision [191]	Appendix D.20	▲	●	◌	◌	◌	◌	◌	●	Rand.
pVFR for PoW [265]	Appendix D.21	▲	◌	◌	●	◌	◌	◌	●	Rand.
Albatross [169]	Appendix D.24	▲	●	●	●	◌	◌	◌	●	Rand.
Alt-PoW [192]	Appendix D.25	▲	●	◌	●	◌	◌	◌	●	Rand.
Attack-Tolerant PoW [193]	Appendix D.29	▲	●	◌	●	◌	◌	◌	●	Rand.
B4SDC [194]	Appendix D.32	▲	●	◌	●	◌	◌	◌	●	Rand.
BeaconBlocks [266]	Appendix D.34	▲	◌	◌	●	◌	◌	◌	◌	Rand.
Block Maturity Level [195]	Appendix D.36	▲	◌	◌	●	◌	◌	◌	◌	Rand.
Bobtail [198]	Appendix D.40	▲	◌	◌	●	◌	◌	◌	◌	Rand.
Chains of Activity [199]	Appendix D.44	▲	◌	◌	●	◌	◌	◌	◌	Rand.
Client-Assisted Consensus [267]	Appendix D.46	▲	◌	◌	●	◌	◌	◌	◌
CloudPoS [268]	Appendix D.48	▲	◌	◌	◌	◌	◌	◌	●	Elec.
Composite Framework Leveraging Proof-of-Stake and Proof-of-Work [201]	Appendix D.51	▲	●	◌	●	◌	●	◌	●	Rand.
Conflux [202]	Appendix D.52	▲	●	◌	●	◌	◌	◌	●	Rand.
Crux [269]	Appendix D.59	▲	◌	◌	●	◌	◌	◌	●	Elec.
Cumulative Proof-of-Work [204]	Appendix D.60	▲	●	◌	●	◌	◌	◌	●	Rand.
Delegated Proof of Stake with Downgrade [270]	Appendix D.68	▲	◌	◌	●	◌	●	◌	●	Rand.
Delegated Proof-of-Reputation [206]	Appendix D.71	▲	●	◌	◌	◌	●	◌	●	Elec.
Delegated Proof-of-Stake [145]	Appendix D.72	▲	●	◌	●	◌	◌	◌	●	Elec.
Deterministic Proof-of-Work [271]	Appendix D.75	▲	◌	◌	◌	◌	◌	◌	●	Elec.
Equihash [207]	Appendix D.84	▲	●	◌	●	◌	◌	●	◌	Rand.
Error-Correction Code Based Proof-of-Work [208]	Appendix D.85	▲	●	◌	◌	◌	◌	◌	●	Rand.
Estimable PoW [209]	Appendix D.86	▲	●	◌	●	◌	◌	◌	●	Rand.
extended PoS [272]	Appendix D.87	▲	◌	◌	●	◌	◌	◌	◌	Rand.
Fair Proof-of-Work System With Computing Power Rating [210]	Appendix D.89	▲	●	◌	●	◌	●	◌	●	Rand.
Fair selection protocol for committee-based permissionless blockchains [273]	Appendix D.90	▲	◌	◌	◌	◌	◌	●	●	Rand.
Fantômette [170]	Appendix D.91	▲	●	●	●	◌	◌	◌	●	Rand.
Filtered Proof-of-Work [274]	Appendix D.95	▲	◌	◌	●	◌	◌	◌	●	Rand.
Goshawk [211]	Appendix D.97	▲	●	◌	●	◌	◌	◌	●	Rand.
Greedy Observed Largest Forest [275]	Appendix D.99	▲	◌	◌	●	◌	◌	◌	●	Rand.
HashCore [276]	Appendix D.104	▲	◌	◌	●	◌	◌	◌	●	Rand.
Hybrid PoW/PoS [277]	Appendix D.106	▲	◌	◌	●	◌	●	◌	◌	Rand.
Hybrid PoW/PoS [213]	Appendix D.107	▲	●	◌	●	◌	◌	◌	●	Rand.
Hybrid Consensus with flexible Proof-of-Activity [214]	Appendix D.109	▲	●	◌	●	◌	◌	◌	●	Rand.
Improved DPoS with K-Means [215]	Appendix D.112	▲	●	◌	●	◌	●	◌	◌	Elec.
Interactive Proof-of-Stake [216]	Appendix D.113	▲	●	◌	●	◌	◌	◌	●	Rand.
Itsuku [278]	Appendix D.115	▲	◌	◌	●	◌	◌	◌	●	Rand.
MaGPoS [171]	Appendix D.120	▲	●	●	◌	◌	◌	◌	◌	●
Multi-tokens Proof of Stake [218]	Appendix D.127	▲	●	◌	●	◌	◌	◌	●	Rand.
Multiple Winners Proof of Work [219]	Appendix D.128	▲	●	◌	●	◌	◌	◌	●	Rand.
NeuCoin [173]	Appendix D.131	▲	●	●	●	◌	◌	◌	●	Rand.
Open Representative Voting [279]	Appendix D.133	▲	◌	◌	◌	◌	◌	◌	●	Elec.
Optical Proof-of-Work [220]	Appendix D.134	▲	●	◌	●	◌	◌	◌	●	Rand.
Ouroboros Crypsinous [280]	Appendix D.135	▲	◌	◌	◌	◌	◌	◌	●	Elec.
Ouroboros Genesis [281]	Appendix D.136	▲	◌	◌	◌	◌	◌	◌	●	Rand.
Ouroboros Praos [282]	Appendix D.137	▲	◌	◌	●	◌	◌	◌	●	Rand.
Parallel Proof-of-Work [221]	Appendix D.138	▲	●	◌	●	◌	◌	◌	●	Rand.
Penalty by Consensus in PoW [174]	Appendix D.140	▲	●	●	◌	◌	◌	◌	●	Rand.
Pixel [283]	Appendix D.144	▲	◌	◌	●	◌	◌	◌	●	Rand.
PoolCoin [222]	Appendix D.146	▲	●	◌	●	◌	●	◌	●	Rand.
Prism [223]	Appendix D.149	▲	●	◌	●	◌	◌	◌	●	Rand.
Private Proof-of-Effort [284]	Appendix D.150	▲	◌	◌	●	◌	◌	◌	●	Rand.
Proof of Adjourn [285]	Appendix D.151	▲	◌	◌	●	◌	◌	◌	●	Rand.
Proof of Contribution [224]	Appendix D.153	▲	●	◌	●	◌	●	◌	●	Rand.
Proof of Experience [225]	Appendix D.155	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof of Segmented Work [226]	Appendix D.159	▲	●	◌	●	◌	◌	◌	◌	Rand.
Proof-of-Accumulated-Work [286]	Appendix D.165	▲	◌	◌	●	◌	◌	◌	●	Rand.
Proof-of-Activity [149]	Appendix D.168	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Behavior [287]	Appendix D.173	▲	◌	◌	●	◌	●	◌	●
Proof-of-Burn [148]	Appendix D.177	▲	◌	◌	◌	◌	◌	◌	●
Proof-of-Credit [261]	Appendix D.182	▲	◌	●	●	◌	●	◌	◌	Rand.
Proof-of-Discrete Logarithm [234]	Appendix D.183	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Equivalence [165]	Appendix D.184	▲	◌	◌	◌	◌	●	◌	●	Rand.
Proof-of-Human-Work [236]	Appendix D.186	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Importance [150]	Appendix D.187	▲	●	◌	◌	◌	◌	◌	●
Proof-of-Interaction [237]	Appendix D.188	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Lottery [238]	Appendix D.190	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Participation [241]	Appendix D.195	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Prestige [288]	Appendix D.199	▲	◌	◌	●	◌	●	◌	●	Rand.
Proof-of-Replicated-Storage [289]	Appendix D.202	▲	◌	◌	◌	◌	◌	◌	●
Proof-of-Reproducibility [290]	Appendix D.203	▲	◌	◌	◌	◌	●	◌	●	Rand.
Proof-of-Reputation with Nakamoto Fallback [291]	Appendix D.205	▲	◌	◌	◌	◌	●	◌	●	Elec.
Proof-of-Space [147]	Appendix D.209	▲	◌	◌	◌	◌	◌	◌	●
Proof-of-Stake [143]	Appendix D.212	▲	●	◌	◌	◌	◌	◌	●
Proof-of-Stake for Bitcoin Subchains [245]	Appendix D.213	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Strategy [246]	Appendix D.215	▲	●	◌	●	◌	●	◌	●	Elec.
Proof-of-Work [1,142]	Appendix D.224	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Work Applied to the Clique Problem [292]	Appendix D.225	▲	◌	◌	●	◌	◌	◌	●	Rand.
Proof-of-Work Based on Analog Hamiltonian [293]	Appendix D.226	▲	◌	◌	●	◌	◌	◌	●	Rand.
Proof-of-Work on the Inflation Propensity of Collatz Orbits [294]	Appendix D.227	▲	◌	◌	◌	◌	◌	◌	●	Rand.
Reputation Based Hybrid Consensus [250]	Appendix D.237	▲	●	◌	●	◌	◌	◌	◌	Rand.
Robust Proof-of-Stake [295]	Appendix D.243	▲	◌	◌	◌	◌	◌	◌	◌	Rand.
Roll-DPoS [251]	Appendix D.245	▲	●	●	◌	◌	◌	◌	●	Rand.
Rollerchain [252]	Appendix D.246	▲	●	◌	●	◌	◌	◌	●	Rand.
Satellite-Aided Consensus [141]	Appendix D.249	▲	◌	◌	◌	◌	◌	◌	●
Service-Zone-Based Hierarchical Consensus [296]	Appendix D.260	▲	◌	◌	●	◌	◌	◌	●	Rand.
SklCoin [297]	Appendix D.262	▲	◌	◌	●	◌	◌	◌	●	Rand.
Solida [255]	Appendix D.264	▲	●	◌	◌	◌	◌	◌	●	Rand.
Thinkey [256]	Appendix D.269	▲	●	◌	●	◌	◌	◌	●	Rand.
Time-Memory-Data Trade-Off [257]	Appendix D.270	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Trusted-Execution-Environment-Stake [157]	Appendix D.218	▲	◌	◌	●	●	◌	◌	●	Elec.
BFT with Satellite Chains [298]	Appendix D.1	▽	◌	◌	◌	◌	◌	●	◌
PBFT with Node Quality Control [299]	Appendix D.5	▽	◌	◌	◌	◌	●	●	◌	Elec.
PoW with Integer Prime Factorisation [189]	Appendix D.18	▽	●	◌	●	◌	◌	◌	●	Rand.
Adaptive Wide-Area Replication [300]	Appendix D.22	▽	◌	◌	●	◌	◌	●	◌	Elec.
AdRaft [301]	Appendix D.23	▽	◌	◌	●	◌	◌	●	◌	Elec.
Alzahrani and Bulusu’s Decentralized Consensus Protocol Utilizing Game Theory and Randomness [302]	Appendix D.26	▽	◌	◌	●	◌	◌	●	◌	Elec.
Amoeba Paxos [303]	Appendix D.27	▽	◌	◌	◌	◌	◌	◌	●	Elec.
Assigned-Majority-Validation [304]	Appendix D.28	▽	◌	◌	◌	◌	◌	◌	●
Auction-Based Consensus [305]	Appendix D.30	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Authorized Proof of Stake [306]	Appendix D.31	▽	◌	◌	●	◌	◌	●	◌	Rand.
BLIC [307]	Appendix D.35	▽	◌	◌	●	◌	◌	●	◌	Rand.
Blockchain for the Common Good [196]	Appendix D.37	▽	●	◌	◌	◌	◌	◌	●	Elec.
Blockchain-Based Federated Learning Framework with Committee Consensus [308]	Appendix D.39	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Byzantine Set Union Consensus [309]	Appendix D.41	▽	◌	◌	●	◌	◌	●	◌	Elec.
Casanova [310]	Appendix D.42	▽	◌	◌	◌	◌	◌	◌	◌	None
Caucus [311]	Appendix D.43	▽	◌	◌	●	◌	◌	●	◌	Rand.
CloudPoS (with CSP Invovlement) [268]	Appendix D.47	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Coinami [312]	Appendix D.49	▽	◌	●	◌	◌	◌	●	◌	Rand.
Committee-Based Byzantine Consensus [313]	Appendix D.50	▽	◌	◌	●	◌	◌	●	◌	Elec.
Consensus Through Herding [314]	Appendix D.54	▽	◌	◌	◌	◌	◌	●	◌
Credence-Based Consensus [315,316]	Appendix D.56	▽	◌	◌	●	◌	●	●	◌	Elec.
Cross-Application Permissioned Blockchain [317]	Appendix D.58	▽	◌	◌	◌	◌	◌	●	◌
Dynamic PBFT [318]	Appendix D.61	▽	◌	◌	◌	◌	◌	●	◌	Rand.
DagGrid [319]	Appendix D.62	▽	◌	◌	●	◌	●	●	◌	Rand.
Delegate Consensus Algorithm [320]	Appendix D.64	▽	◌	◌	●	◌	◌	◌	◌	Rand.
Delegated Adaptive Byzantine Fault Tolerance [321]	Appendix D.65	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Delegated Proof of Economic Value [321]	Appendix D.67	▽	◌	◌	◌	◌	●	●	◌
Dependability-Rank-based Consensus [322]	Appendix D.74	▽	◌	◌	●	◌	●	●	◌	Rand.
DEXON [323]	Appendix D.76	▽	◌	◌	●	◌	◌	●	◌	Rand.
DFINITY [324]	Appendix D.77	▽	◌	◌	●	◌	◌	◌	●	Rand.
Dynamic Hierarchical Byzantine Fault-Tolerant Consensus Based on Credit [325]	Appendix D.79	▽	◌	◌	◌	◌	●	●	◌
Egalitarian Practical Byzantine Fault Tolerance [326]	Appendix D.81	▽	◌	◌	◌	◌	◌	●	◌
Electronic Identification, Authentication and Trust Services Validating Indy-Plenum [327]	Appendix D.82	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Elpis [328]	Appendix D.83	▽	◌	◌	●	◌	◌	●	◌	Elec.
Extensible-PBFT [329]	Appendix D.88	▽	◌	◌	●	◌	◌	●	◌	Elec.
Fast leader-based, randomized Byzantine Agreement [330]	Appendix D.92	▽	◌	◌	●	◌	◌	●	◌	Rand.
FastBFT [331]	Appendix D.94	▽	◌	◌	◌	◌	◌	●	◌
Geo-Scale Byzantine Fault Tolerance [332]	Appendix D.96	▽	◌	◌	◌	◌	◌	●	◌
Graph Learning BFT [333]	Appendix D.98	▽	◌	◌	◌	◌	◌	●	◌
Group-Based Optimized Practical Byzantine Fault Tolerance [334]	Appendix D.102	▽	◌	◌	◌	◌	●	●	◌	Elec.
HotStuff [335]	Appendix D.105	▽	◌	◌	◌	◌	◌	●	◌
Hybrid Byzantine Agreement [336]	Appendix D.108	▽	◌	◌	●	◌	◌	●	◌	Rand.
Identifiable Practical Byzantine Fault Tolerance [337]	Appendix D.110	▽	◌	◌	●	◌	◌	●	◌	Elec.
Istanbul BFT Consensus [338]	Appendix D.114	▽	◌	◌	◌	◌	◌	●	◌
Leader-Stable Fast Byzantine Fault Tolerance [339]	Appendix D.116	▽	◌	◌	◌	◌	◌	◌	◌
LFT2 [340]	Appendix D.117	▽	◌	◌	◌	◌	◌	◌	◌	Elec.
Lisk-BFT [341]	Appendix D.118	▽	◌	◌	◌	◌	◌	◌	◌	Elec.
Majority vOting Cellular Automata [342]	Appendix D.121	▽	◌	◌	◌	◌	◌	●	◌
Mchain Consensus [343]	Appendix D.122	▽	◌	◌	●	◌	◌	●	◌	Rand.
Mobile Crowdsourcing Chain [217]	Appendix D.123	▽	●	◌	●	◌	◌	◌	◌	Elec.
Multi-Block BFT [344]	Appendix D.124	▽	◌	◌	◌	◌	◌	●	◌
Multi-Round Concession Negotiation [172]	Appendix D.125	▽	●	●	◌	◌	●	◌	◌	Elec.
Multi-Supervised Permissioned Blockchain [345]	Appendix D.126	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Multisignature-BFT [346]	Appendix D.129	▽	◌	◌	●	◌	◌	●	◌	Elec.
Musch [347]	Appendix D.130	▽	◌	◌	◌	◌	◌	●	◌
Open Business Environment BFT [348]	Appendix D.132	▽	◌	◌	◌	◌	●	◌	◌
PeerBFT [349]	Appendix D.139	▽	◌	◌	◌	◌	◌	●	◌
Personal Archive Service System [350]	Appendix D.143	▽	◌	◌	◌	◌	◌	●	◌	Comm.
POA-PBFT [351]	Appendix D.145	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Practical Byzantine Fault Tolerance [144]	Appendix D.147	▽	◌	◌	◌	◌	◌	●	◌
Practical Layered Consensus Mechanism [352]	Appendix D.148	▽	◌	◌	◌	◌	◌	◌	◌
Proof of Rest [353]	Appendix D.158	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof of Training Quality [354]	Appendix D.161	▽	◌	◌	◌	◌	◌	●	◌
Proof of Usage [227]	Appendix D.162	▽	●	◌	●	◌	◌	●	◌	Rand.
Proof-of-Accuracy [355]	Appendix D.166	▽	◌	◌	●	◌	◌	◌	◌	Rand.
Proof-of-Achievement [228]	Appendix D.167	▽	●	◌	◌	◌	◌	●	◌
Proof-of-Activity [356]	Appendix D.169	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof-of-Atomicity [357,358]	Appendix D.170	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Proof-of-Authority [359]	Appendix D.171	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Business [232]	Appendix D.178	▽	●	◌	●	◌	●	●	◌	Elec.
Proof-of-Communication [360]	Appendix D.179	▽	◌	◌	◌	◌	●	◌	◌	Elec.
Proof-of-Contribution [233]	Appendix D.181	▽	●	◌	◌	◌	●	●	◌
Proof-of-Lucky-Id [361]	Appendix D.191	▽		◌	●	◌	◌	●	●	Rand.
Proof-of-Majority [362]	Appendix D.192	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof-of-Participation-and-Fees [363]	Appendix D.196	▽	◌	◌	◌	◌	●	◌	●	Elec.
Proof-of-Points [242]	Appendix D.198	▽	●	◌	●	◌	◌	◌	●	Elec.
Proof-of-Reputation [364]	Appendix D.204	▽	◌	◌	◌	◌	●	●	◌	Elec.
Proof-of-Review [243]	Appendix D.206	▽	●	◌	◌	◌	◌	◌	◌
Proof-of-Sovereignty [365]	Appendix D.208	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Stack [366]	Appendix D.211	▽	◌	◌	●	◌	●	●	◌	Rand.
Proof-of-Trust [367]	Appendix D.216	▽	◌	◌	●	◌	●	●	●	Comm.
Proof-of-Validation [247]	Appendix D.220	▽	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Verifying [175]	Appendix D.221	▽	●	●	●	◌	◌	●	◌	Rand.
Proof-of-Vote [368,369]	Appendix D.222	▽	◌	◌	●	◌	◌	●	◌	Comm.
Proof-of-Win [370]	Appendix D.223	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proteus [371,372]	Appendix D.229	▽	◌	◌	◌	◌	◌	●	◌
Raft [151]	Appendix D.230	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Randition [373]	Appendix D.231	▽	◌	◌	●	◌	◌	●	◌	Rand.
Random Leader Selection based on Credit Value [374]	Appendix D.232	▽	◌	◌	●	◌	●	●	◌	Elec.
Randomization to PoW [248]	Appendix D.233	▽	●	◌	●	◌	◌	◌	●	Rand.
Regulated Bitcoin [249]	Appendix D.235	▽	●	◌	●	◌	◌	●	◌	Rand.
Reputaion-Based BFT [375]	Appendix D.236	▽	◌	◌	●	◌	●	●	◌	Elec.
Reputation-based Byzantine Fault Tolerance [376]	Appendix D.239	▽	◌	◌	●	◌	●	◌	◌	Rand.
Rift [377]	Appendix D.241	▽	◌	◌	◌	◌	◌	◌	◌	Elec.
Robust Byzantine Agreement [336]	Appendix D.242	▽	◌	◌	●	◌	◌	●	◌	Rand.
Rock-Scissors-Paper [176]	Appendix D.244	▽	●	●	◌	◌	◌	●	◌
Rotating Multiple Random Sampling [378]	Appendix D.247	▽	◌	◌	●	◌	◌	●	◌	Rand.
Saguaro [379]	Appendix D.248	▽	◌	◌	◌	◌	◌	●	◌
Scalable Byzantine Fault Tolerance [380]	Appendix D.250	▽	◌	◌	●	◌	◌	●	◌	Rand.
Scalable Hierarchical Byzantine Fault Tolerance [381]	Appendix D.251	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Scalable Network-Coded PBFT [382]	Appendix D.252	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Scalable Practical Byzantine Fault Tolerance with Short-Lived Signature Schemes [383]	Appendix D.253	▽	◌	◌	●	◌	◌	●	◌	Comm.
Score Voting-based BFT Consensus [384]	Appendix D.254	▽	◌	◌	◌	◌	●	●	◌	Elec.
Security-Aware Genetic Algorithm based Practical Byzantine fault Tolerance [385]	Appendix D.256	▽	◌	◌	◌	◌	◌	●	◌
Self-Stabilizing Byzantine Consensus [386]	Appendix D.257	▽	◌	◌	●	◌	◌	●	◌	Rand.
separate-proof-of-deep-learning [387]	Appendix D.259	▽	◌	◌	◌	◌	◌	◌	◌
Sharding Permissioned Blockchains Over Network Clusters [388]	Appendix D.261	▽	◌	◌	◌	◌	◌	●	◌
Streamlet [389]	Appendix D.266	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Torneo [259]	Appendix D.272	▽	●	◌	●	◌	◌	●	◌	Rand.
Two-Tier Voting System Architecture [390]	Appendix D.275	▽	◌	◌	◌	◌	◌	●	●
uMine [391]	Appendix D.276	▽	◌	◌	◌	◌	◌	●	◌
Unitary Interchain Network [392]	Appendix D.277	▽	◌	◌	◌	◌	◌	◌	◌
Weak Centralized Consensus Mechanism with Incentive Effects [178]	Appendix D.278	▽	●	●	●	◌	◌	◌	◌	Rand.
Weight of Authentication Byzantine Fault Tolerance [393]	Appendix D.279	▽	◌	◌	◌	◌	◌	◌	●
What, Where, How much [260]	Appendix D.280	▽	●	◌	◌	◌	◌	●	◌
Efficient, General, and Scalable Consensus [154]	Appendix D.80	▽	◌	◌	●	●	◌	●	◌	Rand.
PoS with Robust Round Robin (PoW Bootstrap) [153]	Appendix D.10		●	◌	◌	◌	◌	◌	●	Comm.
PoUW as a Problem-Solving Market [186]	Appendix D.14		●	◌	●	◌	◌	◌	●	Rand.
Blockchain Reputation-Based Consensus [197]	Appendix D.38		●	◌	●	◌	●	◌	●	Elec.
Circle of Trust [200]	Appendix D.45		●	◌	●	◌	●	●	●	Elec.
Consensus of Trust [394]	Appendix D.53		◌	◌	●	◌	●	◌	◌	Rand.
Consensus-based Oracle Protocol for the Secure Trade of Digital Goods [203]	Appendix D.55		●	◌	●	◌	◌	◌	◌	Rand.
Credit-Based Verifier Selection with Double Consensus [395]	Appendix D.57		◌	◌	◌	◌	●	◌	◌
Decision-Theoretic Online Learning Consensus [396]	Appendix D.63		◌	◌	●	◌	●	◌	●	Rand.
Delegated Proof-of-Reputation [205]	Appendix D.69		●	◌	●	◌	●	●	◌	Elec.
Delegated Proof-of-Reputation [397]	Appendix D.70		◌	◌	●	◌	●	◌	●	Elec.
Green-PoW [212]	Appendix D.101		●	◌	●	◌	◌	◌	●	Rand.
Guru [398]	Appendix D.103		◌	◌	●	◌	●	◌	●	Rand.
Identity-Augmented Proof-of-Stake [399]	Appendix D.111		◌	◌	◌	◌	●	◌	●	Rand.
Permissionless Proof-of-Reputation-X [400]	Appendix D.142		◌	◌	●	◌	●	◌	●	Rand.
Proof-of-Balance [401]	Appendix D.172		◌	◌	◌	◌	◌	◌	●
Proof-of-Bid [231]	Appendix D.176		●	◌	●	◌	●	◌	●	Rand.
Proof-of-Human-Engagement [235]	Appendix D.185		●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Networking [239]	Appendix D.193		●	◌	●	◌	◌	◌	◌
Proof-of-Notarized-Work [240]	Appendix D.194		●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Review [402]	Appendix D.207		◌	◌	●	◌	●	◌	●	Elec.
Proof-of-Spending [244]	Appendix D.210		●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Stake with Time Staking [403]	Appendix D.214		◌	◌	●	◌	◌	◌	●	Rand.
Proof-of-Trust [404,405]	Appendix D.217		◌	◌	●	◌	●	◌	●	Rand.
Proof-of-Unique-Human [406]	Appendix D.219		◌	◌	◌	◌	●	◌	●
Reputation Consensus [407]	Appendix D.238		◌	◌	●	◌	●	◌	●	Rand.
Reverse Hash Chain [408]	Appendix D.240		◌	◌	●	◌	◌	◌	◌	Rand.
Semada Proof-of-Reputation [253]	Appendix D.258		●	◌	●	◌	●	◌	●	Rand.
Software Guard Extension-enabled decentralized intrusion detection framework [254]	Appendix D.263		●	◌	◌	◌	◌	◌	◌	Rand.
Sybil Tolerant Equality Protocol [177]	Appendix D.267		●	●	●	◌	●	◌	●
token age based consensus [258]	Appendix D.271		●	◌	◌	◌	●	◌	◌
Trust Consensus Protocol [409]	Appendix D.273		◌	◌	●	◌	●	◌	◌	Elec.
Twice Verifications and Consensuses of Blockchain [410,411]	Appendix D.274		◌	◌	◌	◌	●	●	●	Elec.
PoS with Robust Round Robin (Intel SGX Variant) [153]	Appendix D.11		●	◌	◌	●	◌	◌	●	Comm.
Basalt [159]	Appendix D.33		◌	◌	●	●	◌	◌	●	Rand.
DTNB [160]	Appendix D.78		◌	◌	●	●	◌	◌	●	Rand.
LocalCoin [163]	Appendix D.119		●	◌	●	●	◌	◌	●	Rand.
Proof of Block Inclusion [155]	Appendix D.152		●	◌	◌	●	◌	◌	●	Rand.
Proof of Elapsed Time [146]	Appendix D.154		◌	◌	●	●	◌	◌	●	Rand.
Proof of Luck [152]	Appendix D.157		◌	◌	●	●	◌	◌	◌	Rand.
Proof of Social Contact [162]	Appendix D.160		◌	◌	◌	●	◌	◌	●
Proof of witness presence [164]	Appendix D.163		◌	◌	◌	●	◌	◌	◌
Proof-of-Context [165]	Appendix D.180		◌	◌	◌	●	●	◌	●	Rand.
Proof-of-Location [166]	Appendix D.189		◌	◌	●	●	●	◌	●	Rand.
Proof-of-Queue [156]	Appendix D.201		◌	◌	●	●	◌	●	◌	Rand.
Rationality-proof consensus [158]	Appendix D.234		●	●	◌	◌	●	◌	●
Staked IP-Address Selection [161]	Appendix D.265		◌	◌	●	●	◌	◌	●	Rand.
Sybil-Proof Wireless Network Coordinate Based Byzantine Consensus [167]	Appendix D.268		◌	◌	◌	●	◌	◌	●	Elec.
DPoS with Quantum Entanglement [412]	Appendix D.3		◌	◌	◌	◌	◌	◌	◌
Delegated Byzantine Fault Tolerance [413]	Appendix D.66		◌	◌	◌	◌	◌	◌	◌	Elec.
Delegation Based Scalable Byzantine False [sic] Tolerance Consensus [414]	Appendix D.73		◌	◌	◌	◌	◌	◌	●
Fast Probabilistic Consensus with Weighted Votes [415]	Appendix D.93		◌	◌	●	◌	◌	●	●	Rand.
Green Mining [416,417]	Appendix D.100		◌	◌	●	◌	◌	◌	●	Rand.
Permissioned Trusted Trading Network Consensus Algorithm [418]	Appendix D.141		◌	◌	●	◌	◌	●	◌	Rand.
Proof of Kernel Work [419]	Appendix D.156		◌	◌	◌	◌	●	◌	◌	Rand.
Proof-by-Approval [420]	Appendix D.164		◌	◌	◌	◌	◌	●	◌	Comm.
Proof-of-Behaviour [229]	Appendix D.174		●	◌	●	◌	●	●	●
Proof-of-Belief [230]	Appendix D.175		●	◌	◌	◌	◌	◌	●
Proof-of-Phone [421]	Appendix D.197		◌	◌	◌	◌	◌	◌	●
Proof-of-Probability [422]	Appendix D.200		◌	◌	●	◌	◌	◌	●	Rand.
Proof-of-Work-or-Knowledge [423]	Appendix D.228		◌	◌	●	◌	◌	◌	●	Rand.
Secure and Scalable Hybrid Consensus [424]	Appendix D.255		◌	◌	◌	◌	◌	◌	●

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

, mechanisms with strong Sybil attack resistance are commonly targeted towards permissionless systems and often apply random leader selection strategies. Mechanisms without Sybil attack resistance, unsurprisingly, target permissioned systems and make use of election-based leader selection. In some cases, these mechanisms follow deterministic leader selection methods that are not captured by our categorisation. Schemes with limited Sybil attack resistance make heavy use of physical world linking to achieve Sybil attack resistance: some by using CPUs [153] or TEEs [146,152,154,155,156,157,158], others by relying on IP addresses [159,160,161], mobile phones [162], or physical proximity [163,164,165,166,167]. Incentive schemes are common in mechanisms with strong Sybil attack resistance, likely because these are expected in permissionless systems. Most incentive schemes rely on rewards [142,143,145,149,150,153,155,158,163,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,260] for adherence to the protocol, with only some incorporating penalties [158,168,169,170,171,172,173,174,175,176,177,178,261].

3.7. Mechanisms for Healthcare

Blockchain algorithms in healthcare are proposed to improve patient centricity of electronic healthcare systems [425,426], the effectiveness of legal medicine [425], the credibility and interoperability between healthcare stakeholders [427], as well as medical supply chain management [428]. Legal barriers, unsurprisingly, constitute a major obstruction to blockchain adoption in the healthcare domain [429], as record sharing (predominantly of electronic health records and personal health records [430]) is a highly regulated activity [431] with disjoint approaches throughout the healthcare field [432]. Consequently, as seen in

Table 10. Consensus mechanisms in healthcare.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
PoW Applied to Biomedical Image Segmentation [434]	Appendix E.1	▽	◌	◌	●	◌	◌	●	◌	Rand.
Deep Learning Based Consensus [435]	Appendix E.2	▽	◌	◌	●	◌	◌	◌	◌	Rand.
Lightweight Proof-of-Game [433]	Appendix E.3	▽	◌	◌	●	◌	◌	●	●	Rand.
MedBlock [436]	Appendix E.4	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Proof of Policy [438]	Appendix E.6	▽	◌	◌	◌	◌	◌	●	◌
Proof of Policy [439]	Appendix E.7	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Proof-of-Familiarity [440]	Appendix E.8	▽	◌	◌	◌	◌	●	●	◌
proof-of-medical-stake [441]	Appendix E.9	▽	◌	◌	◌	◌	●	●	◌
Proof of Artificial Intelligence [437]	Appendix E.5		◌	◌	●	◌	●	◌	◌	Rand.

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

, only a single mechanism targets permissionless systems [433] with others targeting permissioned or unspecified deployments [434,435,436,437,438,439,440,441].

3.8. Mechanisms for High Performance

As Oyinloye et al. [442] summarise, ‘throughput, scalability, security, energy consumption, and finality’ can be considered the main attributes of the overall performance of a blockchain system. This is despite an ongoing debate on the appropriateness of applying traditional performance metrics for standard systems to decentralised systems [443]. And indeed, most papers analysed have the goal of putting forward designs that improve on traditional metrics such as throughput and latency. Of the papers in this category (see

Table 11. Consensus mechanisms designed for high performance.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
PoS using Fair and Dynamic Sharding Management [444]	Appendix F.4	▲	●	◌	●	◌	◌	◌	◌	Rand.
Bicomp [445]	Appendix F.7	▲	●	◌	●	◌	◌	◌	◌	Rand.
Hybrid PoW/PoS [446]	Appendix F.24	▲	●	◌	●	◌	◌	◌	◌	Rand.
Scalable BFT consensus mechanism through aggregated signature gossip [447]	Appendix F.35	▲	◌	◌	●	◌	◌	●	●
BFT Consensus on FPGA [448]	Appendix F.1	▽	◌	◌	●	◌	◌	●	◌	Elec.
BFT Consensus with SmartNIC Offloading [448]	Appendix F.2	▽	◌	◌	●	◌	◌	●	◌	Elec.
PBFT with SVM-Based Trust Evaluation [449]	Appendix F.3	▽	◌	◌	◌	◌	●	●	◌	Elec.
Autonomous and Controllable High-performance Consensus [450]	Appendix F.5	▽	◌	◌	◌	◌	◌	◌	◌
BEAT [451]	Appendix F.6	▽	◌	◌	●	◌	◌	●	◌	Elec.
BlockDAG [452]	Appendix F.9	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Checkpoint Consensus [453]	Appendix F.10	▽	◌	◌	●	◌	◌	●	◌	Rand.
Concordia [454]	Appendix F.11	▽	◌	◌	●	◌	◌	●	◌	Rand.
Consensus based on the Mortgage Model [455]	Appendix F.12	▽	◌	◌	●	◌	◌	●	◌	Elec.
Consensus for Mobile Devices using Online Brokers [456]	Appendix F.13	▽	◌	◌	◌	◌	◌	●	◌
FAST [457]	Appendix F.14	▽	◌	◌	◌	◌	◌	●	◌	None
Fast Probabilistic Consensus within Byzantine Infrastructures [458]	Appendix F.15	▽	◌	◌	●	◌	◌	●	◌	None
Fast, Dynamic and Robust Byzantine Fault Tolerance [459]	Appendix F.16	▽	◌	◌	●	◌	◌	●	◌	Rand.
FastPay [460]	Appendix F.17	▽	◌	◌	◌	◌	◌	●	◌	None
FireLedger [461]	Appendix F.18	▽	◌	◌	◌	◌	◌	●	◌	Elec.
FRChain Consensus [462]	Appendix F.19	▽	◌	◌	●	◌	◌	●	◌	Elec.
Gosig [463]	Appendix F.20	▽	◌	◌	●	◌	◌	●	◌	Rand.
High Performance and Scalable Byzantine Fault Tolerance [464]	Appendix F.21	▽	◌	◌	◌	◌	◌	●	◌	Rand.
HPBC [465]	Appendix F.23	▽	◌	◌	●	◌	◌	●	◌	Elec.
Improved Practical Byzantine Consensus [466]	Appendix F.25	▽	◌	◌	◌	◌	◌	●	◌	Elec.
MinBFT-Based Consensus [467]	Appendix F.26	▽	◌	◌	◌	◌	◌	●	◌
Mixed Byzantine Fault Tolerance [468,469]	Appendix F.27	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Proof-of-Execution [470]	Appendix F.29	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Proof-of-Scalable-Traceability [471]	Appendix F.30	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Proof-of-Vote [369]	Appendix F.31	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Raft with Network Stability Evaluation [472]	Appendix F.32	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Random-Checkers Proof-of-Stake [473]	Appendix F.33	▽	●	●	◌	◌	◌	◌	●	Elec.
SACZyzzyva [474]	Appendix F.34	▽	◌	◌	●	◌	◌	●	◌	Rand.
Scalable Dynamic Multi-Agent Byzantine Fault-Tolerance [475]	Appendix F.36	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Scalable Efficient Byzantine Fault Tolerance [476]	Appendix F.37	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Scored PBFT [477]	Appendix F.38	▽	◌	◌	●	◌	●	●	◌	Elec.
Stream of Distributed Secrets for Quantum-safe Blockchain [478]	Appendix F.40	▽	◌	◌	●	◌	◌	◌	◌	Rand.
T-PBFT [479]	Appendix F.41	▽	◌	◌	◌	◌	●	●	◌	Elec.
Blinkchain [480]	Appendix F.8		◌	◌	●	◌	◌	◌	●	Rand.
High-Performance Blockchain Enhanced Consensus [481]	Appendix F.22		◌	◌	●	◌	◌	◌	●	Rand.
Multi Party Computation DPoS [482,483]	Appendix F.28		◌	●	◌	●	◌	◌	◌	Rand.
Self-Referencing Directed Acyclic Graph and Voting-Based PBFT Consensus [484]	Appendix F.39		◌	◌	●	◌	●	◌	●	Elec.

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

), the vast majority provide no Sybil attack resistance by building on BFT principles. For these papers, similar to early work [14,15], commonly a maximum threshold of byzantine processes (e.g., $1/3$) is assumed. Most papers perform benchmarking against similar mechanisms that do not provide Sybil attack resistance.

3.9. Mechanisms for IoT

A large number of papers apply blockchain to IoT (see

Table 12. Consensus mechanisms for the ‘Internet of Things’.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
PoW with Mining Tokens [488]	Appendix G.5	▲	●	◌	●	◌	◌	◌	◌	Rand.
Collaborative Proof-of-Work [489]	Appendix G.8	▲	●	●	●	◌	◌	◌	●	Rand.
Credit-Based Consensus Mechanism [490,491]	Appendix G.13	▲	◌	◌	●	◌	●	◌	●	Rand.
Hybrid PoW/PoS [492]	Appendix G.22	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Trading [493]	Appendix G.47	▲	●	◌	◌	◌	◌	◌	◌	Rand.
Random Proof of Work [494]	Appendix G.50	▲	●	◌	●	◌	◌	●	●	Rand.
Three-Dimensional Greedy Heaviest-Observed Sub-Tree Consensus [495]	Appendix G.56	▲	●	◌	●	◌	◌	◌	●	Rand.
BFT Consensus Based on Dynamic Permission Adjustment [496]	Appendix G.1	▽	◌	◌	◌	◌	●	●	◌	Elec.
IoT Adaptive Dynamic Consensus [497]	Appendix G.3	▽	◌	◌	◌	◌	◌	●	◌
Adaptive Proof-of-Work [498]	Appendix G.6	▽	◌	◌	●	◌	◌	●	◌	Rand.
Collaborative Trust Based Delegated Proof-of-Stake [499]	Appendix G.9	▽	◌	◌	●	◌	◌	●	◌	Rand.
Consensus with Elected Leader [500]	Appendix G.10	▽	◌	◌	●	◌	◌	●	◌	Elec.
Context-based consensus [501]	Appendix G.11	▽	◌	◌	◌	◌	◌	◌	◌	Elec.
Double-Layer PBFT [502]	Appendix G.16	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Dynamic Blind Voting [503]	Appendix G.17	▽	◌	◌	●	◌	◌	◌	◌	Rand.
Improved PBFT [504]	Appendix G.24	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Lightweight Blockchain based Cybersecurity [505]	Appendix G.25	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Lightweight Consensus for IoT [506]	Appendix G.26	▽	◌	◌	◌	◌	◌	●	◌
Luckyminer [507]	Appendix G.27	▽	●	◌	●	◌	◌	◌	●	Rand.
Multi-Chain Proof of Rapid Authentication [508]	Appendix G.28	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Optimized PBFT Consensus with Speaker [509]	Appendix G.29	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof-of-Presence [510]	Appendix G.33	▽	◌	◌	◌	◌	◌	●	◌	Rand.
Proof of Random Count in Hashes [511]	Appendix G.35	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof of Reputation [512]	Appendix G.36	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Balance [513]	Appendix G.38	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Proof-of-Block-and-Trade [514]	Appendix G.39	▽	◌	◌	◌	◌	◌	●	◌	Rand.
Proof-of-Common-Interest [515,516]	Appendix G.40	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Popularity [517]	Appendix G.44	▽	◌	◌	●	◌	●	●	◌	Rand.
Proof-of-Stability [518]	Appendix G.46	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Proof-of-Validity [519]	Appendix G.48	▽	◌	◌	◌	◌	◌	●	◌
ReBFT [520]	Appendix G.51	▽	◌	◌	◌	◌	◌	●	◌
SCBFT [521]	Appendix G.53	▽	◌	◌	◌	◌	◌	●	◌
Time-Dependent Consensus [522]	Appendix G.57	▽	◌	●	◌	◌	◌	◌	◌	Rand.
Tree-Chain [523]	Appendix G.58	▽	◌	◌	●	◌	◌	●	◌	Rand.
Two-Layer-Consensus Architecture for IoT [524]	Appendix G.59	▽	◌	◌	●	◌	◌	●	◌	Rand.
Weighted Majority Consensus Algorithm [525]	Appendix G.60	▽	◌	◌	●	◌	●	●	◌	Rand.
DPoS for Network Intrusion Detection [526]	Appendix G.2		◌	◌	◌	◌	●	◌	◌	Elec.
PBFT Based on Reputation Value [527]	Appendix G.4		◌	◌	◌	◌	●	●	◌	Elec.
Consensus Algorithm for Mobile-Edge Computing [528]	Appendix G.7		◌	◌	●	◌	●	●	●	Elec.
Credit Reinforce Byzantine Fault Tolerance [529]	Appendix G.12		◌	◌	●	◌	◌	◌	●	Elec.
Distributed Time-Based Consensus [530]	Appendix G.15		●	◌	●	◌	◌	◌	●	Rand.
Edge Computing Blockchain Security Consensus Model [531]	Appendix G.18		◌	◌	●	◌	●	◌	◌
Geographic-PBFT [532]	Appendix G.19		◌	◌	◌	◌	◌	◌	●	Elec.
Honesty-Based Distributed Proof-of-Work [533]	Appendix G.20		◌	◌	●	◌	●	●	●	Elec.
Honesty-Based Distributed Proof-of-Authority via Scalable Work [534]	Appendix G.21		◌	◌	●	◌	●	●	●	Elec.
PF-BVM [535]	Appendix G.30		◌	◌	●	◌	●	●	●
Predictive Proof of Metrics [536]	Appendix G.31		●	◌	●	◌	●	●	●	Elec.
Proof of Elapsed Work and Luck [537]	Appendix G.32		◌	◌	●	◌	◌	◌	●	Rand.
Proof-of-Honesty [538,539]	Appendix G.41		◌	◌	◌	◌	●	◌	◌	Rand.
Proof-of-Negotiation/Proof-of-Trust Negotiation [540,541]	Appendix G.42		●	◌	●	◌	●	◌	◌	Rand.
Register, Deposit, Vote [542]	Appendix G.52		◌	◌	◌	◌	◌	◌	◌	None
Sybil Resistant IoT Trust Model [543]	Appendix G.54		◌	◌	●	◌	●	●	◌	Rand.
Synergistic Multiple Proof [544]	Appendix G.55		◌	◌	◌	◌	●	◌	●
Delegated Proof-of-Proximity [545]	Appendix G.14		◌	◌	◌	●	◌	◌	◌
Proof-of-Authentication [546,547,548]	Appendix G.37		◌	◌	●	●	◌	◌	◌	Elec.
Proof-of-Physical Unclonable Function [549]	Appendix G.43		◌	◌	●	●	◌	◌	●	Rand.
Hybrid Consensus [550]	Appendix G.23		◌	◌	•	◌	◌	●	●	Rand.
Proof-of-Reputation-X [551]	Appendix G.45		◌	◌	◌	◌	●	◌	◌
Proof-of-Work Using Maximization-Factorization Statistics [552]	Appendix G.49		◌	◌	●	◌	◌	◌	◌	Rand.
Proof of PUF-Enabled Authentication [553]	Appendix G.34		◌	◌	◌	●	◌	◌	◌

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

), often with the goal of improving the security of IoT stacks [485] or to enable immutable traceability [486]. In common IoT deployments, there is a large disparity of computational capabilities between IoT devices and edge devices [487]. This disparity is also one of the drivers of hierarchicality in these use cases [20]. This favours algorithms with limited or no Sybil attack resistance that offload computation to edge nodes: often these edge nodes are operated centrally, by trustworthy entities.

3.10. Mechanisms for Media and Entertainment

Few mechanisms have been proposed for the media and entertainment domain (see

Table 13. Consensus mechanisms in media.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Proof-of-Play [559]	Appendix H.3	▽	◌	◌	●	◌	◌	●	◌	Rand.
Credibility Score [560]	Appendix H.1		◌	◌	◌	◌	●	◌	●	Elec.
Proof-of-Contribution [561]	Appendix H.2		●	◌	◌	◌	●	◌	◌

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

). While Non-fungible tokens (NFTs) have gained considerable popularity in the arts [554,555] as well as media and entertainment [556,557] and have since generated sales of over 940 million USD [558], according to our analysis, no mechanisms specifically for this phenomenon have been developed. Instead, we see a mechanism tailored to gaming which requires centralised infrastructures for score assessment [559] and a mechanism to counteract false and misleading information presented as news [560]. No mechanisms with strong Sybil attack resistance were found in this category.

3.11. Mechanisms for Supply Chain

The supply chain can be characterised as a highly relevant domain for blockchain due to its promise of delivering information transparency and immutability [562] as well as its potential to bring about disintermediation [563]. Supply chain management and IoT (see Section 3.9) often go hand in hand to improve traceability and interoperability and make frequent use of sensor data originating from IoT devices [564]. Therefore, it is not surprising that, in terms of Sybil attack resistance, many properties are shared with the IoT domain: The mechanisms proposed (see

Table 14. Consensus mechanisms in supply chain.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Consensus Mechanism for Marine Data Management System [569]	Appendix I.2	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Improved Practical Byzantine Fault Tolerance [570,571]	Appendix I.4	▽	◌	◌	◌	◌	◌	●	◌	Comm.
Multi-Center Practical Byzantine Fault Tolerance [567]	Appendix I.5	▽	◌	◌	◌	◌	◌	●	◌
Proof of Accomplishment [568]	Appendix I.6	▽	◌	◌	◌	◌	●	●	◌
C-dBFT [565]	Appendix I.1		◌	◌	◌	◌	◌	●	◌
Group-Based PoW [566]	Appendix I.3		●	◌	●	◌	◌	◌	◌	Rand.
Proof-of-Location [572]	Appendix I.7		◌	◌	●	◌	◌	◌	●	None

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

) only deliver limited Sybil attack resistance [565,566,567,568] or no Sybil attack resistance [569,570,571]. This can be attributed to the trustworthy provenance problem: supply chain efforts require trustworthy intermediaries to prevent physical tampering (e.g., the manipulation of sensors or interference with physical products). Therefore, the mechanisms in this category commonly rely on permissioned systems which can cater to hierarchical architectures [20].

3.12. Mechanisms for Telecom

The application of blockchain in telecom is nascent with only two dedicated mechanisms found (see

Table 15. Consensus mechanisms in telecom.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
Proof-of-Majority [575]	Appendix J.2	▽	◌	◌	◌	◌	◌	●	◌
Delegated Proof-of-Trust [574]	Appendix J.1		◌	◌	●	◌	◌	◌	◌

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

). Darmwal [573] explains this by showing that the telecom domain is bound by numerous historic standards of interoperability and predicts that, therefore, adoption will be slow and should focus on lighthouse projects led by established consortia. This prediction is reflected in the fact that mechanisms in this vertical expose only limited Sybil attack resistance [574] or no Sybil attack resistance [575] at all, hinting at the application of the proposed mechanisms in permissioned contexts.

3.13. Mechanisms for Useful Work

Useful work schemes are ubiquitous, created with the goal of deriving useful outputs from PoW. As most mechanisms implement mechanics similar to conventional PoW, their Sybil attack resistance properties are strong (see

Table 16. Consensus mechanisms using ‘Proofs-of-useful-work’.

			Inc					Perm
	Ref	SA	+	−	Ra	Ph	Re	Pn	Pl	Sel
PoUW for ML Training [576]	Appendix K.1	▲	◌	◌	●	◌	◌	◌	●	Rand.
PoW Applied to High-Dimension, Non-Linear Optimisation Problems [577]	Appendix K.2	▲	●	◌	●	◌	◌	◌	●	Rand.
PoW Based On NCP-Solving [578]	Appendix K.3	▲	◌	◌	●	◌	◌	◌	●	Rand.
PoW Based on Random Multivariate Quadratic Equations [579]	Appendix K.4	▲	◌	◌	●	◌	◌	◌	●	Rand.
PoW on Elements in a Cyclic Group [580]	Appendix K.5	◌	◌	◌	◌	◌	◌	◌	●	Rand.
Calibration of Public Key Cryptographic Systems via Proof-of-Work [581]	Appendix K.7	▲	●	◌	●	◌	◌	◌	●	Rand.
Coin.AI [582]	Appendix K.8	▲	●	◌	●	◌	◌	◌	●	Rand.
Conquering Generals [583]	Appendix K.9	▲	●	◌	●	◌	◌	◌	●	Rand.
Difficulty-based Incentives for Problem Solving [584]	Appendix K.10	▲	●	◌	●	◌	◌	◌	●	Rand.
Hybrid Mining [585]	Appendix K.11	▲	●	◌	●	◌	◌	◌	●	Rand.
Image-based Proof-of-Work [586]	Appendix K.12	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof of Catalytic Space [587]	Appendix K.13	▲	◌	◌	●	◌	◌	◌	●
Proof of Deep Learning with Hyperparameter Optimization [588]	Appendix K.14	▲	◌	◌	●	◌	◌	◌	●	Rand.
Proof of Evolution [589]	Appendix K.15	▲	●	◌	◌	◌	◌	◌	●	Rand.
Proof-of-Deep-Learning [590,591]	Appendix K.18	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Exercise [592]	Appendix K.19	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Learning [593]	Appendix K.20	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Learning [594]	Appendix K.21	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof-of-WorkStore [595]	Appendix K.24	▲	◌	◌	●	◌	◌	◌	●	Rand.
Reciprocally Useful Work [596]	Appendix K.25	▲	●	◌	●	◌	◌	◌	●	Rand.
Proof of Federated Learning [597]	Appendix K.16	▽	◌	◌	◌	◌	◌	◌	◌
Proof-of-Accuracy [598]	Appendix K.17	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Learning [599]	Appendix K.22	▽	●	◌	●	◌	◌	◌	◌	Rand.
BlockML [600]	Appendix K.6		●	◌	●	◌	◌	◌	●	Rand.
Proof-of-Search [601]	Appendix K.23		●	◌	●	◌	◌	◌	◌	Rand.
Susreum [602]	Appendix K.26		◌	◌	◌	◌	◌	◌	●	Elec.
VBFL [603]	Appendix K.27		●	◌	●	◌	●	◌	◌	Rand.

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

). It can be differentiated between fixed PoUW schemes, in which a well-defined computational problem exists, and marketplace-based mechanisms, in which problems can be proposed dynamically. The former are often well-specified and provide appropriate difficulty adjustment mechanisms while the latter sometimes lack such considerations and, therefore, have unclear security properties. Marketplace mechanisms can often only provide limited Sybil attack resistance due to the risk of collusion between sellers and buyers and the challenge of objectively establishing the best solution. This is particularly apparent in artificial intelligence (AI)-based marketplace mechanisms that require the objective evaluation of a potentially large number of proposed machine learning (ML) models.

3.14. Mechanisms for Vehicles

A surprisingly rich domain is the domain of vehicles which shares many benefits and challenges with the domain of IoT. Blockchain applications in the vehicle domain predominantly target data exchange between vehicles, resource sharing (e.g., collaborative use of computing resources), parking coordination, and traffic management [604]. As shown in

Table 17. Consensus mechanisms in vehicles.

			Inc					Perm
	Ref	SA	+	-	Ra	Ph	Re	Pn	Pl	Sel
Consensus Mechanism for Blockchains on IoV [605]	Appendix L.1	▲	◌	◌	●	◌	◌	◌	◌	Elec.
dynamic Proof-of-Work [606,607,608]	Appendix L.3	▲	●	◌	●	◌	◌	◌	●	Rand.
Mixed Consensus Algorithm Based on PoW and PBFT [609]	Appendix L.6	▲	◌	◌	●	◌	●	◌	◌	Rand.
Consensus Program for Charging Piles [611]	Appendix L.2	▽	●	◌	●	◌	●	●	◌	Elec.
Enhanced DPoS [612]	Appendix L.4	▽	◌	◌	◌	◌	●	●	◌
Improved Byzantine Consensus for IoV [613]	Appendix L.5	▽	◌	◌	●	◌	◌	●	◌	Rand.
Multipoint-Relay-Driven Consensus [614]	Appendix L.7	▽	◌	◌	●	◌	◌	●	◌	Rand.
Practical Byzantine Fault Tolerance with Forwarding [615]	Appendix L.8	▽	◌	◌	◌	◌	◌	●	◌	None
Proof of Event and Location [616]	Appendix L.9	▽	◌	◌	◌	◌	◌	●	◌
Proof-of-Communication [617]	Appendix L.10	▽	◌	◌	●	◌	◌	◌	◌	Elec.
Proof-of-Driving [618]	Appendix L.11	▽	◌	◌	●	◌	●	◌	◌	Rand.
Proof-of-Event with Dynamic Federation [619,620]	Appendix L.12	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof-of-Matching [621]	Appendix L.13	▽	●	◌	◌	◌	◌	●	◌	Comm.
Proof-of-Nonce [622]	Appendix L.14	▽	◌	◌	●	◌	◌	●	◌	Rand.
Proof-of-Reputation [623]	Appendix L.16	▽	◌	◌	◌	◌	●	●	◌	None
Proof-of-Utility [624,625]	Appendix L.17	▽	◌	◌	●	◌	◌	●	◌	Elec.
Proof-of-Vehicular-Services BFT [626]	Appendix L.18	▽	◌	◌	◌	◌	●	●	◌	Elec.
Reputation-based Miner Node Selection [627]	Appendix L.21	▽	◌	◌	◌	◌	◌	●	◌
Secured Event-Information Sharing [628]	Appendix L.22	▽	◌	◌	◌	◌	◌	●		Comm.
Semi-Autonomous Distributed Blockchain-Based Framework for UAVs [629]	Appendix L.23	▽	◌	◌	◌	◌	◌	●	◌	Elec.
Time-Oriented Proof of Work [630]	Appendix L.24	▽	◌	◌	◌	◌	◌	◌	◌
Voting-based Consensus Protocol for VANET [631,632]	Appendix L.25	▽	◌	◌	●	◌	●	●	◌	Comm.
Proof-of-Work-at-Proximity [633]	Appendix L.19		●	◌	●	◌	◌	◌	◌	Rand.
Reputation-Based DPoS [634]	Appendix L.20		◌	◌	◌	◌	●	◌	◌
Proof-of-Quality-Factor [635]	Appendix L.15		●	●	●	●	◌	●	◌	Elec.

Ref: Section reference, SA: Sybil attack resistance class, Inc +: Reward scheme, Inc −: Punishment scheme, Ra: Randomisation, Ph: Physical world linking, Re: Reputation system, Perm Pn: Permissioned, Perm PI: Permissionless, Sel Rand.: random leader selection, Sel Comm.: Committee-based leader selection, Sel Elec.: Leader selection via selection. ▲: Strong Sybil attack resistance, : Limited attack resistance, ▽: No Sybil attack resistance. ●: Applicable, ◌: Not applicable.

, schemes with strong Sybil attack resistance [605,606,607,608,609] are outnumbered by schemes with limited or no Sybil attack resistance. In line with Wang et al. [610], who attest that blockchain in vehicular security is in its infancy, we find that some of the mechanisms proposed do not make use of the full potential of a decentralised paradigm by being overly hierarchical and by relying on central actors.

4. Conclusions

The bulk of research interest in the field is focused on a small set of popular mechanisms (see Section 3.2) with Proof-of-Work (PoW), Proof-of-Stake (PoS), and Practical Byzantine Fault Tolerance as the most popular mechanisms. The literature review has shown that, beyond these, many more, seemingly disparate, consensus mechanisms exist (see Section 3). However, upon closer examination, it can be concluded that there are strong similarities between those.

Amongst the systems with strong Sybil attack resistance, we find mostly PoW-like mechanisms that utilise some form of scarce resource constraint (CPU, memory, or otherwise) and PoS-like systems that rely on staking of resources (e.g., cryptocurrencies, stablecoins, reputation tokens, etc.). We also find combinations of the two, e.g., where a PoW bootstrapping phase is combined with a PoS execution phase. Sometimes these mechanisms are combined with reputation systems but the latter are rarely central to their Sybil attack resistance properties.

Systems with limited Sybil attack resistance are amongst the most interesting: these often make creative use of reputation systems (e.g., systems in which the right of a user to mine blocks correlates with their peer-to-peer rating). Physical world linking, i.e., the use of information emanating from objects in the physical world, is also most prevalent in this category: we find CPUs, trusted execution environments, and mobile phones to be common objects used. Furthermore, some mechanisms in this category use properties of well-recognised Internet standards such as the Domain Name System or public Internet Protocol (IP) addresses to determine uniqueness. This category, regrettably, is also one that contains mechanisms with overstated Sybil attack resistance properties and, often, poor specification.

Systems without Sybil attack resistance are mostly contained for completeness. Apart from rare instances where authors claim Sybil attack resistance, most works in this category target permissioned systems (that do not require mechanisms with Sybil attack resistance). Some authors explicitly exclude Sybil attack resistance considerations from their proposals and suggest applying alternative schemes to achieve it.

4.1. State of the Literature

Sybil attack resistance is a hard-to-achieve property that comes with significant trade-offs in terms of complexity, performance, and cost. Many mechanisms that aspire to provide strong Sybil attack resistance fall short of this goal. The choice of consensus mechanisms is overwhelming and system designers have often opted for designing new mechanisms without a strong need for it. In many ways, this is symptomatic for the wider subject area of distributed ledger technology where, despite some signs of the field maturing, solutions looking for problems are still prevalent.

In his 2017 manuscript, Cachin [636] delivered a ‘Snake Oil Warning’, alerting of the risks arising from consensus mechanism being developed without ‘agreement on trust assumptions, security models, formal reasoning methods, and protocol goals’ [636] (p. 2). In the context of this paper, we want to reiterate and enforce this warning: many protocols that suggest Sybil attack resistance do not deliver on this implication. Overall, significant quality issues in many of the protocols proposed are apparent. Many of the papers analysed lack formalisation, leaving essential aspects as an exercise to the reader, thereby exposing implementors and users to security risks. Some papers, while peer-reviewed and, in some cases, highly cited, misunderstand fundamental aspects of decentralised computing. This is particularly evident in reputation-based consensus methods that often address Sybil attack resistance through mitigation schemes that, under scrutiny, do not hold.

However, it is not all doom and gloom: recent years have seen some high-quality contributions that have further enhanced the performance of consensus mechanisms, significantly improved their Sybil attack resistance, or produced innovative approaches to saving energy. It is also to be welcomed that authors analyse the use of consensus mechanisms in industry-specific settings to drive appropriate solutions forward. It can therefore be speculated that the works that will stand the test of time will be those that apply rigorous modelling, formal security analysis, and comprehensive threat modelling.

4.2. Gaps

It is a challenging undertaking to compare the Sybil attack resistance properties of consensus mechanisms: there is no canonical approach to specifying consensus mechanisms for blockchain making it hard to formally scrutinise them. Furthermore, there is no common understanding of what constitutes good Sybil attack resistance, let alone recognised ways of asserting the Sybil attack resistance qualities of a proposed mechanism. Mechanism designers, in many cases, lack consideration for Sybil attacks in their work. Especially for domain-specific consensus mechanisms, it should be established what the permissioning-approach and, therefore, the threat model is.

4.3. Research Directions

Given the challenges discussed, four dominant directions for consensus mechanism research are conceivable. First, research should focus on introducing more rigorous approaches to the field by adapting existing formal methodologies to blockchain environments. Second, research should be undertaken to formally identify suitable canonical consensus mechanisms for common standard use cases. Third, research should enable incremental innovation of such canonical consensus mechanisms, thereby creating ‘best-in-class’ mechanisms for various use cases. Fourth, realistic benchmarks should be developed that allow for the objective comparison of non-functional aspects of blockchain systems (e.g., throughput performance or time-to-finality).

4.4. Future Work

Future work should focus on developing a formal framework to objectively quantify the Sybil attack resistance of consensus mechanisms. Formal methods should be applied that yield an objective categorisation of a protocol’s Sybil attack resistance.