See discussions, stats, and author profiles for this publication at: [Link]

net/publication/337936141

Study of Blockchain Based Decentralized Consensus Algorithms

Conference Paper · December 2019

DOI: 10.1109/TENCON.2019.8929439

CITATIONS READS
61 3,088

6 authors, including:

Soumyashree S Panda Bhabendu Kumar Mohanta

International Institute of Information Technology United Arab Emirates University
25 PUBLICATIONS 1,619 CITATIONS 82 PUBLICATIONS 3,040 CITATIONS

SEE PROFILE SEE PROFILE

Utkalika Satapathy Debasish Jena

International Institute of Information Technology International Institute of Information Technology
22 PUBLICATIONS 829 CITATIONS 101 PUBLICATIONS 3,501 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Bhabendu Kumar Mohanta on 15 December 2019.

The user has requested enhancement of the downloaded file.

 Study of Blockchain Based Decentralized
Consensus Algorithms
Soumyashree S. Panda1 , Bhabendu Kumar Mohanta2 , Utkalika Satapathy3 , Debasish Jena4 ,
Debasis Gountia5 , Tapas Kumar Patra6
1,2,3,4
Department of Computer Science & Engineering, IIIT Bhubaneshwar, Odisha, India, 751003
5
Department of Computer Science & Engineering, IIT Roorkee, Uttarakhand, India, 247667
6
Department of Electronic Systems Engineering, IISC Bangalore, Karnataka, India, 560012
Email: C117011@[Link].in1 , C116004@[Link].in2 , A117010@[Link].in3
debasish@[Link].in4 , [email protected] , [email protected]

Abstract—Blockchain is the backbone technology behind entities and is established in a closed environment. Though all
crypto-currency and Bitcoin. By concept, Blockchain is a dis- the entities are allowed to perform transactions, only a fixed
tributed database where transactions are recorded in an in- set of predetermined nodes can take part in the consensus
corruptible and non-modifiable manner. Currently, Blockchain
technology is envisioned as a powerful framework for open-access process in a Permissioned Blockchain. Consensus algorithms
networks, decentralized information processing and sharing sys- hold an important part in managing the an efficient and secure
tems, etc. This review is motivated due to the lack of an extensive Blockchain system. Some of the popular algorithms are Proof
survey on the existing decentralized consensus mechanisms in of Work (PoW), Proof of Burn (POB), Proof of Stake (PoS),
Blockchain technology. So in this paper, an in-depth review of Raft, Practical Byzantine Fault Tolerant (PBFT), Paxos, etc.
the distributed consensus mechanisms has been presented. In
addition to this, a comparative analysis of the consensus protocols [3]. Table 1 shows a detailed comparison among these two
based on the type of Blockchain is also demonstrated. types of Blockchain configuration.
Index Terms—Blockchain, distributed consensus, Permission- Until now, the focus is predominantly on the application of
less Blockchain, Permissioned Blockchain. Blockchain in different fields. So this paper presents a detailed
study of different consensus algorithms and also analyzed their
I. I NTRODUCTION advantages and disadvantages in terms of performance and
A Blockchain technology based system is a classical dis- fault tolerance ability. So the rest of the paper is outlined
tributed system where all the participating entities are ge- as follows: Section 2 describes why do we need consensus
ographically scattered but connected through different types in a distributed system and the various requirements of con-
of networks. It was formally theorized and implemented sensus algorithms. Section 3 and Section 4 presents various
by S. Nakamoto, in the year 2008 and 2009, respectively consensus mechanisms for a permission-less and Permission-
[1]. Traditional transaction management systems require a ed Blockchain system consensus respectively. Finally Section
centralized trusted party who is responsible for confirmation 5 gives a comparative analysis of these consensus algorithms
and storage of transactions. This obviously have many issues and Section 6 concludes the paper.
like cost, privacy,efficiency and security, etc. Decentralization
is the fundamental characteristic of Blockchain which can II. D ISTRIBUTED C ONSENSUS A LGORITHMS
be employed to solve the above issues. Blockchain basically The concept of consensus is an engrossing topic in a
provides a platform where multiple entities who dont trust each decentralized or distributed network. Consensus means a pro-
other can work or share information in a common platform. cedure to arrive at a common agreement in a decentralized or
Bitcoin, the first application that brought Blockchain into the distributed multi-agent platform. In a conventional distributed
global picture, is also the first cryptocurrency developed and system, we apply consensus to ensure reliability which en-
used. But with progress and in-depth study of Blockchain sures correct execution in presence of faulty individuals and
technology, its application is no more limited to financial fault tolerance. In addition to this, a distributed consensus
sector only. Rather it has gained much popularity in other fields mechanism should satisfy certain properties like termination,
like Government, Technological enterprises, Supply chain, validation, integrity and agreement. An example of consensus
etc [2]. Mainly Blockchain can be used in two different is the state machine replication which is a key aspect of any
ways Permission-less and Permissioned. Permission-less de- distributed consensus protocol. For example, if we want to
sign which is generally established on an open environment run some kind of distributed protocol over a network, every
like Bitcoin, Ethereum, allows anyone to join the system as individual entity runs the current protocol and they store the
well as allows writing to the shared blocks. Permission-less state of the protocol in different state machines. So the entire
design also gives equal privilege to all the nodes in case of con- execution part of the protocol can be represented as a state
sensus process. On the contrary, a Permissioned Blockchain machine. Now this state machine needs to be replicated to
design such as Hyperledger fabric is managed by known set of multiple entities so that every individual entity can reach to

