1. Introduction

2. Overview of Blockchain Technology

2.2. How Blockchain Technology Works

As mentioned previously, a private key is employed in order to initiate a transaction between two participants. Each transaction is added in a pool used by the technology to store all the transactions of the same network. The transaction contains details such as the sender’s information and the receiver’s address, the amount of data that is being transferred and a timestamp. Figure 2 visualizes in a simple way how Blockchain works.

One of blockchain’s major features is its anonymity, which is both an advantage and a problem for the technology. Both parties in a transaction have the need to remain anonymous. That, however, can have a negative impact on the trust between the users. This is why each and every transaction needs to be validated that it is indeed legal and then be put into a block. Thus, an agreement must be reached for the transactions to be put in said block to the blockchain. That can be achieved through consensus algorithms [5].

2.2.1. Consensus Algorithms

Consensus algorithms are mechanisms used in Blockchain so that all participants can reach a mutual agreement on the validity of the transactions being made, despite the fact that potential failures or inconsistencies might be discovered in the data. There are many types of consensus algorithms that have been developed, each with its own advantages and disadvantages as well as unique features. Reaching a consensus on blocks or transactions has proved to be quite challenging because these algorithms need to maintain a certain stability and resilience against node failures, corrupted or delayed messages and nodes that seem malicious or are unresponsive [6].

There are many types of consensus algorithms, the most important of which are summarized below:

2.2.1.1. Proof of Work (PoW)

Originally, Proof of Work was used by Bitcoin. It is like a game where all participants need to agree on a transaction record. Imagine a teacher in a classroom that hands out a quite challenging puzzle that requires time and effort in order to be solved. Once it is solved, however, it becomes easy for everyone to check if the answer is correct. In blockchain, miners or validators are the ones that compete with each other in order to solve a cryptographic puzzle and add a new block in the chain. This same process starts over for the next set of transactions (new blocks), making sure that the blockchain remains secure and agreed upon by all participants, without any need for intermediaries to act as a central authority. Figure 3 shows how the algorithm Proof of Work operates.

2.2.1.2. Proof of Stake (PoS)

Proof of Stake was developed as an alternative to Proof of Work. This algorithm, instead of solving a complex puzzle, works with a process of random selection, like a lottery system, plus in investment-like mechanism, in order to reach a consensus and validate transactions. In this algorithm, validators or stakers, place their own cryptocurrency as a stake, in order to prove that they are serious and trustworthy. Think of it as placing a certain deposit for a future investment. The higher this deposit is, the more probable it is for the staker to be chosen in order to validate new transactions and create new blocks. When the network is required to add new blocks to the blockchain, it will randomly select one of these stakers, based on how high their stake is. Ethereum 2.0 for example is currently using the PoS system. Figure 4 depicts how Proof of Stake works.

2.2.1.3. Delegated Proof of Stake (DPoS)

The Delegated Proof of Stake algorithm is an evolution of the traditional Proof of Stake described previously. In this consensus algorithm, a distributed voting system is promoted, in which members vote a limited number of witnesses, or delegates, to secure the network, make sure no acts of fraud are being committed, validate transactions and create new blocks. This algorithm is based on a reputation system where dishonest delegates can be voted out of the system. In DPoS, the number of delegates is kept to a minimum in order to be able to achieve improved efficiency, scalability and low energy consumption. The DPoS algorithm aims to create a more scalable form of consensus which will be able to significantly increase transaction speeds and reduce costs. This makes DPoS a rather suitable system for distributed applications requiring high transaction propagation rate. Figure 5 shows in detail how Delegated Proof of Stake works.

2.2.1.4. Practical Byzantine Fault Tolerance (PBFT)

Practical Byzantine Fault Tolerance algorithms are highly relevant to distributed systems as they address the Byzantine Generals' Problem. To put it briefly, the issue involves a group of Byzantine generals (or nodes in the case of a blockchain) reaching a consensus on a collective course of action. The Byzantine generals then engage in combined action by coordinating several army units to attack a citadel simultaneously. Regarding blockchains, this involves obtaining consensus on whether to verify a block or set of transactions. The difficulty lies in the fact that messages sent between the generals must traverse enemy territory and might potentially be lost without alerting the sender or the receiver, akin to traveling via an unstable, decentralized network. Additionally, some of the generals might be traitors who want to disrupt the combat strategy by transmitting misleading or altered communications, or by ignoring messages altogether. The problem is to guarantee that faithful generals can come to an agreement on the offensive strategy, without a few disloyal individuals leading them to choose an ineffective plan. In blockchain terminology, a limited number of untrustworthy or possibly malicious nodes should not have the ability to influence the confirmation of a fraudulent block or set of transactions. These transactions are verified individually by well-known and trusted validators, making these algorithms more suitable for implementation in trusted environments. Figure 6 depicts the way Practical Byzantine Fault Tolerance works.

2.2.1.5. Proof of Authority (PoA)

Proof of Authority is another consensus algorithm used in blockchain networks. In this system, approved accounts act as validators and are the ones responsible for validating blocks and transactions. PoA algorithms are based on the reputation and the identity of its validators. They are chosen based on their reliability and overall commitment to the network. Usually, the identity of these validators is public and easily verifiable, thus adding an extra layer of accountability to the whole PoA system. Since those validators put their identity and reputation at stake, they are quite motivated into maintaining and enhancing the integrity of the network. Generally, PoA’s processes of transaction validation are much faster than PoW’s or PoS’s, since validators are limited and well-known in this mechanism, making it ideal for organizations requiring more scalable blockchain solutions. Figure 7 shows us how Proof of Authority really works.

Table 1. Comparison of Blockchain consensus mechanisms.

