Simulation Based Performance Evaluation of Consensus Algorithms in
NS3 for Blockchain Network
Anita Thakur
a
, Virender Ranga
b
and Ritu Agarwal
c
Delhi Technological University, India
Keywords:
Blockchain, Consensus, NS3, Raft, PBFT.
Abstract:
The adoption of blockchain technology extends beyond crypto assets, encompassing diverse domains within
enterprise systems. The inherent qualities of decentralization and encryption lead many to perceive blockchain
as an infallible repository for data security. However, within the intricate layers of blockchain architecture, the
consensus layer assumes a pivotal role in governing the network’s performance and ensuring robust security
measures. The performance of the consensus algorithm directly impacts the efficiency and scalability of the
blockchain network. Each algorithm aims to optimize the consensus process to meet the specific requirements
of a blockchain network. Through simulation-based evaluations, this research paper offers an assessment
of two significant consensus algorithms, namely Raft and practical byzantine fault tolerance (PBFT). The
experimentation is conducted utilizing the NS3 network simulator, enabling the calculation of key performance
metrics, including average throughput, packet delivery ratio, and packet loss ratio, following the leader election
time and agreement time. These evaluations provide valuable insights into the effectiveness and efficiency of
the Raft and PBFT consensus algorithms in real-world scenarios, contributing to the broader understanding of
their applicability and potential in distributed systems.
1 INTRODUCTION
Over the past few years, blockchain has emerged
as a revolutionary technology for safeguarding and
validating various forms of data transfer, com-
mencing with transactions involving cryptocurren-
cies. Blockchain provides exceptional advantages
such as decentralization and immutability, and its sup-
ported components such as smart contracts, consen-
sus mechanisms, distributed data storage, asymmet-
ric encryption, and P2P networking. By commercial-
izing these advancements, blockchain enables decen-
tralized peer-to-peer transactions to be seamlessly ex-
ecuted within a distributed system, obviating the need
for mutual trust among participating nodes. This rev-
olutionary approach effectively addresses the long-
standing challenges associated with high costs, low
efficiency, and insecure data storage prevalent in tra-
ditional centralized systems (Mingxiao et al., 2017).
In blockchain, the consensus algorithm assumes a
paramount role as the foundational mechanism, ex-
a
https://orcid.org/0000-0003-0926-3045
b
https://orcid.org/0000-0002-2046-8642
c
https://orcid.org/0000-0002-0420-1892
erting a profound influence on the holistic perfor-
mance of the blockchain network (Li et al., 2020).
Consensus represents a fundamental principle within
distributed systems, extending beyond the domain of
blockchain technology. It pertains to situations where
multiple processes or nodes uphold a shared data
state. The crucial objective of consensus algorithms
is to attain unanimous accord among these nodes, en-
suring that each node agrees upon a singular, authen-
tic value.
In the context of permissioned blockchains, the
participating nodes possess identifiable identities and
are acknowledged as recognized entities (Cao et al.,
2020). Consensus mechanisms enable decentraliza-
tion by ensuring that all participants have an oppor-
tunity to participate in the decision-making process.
Each participant has an equal chance of becoming a
block proposer or validator, depending on the specific
consensus mechanism employed. Decentralization is
achieved by distributing these roles across a diverse
set of network participants, mitigating the concentra-
tion of power and reducing the risk of a single en-
tity gaining control over the network (Xiong et al.,
2022). Regarding blockchain, the consensus problem
pertains to achieving agreement among non-faulty or
656
Thakur, A., Ranga, V. and Agarwal, R.
Simulation Based Performance Evaluation of Consensus Algorithms in NS3 for Blockchain Network.
DOI: 10.5220/0013583300004664
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 3rd International Conference on Futuristic Technology (INCOFT 2025) - Volume 1, pages 656-663
ISBN: 978-989-758-763-4
Proceedings Copyright © 2025 by SCITEPRESS – Science and Technology Publications, Lda.