978-1-7281-1895-6/19/$31.00 2019
c IEEE 908
 TABLE I
C OMPARISON OF P ERMISSION - LESS AND P ERMISSION - ED B LOCKCHAIN .

Permission-less Blockchain Permission-ed Blockchain

Environment Type Open Closed
Participation in Consensus All nodes Selected nodes
Identity Pseudo-Anonymous Registered Participants
Consensus Type Lottery based Voting based
Transaction Processing Speed Slow Fast
Proof of Work, Proof of Stake, Proof of Burn, Proof Paxos, Practical Byzantine Fault tolerance, Raft,
Consensus Algorithms
of Delegated Stake, etc. etc.

a common output of the protocol. Achieving consensus can Bitcoin system where anyone can join the network at any
be easy and straight forward for certain architectures under time. So under this kind open environments like Bitcoin,
certain scenarios like when how consensus has been achieved, are explained below.
• The entire system is faultless or there is not be any failure Along with that, several other algorithms which are being
in the system, so that every entity can receive the message applied on permission-less models and Permissioned models
correctly. of Blockchain are described below.
• The system behaves in a synchronous way, i.e., it is
expected that you will receive all messages within some
predefined time interval. III. C ONSENSUS IN P ERMISSION - LESS B LOCKCHAIN
S YSTEM
However achieving consensus can be non-trivial in case of a
distributed environment due to the presence of multiple types As mentioned above, the conventional consensus mech-
of failures. Typically in a distributed system, we consider 3 anisms will not be applicable in an open or permission-
different types of failures: less Blockchain system. Hence this Section suggests how
1) Node Failure: A node suddenly crashes or becomes consensus has been achieved in Bitcoin like open environments
unavailable in the middle of communication. So we are along with their shortcomings.
not expected to receive any message from that particular
node. This can hardware or software fault. A. Bitcoin Consensus
2) Partitioned Faults: This type of fault occurs whenever
The main purpose of consensus in Bitcoin is to add a new
links fail, which results in partition in the network. This
block to the existing Blockchain. There can be multiple miners
can hamper reaching in consensus.
in the Bitcoin network and these miners can propose their
3) Byzantine Faults: This kind of fault is more difficult
new blocks based on the transactions they have heard of.
to handle in a distributed environment. Here the entity
It is not necessary that every miner will propose the same
starts behaving maliciously. In both the above faults, we
block. Generally the miners include those transactions in the
can expect the effect on the network, but in this case, it is
new block that they have heard of since the last time a block
difficult to guess because it completely depends on how
has been added. The miners also need to ensure that size of
maliciously the entity is behaving and what the entity is
the newly proposed block does not exceed certain threshold.
doing.
We should focus on the following two observations before
Correctness of a distributed consensus protocol can be designing the algorithm:
characterized by the following two properties:
• Any valid block (a block with all valid transactions) can
1) Safety: It ensures that one will never converge to an be accepted even if it is proposed by only one miner.
incorrect state. • The entire protocol can work in rounds. Broadcast the
2) Liveliness: Every correct value must be accepted even- accepted block to the peers and collect the next set of
tually. transactions. (Once a valid block has been accepted or
The conventional distributed consensus protocols are based on the system has reached to a consensus, from that point
either message passing system or shared memory system. The a round starts. The miner starts getting the transactions
former requires closed environment where every entity needs and they can find out the transactions that are not already
to know the identity of every other entity in the network committed in the Blockchain. Based on that they can
[4]. But in case of shared memory approach, a common propose a new block.)
memory space is used to read and write the shared variables Based on the above two observations, we can design solutions
which everyone present in that network can access. But it so that
is not suitable for internet grade computing as we need to
put a memory which should be readable and writable by • Every miner independently tries to solve a problem.
every individual entity in the network. Similarly, message • The block is accepted for the miner who can prove first
passing approach is not feasible in an open environment like that the challenge has been solved.