Table 1. Comparison of Blockchain consensus mechanisms.

Consensus Mechanism	Energy Consumption	Security	Scalability	Use Cases
Proof of Work (PoW)	High	High, but energy-intensive and vulnerable to 51% attacks	Limited by transaction throughput (e.g., Bitcoin ~7 transactions per second)	Bitcoin, Ethereum (transitioning away), Litecoin
Proof of Stake (PoS)	Low to Moderate	High, dependent on the amount of staked tokens	Better than PoW, but still faces challenges with network congestion	Ethereum 2.0, Cardano, Tezos
Delegated Proof of Stake (DPoS)	Low	High, but relies on a smaller number of validators	High scalability due to fewer validators needed for consensus	EOS, Tron, Steem
Byzantine Fault Tolerance (BFT)	Moderate	Very high, resilient to up to 1/3 of nodes failing or acting maliciously	High scalability with fast transaction finality	Hyperledger Fabric, Tendermint (used in Cosmos)
Proof of Authority (PoA)	Low	High, but depends on the trustworthiness of authorities	High scalability with quick consensus due to limited validators	VeChain, POA Network, Private blockchains

3. Distributed Systems: Concepts and Challenges

3.1. Core Concepts of Distributed Systems

Nodes and networks: as we mentioned previously, distributed systems are networks comprised of independent computers. These computers, that work together in order to complete a set of tasks, are also known as nodes. These nodes exchange messages in order to effectively communicate with each other. Each of these nodes is its own set of a complete terminal (both hardware and software) and there are variations in what their roles are in the network, their resources and their capabilities. Such diversity noted among these nodes is what empowers distributed systems to effectively leverage their vast resources and capabilities, thus enhancing their efficiency and flexibility even further. The architecture of these systems is being widely used in creating both local area networks (LANs) and wide area networks (WANs).

Decentralization: in centralized systems, there is one main unit or a mainframe which controls how the entire network will operate and undertake tasks. If the mainframe crashes, the entire system crashes along with it. In decentralized systems, there is not one single mainframe that controls everything. Instead, control is spread out to the entire network’s terminals, or nodes, each one of them working independently. Thus, in case of a node’s breakdown, the rest of the system keeps functioning well and can complete tasks.

Distributed systems have been utilizing decentralized cooperative algorithms for the purposes of achieving better fault-tolerance rates, higher performance and better load balancing. Since decentralized environments have emerged, such as peer-to-peer networks, decentralized algorithms have become a necessity in order for these networks to be able to coordinate tasks, communicate effectively and make the right decisions locally. There are three well-established cooperative algorithms which are being discussed below [7].

• Voting is a cooperative algorithm used by decentralized systems in order to make decisions collectively. In such a network, each node will place its vote on certain decisions like which version of a specific set of data is correct. The nodes (or computers) will communicate their “votes” with each other, based on a set of rules that each one has, subsequently making a decision based on the total number of votes the corresponding option gathered [7].
• Token Ring is another cooperative algorithm tasked with managing the network’s communication system. In this kind of network, all nodes are connected with each other in the shape of a ring. Within this ring of nodes, there is a digital token which moves around the network, to the node that wants to send a message. Without this token, a node cannot communicate with the other nodes in the network. Once a node has sent its message, it passes the token on to the next node in line to communicate [7].
• Market-based is the third cooperative algorithm of the list that is being employed in a decentralized distributed system. This algorithm works like a “trading marketplace”; nodes offer specific resources and ask for something else in return. For example, a node may offer processing power to another node in exchange for some storage space. These algorithms help a network allocate its resources in the most efficient way, taking into consideration each node’s demands and maximizing the network’s overall performance.

Scalability: the concept of scalability refers to a system’s capability to handle any extra load of work given to it or its potential to accommodate it. Scalability has two important parameters; size and location. Size scalability is about the number of nodes (computers or servers) added into the network and how well this network can handle more nodes or tasks given to it, without it having any negative repercussions to its performance [8]. When it comes to location, geographical scalability is about a system’s ability to maintain its robustness and effectiveness across larger geographical areas. Think of it as an efficient delivery service that can reach its customers fast, no matter how spread out they are.

An illustrative case is Twitter's transition from a monolithic architecture to a microservices-based distributed system. Initially, Twitter faced significant scalability issues, with frequent downtimes during peak usage. By migrating to a distributed system with microservices, Twitter improved its scalability, allowing it to handle millions of users simultaneously. This transition, however, required overcoming challenges related to service orchestration, data consistency, and fault tolerance.

Transparency: distributed systems have the ability to appear to its users and developers as one single unit (network) rather than many autonomous systems working together. The users should not be aware of what is the location of these systems or what files are being transferred. Below, the 7 different types of transparencies are presented [9].

Table 2. 7 types of Transparencies.

Table 2. 7 types of Transparencies.

Type	Description
Access	This kind of transparency hides from the end-user the data behind the system or the way this data is accessed. A prime example of this is ATMs. We do not see how they work but they do their job and we get our money.
Location	The location transparency hides from the user where a system’s resources (or services or files) are located but it can be accessed as if it were a user’s local system.
Concurrency	This type of transparency allows for multiple users to access resources all at the same time, without any of them interfering in the others’ work. One example of this transparency is the way colleagues can work on the same text document simultaneously, in real time.
Replication	Replication transparency makes sure to hide the replicated resources and data from the user and only show them one instance of the data they require.
Failure	This transparency hides from the user a system’s failure and recovery of its components. Every time a server crashes, a user’s request is automatically rerouted and executed by another server, without the user ever realizing the crash.
Migration	Migration transparency allows a system to transfer its resources and processes within the system, without the user ever noticing or being affected by it.
Performance	The system has the ability to reconfigure itself in order to improve its performance, again without the end-user ever noticing or being affected by this process.