correct processes within a distributed system regard-
ing a specific block of transactions at a given posi-
tion within the blockchain. It can be formulated with
three fundamental properties: Agreement ensures that
no two correct processes decide on different blocks.
Validity ensures that only valid and legitimate blocks
become part of the agreed-upon chain. Termination:
The consensus protocol guarantees that all correct
processes will eventually reach a decision.
The role of a consensus protocol in the blockchain
context is crucial as it establishes a mechanism to
order blocks in total order. By doing so, it pre-
vents conflicts and inconsistencies that may arise
when multiple blocks are concurrently appended to
the blockchain, ensuring the integrity and reliability
of the transaction history (Gramoli, 2020). There ex-
ists a multitude of consensus algorithms within the
blockchain domain, encompassing both private and
public blockchain systems. These algorithms can
be categorized into proof-based mechanisms, wherein
nodes furnish evidence of their leadership to append
new blocks to the blockchain, and committee-based
mechanisms, wherein nodes engage in voting to de-
termine the subsequent block to be appended. Note-
worthy algorithms falling within these classifications
include Proof-of-stake (PoS), Proof-of-work (PoW),
DPoS (Delegated PoS), Raft, and PBFT. This research
endeavors to conduct a simulation-based evaluation
of two compelling committee-based consensus proto-
cols, namely Raft and PBFT, utilizing the NS3 net-
work simulator. The objective is to measure various
performance indicators and gain comprehensive in-
sights into their functioning.
Section 1 presents a concise overview, elucidat-
ing the fundamental concepts of blockchain and con-
sensus. Section 2 delves into the review of existing
research conducted in consensus algorithms, encom-
passing a thorough examination of performance met-
rics and other relevant measures. Section 3 provides
detailed insights regarding the two consensus algo-
rithms selected for our study. The subsequent section
4, encompasses the simulation employed, followed
by the presentation and analysis of the obtained re-
sults. Finally, section 5 summarizes the key findings
and contributions of our study. This research pro-
vides valuable contributions to the field of consensus
algorithms in the blockchain. The paper sheds light
on performance characteristics by evaluating the Raft
and PBFT protocols using the NS3 network simulator.
It offers insights that can inform future advancements
in distributed consensus mechanisms.
2 LITERATURE REVIEW
This section aims to undertake an extensive literature
review concerning consensus algorithms in a broader
context while also focusing on studies specifically
dedicated to the comparative analysis of these algo-
rithms. The objective is to identify relevant scholarly
works contributing to our understanding of consensus
mechanisms, their underlying principles, and the fac-
tors influencing their performance.
The work presented by (Huang et al., 2019) fo-
cuses on examining the effects of key parameters,
namely network size, election timeout period, and
packet loss rate, on both the probability of network
splitting and network availability. The findings of
this study indicate that by increasing the election
timeout period, it is possible to effectively reduce
the likelihood of network splitting resulting from
packet loss. Numerous prominent approaches have
emerged within the consensus algorithms domain, in-
cluding PoS, PoA, and PoW, each with distinct ad-
vantages and drawbacks. However, it is worth noting
that these algorithms also exhibit certain limitations.
For instance, PoW necessitates substantial computa-
tional power, PoS addresses complexity concerns, and
PoA demands additional processing time during the
screening process. To alleviate these issues encoun-
tered in the algorithms, as mentioned earlier, the RSP
(Rock-Scissors-Paper) algorithm (Kim et al., 2019)
has been devised, offering effective mitigation strate-
gies. The paper by (Kaur et al., 2021) presents an ex-
tensive review of mainstream consensus protocols, in-
cluding PoS, PoW, PoA, and DPoS. It offers detailed
explanations of these protocols and conducts perfor-
mance analysis. Moreover, the paper introduces a per-
formance matrix that evaluates these protocols based
on parameters such as scalability, fault tolerance rate,
latency, degree of decentralization, and other relevant
factors.
The work of (Foytik et al., 2020) introduces a
blockchain simulator developed to assess consensus
algorithms within a configurable and realistic network
environment. The simulator offers the ability to an-
alyze the influence of both the consensus and net-
work layers, thereby enabling practitioners to make
informed decisions regarding selecting appropriate
consensus algorithms. Additionally, it facilitates the
evaluation of network layer events in scenarios char-
acterized by congestion or contention in the context
of the Internet of Things (IoT).
The simulator enables users to define consensus
algorithm operations with greater fidelity than real-
time performance, all while maintaining scalability.
Simulators are integral across various industries, in-
Simulation Based Performance Evaluation of Consensus Algorithms in NS3 for Blockchain Network
657

