Content uploaded by Madhusanka Liyanage
Author content
All content in this area was uploaded by Madhusanka Liyanage on Sep 24, 2023
Content may be subject to copyright.
Breaking Chains, Empowering IoT: A Comparative
Study of Holochain and Blockchain
Pramitha Fernando∗, An Braeken†Madusanka Liyanage‡
∗† Industrial Engineering INDI, Vrije Universiteit Brussel VUB, Brussels, Belgium
‡School of Computer Science, University College Dublin, Ireland
Email: ∗pramitha@ieee.org, †an.braeken@vub.be, ‡madhusanka@ucd.ie
Abstract—The Internet of Things (IoT) is rapidly spreading
across a wide range of applications because it is a critical
technology for overcoming interoperability and heterogeneity
barriers in many applications. IoT is increasingly being deployed
in a distributed setting because of the vast number of devices and
the physical dispersal of many use cases. Because IoT devices
are often resource restricted, this scattered implementation style
exposes devices to unprecedented privacy and security risks. Dis-
tributed Ledger Technologies (DLTs), such as blockchain, appear
to be a perfect solution to integrate with IoT systems to overcome
these challenges thanks to its key pillars: decentralisation, trans-
parency and immutability. The use of blockchain in IoT has been
widely examined, and the findings demonstrate how blockchain
can be a crucial enabler for IoT. However, blockchain consensus
mechanisms are often very energy-intensive, whereas IoT de-
vices are resource-constrained with limited computational power,
storage and energy. Therefore, as the literature emphasises, new
consensus algorithms could solve most of these issues associated
with blockchain technology. Holochain is an emerging DLT that
promises to provide blockchain’s key benefits and eliminate
problems that come with it, such as consensus algorithms and
the requirement to maintain a globally synchronised ledger. This
paper presents a comparison between blockchain and holochain
in the context of IoT considering scalability, availability, security
and resource requirements.
Index Terms—Distributed Ledger Technology, DLT,
Blockchain, Holochain, IoT, Consensus, Scalability
I. INTRODUCTION
The Internet of Things (IoT) is a rapidly expanding network
of lightweight devices that use embedded sensing, processing,
and communication technologies to collect and communicate
data over the Internet [1]. IoT is spreading in all aspects of our
lives as it is a vital technology to overcome interoperability
and heterogeneity resistances in various applications [2]. Due
to the large number of devices and its physical spread of many
use cases, IoT is increasingly implemented in a distributed
setting. This distributed nature of implementation is exposed to
unprecedented privacy and security threats as IoT devices are
generally resource constrained. Distributed Ledger Technolo-
gies (DLT), such as blockchain, offer several advantages, such
as decentralization, transparency, and immutability, which are
helpful in many applications. Because blockchain is designed
to support distributed networks, it is an ideal candidate for
solving these issues in the IoT network, thanks to its inherent
transparency and fairness. In the literature, several works
discuss the critical role blockchain can play in future IoT
networks [3]. However, IoT devices are resource-constrained,
with limited memory, low computational power and energy
supply. The main issue with current blockchain implemen-
tations is that they use very computationally intensive con-
sensus algorithms, which are optional for certain non-critical
applications, such as resource-constrained IoT devices willing
to trade some level of data integrity for computation and
energy savings [2]. Holochain [4] is an emerging technology
that promises to provide an open-source distributed network
infrastructure to facilitate a secure network without excessive
resource requirements. A holochain network is powered by
Distributed Hash Table (DHT) for data propagation and a hash
chain for preserving data integrity [1].
This article investigates the challenges of implementing
blockchain in IoT, such as resource requirements, overheads,
and scalability issues. In this context, we first consider some
widely used consensus algorithms. Second, we look at how an
emerging DLT known as holochain can assist in circumventing
some of these limitations. We present a detailed description
of the various processes involved with blockchain that cause
its limits and how the holochain design principles might
solve them. The remainder of this paper is organized as
follows: Section II describes the background for this research.
In Section III, we present comparison criteria for two DLT
technologies. Section IV contains the performance evaluation
and discussion of the results. In section V, we conclude the
paper.
II. BACKGROU ND
DLT is a digital system that allows users to record asset-
related transactions. A DLT, unlike traditional databases, does
not have a central location to store information. This decentral-
ized storage improves participant security, transparency, and
trust. DLT originates from peer-to-peer (P2P) networks. There
are three main types of DLTs. Permissioned networks are pri-
vate networks with a closed ecosystem. This prevents exposing
private and sensitive data to unintended parties. Permissionless
networks are public networks; users do not need permission to
access or participate. The last type, Hybrid networks, combine
features from permissioned and permissionless networks to
offer a network that benefits from both of them.
A. Blockchain
Blockchain is a decentralized digital database (ledger)
that stores user transactions. The connected community (i.e.,
nodes) verifies the authenticity of such transactions before
adding them to the ledger. Thus, blockchain employs a dis-
tributed trust model by eliminating the third-party centralized
trust model. Each block in a blockchain contains an array
of transaction records and cryptographic chain links [5]. The
primary benefit of blockchain technology is its decentralized
design. It is made up of a large number of nodes that work
together to form a P2P network. No centralised management
exists, and each node is accountable for the blockchain’s
decisions. Because of its decentralized nature, this system
is considered unhackable. Blockchain technology is built on
three pillars: Decentralization, Transparency and Immutability.
1) Consensus Mechanism: In blockchain systems, a con-
sensus mechanism is a fault-tolerant mechanism used to
achieve the necessary agreement between peer nodes on newly
created blocks. The consensus mechanism aids in determining
which node adds the next block to the chain. Consensus
algorithms are classified into two types: proof-based and vote-
based. Proof-based algorithms include Proof of Work (PoW)
[5], Proof of Stake (PoS), Proof of Burn (PoB), Proof of
Capacity (PoC), and Proof of Elapsed Time (PoET), whereas
vote-based algorithms include Practical Byzantine Fault Toler-
ance (PBFT) [6], Istanbul Byzantine Fault Tolerance (IBFT),
and Raft [7]. Furthermore, customized consensus mechanisms
can be designed based on the needs of the blockchain applica-
tion [8] [9], [10]. The consensus mechanism directly impacts a
blockchain network’s security bound, defined as the maximum
number of faulty nodes tolerated by the network. For example,
the PoW security bound is 2f+ 1 (where fis the number of
faulty nodes) [11]. As a result, if a single entity controls more
than 50% of the network’s resources, a blockchain network
using PoW as its consensus mechanism will be compromised.
However, compromising the network is nearly impossible due
to the distributed architecture and the computationally heavy
mathematical puzzles involved with PoW, which is extensive
and unreachable to realize with the existing computing power.
2) Smart Contracts: A Smart contract is a self-executing
contract that contains the terms of the agreement among
involved parties. In a blockchain network, a smart contract
is a piece of code deployed in the blockchain nodes. When
the terms of the agreement are met, any node in the blockchain
network should execute the code irrespective of the underlying
type of operating system or hardware. Blockchain-based smart
contracts inherit some interesting properties of blockchain,
such as immutability and decentralization.
B. Holochain
Holochain is a P2P post-blockchain ledger system and
decentralized application development framework that enables
developers to build serverless applications with high levels of
security, reliability, performance, and efficiency [4]. The fact
that each peer in the Holochain network has its own ledger
(i.e., source chain) allows it to function independently while
also interacting with all other devices on the network. Both
cryptography and peer accountability contribute to the applica-
tion’s security. The application in Holochain is designed from
the user’s point of view. This is referred to as “agent-centric”
computing. Each network user executes their own copy of
the back-end code via the Holochain runtime. Each user is
in charge of their identity and stores their own public and
private data. There is an encrypted P2P network for each app
that allows users to find and communicate with one another
[4].
1) Source Chain: The source chain is a chronological
journal of every action performed by the user in their copy
of the Holochain app (hApp). The source chain lives on the
user’s device, and every entry must be signed with the user’s
private key. The user’s actions are stored as records in the
source chain. A record consists of an action and an entry. An
action can be defined as the act of changing the application
state, for example, creating a link or deleting an entry. An
entry usually contains binary data. The source chain begins
with four essential system records [4]: DNA hash, membrane
proof, agent ID, and init complete action.
2) Distributed Hash Table (DHT): In a DHT, agents (i.e.,
nodes) share records of their actions, including any data meant
to be shared with other agents in the network. This database
ensures data redundancy and availability. In the DHT, each
agent gets a unique DHT address based on their public key,
and each piece of data also gets its own DHT address based
on its hash. The source lives in an agent’s device. To avoid
data becoming unavailable when the agent goes offline and
to ensure data integrity, agents in the holochain network share
source chain actions and public entries with a random subset of
network peers. These peers witness, validate and hold copies
of shared data. When an agent commits a record containing
private data, the entry data remains in the agent’s source chain,
but the action of the record is shared in the DHT.
3) DNA: DNA is a collection of executable code that
provides functionality for a specific part of an hApp [12]. It
can also be considered a micro-service that provides an access
and integrity layer for personal and shared data. DNA acts as
the “rules of the game” against which peers can validate and
enforce data created by agents [4].
4) Zomes: Zomes are the DNA’s executable code modules.
For instance, a larger app might include chat or profile
modules. The zomes describe the core logic in a DNA [4].
5) Client: A client is a UI or utility script on the partic-
ipant’s device. A client communicates with their holochain
conductor and its running hApps via WebSocket Remote
Procedure Calls (RPCs) [4].
6) Conductor: The conductor is the runtime that sandboxes
and executes the hApp. It is also responsible for signing,
managing data flow and storage, and handling connections.
When the conductor receives a function call, it forwards it to
the appropriate function in the destination hApp [4] [12].
7) Validation Rules: Validation rules for DHT operations
(for shared data) can be specified in hApp DNAs. This enables
agents to verify the integrity of the data they receive. When
an agent commits a record, its conductor ensures that the data
generated by the agent complies with the validation rules. This
prevents the agent from publishing any invalid data that would
Transaction request is
created by a node
Transaction request is
broadcasted to all the
nodes in the network
Nodes validate transaction
request through
consensus mechanism
Verified transactions
are combined to create
new blocks
New blocks are published
in the existing chain
Transaction request is
created and signed by
an agent
Transaction request is
broadcasted to some
selected peer agents
Request is validated via
validation rules presented
in the holochain app
Validated transactions are
accepted by peer agents and
they sign the transaction
Public data is shared
via DHT
a) Transaction flow of blockchain network
b) Transaction flow of holochain network
Fig. 1: Transaction Validation Process
portray it as a bad actor. When an authority (i.e., another agent)
gets an entry for validation, since each node in the network
has a copy of the validation rules, they can quickly validate
it. When the validation rules fail and the data is deemed
invalid, authorities issue and sign a warrant designating the
author as a bad actor. These malicious agents are added to
validators’ permanent block lists, and their data are removed
from DHT shards. When someone requests the data at the
entry’s address, validators instead return the warrant. Everyone
eventually learns about the network’s bad actors and ignores
the rogue agent anytime it attempts to communicate with them
[4].
C. Different Architectures
Distributed architectures can solve the limitations of decen-
tralised architectures, such as central failure points. Blockchain
attempts to solve these problems by creating a distributed
network where each node (i.e., user) holds identical copies
of a public, global data set. In a blockchain network, each
participant contributes to maintaining the availability and
integrity of data. Although this strategy avoids centralised
weaknesses, it is expensive to replicate, check, and achieve a
consensus on the data set’s contents. As a result, participants
are split into two groups: full nodes, who have the necessary
computational resources, reputation, or capital to participate,
and light clients, who must request the service of full nodes,
often in exchange for payment. Holochain takes a different
approach to the problem. It allows each participant in the
system to maintain its state, make that state available to others,
and access the states of others rather than assuming that a
uniform, consistent system state is always required. Holochain
only makes an effort to achieve consensus when absolutely
essential [4]. Fig. 1 illustrates the operation principles of two
DLTs.
III. COMPARISON CRITE RI A OF D LT TECHNOLOGIES
Table I gives an overview of different types of DLTs
available and some of their characteristics. We focus only on
blockchain and holochain due to their popularity and potential.
Scalability, resource consumption, security, and resilience are
some of the most critical characteristics of IoT systems.
Furthermore, when running a wireless network, security and
resilience are also essential to maintain a reliable system due to
the unstable nature of the links. This section presents a broader
explanation of the pros and cons of different technologies, with
a focus on the comparison between holochain and consensus
algorithms for blockchain.
A. Security
Consensus mechanism (Section II-A1) governs the security
of a blockchain network. In PoW, the attacker needs to
have more than 50% of the network’s computational power
to compromise the network, which is practically impossible.
However, this level of protection comes with a cost of compu-
tational power for the non-malicious nodes in the network. In
contrast, voting-based consensus algorithms define the number
of faulty nodes as either inactive or malicious, sending misin-
formation to endanger the entire network. Under the premise
of perfect communication, generic PBFT allows for 1/3of
the total nodes to be either malicious or faulty. Raft operates
reasonably well with 50% fault tolerance but cannot tolerate
malicious nodes [11]. Holochain has its own mechanism for
dealing with malicious nodes in the network. Participants can
effectively evict malicious nodes using the validation rules
described in Section II-B7. Validation rules affect the security
of a holochain network. Therefore, well-designed validation
rules can protect everyone, whereas defective validation rules
leave them vulnerable [4]. In both DLTs, digital signatures are
used to ensure the integrity of the data.
TABLE I: Comaprison with Other DLTs
Blockchain Holochain Hashgraph [13] DAG [13]
Mining Nodes can mint new to-
kens via consensus mech-
anism
Consensus through Virtual
Voting
Previous transaction val-
idates the succeeding to
achieve consensus
No validation or only in-
terested nodes
Transactions per Second
(TPS)
Usually higher with
vote-based consensus and
lower with proof-based
consensus
High TPS because of low
computational consensus
Unique data structure via
directed acyclic graphs
ensure high TPS
Very high TPS due to the
absence of a global con-
sensus
Data Structure Blocks chained in
chronological order.
These blocks are validated
by nodes
Source chain for local data
and DHT for public data
Virtual voting and Gossip
to ensure that transactions
are validated by the major-
ity
Follow the directed
acyclic graph mechanism
where each transaction is
independent
Validation of Transactions Nodes validates
transitions. Nodes have
the power to postpone or
cancel transactions
Validation rules can be de-
fined to validate public
data
Validation of transactions
is as per consensus
The validity of the current
transaction depends on its
ability to validate two pre-
vious transactions
Example Networks Bitcoin [5] and Ethereum Holo Swirlds and NOIA NXT, Tangle and Byteball
B. Scalability
The ability of the network to handle the increase in the
number of nodes is referred to as scalability. PoW has ex-
cellent scalability because it has only two broadcast mes-
sages at different phases. Voting-based mechanisms, on the
other hand, rely heavily on inter-node communication. As
a result, PBFT [6] and Raft [7] are both limited in their
scalability. The absence of attaining global consensus in the
holochain-based approach mitigates the scalability concerns
associated with most blockchain consensus techniques. Inter-
node communication occurs in the holochain network when
data is shared with backup nodes, which is less sophisticated
than blockchain-based approaches. As a result, holochain has
excellent scalability [1].
C. Resource Utilization
Because most IoT devices have limited resources, resource
utilization is crucial. In a DLT-based IoT system, several types
of resources need to be considered: spectrum requirement,
storage requirement, computational power requirement and
energy usage. Fig. 4 depicts the spectrum requirements of
blockchain consensus algorithms and holochain. Spectrum
requirements refer to the number of channels needed for com-
munication. It is evident that by design, vote-based consensus
algorithms require the highest number of channels to reach
a consensus, PBFT being the highest. Both PBFT and Raft
have an O(N)requirement. On the other hand, PoW has a
constant spectrum requirement in the simplest topology. In
terms of spectrum requirements, holochain has an O(log(N))
requirement because of its DHT operations. In a blockchain
(independent of the consensus mechanism), all the local chains
must be identical. But in holochain, only the nodes which
are supposed to keep backups for another node maintain
the duplicated data. As illustrated in Fig. 2, even with 50
nodes, by the end of the 100th block, holochain can reduce
the total storage consumption of the network by 80%. This
will allow IoT devices to store more data while conserving
energy. Maintaining a globally synchronised ledger is costly
in terms of both storage and communications. In terms of
computational power requirements, PoW is the most energy-
intensive consensus algorithm we have discussed here.
D. Transaction Throughput
Transaction throughput denotes the number of transactions
per second (TPS) in the system, and it depends on the
underlying consensus mechanism. A PoW-based blockchain
network has a low TPS because of its computationally difficult
hash puzzles. Voting-based systems are more alive and can
reach a consensus quickly delivering a higher throughput.
The TPS, for instance, is typically capped at 7 for Bitcoin
and 20–30 for Ethereum [11]. Voting-based mechanisms can
achieve a TPS in the region of 100 to 1000 [11]. Note
that while achieving consensus necessitates numerous message
exchanges, communication complexity can be a constraint for
transaction throughput. As a result, transaction throughput is
also dependent on the number of nodes in the network. The
fascinating design principles of holochain hugely benefit the
transaction throughput of the network. Because there is no
requirement to achieve a consensus, transaction throughput
is determined by the physical restrictions of maintaining a
wireless network rather than the number of nodes in the
network. Therefore, holochain has a very high transaction
throughput.
E. Availability and Resilience
High availability is a feature of blockchain and holochain
compared to the client-server architecture. In a blockchain,
data is immediately available to every node, and in a
holochain, only a few responsible nodes keep backups of
others. In holochain, the data is divided into smaller shards
and distributed among nodes rather than stored entirely on
one node. The resilience of a network describes its ability to
recover quickly from breakdowns. Because of the nature of
wireless communications, this is a vital aspect. When a failed
link partitions the network, the two sub-networks can operate
with the remaining nodes. The issue arises when the broken
connection is restored, and the two partitions merge again. The
two networks now have distinct states due to their separation.
This phenomenon is known as forking, and aside from broken
TABLE II: Theoretical Performance Comparison Between Holochain and Different Blockchain Consensus Algorithms
Technology Network Type Transaction
Throughput
Scalability Storage
Growth
Communication
Complexity
Spectrum
Requirement
PBFT [6] Private/Hybrid High Low N2N2+N2N+ 1
Raft [7] Private Very High Medium N2N N + 1
PoW [5] Public Low High N2N2
Holochain Hybrid High High r N +log(N)log(N)+1
Note: N= total nodes, r= number of backup nodes in holochain
links, information propagation latency is a common cause of
forking. The longest chain is typically accepted as the proper
one, and the other blocks are abandoned. As a result, some
data will be lost and deemed invalid. Since there is no need
for a synchronised ledger across all nodes, a holochain offers
high resilience. When network partitioning occurs due to a
faulty link, sub-networks can continue to operate normally.
Some DHT neighbours, however, are inaccessible. Although
no data is lost, not all of it is available to either party.
Since fewer neighbours keep backups for a node, the agents
are now attempting to increase resilience by increasing its
neighbourhood (making new nodes liable for backups). When
the network re-merges, the new data is synced throughout the
DHT. At this stage, everyone has the choice of shrinking their
neighbourhood and pruning redundant data [4].
F. Implementaion Issues
One of the fundamental limitations of holochain technology
is the scarcity of peer-reviewed papers on the subject, making
it difficult to draw precise conclusions about its features.
Furthermore, the holochain framework is not well documented,
and the majority of things are still developing and being built.
However, it should be noted that this open-source project is
always evolving. When it comes to comparing DLTs, there
are no really good frameworks to test for scalability and
resource requirements. Therefore, the best way to compare
these different technologies is through numerical analyses and
creating simulations for selected small parts of the technology,
which we have followed in this project.
IV. PER FO RM AN CE COMPARISON
This section presents the numerical analyses conducted to
compare the performance of the two DTL architectures. Table
II summarises the different features of the technologies we
investigate in this section. Values for the consensus algorithms
are taken from [11].
A. Storage Requirement
In a blockchain, all the local ledgers are kept synchronised.
When a new block is added, all nodes update their ledger. Let
the size of a data block be band the total number of nodes in
the network be N. Therefore, the total network storage grows
by b∗Nwhen a new block is added. In a holochain network,
only a few interested nodes keep backups for a particular
node’s public data. When rkeeps backup data for a node, the
total network storage growth is only r∗b. The total storage
growth in the network is represented in Fig. 2 considering a
network with 50 nodes and assuming that the average block
size is 0.1 MB (in Ethereum, average block size is ≈0.1MB).
10 20 30 40 50 60 70 80 90 100
Number of New Blocks
101
102
103
Increase in Total Storage (MB)
Blockchain
Holochain, r=5
Holochain, r=10
Fig. 2: Storage Requirements
B. Communication Complexity
The communication complexity refers to the number of
communications between transmitter and receiver nodes. Fig.
3 illustrates the communication complexity of different con-
sensus mechanisms presented in Table II. The PBFT requires
2N2+Ncommunications making it the highest in Fig. 3.
In each stage of PBFT, broadcast communication is needed
to exchange information among nodes. Therefore PBFT is
more suited for private blockchain networks with a limited
number of nodes. In Raft, 2Ncomes from communication
between the head and follower nodes (uplink) and again from
the follower nodes and head (uplink). In PoW, 2Ncomes
from broadcasting a client request to all other nodes and
broadcasting the winner miner’s hash results to all other nodes.
Due to the absence of a consensus algorithm in holochain,
the spectrum complexity comes from DHT operations. This
involved finding the corresponding node in the DHT, which
has a complexity of log(N), and that node sending backups
to its q(<=N) neighbours. For comparison, let’s consider
q=N. Therefore, it is clear that holochain and PoW have
the lowest and second lowest communication complexity,
respectively.
C. Spectrum Requirement
The spectrum requirement of a wireless blockchain network
refers to the needed spectrum resource for communication.
While communication complexity comprises the number of
receiver processes, spectrum requirement is the number of
transmitter processes [11]. Fig. 4 represents the spectrum
requirement for different consensus mechanisms. Note that
here we consider the simplest case in which one’s transmission
0 100 200 300 400 500 600 700 800 900 1000
Number of Nodes (N)
101
102
103
104
105
106
107
Communication Complexity
PBFT
PoW
Raft
Holochain
Fig. 3: Communication Complexity
covers all nodes, and the spectrum requirement can vary with
the network topology. Under these conditions, the spectrum
requirements for PBFT, RAFT, PoW are 2N+ 1,N+ 1, and
2, respectively. In PBFT, 2N+ 1 consists of 2Nspectrum
resources for the communication among nodes in prepare and
commit stages and one resource for the pre-prepare stage in
which the leader node broadcasts a message to the rest of
the nodes. For Raft, one spectrum resource is required for
the downlink communication from head to followers, and N
resources are required for the uplink communication from each
follower node to the head. The spectrum requirement for the
PoW is constant as it does not depend on the number of nodes
in the network. This is because PoW only consists of two
broadcast messages. The spectrum requirement of holochain
comes from finding the corresponding nodes in the DHT and
that node sharing data with its neighbours in the address space.
0 100 200 300 400 500 600 700 800 900 1000
Number of Nodes (N)
100
101
102
103
104
Spectrum Requirement
PBFT
PoW
Raft
Holochain
Fig. 4: Spectrum Requirements
V. CONCLUSION
This paper discusses how features of two distributed ledger
technologies, namely blockchain and holochain, affect an IoT
network’s performance. In the IoT context, blockchain has
some limitations due to its scalability issues and high resource
consumption in terms of computational, communication and
storage. The requirement of maintaining a globally synchro-
nised ledger and achieving a global consensus to add new data
to the ledger makes it very hard for attackers to tamper with the
blockchain. However, this is not crucial for every application,
as in some applications, to use the device resources more
efficiently, the integrity of the data can be sacrificed. Holochain
is an emerging distributed ledger technology that promises to
provide the advantages of blockchain’s distributed nature while
eliminating scalability issues with blockchains. In this paper,
we analyzed common blockchain consensus algorithms against
holochain. Based on the results, we can conclude that the
holochain-based approach has good scalability and uses fewer
resources. It is important to note that holochain is still a young
technology and has not been well studied in the context of both
research and business applications. Although, in theory, it is
more promising than blockchain, there is still a lot to learn
about it. Over time, through thorough research, holochain’s
weaknesses can be found and strengthened.
ACK NOW LE DG ME NT
This research has been partly supported by the Science
Foundation Ireland under CONNECT phase 2 (Grant no.
13/RC/2077 P2) projects.
REFERENCES
[1] S. Zaman, M. R. A. Khandaker, R. T. Khan, F. Tariq, and K.-K. Wong,
“Thinking Out of the Blocks: Holochain for Distributed Security in IoT
Healthcare,” IEEE Access, vol. 10, pp. 37064–37 081, 2022.
[2] P. P. Ray, D. Dash, K. Salah, and N. Kumar, “Blockchain for IoT-Based
Healthcare: Background, Consensus, Platforms, and Use Cases,” IEEE
Systems Journal, vol. 15, no. 1, pp. 85–94, 2021.
[3] K. N. Griggs, O. Ossipova, C. P. Kohlios, A. N. Baccarini, E. A.
Howson, and T. Hayajneh, “Healthcare Blockchain System Using Smart
Contracts for Secure Automated Remote Patient Monitoring,” Journal
of Medical Systems, vol. 42, no. 7, p. 130, Jun. 2018.
[4] “Holochain Core Concepts: What is Holochain?” https://developer.
holochain.org/concepts/1 the basics/, accessed: 2023-03-26.
[5] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” Cryp-
tography Mailing list at https://metzdowd.com, 03 2009.
[6] M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” in
Proceedings of the Third Symposium on Operating Systems Design and
Implementation, ser. OSDI ’99. USA: USENIX Association, 1999, p.
173–186.
[7] D. Ongaro and J. Ousterhout, “In Search of an Understandable Con-
sensus Algorithm,” in Proceedings of the 2014 USENIX Conference on
USENIX Annual Technical Conference, ser. USENIX ATC’14. USA:
USENIX Association, 2014, p. 305–320.
[8] Y. Liang, C. Lu, Y. Zhao, and C. Sun, “Interference-Based Consensus
and Transaction Validation Mechanisms for Blockchain-Based Spectrum
Management,” IEEE Access, vol. 9, pp. 90757–90 766, 2021.
[9] P. Fernando, K. Dadallage, T. Gamage, C. Seneviratne, A. Madanayake,
and M. Liyanage, “Proof of sense: A novel consensus mechanism for
spectrum misuse detection,” IEEE Transactions on Industrial Informat-
ics, vol. 18, no. 12, pp. 9206–9216, 2022.
[10] P. Fernando, K. Dadallage, T. Gamage, C. Seneviratne, A. Braeken,
A. Madanayake, and M. Liyanage, “Distributed-Proof-of-Sense:
Blockchain Consensus Mechanisms for Detecting Spectrum Access
Violations of the Radio Spectrum,” IEEE Transactions on Cognitive
Communications and Networking, 2023.
[11] L. Zhang, H. Xu, O. Onireti, M. A. Imran, and B. Cao, “How Much
Communication Resource is Needed to Run a Wireless Blockchain
Network?” 2021.
[12] J. Parmar and K. Vaghani, A Conceptual Study on Holochain and
Blockchain Technology. SCRS, 01 2022, pp. 331–341.
[13] G. Iredale, “Blockchain vs Hashgraph vs Dag vs Holochain: Types
of DLTs,” 101 Blockchains, 02 2021. [Online]. Available: https:
//101blockchains.com/blockchain-vs- hashgraph-vs- dag-vs- holochain/