2019 IEEE Region 10 Conference (TENCON 2019) 909

 Fig. 4. Interaction process in PBFT algorithm.

1) Proof-of-Work (PoW): The idea of PoW came in the year

Fig. 1. Types of nodes in Paxos. 1992 by Dwork and Naor to combat junk emails where we
have to do some work to send a valid email [5]. The attacker
this way will be discouraged to send junk emails because in
that case they have to do some work of some complexity to
forward the junk emails that not prove beneficial for them.
Blockchain based PoW system must have certain features like:
• Asymmetry: The task must be relatively hard but feasible
for the service requester.
• The task must be easy to verify for the service provider.
In this way the service requester will get discouraged to
forge the work but service provider can easily check the
validity of the work because of the asymmetry nature of
the work.
Bitcoin based PoW system extends the hashcash based PoW
system and develop a methodology to protect the Blockchain
by applying the distributed consensus mechanism. Hashcash
system was proposed by Adam Back which uses the puzzle
Fig. 2. State change model for Raft algorithm. friendliness property of the cryptographic hash function [6].
Now coming to Bitcoin based PoW, the miners who take
part in the consensus process need to give a proof that
they have done some work before proposing a new block.
The attacker will be discouraged to propose a new block or
make a change in the existing blocks. Because in that case,
they have to do the entire work of the Blockchain which
is computationally difficult in a generic environment. Every
miner will try to find out a nonce value which will satisfy
certain hash equation.
For example, BH = Hash (PH: MR: N)
N=?
where BH = Block Hash
PH= Previous Block Hash
MR = Merkle Root
and N = Nonce
This BH has a given challenge which is to ensure zeros at
the beginning. So this is termed as the difficulty of the system.
The miners will try with different values of nonce (N) to find
out difficulty. The miner who will first find out nonce value
Fig. 3. Leader election process for Raft algorithm. for his/her own block, that miner will able to include the block
as a part of the Blockchain. Most implementation of Bitcoin

910 2019 IEEE Region 10 Conference (TENCON 2019)