cluding blockchain, for their role in testing, evalua-
tion, cost and time efficiency, scalability analysis, and
risk mitigation.
The study (Hanggoro and Sari, 2021) compares
the performance of two simulators, NS3 and Sim-
Block, in CPU utilization, memory consumption, and
simulation time. The findings reveal that SimBlock
exhibited approximately 10% higher CPU usage than
NS3, whereas SimBlock’s memory utilization was
approximately 14% greater than that of NS3. No-
tably, the simulation time for NS3 is the highest,
taking 55188.3 seconds, whereas SimBlock accom-
plished the simulation of the same number of blocks
and nodes in a significantly reduced timeframe of
68.242 seconds. In contrast, NS3 excels in provid-
ing a highly realistic simulation environment with in-
formative output, ensuring stability and efficient re-
source utilization. However, one notable drawback
is the significant trade-off in simulation time, which
tends to be considerably longer than other simulators.
The work by Hidayat et al. (Hidayat et al., 2022)
aims to assess the performance of various consen-
sus algorithms, including Paxos, Raft, and PBFT,
by utilizing the NS3 network simulator and specif-
ically, simulating the time required to achieve con-
sensus among participants. The results showed that
the PBFT algorithm demonstrates a remarkable speed
advantage, being approximately six times faster than
Paxos and five times faster than Raft in reaching con-
sensus. According to the authors, their paper is the
very first to evaluate three consensus protocols such as
Paxos, PBFT, and Raft on NS3. We drew inspiration
from their work and conducted the study in our simu-
lation environment; we also extensively observed the
packet delivery ratio, packet loss ratio, and average.
The findings show the PBFT is 10 times faster than
Raft in reaching the agreement.
3 CONSENSUS ALGORITHM
A consensus algorithm can be envisioned as a consor-
tium of machines operating as a synchronized unit,
resilient enough to withstand the potential breakdown
of certain constituents within the group.
3.1 Raft Consensus Algorithm
Raft is a consensus algorithm engineered with the
intention of achieving optimal comprehensibility. It
matches Paxos’ fault tolerance and performance ca-
pabilities, making it an equivalent alternative in the
blockchain domain. While designing the Raft, tech-
niques such as decomposition (wherein Raft segre-
gates leader election, log replication, and safety) and
state space reduction (compared to Paxos, Raft min-
imizes the level of non-determinism and the poten-
tial for servers to exhibit inconsistencies among them-
selves) are employed to enhance understandability
(Ongaro and Ousterhout, 2014). Following the emer-
Figure 1: Raft Consensus Algorithm
gence of the Byzantine Generals Problem, Lamport
presented the Paxos algorithm as a solution to the
challenge of ensuring consistency under specific con-
ditions in 1990. However, due to the intricate na-
ture of the paper, it faced difficulty gaining accep-
tance. To address this, Lamport republished the paper
in 1998, and subsequently, Paxos was reintroduced in
2001 (Lamport, 2001),(Lamport, 2019). To maintain
the understandability of the consensus algorithm, Raft
was introduced. In brief, Raft, a distributed system,
is composed of multiple nodes, and one of them is
elected as the leader. The leader is responsible for
coordinating the operations and maintaining the con-
sistency of the system. The other nodes are followers,
which replicate the leader’s actions.
The Leader in the Raft consensus al-
gorithm plays an important role. In brief,
Each node i maintains a log, denoted as log
i
=[(term
1
,command
1
),(term
2
,command
2
),...],
where term
n
represents the term number and
command
n
represents the operation for entry n in
the log. The current term of node i at time t can be
represented as current
term
i(t)
. The state of node i at
time t is denoted as state
i(t)
, where state
i(t)
takes
values from the set follower, candidate, leader. Votes
received by candidate i in term t can be denoted as
votes
i(t)
. Candidate i becomes the leader if it receives
votes from the majority of nodes. Acknowledgment
of node j for the log entries of node i is represented
as ack
i j
. When the leader receives acknowledgments
from the majority of nodes, it considers the log
entries committed.
In the Raft consensus Algorithm (Fig.1.), a Raft
cluster comprises multiple servers, typically five, de-
signed to withstand up to two failures while ensur-
ing system availability. Initially, all nodes within
the cluster assume the follower state. However, if
a follower does not receive communication from the
INCOFT 2025 - International Conference on Futuristic Technology
658