3.2. Challenges in Distributed Systems

Distributed systems may offer some very important features but they are not without their challenges because of their complexity and their constant need for coordination across multiple platforms and locations. Some key challenges distributed systems face are presented below.

Fault tolerance: Distributed systems, much like any other system, are prone to hardware or software faults. The way a distributed system responds and is capable of resolving these faults is known as fault tolerance. Fault tolerance as a concept is based on two components; failure detection and recovery. Generally, there are two main approaches in coping with fault tolerance; proactive and reactive fault tolerance [10].

Proactive fault tolerance: the main idea here is to be able to predict when faults will occur and what kind, and to take all the necessary actions required in order to address them properly when the time comes. Here, there are 3 techniques that are mostly used:

Table 3. 3 techniques of Proactive Fault Tolerance.

Table 3. 3 techniques of Proactive Fault Tolerance.

Type	Description
Preventive maintenance	This technique involves the regular maintenance of the entire system and all of its components in order to keep it robust and prevent its failure.
Predictive analysis	This technique is about analyzing patterns and behaviors of a system, as well as its overall performance, in order to identify potential issues that could cause system failure and address them properly. It works much like the process of weather forecasting.
Rejuvenation	This technique involves the frequent rebooting of a system, or parts of it, in order to clear any errors or bugs that may have accumulated in the system over a period of time.

Reactive fault tolerance: this type of techniques is used after a failure has already occurred in a system and tries to mitigate as much of the damage done as possible. The techniques being employed most frequently here are:

Table 4. 4 techniques of Reactive Fault Tolerance.

Table 4. 4 techniques of Reactive Fault Tolerance.

Type	Description
Redundancy	This technique involves adding extra hardware or software that are not necessary for a system to work properly, but can be utilized in case of a failure, in order to provide a fallback solution. You can think of it as having a spare tyre in the car’s trunk, in case of a tyre burst.
Replication	This method involves the duplication of important data or components across different parts of a system so that every time a failure occurs, a copy can be deployed without interrupting the system’s main functions.
Checkpoints and Rollbacks	This technique works much like an operating system’s restore point feature; it saves a state of the system at certain points (known as checkpoints) that works well and, when a failure happens, the system will roll back to its last saved point, thus restarting its function from that specific checkpoint.
Failover	This last technique is about having an entire backup system that will start working automatically once the main system faces a failure or crashes entirely. The process has to happen so quickly that the user won’t notice any difference in the way the system works. Think of it as a backup power generator that starts working automatically once the main power system of a building goes out.

A well-known example of fault tolerance challenges is the 2012 AWS (Amazon Web Services) outage. A simple configuration error in one of AWS's Elastic Load Balancers led to a series of failures, affecting many popular services, including Netflix and Reddit. This incident highlighted the complexity of achieving fault tolerance in large-scale distributed systems and the need for robust mechanisms to handle failures gracefully [11].

Consistency: consistency in a distributed system is about the capability of the entire system (and all of its components) to present the same data, at the same time. This is very important for the system, as it makes it look reliable and robust. Maintaining this level of consistency, though, has proved to be a challenge for all distributed systems.

First of all, the different types of hardware or software platforms a distributed system is comprised of is quite a challenge to address on its own. Different nodes may have different basic capabilities and features such as storage capacity, processing speed and data management protocols, something that could prove to be a problem when it comes to the uniformity of data updates [12].

Secondly, the way nodes are placed in a network geographically can play a significant role in the overall network's latency. This latency could lead to potential data dissemination and communication delays. Simply put, when data is updated in a node, there could be a significant delay before other nodes in the network are updated with the same data, therefore leading to conflicting information being presented to different users. This, in turn, undermines the network’s integrity immensely [13]. For example, Google Spanner, a globally distributed database, addresses latency issues by using synchronized clocks and advanced algorithms to ensure low-latency and high-consistency transactions. However, this solution comes with the complexity of maintaining precise time synchronization across data centers worldwide, showcasing the trade-offs involved in managing latency in distributed systems. Figure 8 depicts Google Spanner’s architecture.

Last but not least, in distributed systems, multiple processes usually occur across a number of nodes, all at the same time, and this brings forth a need for concurrency control. Concurrency control, however, has proved to be quite challenging. Being able to manage concurrent actions in a distributed system, without causing data conflicts or other discrepancies in the network, requires the use of highly sophisticated synchronization mechanisms. Implementing those mechanisms, however, could prove a challenging task as well, due to trade-offs needed between the three characteristics (consistency, availability, partition tolerance) featured in CAP (Brewer’s) theorem [14].

A few consistency models have been proposed so far, that could address the challenges mentioned previously. The most common ones are strict consistency and eventual consistency. Strict consistency may offer an especially high level of uniformity but this often affects the availability and performance of a system. Eventual consistency, on the other hand, offers performance boosts and greater flexibility but it also introduces temporary inaccuracies.

A real-world example of consistency issues is the "split-brain" problem in Apache Cassandra, a popular distributed NoSQL database. In a split-brain scenario, network partitions can lead to multiple nodes accepting writes independently, resulting in data inconsistencies. Resolving these inconsistencies requires complex conflict resolution mechanisms and can lead to potential data loss or corruption. Figure 9 shows a multiple data center cluster with 3 replica nodes [15].

Partition tolerance: partition tolerance has to do with a distributed system’s ability to keep operating even if partitions keep occurring in the network that result in nodes, or groups of nodes, being unable to communicate effectively with each other. Hardware malfunctions, network failures or other kind of disruptions are the causes of such partitions [16]. Therefore, being able to ensure that a network remains partition tolerant will greatly impact its reliability and availability.