PoW use double SHA256 hash function. In the default set up, of Bitcoin scripts. Smart contracts are self-executing soft-
all miners wait for around 10 minutes and look for all the ware programs in which the terms and conditions among the
transactions which are taken place within that duration. Then negotiating parties are penned down. Generally, the concept
they start the mining process. of state machine replication mechanism is used to ensure
As we have seen the probability of getting a PoW is very consensus in Permissioned Blockchain environment because
low, hence it will never happen that any miner will be able to of the following reasons:
control the Bitcoin network exclusively. In case any attacker • The network is closed and the nodes know each other, so
wants to make some changes in one block, they have to do the state replication is Possible among the known nodes.
more work compared to the collective work of all the blocks • It avoids the overhead of mining (in terms of time, Power,
in the longest chain which is computationally difficult, though Bitcoin, etc.).
not impossible. Thus making an attack difficult with current
hardware and hence Bitcoin system is tamper proof. This A. Paxos
tamper proof characteristics of PoW also ensures that double
spending does not happen in case of a Blockchain network. The first ever consensus algorithm, Paxos, propoed by
Apart from this, PoW based systems suffer from a number of Lamport [7] with the objective to choose a single value under
security attacks like sybil attack, DOS attack, etc. In case of crash or network fault. The idea behind Paxos is very simple.
sybil attack, the attacker tries to fill the network with clients All the nodes in the network have been categorized into three
under its control. This helps the attacker to control the entire types namely the proposers, the acceptors and the learners as
network. These clients work according to the instructions of shown in Fig 1. Every one is a learner in the network that
the attacker which compromises the PoW mechanism. In DOS, learns the consensus value. Let us look into the procedure in
the malicious node will send a lot of data to a particular node detail:
or nodes which will hamper the normal functioning of the • The proposer initially prepares a proposal with a proposal
Bitcoin transactions. Another major flaw in a Bitcoin system number known as prepare message and send it to the
is monopoly problem. It happens when a particular miner acceptors. This proposal number forms a time-line and
gains the control of the network by deploying huge servers for the biggest number is considered up to date. For example,
mining process. So it may happen that this particular miner between proposal number x and z = x+y, where y ¿= 1,
will gradually generate a huge number of blocks and hence the proposal number z will be considered as latest and will
miner can control the entire flow of transactions. As a result, be accepted.
other nodes will get discouraged to join as miners and only P repare message: (proposal number)
few miners with large computing resources will control the • Each acceptor compares received proposal number with
network. the current known values for all proposer’s proposal
message. If it gets a higher number, then it accepts the
B. Proof of Stake (PoS) proposal or else declines it. Then the acceptor prepares
PoS mechanism is an improved version of PoW to reduce the response message of the following form
the excessive electricity consumption of PoW based systems. P repare response: (accept/reject, proposal number, ac-
As a substitute to the computationally expensive PoW mecha- cepted values)
nism, PoS aims to stake nodes’ economic share in the network. where, proposal number is the biggest number the accep-
Like PoW, a node (miner) is selected to add a block to tor has seen.
the Blockchain [3]. But here the miner selection procedure and accepted values are the already accepted values from
is different from PoW. In PoS, the selection of a miner is other proposer.
proportional to the amount of Bitcoin it holds. Block finality • Next a vote is being taken based on the majority decision.
in PoS based system is faster compared to PoW Blockchain, as The proposer checks whether the majority of the accep-
computationally difficult puzzle solving is not there in [Link] tors have rejected the proposal. If yes, then the proposer
PoS based algorithm developed by Ethereum is known as updates it with the latest proposal number. If no, then
Casper. the proposer further checks whether the majority of the
The PoS algorithm pseudo-randomly chooses miners to cre- acceptors have already accepted values. If yes then the
ate blocks of the Blockchain, so that no miner can predict its proposers value can not be selected or else it sends accept
turn in [Link] also solves the monopoly problem of PoW message.
based consensus. Naive PoS algorithms are prone to an attack • Finally, the proposer sends the accept message having the
known as Nothing-at-Stake, thus require some improvements following format to all the acceptors.
in order to provide safety. Accept message: (proposal number, value)
where proposal number: same as prepare phase value
IV. C ONSENSUS IN P ERMISSION - ED B LOCKCHAIN value: single value proposed by proposer
S YSTEM • whenever the acceptor accepts a value, it informs the
In Permissioned Blockchain, consensus is achieved through learner nodes about it so that everyone will learn about
the help of a smart contract, which is basically an extension the accepted value.

2019 IEEE Region 10 Conference (TENCON 2019) 911