leader within a specified time frame, it transitions to
the candidate state. In the Leader Election process,
During the candidate state, the node seeks votes from
other cluster nodes to secure leadership. The candi-
date sends out vote requests, and the remaining nodes
respond accordingly. If the candidate receives votes
from the majority of the nodes, it attains the leader
position.
3.2 Practical Byzantine Fault Tolerance
The initial purpose of the PBFT consensus algorithm
(Castro et al., 1999) was to establish a mechanism that
guarantees the integrity of a distributed network. In a
distributed system composed of 3 f + 1 nodes, where
f denotes the count of Byzantine nodes, consensus
can be achieved when a minimum of 2 f + 1 non-
Byzantine nodes operate without disruptions. PBFT
offers assurances of safety and liveness properties, en-
abling the system to reach a consensus on the correct
ordering of blocks and progress even in the presence
of Byzantine faults. By accommodating a maximum
of F faulty nodes within a network of N = 3 f + 1,
f = (n − 1)/3 validator, PBFT achieves resilience
against malicious or faulty behavior (Wu et al., 2020).
Figure 2: PBFT Consensus Algorithm
The phases of PBFT are shown in Figure 2.
In the request phase, the client initiates a request
to the primary node, which assigns a timestamp
to the request. The client nodes, entrusted with
transmitting transaction requests, proceed with their
designated tasks. Later in the pre-prepare phase, the
primary node (replica 0) logs the request message and
assigns it a sequential order number. Additionally,
the replica 0 node transmits pre-prepare messages
≪ PRE PREPARE,v,n,d >,m > to the remaining
replica nodes (replica 1, replica 2, and replica 3).
Here, v denotes the view number, n represents the
serial number, d signifies the message digest and m
denotes the original message content. Subsequently,
the primary node broadcasts the message to the
subsequent consensus nodes/ server nodes. These
server nodes then undertake an initial evaluation to
determine whether they accept or reject the received
request (shown in the algorithm below) (Castro et al.,
1999).
Algorithm: PBFT
1. < REQUEST,o,t, c > σ
c
= TRUE
broadcast≪ PRE PREPARE,v,n,d >σ
p
, m >
2. // Pre prepare Phase
i f < PRE PREPARE >= T RU E // replica accept
the pre prepare message.
{
brodcast < PREPARE,v,n,d,i >σ
i
; // to all
replica nodes.
}
else do nothing
3. i f prepared(m,v,n,i) = T RUE
{
broadcast < COMMIT, v,n, D(m),i > σ
i
}
4. in Commit Phase
i f committed local(m,v,n,i) = T RUE
{
// replica i executes client requested operation and
sends reply to client
< REPLY, v,t,c, i,r > σ
i
}
else do nothing
Upon receiving 2 f prepare messages from fellow
server nodes (including its own, resulting in a total
of 2 f + 1 messages), server node i meticulously ver-
ifies the consistency of the received v, n, and d pa-
rameters with those it had initially sent out. Sub-
sequently, when server node i gathers 2 f + 1 mes-
sages, and if a majority of nodes opt to accept the
request, it proceeds to transmit a commit message <
COMMIT,v, n,d,i > and transitions into the commit
state. In the commit state, every node sends a commit
message to all other nodes. server node i, upon re-
ceiving 2 f commit messages from other server nodes
(including its own, totaling 2 f + 1 messages), care-
fully verifies the consistency of the v, n, and d param-
eters across these messages. Once client D receives
f + 1 identical commit messages, it confirms the at-
tainment of consensus regarding its request. Subse-
quently, the server nodes respond to the client. If the
client does not reply due to network delays, the re-
quest is re-transmitted to the server nodes (Wu et al.,
2020).
Simulation Based Performance Evaluation of Consensus Algorithms in NS3 for Blockchain Network
659

