0% found this document useful (0 votes)
18 views

About POMA Consensus

Uploaded by

ritesh2407
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views

About POMA Consensus

Uploaded by

ritesh2407
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

About Proof of Match Adaptive (PoMA)

Introduction
The primary functionality of blockchains is to bring reliability to a trustless environment.
This is usually achieved with the help of a consensus mechanism. The consensus
mechanisms used in distributed ledger technologies in general and blockchains, in
particular, are different from those of centralized distributed systems like Hadoop and
Google Chubby[1]. Blockchain consensus mechanisms are typically decentralized,
enabling entities with disparate interests to come together and form a distributed
system.

Consensus Mechanisms in decentralized distributed systems involve the election of a


leader, or a set of leaders to perform a specific task. In the case of blockchains, the task
is to create a block at a given point in time. The identification of leaders must be quick,
fair to all the participants and robust against faults. Consensus mechanisms in
blockchains today, answer the fundamental question of who creates a block and when?.
This reduces the consensus problem in blockchains to that of a leader election problem,
where a block creator is elected among the set of nodes in the network. The
performance and the scalability of a distributed system depend significantly on its
consensus mechanism.

Trends and developments in the blockchain world


The major battle among the consensus mechanisms today is to improve the transaction
processing capabilities. The benchmark for most systems is VISA, which can process
24,000 transactions per second. Six months ago[2], Ripple claimed to have outdone
VISA by processing 48,000 transactions per second. There are newer blockchain
platforms like CREDITS[3] for example, that claim to process up to 488,403 transactions
(approximately half a million) per second. It is important to note that even if the peak
throughput is as high as 488,403 transactions per second, it doesn’t necessarily mean
that an individual transaction on an average, gets processed in real time. Assuming that
the turnaround time for a transaction is as low as 10 milliseconds, the network would
require an enormously large number of nodes in the order of tens of thousands, to
achieve such throughput consistently. Thus, it is easy to see that the turnaround time for
transactions is likely to be much higher.

On the other hand, there are blockchains like Zilliqa [4], that use Proof of Work as a
membership and a consensus criterion, and perform sharding of the network into non-
overlapping partitions. The consensus is achieved within a shard, whose minimum size
is required to be as high as 600 nodes. While Zilliqa is seen as a scalable blockchain
__________________________________________________________________________
Confidential- KrypC Technologies Pvt. Ltd 1
platform, a throughput of 2828[5] transactions per second is unimpressive, given a
network of more than 3600 nodes.

Design objectives for a decentralized distributed consensus protocol


Consensus mechanisms for most blockchains today
1. Are slow
2. Do not scale well with a large number of nodes
3. Are expensive for large networks

While all three may not be applicable to all blockchains, at least one of the above-
mentioned points hold true for every blockchain. Keeping that in mind, the following are
our design objectives for a new decentralized distributed consensus mechanism

● Fast (High throughput - number of leaders elected per second per node)
● Low turnaround time (very low latency - the time taken between a request for
leader election and the actual leader election)
● Simple and lightweight (minimal computational and communication resources -
targeted for constrained devices)
● Reasonably fault tolerant
● Scalable with increasing number of nodes

The Need for a new decentralized distributed system


We see new use cases emerge for Distributed ledger technologies with high data
volumes and velocities. One such use case involves real-time systems[6] comprising a
large number of constrained devices. Current DLT designs are inadequate for such
applications because they are inherently slow and demand more resources. As an
example, the Internet of Things ecosystem, for instance, could possibly scale to
thousands and millions of devices. A consensus mechanism should thus grow beyond
such limitations in computational and communication capabilities of devices. Hence,
there is a need for a decentralized distributed system that can scale easily with
increasing number of users and nodes, can process data in a real-time manner and is
lightweight enough to run in constrained devices like the Arduino or Intel Galileo
Microcontrollers. This would require a rethink of the fundamental design of such
systems, and the place to start is the consensus mechanism.

One of the factors influencing the design of consensus mechanisms is that, while
computational technologies have evolved significantly in performance over the past
several years, the performance of communication technologies haven’t scaled up
proportionally. Communication between devices often hit roadblocks like low speeds,
long latencies and unreliability (e.g. noisy wireless communication). Another issue is

__________________________________________________________________________
Confidential- KrypC Technologies Pvt. Ltd 2
that, divulging the addresses of devices could potentially lead to compromised security,
and efforts to mask those using mechanisms such as DNS, merely add to the
overheads without mitigating the risk.

This trend towards boosting the performance of blockchains, taking the limitations in the
computational and communication capabilities of the underlying devices into
consideration, can be seen in blockchains such as CREDITS[7], that extract the
maximum performance out of its performing nodes with the use of assembly language
programming in time and memory critical sections of their code.

KrypC has developed PoMA ground-up. PoMA is a fast, lightweight, scalable and
decentralized distributed consensus mechanism that helps identify a leader or a set of
leaders among the nodes for a specific task. The nature of this task could depend on
the underlying application. KrypC has treated the problem of high-speed consensus as
a problem in real-time computation, leveraging its experience in the semiconductor and
telecom industries.

Characteristics of PoMA
Unlike many blockchain consensus mechanisms such as Proof of Work [8], Proof of
Stake[9] or the Proof of Elapsed Time[10], PoMA is not tightly coupled to any distributed
ledger platform. It can be plugged into blockchains like Ethereum [11] or Quorum[12], or
can be used as a building block for a new distributed ledger system 1. The
characteristics of PoMA are

● Fast, Simple and Lightweight


● Latencies in the order of tens of milliseconds
● Very high throughput in the order of thousands of transaction per second per
node
● Quantum Resistance in leader selection
● No single point of failure
● Fair and decentralized
● Configurable trust model and tolerance levels

To achieve scalability in large networks in face of limited communication capabilities of


an individual device, our consensus mechanism partitions the network into overlapping
groups (slivers) using concepts from Galois Field in Classical Algebra. Leader election
performed within each sliver, instead of the entire large network, thereby exploiting the
concurrencies. This allows scaling up without compromising performance.

1
KrypC is developing a high speed Distributed Ledger system.
__________________________________________________________________________
Confidential- KrypC Technologies Pvt. Ltd 3
Fig: Performance and Resource Requirements for consensus mechanisms

References
[1] BURROWS , M. The Chubby lock service for loosely-coupled distributed systems. In Proc. of the 7th
OSDI(Nov. 2006).
[2] David Robledo, https://oracletimes.com/xrp-ripple-surpasses-visa-transaction-speed
[3] https://credits.com/Content/Docs/TechnicalWhitePaperCREDITSEng.pdf, Version 1.6/26 Nov 2017
[4] https://docs.zilliqa.com/whitepaper.pdf, Version 0.1/10 August 2017
[5] Nabeel Malik, https://hackernoon.com/zilliqa-a-game-changer-when-it-comes-to-blockchain-scalability-
4fb1c13b1b8a
[6] A. Stankovic. Misconceptions about real-time computing: a serious problem for next-generation
systems. Computer, 21(10):10–19, 1988.
[7] https://medium.com/@credits/why-is-credits-faster-than-other-blockchains-1555a5f3e995
[8] https://en.bitcoin.it/wiki/Proof_of_work
[9] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs
[10] https://www.hyperledger.org/wp-content/uploads/2018/01/Hyperledger_Sawtooth_WhitePaper.pdf
[11] https://github.com/ethereum/wiki/wiki/White-Paper
[12] https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf

__________________________________________________________________________
Confidential- KrypC Technologies Pvt. Ltd 4

You might also like