As mentioned, if more than (N/2 - 1) acceptors fail, then no members. Hence, it is more essential to resolve crash faults
proposer will get enough reply messages to form a conclusion rather than Byzantine faults for private Blockchain.
and we can not reach consensus. Even though the concept
C. Byzantine Fault Tolerance and and it’s Variant
behind Paxos is very simple to understand but the theoretical
proof is very complicated. The real life application of the same In relation to distributed systems, Byzantine Fault Tolerance
may need to go for sequence of selections which is known is the capability of a distributed network to execute as required
as multi-Paxos system. Multi-Paxos systems need a repeated and correctly reach to a consensus despite malicious nodes.
application of Paxos which increases the system complexity. Derived from the Byzantine General Problem, where the Gen-
This is because the number of messages exchanged between eral sends an attack message to one group of lieutenants where
the nodes also increases. There is also a chance of livelock or as send a retreat message to another group of lieutenants.
starvation in Paxos based systems. Hence it becomes difficult for the system to find out what
action to take. The byzantine fault tolerance model has the
B. Raft following assumptions:
Raft algorithm is designed as an easy alternative to Paxos. • Total N number of nodes with at most f faulty nodes
The basic idea behind Raft is that the nodes collectively selects • Closed Environment (Receiver always knows the identity
a leader and rest of the nodes become followers. The leader of the sender)
is responsible for state transition log replication across the • Fully connected
followers [8]. Record entries flow in only one direction from • Reliable communication medium
the leader to the followers. Unlike Paxos, here each node can • Synchronous system
be at any of the three states namely leader, candidate and Byzantine fault-tolerant systems are typically built using repli-
follower at any particular time. Raft algorithm runs in rounds cation. For this, the state machine approach is used which
which is known as term. Each term starts with an election helps to implement fault toerant services. The variant of BFT
where one or more candidates strive to become a leader. The that has been designed for synchronous distributed systems
state change is shown in the Fig 2. is called “Lamport-Shostak-Pease” algorithm [9]. It was one
Coming to a detailed view of the algorithm: of the first algorithm for handling byzantine faults [Byzantine
• Initially, we have a set of follower nodes, who look out general problem, lamoprt, acm]. This ensures consensus in
for a leader. If within certain time interval they do not presence of f number of faulty nodes, provided we have
find one, then the leader election process starts. In this (2f + 1) number of lieutenants apart from the commander.
election phase, some of the followers volunteer to become But our real systems behave in an asynchronous way as
a leader and request votes from all other nodes. Then there is no guarantee that a message will be received within
these candidate nodes send request messages to other a certain time interval. For this reason, a variant of BFT
followers of the system for vote. known as Practical Byzantine Fault Tolerance (PBFT), has
Request vote:(term, index), been developed for real life asynchronous systems [10]. As
where term: last calculated number known to candidate in case of a pure asynchronous system achieving consensus is
+ 1 and index: committed transaction available to the impossible even in the presence of a single faulty node. So to
candidate. This is the first part of Raft algorithm. This ensure liveness property, instead of pure asynchronous system,
Request vote message will be forwarded to all the nodes a weak asynchronous system has been considered.
in the network. Coming to the algorithm, the byzantine model consists of
• When a node receives the request, it compares the term three types of nodes: the clients, a commander (leader) and
and index in the received message with corresponding the lieutenants (followers).
current known values. Fig. 3 shows the voting procedure The entire algorithm runs in three phases: pre-prepare,
in detail. prepare and commit phase.
• Like Paxos, the followers vote for one of the candidates • Pre-prepare Phase: The commander assigns a sequence
and based on the majority of votes, a leader is selected. number to the request submitted by a client and multicast
• Then in the next part, the elected leader will propose it to the network. Among other data, the request message
values which the followers will choose so that the system also contains the digital signature and message digest
can reach consensus. for verification. The lieutenants of the network confirm
The leader sends out heartbeats (signals) to all followers at the block by verifying the digital signature and message
regular intervals in order to maintain its authority. Compared digest.
with Paxos and PBFT, this algorithm has high efficiency and • Once the validating lieutenants accepts the pre-prepare
clarity. Hence it has been extensively employed in distributed message, they enter to the prepare phase by multicasting
[Link] algorithm realizes the same safety performance the message to the rest of the network. Once again the
as Paxos and is better suited in real life implementation and replicas (commander and lieutenants) verify the prepare
comprehension. As mentioned, Raft algorithm cannot support message before accepting them.
byzantine nodes and can stand up to failure of 50 % of nodes • The messages commits, when (2f ) prepare message from
. As in case of Permission-ed Blockchain, nodes are verified different backups matches with the corresponding pre-

912 2019 IEEE Region 10 Conference (TENCON 2019)

 TABLE II
C OMPARISON BASED ON C HARACTERISTICS .

Characteristics PoW PoS PoB Paxos Raft BFT and its

variants
Trust Model Un-trusted Un-trusted Un-trusted Semi-trusted Semi-trusted Semi-trusted
Blockchain Type Permission-less Both Both Permission-ed Permission-ed Permission-ed
Transaction Finality Probabilistic Probabilistic Probabilistic Immediate Immediate Immediate
Degree of Decentraliza- High(Entirely Decen- High High Low Low Low
tion tralized)
Scalability High High High Low Moderate Low
Compliance to Probabilistic Probabilistic Probabilistic Deterministic Deterministic Deterministic
Distributed Consensus
Properties
Reward Yes Yes Yes Mostly No Mostly No Mostly No
Network Realization Bitcoin,Ethereum Peercoin, Slimcoin Hyperldeger
808Coin Fabric, Byzcoin,
Tendermint