4 EXPERIMENTAL RESULTS
AND ANALYSIS
Our study employs the discrete-event network simula-
tor NS3, which simulates the Raft and PBFT consen-
sus algorithms and evaluates the performance. This
simulation-based approach allows us to analyze and
assess the efficiency and effectiveness of these algo-
rithms within a controlled network environment. NS3
is an advanced, open-source discrete-event network
simulation tool that enables researchers and devel-
opers to model and analyze complex communication
networks. Developed in C++ and optimized for per-
formance, NS3 offers an extensive range of network-
ing protocols, device models, and simulation scenar-
ios.
The Raft consensus algorithm, implemented
(Zhayujie, 2023), consists of the important task
of electing the leader node since only the leader
is responsible for coordinating the operations and
maintaining the consistency of the system. In this
experiment, we have observed the leader selection
time among a group of nodes. We have also analyzed
the agreement time and calculated the performance
metric packet delivery ratio and packet loss ratio, etc.
Algorithm 1: Leader Election
Input: total number o f nodes, node has voted,
vote pass, vote f ail,
Output: Node < node id > has elected as leader
at time < seconds >,
1. Defining the value to total number o f nodes that
are going to be participating in the consensus pro-
cess.
2. In the case of VOT E REQUEST
i f (node has voted == 0)
{
//successfully process the vote request
set the (node has voted = 1)
}
otherwise
i f (node has voted == 1)
// node has already voted and the request is not
processed
3. In the case of VOT E RESPONSE
//if more than half of the nodes give the response
to vote request,the node is elected as the Leader
i f (vote pass + 1 > total number o f nodes/2)
{
// node < node id > is elected as Leader
// stop the next election process
vote pass = 0;
vote f ail = 0;
}
else
i f (vote f ail >= total number o f votes/2)
// more than half of the node has opposed
// node < node id >does not become Leader
// re initiate the voting process
vote pass = 0;
vote f ail = 0;
Figure 3: Topology of 20 Nodes with 4 Nodes Broadcasting
Votes to Neighboring Nodes
In the pursuit of attaining leadership status, can-
didate nodes initiate the election process by sending
vote requests to other nodes. Each server is allowed
to cast a vote for a single candidate during the desig-
nated term, adhering to a first-come, first-served prin-
ciple. A simulation of the leader selection algorithm,
depicted in Figure 3, reveals that two candidate nodes
commenced the election process with slight temporal
variations. Once a node has cast its vote for a candi-
date, it sets the value of the variable node has voted
to 1 and refrains from voting for any other candidate
node.
Within our simulated environment comprising 20
nodes, the initiation of an election is observed at 4
distinct nodes, specifically nodes 18, 2, 7, and 10, at
timestamps of 0.172 seconds, 0.177 seconds, 0.192s,
and 0.212s, respectively. Ultimately, node 18 won
the election, securing the majority of votes and subse-
quently assuming the role of the leader at time 0.204s.
Similarly, In 50 nodes, the election process is initi-
ated by nodes 20, 42, 18, 2, 30,24,45,7, and 36 at
timestamps of 0.161s, 0.171s, 0.172s, 0.177s, 0.179s,
0.182s, 0.187s, 0.192s and 0.193s respectively, where
node 20 becomes the leader node. The agreement
time, which refers to the time taken to achieve the
consensus, is evaluated by varying the number of
INCOFT 2025 - International Conference on Futuristic Technology
660