The real challenge of maintaining high levels of partition tolerance lies in keeping a balance between other characteristics as well, such as consistency and availability. In a distributed system, however, only two of the three characteristics (consistency, availability, partition tolerance) can be achieved, as stated in the CAP theorem.

The CAP theorem, also known as Brewer's theorem, is a fundamental principle in the design of distributed systems [17]. Formulated by Eric Brewer in 2000, it states that it is impossible for a distributed data store to simultaneously provide all three of the following guarantees:

• Consistency (C): Every read from the system receives the most recent write or an error. In other words, all nodes see the same data at the same time.
• Availability (A): Every request (read or write) receives a non-error response, without the guarantee that it contains the most recent write.
• Partition Tolerance (P): The system continues to operate despite network partitions, where communication between some subsets of nodes is lost.

According to the CAP theorem, a distributed system can satisfy at most two of these three guarantees simultaneously:

• CA (Consistency and Availability): These systems reject partitions, meaning they require a consistent network. If a partition occurs, the system must either sacrifice consistency or availability.
• CP (Consistency and Partition Tolerance): These systems remain consistent in the presence of network partitions but may not be available to all nodes.
• AP (Availability and Partition Tolerance): These systems remain available even when network partitions occur but may not guarantee consistency.

Figure 10 summarizes the CAP theorem’s key points.

In practical terms, no distributed system can achieve perfect consistency, availability, and partition tolerance simultaneously [18]. Therefore, systems’ designers have to make decisions about the necessary trade-offs between these three characteristics and the expected network requirements needed and overall environment. For instance:

➢

Databases like Cassandra and DynamoDB: Prioritize availability and partition tolerance (AP), allowing them to remain available during network partitions but possibly returning stale data.

➢

Ø Systems like HBase and MongoDB: Often focus on consistency and partition tolerance (CP), ensuring data consistency across partitions at the cost of potential availability issues during network failures.

➢

Ø Relational databases with distributed architectures: Tend to focus on consistency and availability (CA), often at the expense of partition tolerance, requiring a reliable network to function correctly.

Security: security is one of the most vital challenges distributed systems have to address in the most effective way. When talking about security, making sure the users’ privacy and data’s integrity are both well protected is of the utmost importance. One way of ensuring those is the system’s authentication mechanisms [19]. These mechanisms need to be robust and constantly up-to-date, in order to be able to repel attempts for unauthorized access while making sure legitimate users can have access to the resources they need.

The second challenge that arises, regarding security, has to do with authorization and control access. The systems need to be able to determine what is the right access level for each individual user. That’s why different policies need to be defined and enforced, so that the system knows who has access to what and under what conditions. While authorization mechanisms are essential to be imposed in a system, implementing methods that ensure data’s confidentiality and integrity is equally important. This could be achieved, first and foremost, by establishing encryption techniques in the network, for both data at rest and in transit [20]. Furthermore, care should be taken into the implementation of detection and mitigation mechanisms for data tampering.

Lastly, one more challenging aspect of security is the implementation of non-repudiation and auditability mechanisms in a distributed system. Non-repudiation is needed so that the participants of a transaction cannot question or outright deny their participation in it, while auditability is responsible for tracking and examining a system’s activities. These two mechanisms are quite difficult to be implemented due to the need for total synchronization and secure logs across multiple locations.

A notable example is the 2017 Equifax data breach, where attackers exploited a vulnerability in a distributed web application framework to access sensitive data of over 140 million consumers. This incident underscores the importance of robust security measures, including regular patching, intrusion detection systems, and secure communication protocols in distributed systems [21].

4. The Intersection of Blockchain and Distributed Systems

5. Decentralized Decision-Making

6. Applications of Blockchain in Distributed Decision-Making

7. Big Data and Blockchain in Decision-Making

8. Challenges and Potential Issues in Integrating Big Data and Blockchain for Decentralized Decision-Making

Table 6. A summary of Challenges in integrating Big Data and Blockchain for decentralized decision-making.

9. Future Directions and Emerging Trends

10. Conclusions

References

