![](bg6.png)
industry today. Part of its popularity lies in the fact
that companies and individuals began implementing
oracles as a distributed application i.e. the oracle
itself was built on a blockchain. This enables ora-
cles to be used in other industries for data validation
as well. ChainLink is one such company that has
quickly risen to fame (Ellis et al., 2017). It offers a
distributed solution to the external data access prob-
lem. The great thing about ChainLink is that it works
as an oracle verifier, as well as a reverse verifier, i.e.
it can validate data coming from a blockchain appli-
cation too. There are many projects like ChainLink
that create distributed oracles and such services are
used by other popular DApps. Chainlink itself, con-
nects DApps to external APIs and also provides sup-
port for blockchain transactions. It has partnered with
the likes of Google, Binance and other major players
in the DLT/Blockchain industry.
One DApp that uses Chainlink’s oracle services is
Loopring - an open protocol for building decentral-
ized exchanges. Despite the P2P and decentralized
nature of blockchains, most cryptographic assets to-
day are exchanged at centralised exchanges (like Bi-
nance, Bitmex, etc). When trading through these cen-
tralised exchanges, traders must transfer their assets
to a wallet provided by the exchange, and then the ex-
change will facilitate the trade. One problem here is
that after transferring your assets, you are no longer
in control of them - the exchange does not provide the
wallet’s private key to traders. During this interme-
diary period, you can’t control what happens to your
assets and Loopring identifies this as a single point
of failure. Their website lists around 40 hacks of ex-
changes and online marketplaces since 2013, each re-
sulting in a loss of tens of millions of dollars on av-
erage. All of this money ultimately belongs to traders
using the exchange. Loopring’s aim is to create non-
custodial, decentralised exchanges. To do this, they
use zero-knowledge proofs (ZKP). ZKP aims to allow
a user to prove they know a secret value, without dis-
closing the secret itself. In other words, a trader can
prove that he knows his private key without actually
disclosing it. This is an application of the commit-
and-reveal design pattern, where secret values are
hidden from unauthorized users and only the final so-
lutions are visible. Using this pattern, Loopring is try-
ing to make blockchains scalable and increase trans-
action throughput. Apart from commit-and-reveal,
Loopring uses an off-chain data storage in addition
to the Ethereum blockchain.
Another pattern that receives some attention
is the flyweight pattern. The DApp for Smart
Health (DASH) is a distributed application that
uses blockchain technology in the healthcare sector
(Zhang et al., 2018). Patient records and information
are stored on the blockchain. However, storing insur-
ance policies, coverage details and other patient infor-
mation requires a lot of storage which causes scalabil-
ity issues. Using the flyweight pattern, DASH stores
all policies separately and creates references to appro-
priate policies for each patient. Since the number of
insurance policies is a much smaller subset compared
to the number of patients, the flyweight pattern helps
to save a lot of storage space.
Coming to the giants in the blockchain space; the
Bitcoin community has been working hard on the
lightning network since 2016 with the first version
going live in early 2018. The Lightning Network is
defined as a Layer 2 protocol that functions on top
of a blockchain-enabled cryptocurrency like Bitcoin
(Poon and Dryja, 2015). The protocol is in its early
stages and is only available for public tests now. It
uses the state channel design pattern by enabling
micro-transaction networks to work at a higher layer
of abstraction than the payment protocol. Once a cer-
tain number of micro-transactions have been recorded
and settlement occurs, the final amounts are added
onto the blockchain. However, recent research sug-
gests that the micro-transaction network is highly
centralised (Lin et al., 2020). It has found ”hubs”
on the network that handle a majority of the micro-
transactions. Further, taking out one of these hubs
results in the network collapsing into several compo-
nents. This is undesirable as it can lead to splits in
the network, where two or more groups of validators
(validating micro-transactions) start working on sepa-
rate chains, leading to two or more competing chains.
This could destroy the network since each group is
likely playing by its own rules. It is worth noting here
that the main Bitcoin network too is controlled ma-
jorly by only 5 mining pools (companies).
Ethereum, on the other hand, quite successfully
uses some of the discussed patterns. Ethereum’s en-
vironment is designed as a state machine. The state
of the network includes the current state of each con-
tract as well as the amount of funds available at each
address. The state of a contract is defined by its inter-
nal variables and the funds available to it. This state
information is stored on an external database (Lev-
elDB and RocksDB) as a trie data structure
4
. The
root is hashed and stored with every new block on the
blockchain for hash integrity. Additionally, the exter-
nal database stores current as well as past state-tries of
the network, which enables the network to roll-back
the state if needed.
The off-chain data storage design pattern is wo-
4
A trie is like a binary tree except that each tree node
may have upto n child nodes
Emerging Design Patterns for Blockchain Applications
247