nodes and message size while maintaining a constant
delay of 15ms.
Figure 4: Time to reach the consensus in Raft consensus
algorithm
On the other hand, PBFT encompasses three cru-
cial elements: Replica, Primary, and View. The pri-
mary entity serves as the initiator of the voting mech-
anism, while the replica node ensures the efficacy of
the voting process. In the event of a primary node
failure, the view rotation function is invoked to re-
place the existing primary node. The PBFT algo-
rithm implemented (Zhayujie, 2023) within the sim-
ulated environment follows a phased approach con-
sisting mainly of Pre-prepare, Prepare, Commit, and
View Change. Within this network, the client initiates
a request, which is then sent to the primary node. The
primary node, selected from a cluster of nodes, pro-
ceeds to execute the requested operation on behalf of
the client and broadcasts a prepared message to the
replica nodes. During the prepare response phase,
if more than half of the responses indicate a PASS
(i.e., tx[index].prepare vote >= (2∗N)/3), the nodes
proceed to broadcast a COMMIT message. Subse-
quently, if the client receives responses from more
than half of the nodes indicating a commit message
(i.e., tx[index].commit vote > (2 ∗ N)/3), it can be
concluded that the consensus has been successfully
achieved. Similarly, for the next round, a new primary
node (Leader) is selected.
4.1 Observation
Based on the experimental findings, several perfor-
mance metrics are analyzed, including agreement
time, packet send, packet loss ratio, and packet deliv-
ery ratio. In Figure 4, the tx size is varied from 1 KB
to 1000 KB, while the number of nodes ranged from
10 to 50, with a constant delay of 15ms. Notably,
both the PBFT and Raft algorithms exhibited mini-
mal, nearly negligible impact on agreement time in re-
sponse to changes in the number of nodes and tx size.
Specifically, for message sizes of 1 KB, 10 KB, 100
Figure 5: Topology of 20 Nodes, where nodes broadcasting
message
Figure 6: Time to reach the consensus in PBFT consensus
algorithm
KB, and 1000 KB, the agreement times in 10 nodes
are observed to be 1.24461 s, 1.24776 s, 1.29646
s, and 1.36801 s, respectively. Similarly, within the
PBFT consensus algorithm Figure 6, agreement times
for message sizes of 1 KB, 10 KB, 100 KB, and
1000 KB are recorded as 0.127485 s, 0.128685 s,
0.1408615 s, and 0.262621 s, respectively. Compar-
ative analysis reveals that PBFT achieved agreement
significantly faster, approximately 10x faster, than the
Raft consensus algorithm Figure 7. To investigate the
Figure 7: Agreement time comparison between Raft and
PBFT
Simulation Based Performance Evaluation of Consensus Algorithms in NS3 for Blockchain Network
661