TABLE III
C OMPARISON BASED ON P ERFORMANCE .

Performance Attributes PoW PoS PoB Paxos Raft BFT and its variants
Crash fault tolerance 50% 50% 50% 50% 50% 33%
Byzantine fault
50% 50% 50% NA NA 33%
tolerance
Response Time 10 Minutes 1 Minute 1 Minute 1 second
Rate of Energy consumption High Better than PoW Better than PoW High High Moderate
Transaction Throughput Very Low Low Low Very High Very High Average
Transaction Latency Very High High High Very Low

prepare messages. Hence, the total (2f + 1) votes (one Hence, a detailed review of the existing consensus algorithms
from primary) from the non-faulty replica helps the sys- has been presented in the paper. In case of permission-
tem to reach to a consensus. Fig. 4 shows the interaction less systems, it is easy to achieve robust consensus among
process. large number of untrusted nodes using complex computations
PBFT based consensus algorithms, we need (3f + 1) number though transaction finality remains non-deterministic. On the
of replicas in order to reach to the consensus. It provides high contrary, permission-ed Blockchain provides high throughput
throughput, low latency and less energy usage in verifying in less time while sacrificing the degree of decentralization.
transactions as compared to PoW based consensus mechanism. R EFERENCES
It also provides privacy over the system by ensuring tamper
[1] S. Nakamoto et al., “Bitcoin: A peer-to-peer electronic cash system,”
proof message transmission. Authenticity of nodes is also 2008.
verified through signatures. Despite its promising advantages, [2] C. Shen and F. Pena-Mora, “Blockchain for citiesa systematic literature
there are some significant limitations to the PBFT consensus review,” IEEE Access, vol. 6, pp. 76 787–76 819, 2018.
[3] M. S. Ali, M. Vecchio, M. Pincheira, K. Dolui, F. Antonelli, and M. H.
algorithm. The overhead incurred by multicasting messages Rehmani, “Applications of Blockchains in the Internet of Things: A
again and again makes it difficult to scale beyond a fixed num- comprehensive survey,” IEEE Communications Surveys & Tutorials,
ber of replicas. PBFT is also susceptible to sybil attack. PBFT 2018.
[4] Q. He, N. Guan, M. Lv, and W. Yi, “On the consensus mechanisms of
has well adopted in consensus for Permissioned Blockchain blockchain/dlt for internet of things,” in 2018 IEEE 13th International
environments like Hyperledger, Tendermint Core, etc. Symposium on Industrial Embedded Systems (SIES). IEEE, 2018, pp.
1–10.
V. C OMPARATIVE A NALYSIS [5] C. Dwork and M. Naor, “Pricing via processing or combatting junk
mail,” in Proc. of the Annual International Cryptology Conference.
This Section presents a comparison of the different consen- Springer, pp. 139–147, 1992.
sus algorithms that we have discussed so far in this paper. [6] A. Back et al., “Hashcash-a denial of service counter-measure,” 2002.
[7] L. Lamport et al., “Paxos made simple,” ACM Sigact News, vol. 32,
Table 2 and Table 3 below present a detailed comparison no. 4, pp. 18–25, 2001.
between the above mentioned consensus algorithms in terms [8] D. Ongaro and J. Ousterhout, “In search of an understandable consensus
of characteristics and performance. algorithm,” in Proc. of the USENIX Annual Technical Conference (ATC),
pp. 305–319, 2014.
[9] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals prob-
VI. C ONCLUSION lem,” ACM Transactions on Programming Languages and Systems
(TOPLAS), vol. 4, no. 3, pp. 382–401, 1982.
With the evolution of ICT, the Blockchain technology has [10] M. Castro, B. Liskov et al., “Practical byzantine fault tolerance,” in
attracted interest from various dimensions. Consensus algo- OSDI, vol. 99, pp. 173–186, 1999.
rithm is the main technology of Blockchain, but on-going
research of the consensus algorithms is still in its initial stage.

2019 IEEE Region 10 Conference (TENCON 2019) 913

View publication stats