ArticlePDF Available

A Framework for Blockchain-Based Applications

Authors:

Abstract

Blockchains have recently generated explosive interest from both academia and industry, with many proposed applications. But descriptions of many these proposals are more visionary projections than realizable proposals, and even basic definitions are often missing. We define “blockchain” and “blockchain network”, and then discuss two very different, well known classes of blockchain networks: cryptocurrencies and Git repositories. We identify common primitive elements of both and use them to construct a framework for explicitly articulating what characterizes blockchain networks. The framework consists of a set of questions that every blockchain initiative should address at the very outset. It is intended to help one decide whether or not blockchain is an appropriate approach to a particular application, and if it is, to assist in its initial design stage.
A Framework for Blockchain-Based Applications
Ephraim Feig
IEEE Life Fellow
Abstract
Blockchains have recently generated explosive interest from both academia and industry,
with many proposed applications. But descriptions of many these proposals are more vision-
ary projections than realizable proposals, and even basic definitions are often missing. We define
“blockchain” and “blockchain network”, and then discuss two very dierent, well known classes
of blockchain networks: cryptocurrencies and Git repositories. We identify common primitive ele-
ments of both and use them to construct a framework for explicitly articulating what characterizes
blockchain networks. The framework consists of a set of questions that every blockchain initiative
should address at the very outset. It is intended to help one decide whether or not blockchain
is an appropriate approach to a particular application, and if it is, to assist in its initial design
stage.
1 Introduction
Blockchain has been heralded as “a foundational technology: It has the potential to create new
foundations for our economic and social systems”[1]. People claim that blockchain will streamline the
electronic health records process [2]; will “add greater visibility and eciency across the entire supply
chain to deliver higher value to your customers and trading relationships”[3]; will track ownership of
real estate [4]; may “disrupt the insurance industry and change the way we share data, process claims
and prevent fraud”[5]; “could revolutionize the Internet of Things” [6].
There are no explicit description of the blockchains in the cited applications. But the blockchains
of cryptocurrencies are well understood. As Satoshi Nakamoto writes [7], they are needed to enable
“electronic transactions without relying on trust.” A complete, immutable public record of transac-
tions is not a design goal in cryptocurrencies. Quite the contrary, cryptocurrency purists would prefer
no record at all, to strengthen identity-hiding. Nakamoto wrote that, as was well known already [8],
“To accomplish this without a trusted party, transactions must be publicly announced.” The public
ledger is the price to pay in order to enable cryptocurrency with integrity.
What exactly is the trust that Nakamoto was referring to in his paper? In an online forum [9]he
writes,“The root problem with conventional currency is all the trust that’s required to make it work.
The central bank must be trusted not to debase the currency, but the history of fiat currencies is full
of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but
they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them
with our privacy, trust them not to let identity thieves drain our accounts.”
The central bank and fiat currencies issues that Nakamoto bemoans pale in comparison to their
analogues in the cryptocurrency world. Anybody can create a cryptocurrency (there are over 1,500 of
them [10]) and even the most established ones will fork at the whims of their creators [11]. As for banks’
abuses, relative to total currency volume, they pale in comparison to Ponzi schemes by cryptocurrency
exchanges [12]. As for draining accounts, cryptocurrencies lose by a wide margin [13]. The concern
that we have to trust banks to hold and transfer funds is genuine, but mostly in cases where the
transfer is prohibited by some legal authority. The big advantage cryptocurrencies oer is identity-
hiding, and only to those who are able to cover their tracks [14]. To gain this advantage, Bitcoin needed
1
a blockchain with proof-of-work (PoW). The cost for this advantage today (3/1/2018) is estimated at
791 KWh of electricity consumed per transaction [15], slow batch-processing of transactions, plus the
loss of such standard payment services as fraud protection and loss recovery.
The enormous costs of operating the Bitcoin network are recognized, and new types cryptocurren-
cies are being deployed to deal with them. Those that use proof-of-stake (PoS) instead of PoW are
emerging [16], and Ethereum is expected to implement its version [17] in the near future. PoS adds an
escrow component to the network [18], bringing it a little closer to standard payment systems, while
still bypassing central authority. Blockchains for applications other than currencies go even further
in conforming to standard trust models. Permissioned-blockchains have been suggested for enterprise
applications, in which “participants need to obtain an invitation or permission to join. The access con-
trol mechanism could vary: existing participants could decide future entrants; a regulatory authority
could issue licenses for participation; or a consortium could make the decisions instead.”[19] Moving
even further from trust averse systems, we have private networks that are not only permissioned but
also restrict who can see the blockchain.
Git may be the most successful blockchain platform [20] and has been operational over a decade.
It is the most popular version control system. While it is used primarily for team development of
software, it can be used to maintain any set of text-based records. The software that powers Bitcoin is
developed on Git [21] as an open source project. Every branch of a Git repository is a blockchain with
commits as blocks. Peers are software developers, and they all should maintain the master branch of
the repository. Git is permission-based, and consensus is based on trust; there is no mining or proof-
of-anything. Git blockchains of open-source projects are visible to the public; private repositories
restrict who can see them.
Unlike Bitcoin, where forking is an inadvertent, uncommon event, with Git, branching is modus
operandi. Unlike Bitcoin, where forks are abandoned upon acceptance of a longest blockchain, in
Git, branches are frequently merged. And strikingly, unlike Bitcoin, where there is total aversion to
central authority, even though Git is a peer-to-peer system, Git projects are almost always used in
conjunction with some Git hosting service such as GitHub, Bitbucket, Perforce or CloudForge [22].
People disagree whether or not Git branches are blockchains [23, 24, 25, 26] because there have
been only few definitions proposed in this new field, and these have not been consistent. We like the
approach in [27], where the term “blockchain” refers to a data-structure, and the term ”blockchain
network” refers to how that data structure is deployed. We also want the definitions suciently
broad so as to include cryptocurrencies and Git branches, which operate in totally dierent trust
environments.
Definition: Ablockchain is a sequence of blocks of data in which each block, other than the first,
is cryptographically linked to its predecessor.
Cryptographic linking is well understood [28]. We are not specifying how the blocks are crypto-
graphically linked. Bitcoin linking is described in [29] and Git linking in [30].
Definition: Ablockchain network is a peer-to-peer network in which peers collaborate to achieve
a common goal by using a blockchain.
The Bitcoin system is a blockchain network. A Git repository is a blockchain network, with the
master branch as the blockchain used in collaboration. While Git peers often fork the blockchain
by creating new branches, they collaborate using the master branch and strive to merge their other
branches with it. In general, we do not insist that peers all maintain identical or complete blockchains,
or that the network maintain an immutable blockchain, though these may be the common goal in some
applications.
2
2 Background
Bitcoin and Git blockchains have a fundamental data structure in common- blocks connected by
cryptographic hashes- and a fundamental dierence- the presence or absence of proof-of-work (PoW).
Both cryptographic hashing and PoW have been studied a long time before the word blockchain was
introduced. It is instructive to see how they were deployed and then ask, why all of a sudden, the two
of them combined are generating so much enthusiasm?
The idea of chaining blocks of data together with cryptographic hashes has been around since the
late 1970’s. By 1982, when Ralph Merkle’s patent [31] was granted, cryptographic protocols were
already evolving [32]. The data structure named after him, the Merkle Tree, found utility in peer-to-
peer systems in which peers all needed to share identical data [33, 34]. Any change in the data would
be very quickly detected. In most cases, when a change is detected, there is recourse, the change can
be undone. Peers who want the change can accept it; peers who do not want the change, can undo
it. If peers cannot reach consensus, they can diverge along distinct paths.
The Bitcoin blockchain is a binary Merkle Tree in which every right branch contains only one
leaf, considered as a sequence from left to right. Every Bitcoin block stores transaction data as a
Merkle Tree. Therefore, any change is easily detectable. But a bitcoin transaction is irreversible, and
there is no remedy to a double spend. Therefore, to preserve Bitcoin’s integrity, Nakamoto had to
introduce PoW. Fortuitously, PoW also provided the mechanism for disseminating new bitcoins and
incentivizing peers.
PoW was introduced by C. Dwork and M. Naor in 1992 [35] to combat email spam. More generally,
PoW can be used to deter people from doing undesirable things by making them very expensive. PoW
was proposed to mitigate distributed denial-of-service attacks [36]. In 2003, PoW was proposed to
provide incentives in peer-to-peer systems [37]. The particular PoW used in Bitcoin is a variant of
Adam Back’s Hashcash [38], proposed in 1997, which requires finding a nonce that yields a hash with
some leading 0’s.
Until Bitcoin, PoW did not gain any significant traction. A study of its original proposed appli-
cation, spam prevention, concluded that PoW “does not work” [39]. With Bitcoin, things changed.
There were users who insisted on a payment system in which participants hide their identities, and
for them, the gains outweighed the costs.
3 Blockchain Network Dynamics
The blockchain networks of cryptocurrencies and Git are characterized by the following activities:
1. Developers create and deploy the network.
Once the network is deployed,
2. Users input data into the network
3. Peers propose blocks to add to the blockchain
4. Peers validate proposed blocks
5. Peers strive to reach consensus
They are also dierent in two fundamental ways:
6. Whether or not there are irreversible inputs
7. Whether or not the blockchain is immutable
And in all cases,
3
8. Peers are incentivized to perform
We see three types of participants: developers, users and peers. While developers play a critical
role, they are not part of the framework. The framework relates to the steady-state network once it
is operational.
With cryptocurrencies, peers are users but most users are not peers. Most users just input trans-
actions. When they receive payments, they have no interaction with the blockchain. The blockchain
being public, everybody can be a user by just looking at it. However, one cannot use the blockchain
to prove payment to a particular payee because one cannot force a payee to provide proof of received
payment. There is a whole class of users who analyze cryptocurrency blockchains to catch illegal
behavior such as money laundering and tax evasion. These include US departments DEA, FBI, ICE,
IRS and SEC [40].
In Git, users who enter data into the blockchain are also peers. They input snippets of code and
together they create and maintain some desired code. Git users who are peers do not hide their
identities, but quite the opposite, seek recognition for their contributions. Another set of users take
the code and deploy it.
In Bitcoin, after a peer succeeds a PoW, it will propose a block comprising a set of transactions,
the size limited by the Bitcoin protocol. The Bitcoin incentives are such that the peer will validate
the block before proposing it to the network. Almost always, even though all peers are working hard
on their proofs, only one gets to propose a block (in the rare case of a fork, two or more peers will
each propose a block) and the other peers will validate it. Immediately afterwards, the peers start all
over again, work on their proofs, and when a peer succeeds, it proposes a new block of transactions.
One can see the enormous costs here, as at every cycle, all the peers’ duplicate eorts are essentially
wasteful but necessary to maintain the integrity of the system.
In Git, a block is a commit, with data describing changes made to the code. These changes take
the form of additions to and deletions from the code. There are no size limitations to a commit.
Several peers may simultaneously submit blocks of code that they have been working on individually,
and all of these may be added to the blockchain.
In Bitcoin, validation involves a fixed, deterministic set of rules [41] and is accomplished auto-
matically, without human intervention. Peers validate that payers have sucient funds to cover their
payments, and to do so, they have to verify that the bitcoins used for payment are still in circulation.
As Nakamoto pointed out [7], “The only way to confirm the absence of a transaction is to be aware
of all transactions.” This is why a Bitcoin peer needs the entire blockchain.
In Git, validation is more nuanced and involves human activity. There are no fixed, deterministic
rules that specify validity for a block. When a new block is proposed to add to the master branch,
peers must check that it does not crash the code. In order to do that, they must have the entire code.
This is why a Git peer needs the entire master branch. Peers cannot guarantee that a block does
not crash the code; they can only say they tested it suciently and are comfortable with proceeding
forward; if a bug is later found, somebody will probably fix it. They may also validate that the
proposed code actually does what the user wrote in the message part of the commit that it should do,
and that what it does is desirable.
Consensus in Bitcoin is automatic. Peers choose the candidate blockchain of greatest height. The
Bitcoin protocol with its PoW guarantees that, as long as peers possessing a ma jority of the hash
power in the network validate truthfully, then asymptotically, the blockchain with greatest height will
be valid. Note that it is a majority of hash power in the network, not a ma jority of peers, that is
necessary for users to trust the Bitcoin network. If there is no consensus, the blockchain may fork
and peers may continue with either or both branches of the fork.
Consensus in Git is not automatic. Peers are structured with hierarchical authority. They may
know each other, converse with each other, and often defer to peers with the most significant contri-
butions. Git uses an interesting form of PoS; the stake includes a peer’s reputation, permission level,
and membership in the development team. As with Bitcoin, if no consensus is reached, the project
4
may fork and peers may continue as they choose.
Bitcoin transactions are irreversible. Once a payment is made, there is no recourse. With Git, if
a user commits a block with a subtle bug that the peers did not catch, somebody can fix that bug in
a later commit. This is not an uncommon Git event.
The Bitcoin blockchain is practically immutable. With Git, by design, one can rewrite history [42].
Cryptocurrency peers are incentivized with mining rewards and transaction fees. Git peers on
open-source projects are rewarded by getting the code they desire and by recognition. On closed
projects, peers are often salaried software developers.
4 The Framework
The framework is a set of questions that ask for specifics relating to blockchain network dynamics. It
should be used at the conceptual stage, before development, of a blockchain-based application.
1. Who are the users?
2. What data do users input?
3. Are any inputs irreversible?
4. Who are the peers?
5. How do peers create blocks?
6. What do peers validate?
7. How do peers validate?
8. How do peers reach consensus?
9. Is the blockchain immutable?
10. How are peers incentivized?
Who are the users? Do users have a task that current systems not handle well? Do they want
to do something that they could not have done without a blockchain? Are they primarily concerned
that their data is at risk? Are they anticipating reduced costs? What performance expectations, like
transaction latency, do they expect? Will users have access restrictions to the blockchain? Will there
be one blockchain for several classes of users or several blockchains, each for one class of users?
What data do users input? Do users enter blobs (large data sets) or transactional data
with pointers to blobs that are stored elsewhere? Will there be one blockchain for several types of
transactions or several blockchains, each for a particular type of transaction?
Are any inputs irreversible? For these, what are the potential liablilities?
Who are the peers? Who can become a peer? How many peers are necessary? What is a
desirable number of peers? Who are the initial peers? How much trust is there amongst the peers?
Will peers have access restrictions to the blockchain? Are some peers also peers in other blockchain
networks?
How do peers create blocks? How many transactions or contracts or whatever go into a block?
When are blocks formed? Do blocks have size limitations? Is the data in the blocks structured or
unstructured or both? Do peers have to process data before putting it in a block?
What do peers validate? Do peers validate that the data satisfies certain conditions aside from
5
syntactical constraints and/or proof-of-something? Is validation deterministic or do peers sometimes
have to make judgement calls?
How do peers validate? What information do peers need in order to validate? Do they need
the blockchain to be able to validate? Do they need the entire blockchain? Can peers communicate
with each other during validation?
How do peers reach consensus? What is the trust model? Can peers communicate with each
other during the consensus process?
Is the blockchain immutable? If so, what are the potential liabilities?
How are peers incentivized? Do peers compete for rewards? Do users compete to get peers to
service their inputs?
5 Discussion
People have recently become enamored with avoiding reliance on trust. More accurately, they think
they can create distributed networks of untrusting peers that are more trustworthy than individuals
or organizations. They think that complete histories of records, even personal ones, should be on
public display, with identities hidden. They want contractual or compliance obligations automatically
validated without third party intervention. They see blockchain as the driving technology enabling
all this.
As we have seen, the core technologies behind blockchain have been known for decades. Cryp-
tographic linking of data is used in peer-to-peer file sharing such as BitTorrent [43] and data and
software distribution [44]. They do not need proof-of-work because any tampering could be quickly
detected and dealt with. Things changed with Bitcoin, where double spending, even if detected im-
mediately, could not be undone. Bitcoin introduced a novel twist, combining cryptographic linking
with proof-of-work, and after percolating for several years, the concept is now generating tremendous
excitement.
Git shows that blockchains can be successful in environments of trust. It makes sense, then, not to
restrict the definition of blockchain to any particular trust model. Dierent trust models will lead to
dierent validation and consensus protocols. Open source projects that are hosted on GitHub provide
examples of trust-based consensus practices. For example, see the instructions to prospective peers
relating to consensus in Bitcoin Core [45]. Contrast that with the instruction to peers of the Git
platform software [46].
When designing a business application, one should ask, where in the application do fraud or
accidental errors happen? In many cases, they hardly ever happen to the data once it is stored, but
typically happen during data entry. In such cases, validation may require some level of trust. For
example, in supply-chain applications, if peers are not actually present when transactions occur (like
boxes loaded on a truck), how will they validate that data entered are true records of what happened?
Immutability, a requirement in almost all currently proposed blockchains, can be a liability. For ex-
ample, with a public blockchain, if a secret key is compromised, then all immutable records associated
with that key are permanently exposed. With standard systems, if a password is compromised, records
associated with that password are exposed until the password is changed. Relaxing the requirement
for immutability may be an appropriate choice for some blockchain-based applications.
Irreversibility, which is considered an advantage in certain applications, can also be a liability. With
Bitcoin, a payer cannot even use the blockchain to prove who is the payee. If a bitcoin owner loses a
private key, the coin associated with it is permanently lost. There is no equivalent to a password-reset
in Bitcoin. It is estimated that millions of bitcoins are already lost forever [47].
6
6 Conclusion
Blockchain-based applications other than cryptocurrencies and Git are at a very early stage, and there
is clearly enormous enthusiasm to explore and create them. We foresee a spectrum of trust models
evolving, and blockchain networks with validation and consensus protocols corresponding to them.
We defined blockchains and blockchain networks, expanding the usual definition by not requiring
immutability. We looked at two motivating examples with polar opposite trust models- Bitcoin and
Git. By considering their common properties, we created a framework to compel concreteness in
discussing proposed blockchain-based applications and to guide in their early design stages.
References
[1] https://hbr.org/2017/01/the-truth-about-blockchain
[2] https://www.wired.com/2017/02/moving-patient-data-messy-blockchain-help/
[3] https://www.ibm.com/blockchain/supply-chain/
[4] https://www.fastcompany.com/40449268/will-blockchain-revolutionize-global-real-estate-next
[5] https://www.fastcompany.com/40449268/will-blockchain-revolutionize-global-real-estate-next
[6] https://www.forbes.com/sites/delltechnologies/2017/06/27/how-blockchain-could-revolutionize-
the-internet-of-things/
[7] https://bitcoin.org/bitcoin.pdf
[8] W. Dai, b-money, http://www.weidai.com/bmoney.txt, 1998
[9] http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source
[10] https://coinmarketcap.com/
[11] http://fortune.com/2017/08/07/bitcoin-cash-bch-hard-fork-blockchain-usd-coinbase/
[12] https://www.theatlantic.com/technology/archive/2017/05/cryptocurrency-ponzi-schemes/
528624/
[13] https://www.benzinga.com/fintech/17/11/10824764/12-biggest-cryptocurrency-hacks-in-
history
[14] https://www.inc.com/will-yakowicz/startups-law-enforcement-agencies- catch-criminals-who-
use-cryptocurrency.html
[15] https://digiconomist.net/bitcoin-energy-consumption
[16] https://www.poslist.org/
[17] https://arxiv.org/pdf/1710.09437v2.pdf
[18] https://hackernoon.com/what-is-proof-of-stake-8e0433018256|
[19] https://www.ibm.com/blogs/blockchain/2017/05/the-dierence-between-public-and-private-
blockchain/
[20] https://octoverse.github.com/
[21] https://github.com/bitcoin/bitcoin
[22] https://www.git-tower.com/blog/git-hosting-services-compared/
7
[23] https://stackoverflow.com/questions/46192377/why-is-git- not-considered-a-block-chain
[24] https://news.ycombinator.com/item?id=9436847
[25] https://medium.com/@shemnon/is-a-git-repository-a-blockchain-35cb1cd2c491
[26] https://www.reddit.com/r/Bitcoin/comments/33s8x0/is git a block chain domus tower says
yes/
[27] W. Wang, et al, ”Decentralized Caching for Content Delivery Based on Blockchain: A Game
Theoretic Perspective”, https://arxiv.org/pdf/1801.07604.pdf
[28] https://en.wikipedia.org/wiki/Linked timestamping
[29] https://bitcoin.org/en/developer-reference#block-headers
[30] https://gist.github.com/masak/2415865
[31] Method of providing digital signatures, US Patent 4,309,569, Ralph C. Merkle, Filed 9/5/1979,
Granted 1/5/1982. https://patents.google.com/patent/US4309569
[32] Ralph C. Merkle: Protocols for Public Key Cryptosystems, IEEE Symp. on Security and Privacy,
4/14-16/1980, Oakland, CA. http://www.merkle.com/papers/Protocols.pdf
[33] https://en.wikipedia.org/wiki/Merkle tree
[34] https://brilliant.org/wiki/merkle-tree/
[35] C. Dwork and M. Naor: Pricing via Processing or Combatting Junk Mail. Advances in Cryptology
- CRYPTO’92, LNCS 740, Springer Verlag 1992, pp.139-147. http://www.wisdom.weizmann.ac.il/
naor/PAPERS/pvp.ps
[36] D. Mankins, R. Krishnan, C. Boyd, J. Zao and M. Frentz: Mitigating Distributed Denial of Service
Attacks with Dynamic Resource Pricing, Proc. of 17th Annual Computer Security Applications
Conference (ACSAS 2001), 2001.
[37] A. Serjantov and S. Lewis: Puzzles in P2P Systems, 8th Cab erNet Radicals Work- shop, Corsica,
Oct 2003. https://web.eecs.umich.edu/zmao/eecs589/papers/Serjantov04.pdf
[38] http://www.hashcash.org/papers/announce.txt
[39] https://www.cl.cam.ac.uk/rnc1/proofwork.pdf
[40] https://www.ethnews.com/six-us-government-agencies-hire-investigative-blockchain-firm-
chainalysis
[41] https://en.bitcoin.it/wiki/Protocol rules
[42] https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
[43] https://en.wikipedia.org/wiki/BitTorrent
[44] https://en.wikipedia.org/wiki/Code signing
[45] https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
[46] https://github.com/git/git/blob/master/Documentation/SubmittingPatches
[47] http://fortune.com/2017/11/25/lost-bitcoins/
8
... Blockchain concepts, functionality, present implementation, mining, cybersecurity, transaction protocols are discussed by many researchers such as Crosby et al. 2015, Feig, 2018, 2014, Zheng et al, 2017, Swan, 2015, Brakeville et al. 2016, Puthal et al. 2017, Hasan and Salah, 2018. BCT fundamentals, potential applications, and emergent DLT frameworks are addressed by Atkins, et al. (2013), Cong et al. 2018, Wang et al. 2018, Li, et al. 2018, Boyes et al. 2014, Andersen et al. 2017, Coyne et al. 2017. ...
... On the other hand, there are also downsides and risks associated with the standard BCT that can be ignored at this time. These limitations may involve (Crosby et al. 2015, Feig, 2018, 2014, Zheng et al, 2017, Swan, 2015, Brakeville et al. 2016, Puthal et al. 2017, Kshetri et al, 2017Hasan and Salah, 2018): ...
... Several authors have accentuated the data structure similarities between Git and DLT, and that it is possibly usable for some form of DLT-based version control, e.g., "blockchain can be seen as a Peer-to-Peer (P2P) hosted Git repository" [19]. Feature wise Git repository branches are blockchains according to the definition "A blockchain is a sequence of blocks of data in which each block, other than the first, is cryptographically linked to its predecessor" [20]. A blockchain network definition is "a Peer-to-Peer network in which peers collaborate to achieve a common goal by using a blockchain" [20]. ...
... Feature wise Git repository branches are blockchains according to the definition "A blockchain is a sequence of blocks of data in which each block, other than the first, is cryptographically linked to its predecessor" [20]. A blockchain network definition is "a Peer-to-Peer network in which peers collaborate to achieve a common goal by using a blockchain" [20]. According to this definition, a Git repository is a blockchain network, the Git repository peers are developers in a software development project, and the blockchain is the master branch. ...
Conference Paper
Full-text available
The number of installed Internet of Things (IoT) devices is growing rapidly and securing these IoT installations is an important task that may require technical knowledge that the owners of these devices do not always possess. Although experts have pointed out, that security should always be a priority when creating IoT products, the challenges are numerous and security solutions are not always targeted to decentralized or distributed architectures. In this paper, we explore the mechanisms for creating a method for a distributed IoT software update service that utilize distributed ledger technologies, such as Ethereum smart contracts and the InterPlanetary File System (IPFS). Our aim is to present a method that offers a more transparent version control of updates than current solutions, which are mostly conceptually centralized. We also aim to avoid relying on a central node for distributing updates and to create a fully secured and automated process for update management.
... Nodes agree on the inclusion of the next block information via consensus algorithms [26]. Its decentralized, persistent and immutable characteristics make blockchain suitable for the needs of automated systems in which interactions between multiple untrusted parties are recorded [10]. Such systems have long been primarily used for payments via cryptocurrency transactions, as their infrastructure allows for the storage and regulation of exchanges without the arbitration of external authoritative entities [19]. ...
Chapter
Full-text available
The automation of business processes via blockchain-based systems allows for trust, reliability and accountability of execution. The link that connects modules that operate within the on-chain sphere and the off-chain world is key as processes often involve the handling of physical entities and external services. The components that create that link are named oracles. Numerous studies on oracles and their implementations are arising in the literature. Nevertheless, their availability, integrity and trust could be undermined if centralized architectures are adopted, as taking over an oracle could produce the effect of a supply-chain attack on the whole system. Solutions are emerging that overcome this issue by turning the architecture underneath the oracles into a distributed one. In this paper, we investigate the design and application of oracles, distinguishing their adoption for the in-flow or out-flow of information and according to the initiator of the exchange (hence, pull- or push-based).
... This work examines the weakness of the ECDSA and its current vulnerability and uses in the Bitcoin Blockchain or Distributed Ledger Technology (DLT). Many industries are rapidly adopting versions or mutations of the first of the Bitcoin Blockchain technology in essential sectors such as information technology, financial services, government facilities, healthcare, and Public Health Sector seemingly, without cybersecurity due diligence, a proper comprehension of the cryptography vulnerabilities or plans for addressing quantum computing threats [2]. The ECDSA is the foundation of Public Key Infrastructure (PKI) for many Internet applications and open source projects, and it's the primary source for public-key cryptography. ...
Article
Full-text available
This paper evaluates the current cybersecurity vulnerability of the prolific use of Elliptical Curve Digital Signature Algorithm (ECDSA) cryptography in use by the Bitcoin Core, Ethereum, Bitcoin Cash, and enterprise blockchains such as Multi-Chain and Hyperledger projects Fabric, and Sawtooth Lake. These blockchains are being usedin media, health, finance, transportation and government with little understanding, acknowledgment of the risk and no known plans for mitigation and migration to safer public-key cryptography. The second aim is to evaluate ECDSA against the threat of Quantum Computing and propose the most practical National Institute of Standards and Technology (NIST) Post-Quantum Cryptography candidate algorithm lattice-based cryptography countermeasure that can be implemented near-term and provide a basis for a coordinated industry-wide lattice-based public-key implementation. Commercial quantum computing research and development is rapid and unpredictable, and it is difficult to predict the arrival of fault-tolerant quantum computing. The current state of covert and classified quantum computing research andadvancement is unknown and therefore, it would be a significant risk to blockchain and Internet technologies to delay or wait for the publication of draft standards. Since there are many hurdles Post-Quantum Cryptography (PQC) must overcome for standardisation, coordinated large-scale testing and evaluation should commence promptly.
Book
his book constitutes the proceedings of the Blockchain and RPA Forum, held as part of the 19th International Conference on Business Process Management, BPM 2021, which took place during September 6-10, 2021, in Rome, Italy. The Blockchain Forum and the RPA Forum have in common that they are centered around an emerging and exciting technology. The blockchain is a sophisticated distributed ledger technology, while RPA software allows for mimicking human, repetitive actions. Each of these have the potential to fundamentally change how business processes are being orchestrated and executed in practice. The 8 papers presented in this volume were carefully reviewed and selected from a total of 14 submissions.
Chapter
About a decade ago the fundamental operating principle of the Blockchain was introduced. It took several years before the technology gained widespread recognition in industry and academic communities outside of the computer science sphere. Since then many academic communities have taken up the topic, but so far no well-defined research agenda has emerged: research topics are scattered and rigorous approaches are scarce. More often than not, use cases implemented by industry apply a trial and error approach and there exists a dearth of theory-based academic papers on the topic following robust methodologies. Being a nascent research topic, case studies on Blockchain applications are a suitable approach to systematically transfer industry experience into research agendas which benefit both theory development and testing as well as design science research. In this paper I offer guidelines and suggestions on how to design and structure Blockchain case studies to create value for academia and the industry. More specifically, I describe Blockchain characteristics and challenges, present existing Blockchain case studies, and discuss various types of case study research and how they can be useful for industry and academic research. I conclude with a framework and a checklist for Blockchain case study research.
Article
Full-text available
Blockchain Technology (BCT) is a growing digital technology that in recent years has gained widespread traction in various industries in the public and private sectors. BCT is a decentralized ledger that records every transaction made in the network, known as a ‘block’, the body of which is comprised of encrypted data of the entire transaction history. BCT was introduced as the working mechanism that forms the operational basis of Bitcoin, the first digital cryptocurrency to gain mainstream appeal. The introduction of decentralized data exchange technology in any industry would require strengthened security, enforce accountability, and could potentially accelerate a shift in workflow dynamics from current centralized architectures to a decentralized, cooperative chain of command and affect a cultural and societal change by encouraging trust and transparency. BCT aims at creating a system that would offer a robust self-regulating, self-monitoring, and cyber-resilient data transaction operation, assuring the facilitation and protection of a truly efficient data exchange system. In the state of Florida, climate change and unpredicted weather disasters have put pressure on state and local decision-makers to adapt quick and efficient post-disaster recovery systems. Part of the recovery efforts is the reconstruction of buildings and infrastructure. The introduction of new technologies in the Architecture, Engineering, and Construction (AEC) industry can contribute to addressing recovery and rebuilding after the event of a natural disaster. With parallel technological advancement in geospatial data and Geographic Information System (GIS), as well as worsening climatic conditions, concerns can be suitably addressed by employing an integrated system of both Building Information Modeling (BIM) and BCT. While several potential applications of BIM must provide solutions to disaster-related issues, few have seen practical applications in recent years that indicate the potential benefits of such implementations. The feasibility of BIM-based applications still rests on the reliability of connectivity and cyber-security, indicating a strong use case for using BCT in conjunction with BIM for post-disaster recovery. This research depicts a survey of BCT and its applications in the Architecture, Engineering, and Construction (AEC) industries and examines the potential incorporation within the BIM process to address post-disaster rebuilding problems. Moreover, the study investigates the potential application of BCT in improving the framework for automating the building permitting process using Smart Contract (SC) technologies and Hyperledger Fabric (HLF), as well as discussing future research areas. The study proposes a new conceptualized framework resulting from the integration of BCT and BIM processes to improve the efficiency of building permit processes in post-disaster events.
Article
Full-text available
About a decade ago the fundamental operating principle of the Blockchain was introduced. It took several years before the technology gained widespread recognition in industry and academic communities outside of the computer science sphere. Since then many academic communities have taken up the topic, but so far no well-defined research agenda has emerged: research topics are scattered and rigorous approaches are scarce. More often than not, use cases implemented by industry apply a trial and error approach and there exists a dearth of theory-based academic papers on the topic following robust methodologies. Being a nascent research topic, case studies on Blockchain applications are a suitable approach to systematically transfer industry experience into research agendas which benefit both theory development and testing as well as design science research. In this paper I offer guidelines and suggestions on how to design and structure Blockchain case studies to create value for academia and the industry. More specifically, I describe Blockchain characteristics and challenges, present existing Blockchain case studies, and discuss various types of case study research and how they can be useful for industry and academic research. I conclude with a framework and a checklist for Blockchain case study research.
Conference Paper
Full-text available
This paper presents a proposal for developing secure social media spaces for groups of people that could be vulnerable to external influences. These could be refuges from war torn or politically unstable countries that could be persecuted by political opponents, or young children that could be targeted online by paedophiles and other online criminals. The system utilizes Block-Chaining technologies to provide the secure environment and Recommender Systems to link members to sub-groups based on their preferable discussion topics and ideas. There are challenges in the proposal as the key issue of trust in the system must be guaranteed by a third party. This organization will need to verify the identity of every subscriber and then create secure user identities / profiles that guarantee the anonymity of members. Block-chaining technologies will also allow the monitoring of user behaviour to ensure the trustworthiness of the environment is maintained. The cost of the system and its operation will be another consideration. The reputation of Block-Chaining technologies due to its links with crypto-currencies should not be considered a negative factor as there are many successful implementations in everyday life
Article
Full-text available
Blockchains enables tamper-proof, ordered logging for transactional data in a decentralized manner over open-access, overlay peer-to-peer networks. In this paper, we propose a decentralized framework of proactive caching in a hierarchical wireless network based on blockchains. We employ the blockchain-based smart contracts to construct an autonomous content caching market. In the market, the cache helpers are able to autonomously adapt their caching strategies according to the market statistics obtained from the blockchain, and the truthfulness of trustless nodes are financially enforced by smart contract terms. Further, we propose an incentive-compatible consensus mechanism based on proof-of-stake to financially encourage the cache helpers to stay active in service. We model the interaction between the cache helpers and the content providers as a Chinese restaurant game. Based on the theoretical analysis regarding the Nash equilibrium of the game, we propose a decentralized strategy-searching algorithm using sequential best response. The simulation results demonstrate both the efficiency and reliability of the proposed equilibrium searching algorithm.
Conference Paper
Full-text available
Distributed denial of service (DDoS) attacks exploit the acute imbalance between client and server workloads to cause devastation to the service providers. We propose a distributed gateway architecture and a payment protocol that imposes dynamically changing prices on network, server, and information resources in order to push some cost of initiating service requests - in terms of monetary payments and/or computational burdens back onto the requesting clients. By employing different price and purchase functions, the architecture can provide service quality differentiation and furthermore, select good client behavior and discriminate against adversarial behavior. If confirmed by additional experiments, judicious partitioning of resources using different pricing functions can improve overall service survivability.
https://www.cl.cam.ac.uk/ ⇠ rnc1/proofwork.pdf [40] https://www.ethnews.com/six-us-government-agencies-hire-investigative-blockchain-firmchainalysis [41] https://en.bitcoin.it/wiki/Protocol rules [42] https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History [43] https
  • A Serjantov
  • S Lewis
A. Serjantov and S. Lewis: Puzzles in P2P Systems, 8th Cab erNet Radicals Work-shop, Corsica, Oct 2003. https://web.eecs.umich.edu/ ⇠ zmao/eecs589/papers/Serjantov04.pdf [38] http://www.hashcash.org/papers/announce.txt [39] https://www.cl.cam.ac.uk/ ⇠ rnc1/proofwork.pdf [40] https://www.ethnews.com/six-us-government-agencies-hire-investigative-blockchain-firmchainalysis [41] https://en.bitcoin.it/wiki/Protocol rules [42] https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History [43] https://en.wikipedia.org/wiki/BitTorrent [44] https://en.wikipedia.org/wiki/Code signing [45] https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md [46] https://github.com/git/git/blob/master/Documentation/SubmittingPatches [47] http://fortune.com/2017/11/25/lost-bitcoins/
  • C Ralph
  • Merkle
Ralph C. Merkle: Protocols for Public Key Cryptosystems, IEEE Symp. on Security and Privacy, 4/14-16/1980, Oakland, CA. http://www.merkle.com/papers/Protocols.pdf