total number of packets sent in the Raft and PBFT, the
number of nodes is systematically varied while main-
taining a constant delay of 1ms and a fixed tx size of
11 KB. It has been observed that PBFT sent a massive
number in comparison to Raft. The PBFT algorithm
presents a notable challenge due to its high message
complexity. In common situations, PBFT necessitates
N
2
messages for each consensus round, which can po-
tentially hinder scalability when applied to large-scale
networks.
Figure 8: Total number of packets sent
Furthermore, within the PBFT algorithm, an in-
crease in message size under low delay and limited
bandwidth results in packet loss. Conversely, in the
Raft algorithm, a packet delivery ratio of 100% is ob-
served across a range of nodes from 10 to 50 and mes-
sage sizes from 1 to 1000KB. In the simulated envi-
Figure 9: Packet loss in PBFT algorithm
ronment with a 1 ms delay and 11 KB message size,
the average throughput in Raft is found to be higher
compared to PBFT. Specifically, for Raft, the average
throughput values are measured 66.77 Kbps, 66.79
Kbps, and 66.80 Kbps for 10, 30, and 50 nodes, re-
spectively. In contrast, PBFT exhibited lower average
throughput, with values of 22.89 Kbps, 17.80 Kbps,
and 16.76 Kbps for the corresponding node configu-
rations.
5 CONCLUSION
Over the years, there has been an exponential surge in
the advancement of blockchain technology and its uti-
lization across various fields. Within these decentral-
ized and distributed systems, a significant challenge
lies in attaining consensus among all participants on
a single data value, which is crucial for maintaining
the system’s reliability. The primary aim of this study
is to analyze two widely adopted algorithms within a
controlled environment and examine their consensus
mechanisms, throughput, packet loss ratio, and other
related factors. It has been observed that the PBFT
algorithm is approximately ten times faster than the
Raft algorithm, as evidenced by the agreement time.
However, as previously discussed, Raft demonstrates
better throughput performance. In future research en-
deavors, our focus will be on enhancing the PBFT
consensus algorithm based on the observed results.
We will investigate and explore potential modifica-
tions or optimizations that can be implemented to fur-
ther improve the performance and efficiency of PBFT
in achieving consensus in distributed systems.
REFERENCES
Cao, B., Zhang, Z., Feng, D., Zhang, S., Zhang, L., Peng,
M., and Li, Y. (2020). Performance analysis and com-
parison of pow, pos and dag based blockchains. Digi-
tal Communications and Networks, 6(4):480–485.
Castro, M., Liskov, B., et al. (1999). Practical byzantine
fault tolerance. In OsDI, volume 99, pages 173–186.
Foytik, P., Shetty, S., Gochhayat, S. P., Herath, E., Tosh,
D., and Njilla, L. (2020). A blockchain simulator for
evaluating consensus algorithms in diverse network-
ing environments. In 2020 Spring Simulation Confer-
ence (SpringSim), pages 1–12. IEEE.
Gramoli, V. (2020). From blockchain consensus back to
byzantine consensus. Future Generation Computer
Systems, 107:760–769.
Hanggoro, D. and Sari, R. F. (2021). Performance com-
parison of simblock to ns-3 blockchain simulators. In
2021 4th International Conference on Circuits, Sys-
tems and Simulation (ICCSS), pages 45–50. IEEE.
Hidayat, S. A., Juniardi, W., Khatami, A. A., and Sari,
R. F. (2022). Performance comparison and analysis
of paxos, raft and pbft using ns3. In 2022 IEEE Inter-
national Conference on Internet of Things and Intelli-
gence Systems (IoTaIS), pages 304–310. IEEE.
Huang, D., Ma, X., and Zhang, S. (2019). Performance
analysis of the raft consensus algorithm for private
blockchains. IEEE Transactions on Systems, Man,
and Cybernetics: Systems, 50(1):172–181.
Kaur, M., Khan, M. Z., Gupta, S., Noorwali, A.,
Chakraborty, C., and Pani, S. K. (2021). Mbcp:
Performance analysis of large scale mainstream
blockchain consensus protocols. Ieee Access,
9:80931–80944.
Kim, D.-H., Ullah, R., and Kim, B.-S. (2019). Rsp con-
sensus algorithm for blockchain. In 2019 20th Asia-
INCOFT 2025 - International Conference on Futuristic Technology
662

Pacific Network Operations and Management Sympo-
sium (APNOMS), pages 1–4. IEEE.
Lamport, L. (2001). Paxos made simple. ACM SIGACT
News (Distributed Computing Column) 32, 4 (Whole
Number 121, December 2001), pages 51–58.
Lamport, L. (2019). The part-time parliament. In Concur-
rency: the Works of Leslie Lamport, pages 277–317.
Li, X., Jiang, P., Chen, T., Luo, X., and Wen, Q. (2020). A
survey on the security of blockchain systems. Future
generation computer systems, 107:841–853.
Mingxiao, D., Xiaofeng, M., Zhe, Z., Xiangwei, W., and
Qijun, C. (2017). A review on consensus algorithm
of blockchain. In 2017 IEEE international conference
on systems, man, and cybernetics (SMC), pages 2567–
2572. IEEE.
Ongaro, D. and Ousterhout, J. (2014). In search of an un-
derstandable consensus algorithm. In 2014 USENIX
annual technical conference (USENIX ATC 14), pages
305–319.
Wu, Y., Song, P., and Wang, F. (2020). Hybrid
consensus algorithm optimization: A mathematical
method based on pos and pbft and its application in
blockchain. Mathematical Problems in Engineering,
2020(1):7270624.
Xiong, H., Chen, M., Wu, C., Zhao, Y., and Yi, W. (2022).
Research on progress of blockchain consensus algo-
rithm: A review on recent progress of blockchain con-
sensus algorithms. Future Internet, 14(2):47.
Zhayujie (2023). Blockchain-simulator.
https://github.com/zhayujie/blockchain-simulator.
Accessed: 2023-05-20.
Simulation Based Performance Evaluation of Consensus Algorithms in NS3 for Blockchain Network
663