1. Schinckus, C. The good, the bad and the ugly: An overview of the sustainability of blockchain technology. Energy Res. Soc. Sci. 2020, 69, 101614. [Google Scholar] [CrossRef]
2. Gad, A.G.; Mosa, D.T.; Abualigah, L.; Abohany, A.A. Emerging Trends in Blockchain Technology and Applications: A Review and Outlook. J. King Saud Univ. - Comput. Inf. Sci. 2022, 34, 6719–6742. [Google Scholar] [CrossRef]
3. Zheng, Z. , Xie, S., Dai, H., Chen, X., & Wang, H. (2017, June). An overview of blockchain technology: Architecture, consensus, and future trends. In 2017 IEEE international congress on big data (BigData congress) (pp. 557-564). Ieee.
4. Bhutta, M.N.M.; Khwaja, A.A.; Nadeem, A.; Ahmad, H.F.; Khan, M.K.; Hanif, M.A.; Song, H.; Alshamari, M.; Cao, Y. A Survey on Blockchain Technology: Evolution, Architecture and Security. IEEE Access 2021, 9, 61048–61073. [Google Scholar] [CrossRef]
5. Guo, H.; Yu, X. A survey on blockchain technology and its security. Blockchain: Res. Appl. 2022, 3. [Google Scholar] [CrossRef]
6. Andoni, M.; Robu, V.; Flynn, D.; Abram, S.; Geach, D.; Jenkins, D.; McCallum, P.; Peacock, A. Blockchain technology in the energy sector: A systematic review of challenges and opportunities. Renew. Sustain. Energy Rev. 2018, 100, 143–174. [Google Scholar] [CrossRef]
7. Malek, S. , Mikic-Rakic, M., & Medvidovic, N. (2005, November). A decentralized redeployment algorithm for improving the availability of distributed systems. In International Working Conference on Component Deployment (pp. 99-114). Berlin, Heidelberg: Springer Berlin Heidelberg.
8. Kuhlenkamp, J.; Klems, M.; Röss, O. Benchmarking scalability and elasticity of distributed database systems. Proc. Vldb Endow. 2014, 7, 1219–1230. [Google Scholar] [CrossRef]
9. Creel, K.A. Transparency in Complex Computational Systems. Philos. Sci. 2020, 87, 568–589. [Google Scholar] [CrossRef]
10. Ledmi, A. , Bendjenna, H., & Hemam, S. M. (2018, October). Fault tolerance in distributed systems: A survey. In 2018 3rd International Conference on Pattern Analysis and Intelligent Systems (PAIS) (pp. 1-5). IEEE.
11. Nanthini, N. , Vidhyasri, R., & Anand, V. V. (2024, April). Fault Tolerance Using AutoScaling in Amazon Web Services. In 2024 International Conference on Computing and Data Science (ICCDS) (pp. 1-6). IEEE.
12. Ahmed, J.; Karpenko, A.; Tarasyuk, O.; Gorbenko, A.; Sheikh-Akbari, A. Consistency issue and related trade-offs in distributed replicated systems and databases: a review. Radioelectron. Comput. Syst. 2023, 171–179. [Google Scholar] [CrossRef]
13. Hogade, N.S.; Pasricha, S.; Siegel, H.J. Energy and Network Aware Workload Management for Geographically Distributed Data Centers. IEEE Trans. Sustain. Comput. 2022, 7, 400–413. [Google Scholar] [CrossRef]
14. Lee, E. A. , Bateni, S., Lin, S., Lohstroh, M., & Menard, C. (2021). Quantifying and generalizing the CAP theorem. arXiv:2109.07771.
15. Skorykh, O. (2022). Migration of NoSQL (Cassandra) to relational database (Postgres) on high demanded distributed system (Doctoral dissertation, Hochschule für Angewandte Wissenschaften Hamburg).
16. Adoni, H.W.Y.; Nahhal, T.; Krichen, M.; Aghezzaf, B.; Elbyed, A. A survey of current challenges in partitioning and processing of graph-structured data in parallel and distributed systems. Distrib. Parallel Databases 2019, 38, 495–530. [Google Scholar] [CrossRef]
17. Brewer, E.A. Towards robust distributed systems (abstract). PODC00: ACM Symposium on Principles of Distributed Computing. LOCATION OF CONFERENCE, United StatesDATE OF CONFERENCE; p. 7.
18. Khoshaba, O. , Grechaninov, V., Molodetska, T., Lopushanskyi, A., & Zavertailo, K. (2022, November). Study of the Workspace Model in Distributed Structures Using CAP Theorem. In International scientific-practical conference (pp. 229-242). Cham: Springer Nature Switzerland.
19. Singh, S.; Hosen, A.S.M.S.; Yoon, B. Blockchain Security Attacks, Challenges, and Solutions for the Future Distributed IoT Network. IEEE Access 2021, 9, 13938–13959. [Google Scholar] [CrossRef]
20. Yao, Q.; Wang, Q.; Zhang, X.; Fei, J. Dynamic Access Control and Authorization System based on Zero-trust architecture. CCRIS 2020: 2020 International Conference on Control, Robotics and Intelligent System. LOCATION OF CONFERENCE, ChinaDATE OF CONFERENCE;
21. Daswani, N. , Elbayadi, M., Daswani, N., & Elbayadi, M. (2021). The Equifax Breach. Big Breaches: Cybersecurity Lessons for Everyone, 75-95.
22. Huang, H.; Lin, J.; Zheng, B.; Zheng, Z.; Bian, J. When Blockchain Meets Distributed File Systems: An Overview, Challenges, and Open Issues. IEEE Access 2020, 8, 50574–50586. [Google Scholar] [CrossRef]
23. B. Rawat, D. B. Rawat, D., Chaudhary, V., & Doku, R. (2020). Blockchain technology: Emerging applications and use cases for secure and trustworthy smart systems. Journal of Cybersecurity and Privacy, 1(1), 4-18.
24. Panwar, A.; Bhatnagar, V. Distributed Ledger Technology (DLT): The Beginning of a Technological Revolution for Blockchain. 2020 2nd International Conference on Data, Engineering and Applications (IDEA). LOCATION OF CONFERENCE, IndiaDATE OF CONFERENCE; pp. 1–5.
25. Zhou, S.; Li, K.; Xiao, L.; Cai, J.; Liang, W.; Castiglione, A. A Systematic Review of Consensus Mechanisms in Blockchain. Mathematics 2023, 11, 2248. [Google Scholar] [CrossRef]
26. Esmat, A.; de Vos, M.; Ghiassi-Farrokhfal, Y.; Palensky, P.; Epema, D. A novel decentralized platform for peer-to-peer energy trading market with blockchain technology. Appl. Energy 2020, 282, 116123. [Google Scholar] [CrossRef]
27. Cherupally, S.R.; Boga, S.; Podili, P.; Kataoka, K. Lightweight and Scalable DAG based distributed ledger for verifying IoT data integrity. 2021 International Conference on Information Networking (ICOIN). LOCATION OF CONFERENCE, South KoreaDATE OF CONFERENCE; pp. 267–272.
28. Zhao, W. From Traditional Fault Tolerance to Blockchain; Wiley: Hoboken, NJ, United States, 2021. [Google Scholar]
29. Tikhomirov, S. , Moreno-Sanchez, P., & Maffei, M. (2020, September). A quantitative analysis of security, anonymity and scalability for the lightning network. In 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) (pp. 387-396). IEEE.
30. Krichen, M.; Ammi, M.; Mihoub, A.; Almutiq, M. Blockchain for Modern Applications: A Survey. Sensors 2022, 22, 5274. [Google Scholar] [CrossRef]
31. Mueller-Bloch, C.; Andersen, J.V.; Spasovski, J.; Hahn, J. Understanding decentralization of decision-making power in proof-of-stake blockchains: an agent-based simulation approach. Eur. J. Inf. Syst. 2022, 1–20. [Google Scholar] [CrossRef]
32. Singh, A.; Kumar, G.; Saha, R.; Conti, M.; Alazab, M.; Thomas, R. A survey and taxonomy of consensus protocols for blockchains. J. Syst. Arch. 2022, 127. [Google Scholar] [CrossRef]
33. Cornito, C.M. Striking a Balance between Centralized and Decentralized Decision Making: A School-Based Management Practice for Optimum Performance. Int. J. Soc. Educ. Sci. 2021, 3, 656–669. [Google Scholar] [CrossRef]
34. Truong, N.; Lee, G.M.; Sun, K.; Guitton, F.; Guo, Y. A blockchain-based trust system for decentralised applications: When trustless needs trust. Futur. Gener. Comput. Syst. 2021, 124, 68–79. [Google Scholar] [CrossRef]
35. Dong, J.; Song, C.; Liu, S.; Yin, H.; Zheng, H.; Li, Y. Decentralized peer-to-peer energy trading strategy in energy blockchain environment: A game-theoretic approach. Appl. Energy 2022, 325. [Google Scholar] [CrossRef]
36. Zhang, J.; Wu, M. Cooperation Mechanism in Blockchain by Evolutionary Game Theory. Complexity 2021, 2021, 1–9. [Google Scholar] [CrossRef]
37. Kiayias, A. , & Zindros, D. (2020). Proof-of-work sidechains. In Financial Cryptography and Data Security: FC 2019 International Workshops, VOTING and WTSC, St. Kitts, St. Kitts and Nevis, –22, 2019, Revised Selected Papers 23 (pp. 21-34). Springer International Publishing. 18 February.
38. Saleh, F. Blockchain without Waste: Proof-of-Stake. Rev. Financial Stud. 2020, 34, 1156–1190. [Google Scholar] [CrossRef]
39. Saad, S.M.S.; Radzi, R.Z.R.M. Comparative Review of the Blockchain Consensus Algorithm Between Proof of Stake (POS) and Delegated Proof of Stake (DPOS). Int. J. Innov. Comput. 2020, 10. [Google Scholar] [CrossRef]
40. Huang, J. , He, D., Obaidat, M. S., Vijayakumar, P., Luo, M., & Choo, K. K. R. (2021). The application of the blockchain technology in voting systems: A review. ACM Computing Surveys (CSUR), 54(3), 1-28.
41. Khan, S.N.; Loukil, F.; Ghedira-Guegan, C.; Benkhelifa, E.; Bani-Hani, A. Blockchain smart contracts: Applications, challenges, and future trends. Peer-to-Peer Netw. Appl. 2021, 14, 2901–2925. [Google Scholar] [CrossRef]
42. El Faqir, Y., Arroyo, J., & Hassan, S. (2020, August). An overview of decentralized autonomous organizations on the blockchain. In Proceedings of the 16th international symposium on open collaboration (pp. 1-8). [CrossRef].
43. Taş, R.; Tanrıöver, Ö.Ö. A Systematic Review of Challenges and Opportunities of Blockchain for E-Voting. Symmetry 2020, 12, 1328. [Google Scholar] [CrossRef]
44. Jafar, U.; Ab Aziz, M.J.; Shukur, Z. Blockchain for Electronic Voting System—Review and Open Research Challenges. Sensors 2021, 21, 5874. [Google Scholar] [CrossRef]
45. Aufiero, S. , Ibba, G., Bartolucci, S., Destefanis, G., Neykova, R., & Ortu, M. (2024). Dapps ecosystems: Mapping the network structure of smart contract interactions. arXiv:2401.01991.
46. Vacca, A.; Di Sorbo, A.; Visaggio, C.A.; Canfora, G. A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges. J. Syst. Softw. 2020, 174, 110891. [Google Scholar] [CrossRef]
47. Hauck, R. Blockchain, Smart Contracts and Intellectual Property. Using distributed ledger technology to protect, license and enforce intellectual property rights. Leg. Issues Digit. Age 2021, 1, 17–41. [Google Scholar] [CrossRef]
48. Carvalho, A. Bringing transparency and trustworthiness to loot boxes with blockchain and smart contracts. Decis. Support Syst. 2021, 144, 113508. [Google Scholar] [CrossRef]
49. Khatoon, A. A Blockchain-Based Smart Contract System for Healthcare Management. Electronics 2020, 9, 94. [Google Scholar] [CrossRef]
50. Sookhak, M.; Jabbarpour, M.R.; Safa, N.S.; Yu, F.R. Blockchain and smart contract for access control in healthcare: A survey, issues and challenges, and open issues. J. Netw. Comput. Appl. 2020, 178, 102950. [Google Scholar] [CrossRef]
51. Appel, I.; Grennan, J. Control of Decentralized Autonomous Organizations. AEA Pap. Proc. 2023, 113, 182–185. [Google Scholar] [CrossRef]
52. Liu, L.; Zhou, S.; Huang, H.; Zheng, Z. From Technology to Society: An Overview of Blockchain-Based DAO. IEEE Open J. Comput. Soc. 2021, 2, 204–215. [Google Scholar] [CrossRef]
53. Bellavitis, C.; Fisch, C.; Momtaz, P.P. The rise of decentralized autonomous organizations (DAOs): a first empirical glimpse. Ventur. Cap. 2022, 25, 187–203. [Google Scholar] [CrossRef]
54. Liang, X., Lin, Y., Fu, H., Zhu, L., & Li, X. (2022). Rscfed: Random sampling consensus federated semi-supervised learning. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition (pp. 10154-10163).
55. Hou, D.; Zhang, J.; Man, K.L.; Ma, J.; Peng, Z. A Systematic Literature Review of Blockchain-based Federated Learning: Architectures, Applications and Issues. 2021 2nd Information Communication Technologies Conference (ICTC). LOCATION OF CONFERENCE, ChinaDATE OF CONFERENCE; pp. 302–307.
56. De Filippi, P. , & Lavayssière, X. (2020). Blockchain technology: Toward a decentralized governance of digital platforms?. The Great Awakening: New Modes of Life amidst Capitalist Ruins, 185-222.
57. Zwitter, A.; Hazenberg, J. Decentralized Network Governance: Blockchain Technology and the Future of Regulation. Front. Blockchain 2020, 3. [Google Scholar] [CrossRef]
58. Singh, S. , Wable, S., & Kharose, P. (2021). A review of e-Voting system based on blockchain technology. International Journal of New Practices in Management and Engineering, 10(04), 09-13.
59. Patel, R.; Migliavacca, M.; Oriani, M.E. Blockchain in banking and finance: A bibliometric review. Res. Int. Bus. Finance 2022, 62. [Google Scholar] [CrossRef]
60. Ullah, N.; Al-Rahmi, W.M.; Alfarraj, O.; Alalwan, N.; Alzahrani, A.I.; Ramayah, T.; Kumar, V. Hybridizing cost saving with trust for blockchain technology adoption by financial institutions. Telematics Informatics Rep. 2022, 6. [Google Scholar] [CrossRef]
61. Tsao, Y.-C.; Vu, T.-L. A decentralized microgrid considering blockchain adoption and credit risk. J. Oper. Res. Soc. 2021, 73, 2116–2128. [Google Scholar] [CrossRef]
62. Dashkevich, N.; Counsell, S.; Destefanis, G. Blockchain Application for Central Banks: A Systematic Mapping Study. IEEE Access 2020, 8, 139918–139952. [Google Scholar] [CrossRef]
63. Queiroz, M.M.; Telles, R.; Bonilla, S.H. Blockchain and supply chain management integration: a systematic review of the literature. Supply Chain Manag. Int. J. 2019, 25, 241–254. [Google Scholar] [CrossRef]
64. Moosavi, J.; Naeni, L.M.; Fathollahi-Fard, A.M.; Fiore, U. Blockchain in supply chain management: A review, bibliometric, and network analysis. Environ. Sci. Pollut. Res. 2021, 1–15. [Google Scholar] [CrossRef]
65. Sunny, J.; Undralla, N.; Pillai, V.M. Supply chain transparency through blockchain-based traceability: An overview with demonstration. Comput. Ind. Eng. 2020, 150, 106895. [Google Scholar] [CrossRef]
66. Bader, L.; Pennekamp, J.; Matzutt, R.; Hedderich, D.; Kowalski, M.; Lücken, V.; Wehrle, K. Blockchain-based privacy preservation for supply chains supporting lightweight multi-hop information accountability. Inf. Process. Manag. 2021, 58. [Google Scholar] [CrossRef]
67. Haleem, A.; Javaid, M.; Singh, R.P.; Suman, R.; Rab, S. Blockchain technology applications in healthcare: An overview. Int. J. Intell. Networks 2021, 2, 130–139. [Google Scholar] [CrossRef]
68. Attaran, M. Blockchain technology in healthcare: Challenges and opportunities. Int. J. Heal. Manag. 2020, 15, 70–83. [Google Scholar] [CrossRef]
69. Mann, S.P.; Savulescu, J.; Ravaud, P.; Benchoufi, M. Blockchain, consent and prosent for medical research. J. Med Ethic- 2020, 47, 244–250. [Google Scholar] [CrossRef]
70. Odeh, A.; Keshta, I.; Abu Al-Haija, Q. Analysis of Blockchain in the Healthcare Sector: Application and Issues. Symmetry 2022, 14, 1760. [Google Scholar] [CrossRef]
71. Datta, A. (2021). Blockchain enabled digital government and public sector services: A survey. Blockchain and the Public Sector: Theories, Reforms, and Case Studies, 175-195.
72. Cagigas, D.; Clifton, J.; Diaz-Fuentes, D.; Fernandez-Gutierrez, M. Blockchain for Public Services: A Systematic Literature Review. IEEE Access 2021, 9, 13904–13921. [Google Scholar] [CrossRef]
73. Soner, S.; Litoriya, R.; Pandey, P. Exploring Blockchain and Smart Contract Technology for Reliable and Secure Land Registration and Record Management. Wirel. Pers. Commun. 2021, 121, 2495–2509. [Google Scholar] [CrossRef]
74. Wang, Q.; Su, M. Integrating blockchain technology into the energy sector — from theory of blockchain to research and application of energy blockchain. Comput. Sci. Rev. 2020, 37, 100275. [Google Scholar] [CrossRef]
75. Kumar, N.M.; Chand, A.A.; Malvoni, M.; Prasad, K.A.; Mamun, K.A.; Islam, F.; Chopra, S.S. Distributed energy resources and the application of AI, IoT, and blockchain in smart grids. Energies 2020, 13, 5739. [Google Scholar] [CrossRef]
76. Mengidis, N. , Tsikrika, T., Vrochidis, S., & Kompatsiaris, I. (2021). Cybersecurity in next generation energy grids: Challenges and opportunities for blockchain and Ai technologies. Digital Transformation, Cyber Security and Resilience of Modern Societies, 299-314.
77. Rane, S. B. , & Narvel, Y. A. M. (2022). Data-driven decision making with Blockchain-IoT integrated architecture: a project resource management agility perspective of industry 4.0. International Journal of System Assurance Engineering and Management, 13(2), 1005-1023.
78. Deepa, N.; Pham, Q.-V.; Nguyen, D.C.; Bhattacharya, S.; Prabadevi, B.; Gadekallu, T.R.; Maddikunta, P.K.R.; Fang, F.; Pathirana, P.N. A survey on blockchain for big data: Approaches, opportunities, and future directions. Futur. Gener. Comput. Syst. 2022, 131, 209–226. [Google Scholar] [CrossRef]
79. Theodorakopoulos, L.; Theodoropoulou, A.; Stamatiou, Y. A State-of-the-Art Review in Big Data Management Engineering: Real-Life Case Studies, Challenges, and Future Research Directions. Eng 2024, 5, 1266–1297. [Google Scholar] [CrossRef]
80. Giannaros, A.; Karras, A.; Theodorakopoulos, L.; Karras, C.; Kranias, P.; Schizas, N.; Kalogeratos, G.; Tsolis, D. Autonomous Vehicles: Sophisticated Attacks, Safety Issues, Challenges, Open Topics, Blockchain, and Future Directions. J. Cybersecur. Priv. 2023, 3, 493–543. [Google Scholar] [CrossRef]
81. Rahim, R. , Patan, R., Manikandan, R., & Kumar, S. R. (2020). Introduction to blockchain and big data. In Blockchain, Big Data and Machine Learning (pp. 1-23). CRC Press.
82. Sundarakani, B.; Ajaykumar, A.; Gunasekaran, A. Big data driven supply chain design and applications for blockchain: An action research using case study approach. Omega 2021, 102, 102452. [Google Scholar] [CrossRef]
83. Bhuiyan, M. Z. A., Zaman, A., Wang, T., Wang, G., Tao, H., & Hassan, M. M. (2018, May). Blockchain and big data to transform the healthcare. In Proceedings of the international conference on data processing and applications (pp. 62-68).
84. Li, J.; Herdem, M.S.; Nathwani, J.; Wen, J.Z. Methods and applications for Artificial Intelligence, Big Data, Internet of Things, and Blockchain in smart energy management. Energy AI 2023, 11. [Google Scholar] [CrossRef]
85. Antonopoulou, H.; Theodorakopoulos, L.; Halkiopoulos, C.; Mamalougkou, V. Utilizing Machine Learning to Reassess the Predictability of Bank Stocks. Emerg. Sci. J. 2023, 7, 724–732. [Google Scholar] [CrossRef]
86. Kuo, T. T. , & Ohno-Machado, L. (2018). Modelchain: Decentralized privacy-preserving healthcare predictive modeling framework on private blockchain networks. arXiv:1802.01746.
87. Rubio, M. A., Tarazona, G. M., & Contreras, L. (2018). Big data and blockchain basis for operating a new archetype of supply chain. In Data Mining and Big Data: Third International Conference, DMBD 2018, Shanghai, China, June 17–22, 2018, Proceedings 3 (pp. 659-669). Springer International Publishing.
88. Paramesha, M. , Rane, N., & Rane, J. (2024). Big data analytics, artificial intelligence, machine learning, internet of things, and blockchain for enhanced business intelligence. Available at SSRN 4855856.
89. Karafiloski, E. , & Mishev, A. (2017, July). Blockchain solutions for big data challenges: A literature review. In IEEE EUROCON 2017-17th International Conference on Smart Technologies (pp. 763-768). IEEE.
90. Guo, L.; Xie, H.; Li, Y. Data encryption based blockchain and privacy preserving mechanisms towards big data. J. Vis. Commun. Image Represent. 2019, 70, 102741. [Google Scholar] [CrossRef]
91. Karras, A.; Giannaros, A.; Theodorakopoulos, L.; Krimpas, G.A.; Kalogeratos, G.; Karras, C.; Sioutas, S. FLIBD: A Federated Learning-Based IoT Big Data Management Approach for Privacy-Preserving over Apache Spark with FATE. Electronics 2023, 12, 4633. [Google Scholar] [CrossRef]
92. Wibowo, S. , & Sandikapura, T. (2019, November). Improving data security, interoperability, and veracity using blockchain for one data governance, case study of local tax big data. In 2019 International Conference on ICT for Smart Society (ICISS) (Vol. 7, pp. 1-6). IEEE.
93. Ahsan, A. , & Shabbir, A. (2021). Blockchain and Big Data: Exploring Convergence for Privacy, Security and Accountability. Sage Science Review of Educational Technology, 4(2), 53-68.
94. Alza Jr, G. (2021). Blockchain & CCPA. Santa Clara High Tech. LJ, 37, 231.
95. Xu, C.; Wang, K.; Li, P.; Guo, S.; Luo, J.; Ye, B.; Guo, M. Making Big Data Open in Edges: A Resource-Efficient Blockchain-Based Approach. IEEE Trans. Parallel Distrib. Syst. 2018, 30, 870–882. [Google Scholar] [CrossRef]
96. Fahlevi, M.; Moeljadi; Aisjah, S.; Djazuli, A. Corporate Governance in the Digital Age: A Comprehensive Review of Blockchain, AI, and Big Data Impacts, Opportunities, and Challenges. E3S Web Conf. 2023, 448. [Google Scholar] [CrossRef]