Conference PaperPDF Available

Abstract and Figures

Blockchains have been applied in different domains to guarantee data integrity and provide a decentralized computational infrastructure for executing smart contracts. Multiple blockchain-related patterns have been summarized by academics and industry practitioners covering different aspects, such as engineering applications on top of a blockchain, structuring smart contracts, and security. The existence of these patterns is both helpful and challenging for designers. Helpful, as the existence of these patterns means that developers do not need to recreate solutions to common problems. Challenging, as the multitude of patterns leaves a designer confused about when to adopt or adapt patterns. In this paper, we propose a decision model that assists developers and architects in selecting appropriate patterns for blockchain-based applications. The selection is based on the characteristics of the use cases and trade-offs implicit in the patterns. We evaluated the proposed decision model based on expert opinion regarding its correctness and usefulness in guiding the architecture design and understanding the rationale of various design decisions.
Content may be subject to copyright.
A Decision Model for Choosing Patterns in
Blockchain-Based Applications
Xiwei Xu
CSIRO Data61
University of New South Wales
Sydney, Australia
H.M.N. Dilum Bandara
CSIRO Data61
University of New South Wales
Sydney, Australia
Qinghua Lu
CSIRO Data61
University of New South Wales
Sydney, Australia
Ingo Weber
Chair of Software and Business Engineering
Technische Universitaet Berlin
Berlin, Germany
Len Bass
Institute for Software Research
Carnegie Mellon University
Pittsburgh, PA, USA
Liming Zhu
CSIRO Data61
University of New South Wales
Sydney, Australia
Abstract—Blockchains have been applied in different domains
to guarantee data integrity and provide a decentralized com-
putational infrastructure for executing smart contracts. Multiple
blockchain-related patterns have been summarized by academics
and industry practitioners covering different aspects, such as en-
gineering applications on top of a blockchain, structuring smart
contracts, and security. The existence of these patterns is both
helpful and challenging for designers. Helpful, as the existence
of these patterns means that developers do not need to recreate
solutions to common problems. Challenging, as the multitude
of patterns leaves a designer confused about when to adopt
or adapt patterns. In this paper, we propose a decision model
that assists developers and architects in selecting appropriate
patterns for blockchain-based applications. The selection is based
on the characteristics of the use cases and trade-offs implicit in
the patterns. We evaluated the proposed decision model based
on expert opinion regarding its correctness and usefulness in
guiding the architecture design and understanding the rationale
of various design decisions.
Index Terms—D.2.11.e Patterns, C.2.0.a Architecture
Blockchain is an immutable, transparent, and distributed
ledger hosted by a peer-to-peer network. It also provides a
neutral execution infrastructure for running programs, called
smart contracts. With its emergence in financial use cases,
blockchain has many financial sector applications, ranging
from trade finance to cross-border payments to securities.
Today, blockchains are penetrating almost all industries, and
use cases have been investigated in supply chains, electronic
health records, energy supply and trading, asset management,
and protecting critical civil infrastructure [1], [2]. Blockchains
have been used in software systems for purposes, such as
providing decentralized and trusted data storage [3], enabling
decentralized access control [4], and facilitating multi-party
coordination [5].
Blockchains provide unique properties from the soft-
ware architecture perspective, including immutability, non-
repudiation, data integrity, transparency, and equal rights.
However, the design of blockchain sacrifices confidentiality
and performance compared to conventional data storage so-
lutions. Therefore, to better leverage the positive properties
of blockchain technology while working around its limita-
tions, architectural guidance on blockchain-based application
design is needed. Both academia [6], [7], [8], [9], [10] and
industry1have documented reusable solutions for blockchain-
based application design in the form patterns. When building
blockchain-based applications using these patterns, we need
to systematically consider the forces and consequences of
the patterns, and how they evolve and interact. Selecting
and applying patterns, and possibly adapting them, requires
trade-off analysis. In practice, selecting patterns from pattern
collections is nontrivial due to the limited information pro-
vided about relationships among patterns – especially across
different publications. Moreover, the context of use cases and
technical constraints are essential, as some of the patterns
may not apply to specific blockchain or distributed ledger
technology designs.
This paper builds on previous work on patterns and presents
a set of decision models for guiding the selection of blockchain
patterns. The decision models present each pattern’s qual-
ity trade-offs and the relationship among patterns, which is
currently fragmented in separate pattern collections. Such an
overview of patterns across different publications can assist the
architects and designers to navigate from pattern to pattern
until a suitable combination of patterns that can meet the
design goals is found. Also, the information captured in the
decision models can be useful background knowledge, which
can help designers make rational decisions. We aim to provide
a method to structure the patterns to assist architects in the
blockchain-based application design, rather than providing an
exhaustive list of patterns or their overview. The proposed
decision models are created with extensibility in mind.
The remainder of the paper is organized as follows: In
Sec. II, we discuss the blockchain-based application design
process. The process used to derive and validate the deci-
sion models, a high-level overview of the proposed decision
models, and the notations are presented in Sec. III. Sec. IV
to VIII present five decision models for different aspects of
application design. The evaluation of the proposed decision
models is discussed in Sec. IX. Related work on blockchain-
related architectural patterns and decision models is presented
in Sec. XI. Concluding remarks are presented in Sec. XII.
Fig. 1 outlines an idealized design process for a blockchain-
based application. The boxes with bold labels represent the
design activities covered by the proposed decision models.
As with any software system, the process starts with the
requirement elicitation to collect requirements, and stakeholder
and domain concerns.
However, the unique design and specific properties of
blockchain render it useful in some use cases and limit its
applicability in others. Therefore, it is necessary to assess
the suitability of applying blockchain technology [11] against
the requirements and characteristics of the use case that it
is intended to be used for. Blockchains are more useful in
use cases that involve a range of participants, which may
even span across borders and jurisdictions. Moreover, as there
is no central entity that can engender trust across borders,
a blockchain can help to decentralize trust. Furthermore, a
blockchain provides a level playing field for all the participants
due to the disintermediation and equal rights in a multi-party
setting. A blockchain is also a preferred option when data
immutability and transparency are desired. For example, it
can enable traceability of goods in a supply chain to support
recall of products or detect and control fraud and substitution.
Blockchains with certain consensus mechanisms may not be
suitable for use cases requiring high performance or real-
time data processing. However, with different configurations
and deployments of a blockchain platform, smart contracts,
and other architectural patterns, blockchain can also be used
in use cases with sensitive, high-volume, and high-velocity
data or where the data should be updatable. Nevertheless, this
paper does not address assessing the suitability of applying
blockchain for a given application. Instead an interested reader
may refer to [11] or [12, Chapter 6].
Design Data
(Section IV)
(Section VII)
(Section VI)
(Section V)
Design Smart
(Section VIII)
Other Design
Fig. 1. Blockchain-based application design process.
Should a blockchain-based solution be required, the next
step is to decide what data to store on the blockchain (aka.,
on-chain) and keep off-chain. Such distinction in terms of data
management, performance, and security is needed because
blockchains typically have limited computational and data
storage capacity. A decision model to choose data management
patterns is presented in Sec. IV. Performance is an essential
software quality attribute. As the selection of patterns to store
data on-chain or off-chain is mainly driven by the performance
and security aspects, a decision model to choose performance-
related patterns is presented in Sec. V. Security is another
significant quality attribute, and the respective decision model
is presented in Sec. VI. The design process may also involve
other quality attributes that the proposed decision models do
not cover.
Many use cases require a blockchain to interact with the
real-world. For example, it is imperative to ascertain that the
data about goods and parties on a blockchain correctly reflects
the actual physical objects and their state in a supply chain.
This requires storing supply chain event data, such as handing
over goods from one party to another and bar code scanning,
as they occur. Therefore, blockchain-based solutions typically
send/receive data to/from off-chain components to extend the
capabilities of blockchain-based applications. The component
that connects blockchain with the external world is called an
oracle. A decision model to select interaction patterns with
oracles is presented in Sec. VII.
Smart contracts are (pieces of) programs deployed and ex-
ecuted on a blockchain. While many programming principles
and architectural patterns used in conventional software design
are also applicable to smart contracts, several characteristics
are unique to smart contracts and blockchain execution envi-
ronments. Therefore, a decision model to select smart contract
patterns is presented in Sec. VIII. There might be other design
activities, e.g., the ones that apply to applications built on top
of smart contracts. Such design activities are not covered in
the paper.
Designing data management, performance, and security
could be performed in parallel, as they are mostly independent,
whereas oracle design depends on data management design.
Also, smart contract design depends on all previous design
decisions, e.g., data push/pull behavior of an oracle. However,
these design steps can be applied in a different order that may
be better suited for a given design problem.
Decision models have been used in software architecture
and design to map the problem space and the solution
space [13]. The proposed decision models are aimed to provide
a decision flow for selecting among blockchain application
patterns with quality rationales. Accordingly, our solution
space consists of a set of blockchain application patterns that
describe a software system’s high-level structure and behavior
as the solution to multiple requirements [14].
A. Methodology
1) Model Creation: The decision models are created to map
elements in the problem space to the elements in the solution
space. Initially, the decision models were created based on the
categories proposed in [6]. The selection paths were identified
mainly based on the details provided in the “related patterns”
section of each pattern. Further, when we took a holistic view
of multiple pattern collections, we were able to identify new
selection paths among patterns based on our experience. The
quality impacts and trade-offs were derived from the “forces”
and “consequences” sections of the patterns. With a basic
structure of the decision models, other pattern collections
from [8], [7], [10], [15] were fitted into the initial decision
models to broaden the coverage of patterns. Most of the
patterns discussed in the related work (see Sec. XI) were also
covered. Further, we included two common practices in the
industry that are not yet formally summarized as patterns,
namely single authorization and embedded into other func-
tions. When a pattern paper did not follow a comprehensive
pattern template, we used our experience from several years
of blockchain research and application development to identify
the relationships among patterns.
2) Evaluation: We conducted a set of interviews with six
domain experts, including two researchers and one research
engineer from academia, and three practitioners from the
industry. Based on their feedback, we refined the decision
models with more precise explanations of the quality trade-
offs and definitions of the graphical notations. The majority
of the experts affirm the proposed decision models’ overall
usefulness in designing and evaluating the architecture design
of blockchain-based applications.
B. Decision Model Notation
Design Goal Pattern 1
Pattern 3
Pattern 4
+ NFP 5
- NFP 6
Pattern 2
+ NFP 1
- NFP 2
+ NFP 7
- NFP 8
+ NFP 3
- NFP 4
Fig. 2. Decision model notation.
Fig. 2 illustrates the notations used in the decision models.
We borrow the notation of gateways from the Business Process
Model and Notation (BPMN)2. Every decision model has a
high-level design goal represented by a grey box. A circle
denotes the start of the decision process. An inclusive gateway
may trigger more than one outgoing path. In contrast, an
exclusive gateway triggers only one of the outgoing paths.
Aparallel gateway triggers all the outgoing paths. Rounded
rectangles represent the patterns. A line with a double-headed
arrow between two patterns represents a “complements” rela-
tionship. Constraints of a pattern are represented by an octagon
attached to the pattern using a dashed arrow. The consequences
of applying a pattern are analyzed based on their impact on
the Non-Functional Properties (NFPs). A NFP that is enhanced
by the pattern is indicated with a plus sign (+). Conversely, a
minus sign (-) indicates a NFP that is negatively affected by
the pattern. We cover typical architecturally significant NFPs,
including performance, security, reliability, and modifiability.
We also consider data quality and unique blockchain proper-
ties, like transparency and accountability. However, the set is
not exhaustive, and NFPs relevant for a specific context may
be missing.
The patterns categorized under data management are further
divided into on-chain and off-chain data management. While
some of the on-chain computation using smart contracts is
analogous to data management using blockchain transactions,
we do not cover computation on a blockchain in this paper.
1) On-chain Data Management Decision Model: First, we
consider the design goal of separating on-chain and off-chain
data on the blockchain. Table I lists the patterns covered
by the on-chain data management decision model. Fig. 3
illustrates the proposed decision model for choosing both
on-chain data management and performance patterns. The
performance patterns included within the dashed rectangle are
discussed in Sec. V. While both groups of patterns are included
in the same figure to depict the decision flow in terms of
data size (illustrate by the exclusive gateway), the selection of
patterns can be performed parallelly.
Characteristics of the data to be managed by the blockchain
determine what patterns should be selected. If the data to
be stored surrogate asset ownership or identification, the
tokenization pattern could be used to create and manage
digital, authoritative records of assets on the blockchain. A
token can also be used to represent identity, which is mainly
used in security design. When it comes to asset ownership,
tokenization reduces the risk of handling high-value digital
and physical fungible and non-fungible assets. A legal process
in the physical world is required to make the ownership
transfer on blockchain an authoritative record. Blockchain
transactions ensure authorized creation, transfer, and trading
of tokens enhancing flexibility and cost-efficiency. However,
the asset represented by the token could be manipulated
outside the blockchain without recording the transaction on
the blockchain. This compromises data integrity.
If a token is no longer needed, we should mark it as
unspendable to avoid misuse, such as double-spending. For
example, a non-fungible token should be destroyed once it is
no longer needed, fungible tokens are destroyed to increase
the value of tokens by reducing the supply, and a token
should be destroyed on the source blockchain before it is
Name Summary
on-chain data [6]
Encrypt data before storing it on blockchain
genesis [7]
Set the state on the blockchain’s genesis block
Legal and smart
contract pair [6]
Bind a legal agreement and the corresponding
smart contract that codifies the legal agreement
Raw data on-chain Add every piece of raw data onto the blockchain
Tokenization [6] Use tokens on the blockchain to represent
transferable digital or physical assets and services
Token burning [7] Make states and smart contracts on blockchain
Goal: Deciding which data to store on-chain
Encrypt on-
chain data
Raw data on-
Token burning
Block size
token no longer needed
Hash on-chain Merkle-tree
root on chain
State channel
data is big
(data size > TX size )
surrogate for
or ownership
data is initial
world state
data is confidential
large number of data points
smart contract is used
store data
Data aggregation
+ flexibility
+ cost eciency
- integrity
+ integrity
+ transparency
- performance
- cost eciency
- flexibility
+ performance
+ cost eciency
+ privacy
- integrity
+ performance
- integrity
+ cost eciency
+ privacy
- performance
- integrity
+ integrity
+ cost eciency
- flexibility
+ confidentiality
- performance
+ consistency
+ accountability
Legal processes
for ownership
data is small
(data size < TX size )
proof of
aggregatable data
Legal and
smart contract
+ privacy
- integrity
large number of intermediate states
Fig. 3. Decision model for on-chain data management and performance.
swapped/migrated to the target blockchain. In such cases,
the token burning pattern could be applied to make tokens
or smart contracts unusable while ensuring consistency and
accountability. Token burning complements tokenization.
Decentralized Applications (DApps) are designed to use
a blockchain as a back-end server that runs business logic
using smart contracts and stores data as a key-value database.
However, the volume of data stored using a transaction is
constrained by the transaction (TX) size and block size of
the chosen blockchain platform. Similarly, in platforms such
as Ethereum, the computational complexity of a smart contract
is also bounded by transaction and block size. Therefore, the
applicability of on-chain patterns depends on the size of data
to be stored or computational complexity.
If the application data are small and not sensitive, storing
all data on the blockchain is feasible. In such cases, the raw
data on-chain pattern could be applied to store all application
data immutably and transparently on the blockchain. There are
different ways to store data on a blockchain, e.g., embedded
into a transaction, as a smart contract variable, or smart
contract log events. These options have different trade-offs,
including cost and flexibility [16]. Further, not only writing
arbitrary data to a blockchain is slow and expensive but also
less flexible. The constraint to this pattern is the transaction
size, as it is smaller than the block size.
If the application data needs to be set while initializing the
blockchain, the establish genesis pattern could be used to set
the state on the genesis block. For example, when launching
a new blockchain, the initial distribution of the native tokens
can be set using this pattern. However, the size of the data
included in the genesis block is limited by the block size.
This pattern complements raw data on-chain. While genesis
block can be created with no cost, flexibility is low as only
limited data types and size can be written into the block.
The blockchain data is accessible to all users on the
blockchain network as they have the same level of privileges.
If data are supposed to be accessible only to the transacting
participates (e.g., commercially sensitive), the encrypting on-
chain data pattern – which complements raw data on-chain
– could be applied to encrypt the data before adding to the
blockchain. We assume that the blockchain platform uses no
advanced cryptography, like Zero-knowledge proof. However,
as the encrypted data are stored immutably, they may be
subject to brute force decryption attacks in the future.
Legal and smart contract pair is a pattern that evolves from
the hash on-chain pattern discussed in Sec. V. This pattern
provides a bidirectional binding between a legal agreement and
the corresponding smart contract to provide an authoritative
source to the legal contract. The two-directional binding is
based on the hash of the legal agreement and the smart
contract’s immutable address; thus, making sure that the legal
agreement and smart contract have 1-to-1 mapping.
2) Off-chain Data Access Control Decision Model: As
the data stored on a blockchain is accessible to all users
on the blockchain network, one way to preserve privacy
is to keep sensitive data off-chain while providing access
to them using off-chain access control logic. The off-chain
components within a blockchain-based application could apply
conventional architectural patterns that fulfill the requirements
of the given use case. Here we consider an example set
of conventional data access control patterns presented in the
context of Self-Sovereign Identity (SSI) to constrain the access
to off-chain credentials [8]. Table II lists the patterns covered
by the off-chain data access control decision model, and Fig. 4
Name Summary
One-off access [8] Share a link that redirects to the content only
Selective content
generation [8]
Customize access to data according to the
requirement specified by the data owner
access [8]
Share a link that redirects to the data only within
the specified time window
illustrates the related decision model.
Typically, when storing off-chain data, a developer needs
to consider two types of constraints, namely content and
temporal constraints. If data access needs to be constrained
to enhance privacy, the selective content generation pattern
could be applied to generate a customized response based on
the access control rules to avoid leaking unnecessary data.
For example, in the context of SSI, a certificate issuer could
generate a customized credential based on the identity holder’s
specific requirement, such as to show the grade earned for a
module than exposing the entire transcript. Other conventional
access control patterns such as policy-based and token-based
access control could be included in this decision model to
complement the selective content generation pattern.
Selective content
One-o access
Goal: Accessing o-chain data
selective data
time limited data access
+ privacy
(data minimization)
+ privacy
+ privacy
one time data access
Snapshot of
Fig. 4. Decision model for off-chain data access control.
If the access to data needs to be time-constrained, the time-
constrained access pattern could be applied to enforce the
period of access to off-chain data. For example, in the SSI
context, a certificate holder could share a link to a verifier
that redirects to the credentials only within the defined period,
e.g., when applying to a job. The one-off access pattern could
be applied to allow only one-time access to the data. This
pattern can be generalized to provide access up to a predefined
number of times. One constraint of both temporal patterns is
that a malicious user may take a snapshot of the data/content
while accessing it and keep it longer.
The patterns covered in this section are designed to deal
with big data used in blockchain-based applications. From
Name Summary
on-chain [6]
Store hash of an arbitrarily large dataset (that may
not fit on to a blockchain transaction) on blockchain
Merkle tree root
on-chain [5]
Store multiple pieces of raw data off-chain,
calculate a Merkle tree based on those data, and
store the Merkle tree root on-chain
aggregation [7]
Aggregate a set of states into a single (or a few)
State channel [6] Settle micro-payments off-chain in a payment
channel. Record only the opening and final
settlement transaction on the blockchain.
the four Vs of big data, the blockchain performance patterns
mainly target high volume data (both a datum that is large and
massive collection of data). Table III lists the patterns covered
by the performance decision model. The graphical presentation
of the related decision model is shown previously in Fig. 3.
Depending on the data size or volume, patterns on different
layers could be considered. For example, if a datum is larger
than the transaction size, the hash on-chain pattern at the ap-
plication layer could be used to store a cryptographic represen-
tation of the data (e.g., hash value) on blockchain to prove its
off-chain existence. To further improve scalability and support
high data volume (where the existence of every piece of data
within a data collection needs to be verified), more complex
hash-based data structures such as a Merkle tree [5] can be
used with Merkle tree root on-chain pattern. This pattern
complements the hash on-chain pattern. Another pattern to
manage a large collection of data is state aggregation, which
aggregates a set of states into a single or small subset of states.
For example, in blockchain data swap/migration, the closing
balance of a set of accounts can be swapped/migrated rather
than the balance of individual accounts. However, this pattern
is constrained by the data type to be aggregated. State channel
only records the opening and final settlement transactions on
the blockchain while handling all intermediate transactions of
small monetary value off-chain in a payment channel. Because
the raw data is off-chain in these patterns, data can be changed
without authorization affecting the integrity.
Security is a cross-cutting concern that is applicable
throughout the application. Security patterns are applicable
at different layers ranging from blockchain infrastructure to
smart contract layers. We derived two decision models for
authentication and authorization.
A. Authentication Decision Model
Authentication in blockchains makes sure an identity or its
account is what it claims to be. An identity is defined as a set of
attributes related to an entity. Several authentication patterns
can be used to manage identities in blockchains. Table IV
lists the patterns covered by the authentication decision model
illustrated in Fig. 5. Only the on-chain patterns are discussed.
Name Summary
registry [8]
Maintain the bindings between an identifier and the
corresponding identity attributes using a registry
registration [8]
Register/use a separate identifier for each transacting
Update by
delegates [8]
Maintain a list of delegates that can help the user
recover a lost identity
Update by
Identifier Registry
Goal Authentication
requires a resolver when DID
is used
delegate can change identifier
interact with multiple parties
+ integrity
+ upgradability
+ interoperability
- privacy
+ privacy
+ recoverability
+ lost identity tolerance
+ recoverability
Fig. 5. Decision model for authentication.
An identifier is a unique persistent string that can uniquely
identify an entity. The mapping between identifiers and the
corresponding identity data attributes can be registered in an
identifier registry on the blockchain. Decentralized identifiers
(DIDs)3are a widely adopted standard in SSI projects. A DID
needs to be resolved when in use. Thus, maintaining a shared
registry of DIDs improves the system interoperability, as the
identifier registry can be used as the resolver for DIDs from
different blockchains. However, the use of a single identifier
for all the transactions from different applications may lead
to privacy issues, as the associated public key could be linked
to expose information about the user and his/her behavior.
Multiple registration complements the first pattern, where it
allows a user to have a separate identifier for each application
or role. Such a design can isolate interactions with one party
from another, minimizing the potential to link identities. The
multiple identifiers can be registered in the identifier registry.
Key loss or compromise is an issue when an identity has a
single public-private key pair to authenticate transactions from
the user. Conversely, update by delegates pattern allows an
identifier to be associated with a list of recovery delegates
that could manipulate the corresponding identity on behalf of
its owner. It also complements the first pattern. If the key is
lost, the user could update the identity with a new key pair
with the delegates’ approval.
B. Authorization Decision Model
Table V lists the patterns covered by the authorization
decision model. Fig. 6 is a graphical representation of the cor-
responding decision model. Smart contracts deployed on the
Name Summary
permission [6]
Restrict invocation of individual functions in the
smart contract to permissioned set of accounts
authorization [6]
Allow a subset of predefined addresses to sign
Off-chain secret
enabled dynamic
authorization [6]
Use a secret created off-chain to bind the
authority for a transaction dynamically
Use a predefined address to sign transactions
Fig. 6. Decision model for authorization.
blockchain are accessible to all participants of the blockchain
platform. Thus, a permission-less function can be triggered
by any user. The embedded permission pattern can be applied
to a smart contract to provide function-level authorization.
When a transaction invokes a smart contract function, the
caller’s authorization to execute the function is validated be-
fore executing the rest of the contract logic. For each function
invocation, several authorization patterns providing different
levels of flexibility and cost could be used. If only a single
authority (in the form of a blockchain account) is allowed to
authorize an activity, the single authorization pattern could be
used. Sometimes, we may also want to use m-of-n(mn)
multi-signatures to define the number of authorities required
to authorize a transaction. This is useful when more than one
authority is required to authorize an activity or when a subset
of authorities are unavailable at the time of authorization. In
such cases, the multiple authorization pattern provides more
flexibility by enabling a set of blockchain accounts to authorize
a function call. Although this pattern allows flexible binding
between the function call and authorities from a larger set
of blockchain accounts, all valid authorities still need to be
specified in the smart contract.
Name Summary
oracle [6]
Introduce external state into the blockchain
through a centralized oracle
oracle [6]
Introduce external state into the blockchain
through multiple independent oracles
History oracle [15] Provide historical states in addition to the latest
Pull-based inbound
oracle [17]
Let the on-chain component request the
off-chain state from an off-chain component
Pull-based outbound
oracle [17]
Let the off-chain component retrieve the
on-chain state from an on-chain component
Push-based inbound
oracle [17]
Let the off-chain component send the off-chain
state to an on-chain component
outbound oracle [17]
Let the off-chain component poll the on-chain
state from an on-chain component
Voting [6] Enable a group of blockchain users or oracles
to make a collective decision
When the authority to authorize an activity is not known in
advance, the off-chain secret enabled dynamic authorization
pattern could be used. The function call being authorized
is defined with a hash value of an off-chain secret such
as a random string. Whoever knows this off-chain secret
could then authorize the function call by revealing the secret
using a transaction. The smart contract can then compare the
predefined hash with the hash computed from the secret to
determine the authorization. One constraint of this pattern is
that the off-chain secret cannot be reused once revealed in a
transaction. As the off-chain secret could be used on different
blockchain platforms simultaneously, this pattern improves the
interoperability, e.g., atomic swap across blockchains. The
last three authorization patterns complement the first pattern.
Similar to before, other existing authorization patterns could
be applied to the context of blockchain-based applications,
e.g., delegated access control.
From the software architecture perspective, a blockchain
could be used as a component or connector within a large
software system. As discussed in Sec. II, blockchain-based
solutions typically need to send/receive data to/from off-chain
components. An oracle is used to bridge blockchain with the
external world. An oracle can be characterized along three
dimensions [6], [10]: the direction of the data flow, the initiator
of the data flow, and decentralization of the deployment. Thus,
the patterns in this category cover such dimensions of oracles.
Table VI lists the patterns covered by the decision model
shown in Fig. 7. This decision model could be skipped for
use cases that can operate purely on the transaction and global
state, e.g., cryptocurrencies.
When it comes to the oracle deployment options, a cen-
tralized oracle could be applied to collect the external state.
The centralized oracle introduces a trusted third-party into
Goal: Connect blockchain with external world
external system uses on-chain state
outbound oracle
outbound oracle
external system querys on-demand
external system keeps polling
Centralized Oracle
single data source
Inbound Oracle
Inbound Oracle
History Oracle
external system sends
state to blockchain
blockchain requests external state
is required
multiple data sources
need historical
+ performance
- availability
Single point of
+ availability
- performance
+ equality
+ data credibility
- performance
- cost eciency
+ consistency
- performance
+ transparency
- performance
+ performance
- transparency
+ flexibility
- performance
+ consistency
- performance
Fig. 7. Decision model for interaction with the external world.
the blockchain system to verify the external state. Such a
centralized oracle component becomes a single point of failure,
whose unavailability, failure, or compromise may prevent
blockchain from completing the transaction validation. To
overcome a single point of failure, a decentralized oracle
consisting of multiple external servers and independent data
sources could be used. In this case, the voting pattern could be
used with multiple decentralized oracles to reach consensus on
the external state. Thus, if the result reported by one oracle is
debatable, other oracles or anyone with a blockchain account
could propose a new answer and vote for the proposed result
until the consensus is achieved. For example, k-of-mthreshold
signature could be used by multiple oracles to sign on the same
value to be written on to the blockchain.
The direction of the data flow is typically the first factor
to consider. If the data flow from the external world to the
blockchain, an inbound oracle is used to transfer data from the
external world to the blockchain. Depending on the initiator
of the data flow, we can choose either the pull-based inbound
oracle or a push-based inbound oracle pattern.
When a smart contract requests an off-chain state/data, the
pull-based inbound oracle receives the request from the caller
smart contract, gathers the state from off-chain components,
and sends the state back to the caller using a transaction.
This process is transparent as it is implemented using smart
contracts that communicate via delegated calls. A pull-based
inbound oracle’s performance is constrained by the blockchain
Name Summary
registry [6]
Use a registry to store the mapping between
(contract identifier, version) and its address
Data contract [6] Store data in a separate smart contract
Embedded into
other functions
Embed accessorial functions into regular functions
that must be called to use the services
contract [6]
Use an on-chain template contract as a factory to
generate contract instances from the template
execution [6]
Offer a reward to the caller of a contract function
for invoking it
Proxy contract1Use a proxy smart contract to relay transactions to
the latest version of contract logic
network’s transaction rate and the time needed to collect
external data once the request is made to the oracle.
Apush-based inbound oracle uses off-chain components to
monitor external state/data changes and proactively injects any
updates into the blockchain. This enhances the performance as
the calling smart contract does not need to wait for the oracle
to collect data. However, because such a push-based inbound
oracle is not deployed on blockchain as a smart contract, the
data provision depends on off-chain components that do not
have the same level of security guarantees as to the blockchain.
If the use case needs to resolve temporal conflicts, the history
oracle pattern could be applied to complement push-based
inbound oracle to provide historical values of off-chain data.
In these patterns, how the data came into existence is invisible.
If the data flow from blockchain to the external world, an
outbound oracle can be used to transfer data from blockchain
to the external system. Similar to in-bound oracles, there
are push-based outbound oracles and pull-based outbound
oracles. The former keeps monitoring the blockchain for
relevant updates. For example, watching the events logged by
an Ethereum smart contract and subsequently triggering rele-
vant off-chain activities. Alternatively, a pull-based outbound
oracle query on-chain data on demand.
The structural design of a smart contract impacts its exe-
cution cost. On a public blockchain, the cost of deploying a
smart contract depends on the size of the smart contract(s).
Further, additional fees need to be paid to embed data on a
smart contract. Thus, the data storage fee is proportional to
the size of the smart contract and its state. Besides, different
structural designs of smart contracts may affect performance
because of computational complexity and the required number
of transactions to trigger relevant functions. Table VII lists
the patterns covered by the smart contract decision model
illustrated in Fig. 8. The coding patterns, such as the ones
in [9], are not covered in this paper.
The overall design goal of this decision model is to engineer
multiple smart contracts. Each smart contract could use differ-
ent combinations of patterns according to what it is expected
Goal: Engineering multiple smart contracts
invocation requires
external trigger
+ modifiability
+ name consistency
- cost eciency
+ security
+ performance
+ code consistency
- cost eciency Factory
need multiple contract instances
need a look-up table for multiple contracts
/ be able to upgrade
from the
Data Contract
+ modifiability
- cost eciency
separate data from logic
+ flexibility
- guaranteed execution Incentive
Embedded into
other functions
- flexibility
+ guaranteed execution
Proxy Contract
be able to upgrade / access control
+ modifiability
- cost eciency
separate out auxiliary and
regular functions
integrate auxiliary function with
regular function
Fig. 8. Decision model for multiple smart contracts.
to achieve. To maintain a central registry of all smart contracts
related to an application, an on-chain contract registry could be
used. Such a registry can maintain the mapping between user-
defined symbolic names and blockchain addresses of smart
contracts. The smart contract associated with a registered
symbolic name could be upgraded by deploying a new version
of the contract without breaking the dependencies with other
smart contracts. A factory contract could be used to generate
smart contract instances from a contract template already de-
ployed on the blockchain. These instances could be customized
versions of one or more standard smart contracts coded as a
template. Further, a contract registry can be used to record all
the contract instances generated by a contract factory. A proxy
contract enables upgradable smart contracts and access control
on contract invocation. All the contract invocation calls go
through the proxy, which redirects the transaction to the latest
version of the smart contract using a delegated call. Once a
new version of the smart contract is deployed, the proxy could
be updated to refer to the new contract.
The data contract pattern follows the software design princi-
ple of separating data from the business logic. A data contract
embeds data and provides function calls to perform CRUD
(Create, Read, Update, and Delete) operations on embedded
data via authorized transactions. Like most of the on-chain
patterns, the size of the data on-chain is restricted by the
transaction size. Data contract pattern increases the cost due to
the increased size of smart contract code and added complexity
in executing them.
Smart contracts are event-based programs that cannot ex-
ecute autonomously. A transaction or another smart contract
must trigger the state-changing functions defined in a smart
contract. We may also want to run auxiliary functions asyn-
chronously to perform tasks, such as automatic dividend pay-
outs and clean up of expired records. To trigger such auxiliary
functions, the incentive execution pattern could be used to
provide a reward to the caller of the smart contract function.
To further guarantee the execution of auxiliary functions, their
logic could be integrated into regular functions calls using the
embedded into other functions pattern.
We conducted a set of interviews to assess the correctness,
completeness, and usefulness of the proposed decision models.
We further evaluated how the decision models could be applied
in the blockchain-based application design process.
A. Interview Questions
For each decision model, we asked the following questions
from the domain experts:
Is the decision model easy to use?
Is the decision model correct?
Are any important patterns missing?
Does the information in the decision model sufficiently
support the design decisions?
Further, using the following set of questions, we obtained
feedback on the proposed decision models’ overall usefulness:
Are decision models useful to support decision-making
in the design and development of a blockchain-based
application? Why?
Are decision models useful in architectural evaluation?
Do decision models add additional value in architecture
design and evaluation, compared with pattern collections
like [8], [6], [7]? Why?
Do the decision models cover important aspects of a
blockchain-based application? Are any aspects missing?
What are your suggestions to enhance the suitability and
decision models or their application?
B. Key Findings
The overall feedback of five of the participants was positive,
while the sixth one was neutral. Following are the key findings
from the interviews:
1) Usefulness – Enable Guided and Structured Design: The
participants affirmed that the proposed decision models could
provide design guidance for architects and developers during
the design process. One participant used the analogy of a
guided tour to investigate relevant patterns. It was further noted
that the workflow and graphical illustrations bring structure
into the design process and ensure that critical patterns are
not missed. Compared with pattern collections, the partici-
pants thought the proposed decision models enhance value by
making the relationship among patterns explicit.
2) Usefulness – Architecture Evaluation and Documenta-
tion: Most participants thought the proposed decision models
are useful in architecture evaluation and documentation of
architecture design rationale, as the quality trade-offs can be
used to compare multiple design alternatives. Further, the
trade-offs provide the basis for justifying design decisions.
One participant noted that the property trade-offs make it hard
to compare patterns against a single property. In the future,
we plan to address this limitation by building an automated
tool for design support, allowing architects to select a set of
patterns based on design goals and desired NFPs.
3) Usefulness – Focus on Application Design Rather than
Infrastructure: Participants noted that the decision models
are more useful for application-level design, and do not
provide guidance on designing the blockchain infrastructure
or governance model.
4) Usefulness – Not Novice Friendly: One participant noted
that designers need to be familiar with the patterns before
using the decision models. We agree that pattern catalogs are
more suitable for learning patterns. In contrast, the decision
models are aimed to guide designers who understand the
patterns to design an application by combining a set of patterns
while considering their relationship and NFPs.
5) Completeness – Missing Patterns: While commenting
on the completeness of the decision models, participants
mentioned that blockchain deployment and configuration,
blockchain governance, and legal concerns are not covered.
While we admit this limitation, this work focuses on demon-
strating how decision models could be used to identify related
patterns for a subset of frequently occurring contexts. As such,
we postpone extending the scope to future work.
6) Correctness – Individual Decision Models: Most feed-
back on individual decision models were clarifications on how
patterns relate to each other and their NFP trade-offs. We have
integrated all the comments into the decision models presented
above. Some missing patterns suggested by the participants
were either industrial instances, e.g., ERC-20 and ERC-721
tokens in Ethereum, or detailed implementations, e.g., embed-
ding data into a transaction, as smart contract variables, or
as smart contract log events. We did not consider these to be
architectural patterns. There were also suggestions to consider
patterns that were not widely documented/accepted. For exam-
ple, one participant pointed out that the authentication model
could include off-chain KYC (Know Your Customer) patterns,
like the registration of users in cryptocurrency exchanges in
some countries.
7) Potential Improvements: Most of the participants sug-
gested implementing the proposed decision models as an
automated design tool. One participant suggested testing and
refining the decision models through real-world case studies.
We plan to extend our current pattern website4with such an
automated design tool, more patterns, and case studies.
The majority of the patterns included in decision models
could be used with both permissioned and permissionless
blockchains alike. However, a few patterns like state channel
and incentive execution and NFPs like cost-efficiency and
performance only apply to permissionless blockchains. We
excluded several patterns from collections that did not fit into
the five aspects of application design considered in this paper.
Further, several pattern collections, such as smart contract and
payment patterns, were excluded from scope due to resource
constraints. Thus, the number of decision models and patterns
included in them covers only a subset of the blockchain-based
application design space.
The interview participants were selected from the industry
and academia to redress the subjective bias in expert feed-
back. Although the evaluation is not extensive, the selected
participants are all experienced blockchain practitioners or
researchers active in the industry, academic community, and
relevant standard bodies. All participants had 2-5 years of
experience on multiple national-level blockchain projects.
The design models, a high-level description, and questions
were shared with the interviewees a week before the interview.
They were asked to note down the answers before the meet-
ing, where the answers and further feedback were obtained.
Further, each session was conducted by two interviewers,
and their observations were compared at the end of the
session. However, all participants were either direct or indirect
professional contacts of the researchers.
When a pattern collection did not follow a comprehensive
pattern template, we had to use our experience to identify
relationships among patterns. Also, we applied our expert
knowledge to identify new relationships and selection paths
among patterns. While this could affect the proposed decision
models’ reproducibility, it is a necessary trade-off we had to
make to bring structure into the decision model while pooling
patterns from multiple collections.
With the future addition of an automated decision tool to
our pattern website4and a discussion forum, we wish to ini-
tiate a dialogue with blockchain-based application designers;
uncover more patterns, relationships, and NFPs; and conduct a
thorough evaluation involving many independent practitioners.
Further, we plan to assess the effectiveness of design assistance
provided by the proposed models by observing designers
with limited experience in blockchains as they apply it to
design future projects or in a classroom setting. Through this
feedback, we plan to identify and refine gaps in the decision
models and their application.
To document the reusable solutions for blockchain-based
application design, blockchain patterns have been summa-
rized [6], [7], [8], [10], [18], [19]. Some of them are generic
and can be applied for general purposes [6], [10], [18], [19],
while others apply to specific use cases [7], [8]. There are
also design patterns for writing smart contracts from both
academia and industry1. The binary code of a smart contract
deployed on a public blockchain is publicly accessible, and
for many, the code is also open-source. Empirical analysis has
been conducted using smart contracts from different public
blockchain platforms to identify the common programming
patterns [20], [9], [21]. Some works also apply existing
patterns from conventional programming languages to smart
contract programming [22]. In practice, selecting patterns is
not easy due to the fragmented information provided about the
relationships among different patterns and the pattern collec-
tions they belong to. Conversely, the proposed decision models
can guide the selection of multiple blockchain patterns while
considering each pattern’s quality trade-offs and relationships
among patterns.
Architectural patterns are mostly expressed as informal text
with unstructured design reasoning. Decision models have
been applied in pattern-driven software architecture design
to model the problem and solution space, and assist devel-
opers/architects in selecting patterns from pattern collections.
A pattern selection approach that organizes NFPs in graphs
to provide guidance and reasoning support for designers to
select patterns is proposed in [23]. Another pattern selection
approach based on the desired quality attributes is intro-
duced in [24], which formalized the pattern relationships
and annotated them with the effects on quality attributes.
Then QOC (Questions, Options, and Criteria) was applied
to analyze further the consequences of design alternatives
with combinations of different patterns. A decision model
for cyber-foraging systems is presented in [13], which maps
functional and non-functional requirements to architectural
tactics for cyber-foraging. Each mapping is qualified with the
benefits and trade-offs of using each tactic to help designers
to understand the effect of their decisions. Pattern view is
introduced in [17], which adopted a graphical model to capture
patterns and their relations across pattern languages under a
particular problem context.
Many blockchain-related patterns have been summarized
by academics and industry practitioners where blockchain
is used as a trusted data storage, access control, and iden-
tity management platform. When building blockchain-based
applications using these patterns, we need to systematically
consider the forces and consequences of the patterns, and
how they evolve and interact. The proposed decision models
can assist developers and architects in selecting appropriate
patterns for blockchain-based applications. The selection is
based on the characteristics of the use cases and trade-offs im-
plicit in the patterns. The decision models were evaluated and
refined in terms of correctness, usefulness, and completeness
via expert opinions. As per the feedback, it was identified that
the proposed design model brings structure and rationale to
the decision process. We are currently expanding our pattern
website to include an automated decision tool based on the
proposed decision models, more patterns, and case studies.
We further plan to collect feedback through the website to
improve the decision models iteratively.
[1] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technical
survey on decentralized digital currencies,IEEE Communications Sur-
veys Tutorials, vol. 18, no. 3, pp. 2084–2123, 2016.
[2] A. Bratanova et al., “Blockchain 2030: A look at the future
of blockchain in Australia,” CSIRO Data61, Brisbane, Australia,
Tech. Rep., Apr. 2019. [Online]. Available:
insightsandpublications/reports-publications/blockchain- 2030.html
[3] S. Wilkinson, T. Boshevski, J. Brandoff, and V. Buterin, “Storj: A peer-
to-peer cloud storage network,” 2009.
[4] D. Di Francesco Maesa, P. Mori, and L. Ricci, “Blockchain based access
control,” in Distributed Applications and Interoperable Systems, 2017,
pp. 206–220.
[5] I. Weber, Q. Lu, A. B. Tran, A. Deshmukh, M. Gorski, and M. Strazds,
“A platform architecture for multi-tenant blockchain-based systems,” in
IEEE Intl. Conf. on Software Architecture (ICSA), 2019, pp. 101–110.
[6] X. Xu, C. Pautasso, L. Zhu, Q. Lu, and I. Weber, “A pattern collection
for blockchain-based applications,” in Proc. 23rd European Conf. on
Pattern Languages of Programs (EuroPLoP ’18), 2018, pp. 1 – 20.
[7] H. M. N. D. Bandara, X. Xu, and I. Weber, “Patterns for blockchain
data migration,” in Proc. 25th European Conf. on Pattern Languages of
Programs (EuroPLoP ’20), 2020.
[8] Y. Liu, Q. Lu, H.-Y. Paik, and X. Xu, “Design patterns for blockchain-
based self-sovereign identity,” in Proc. 25th European Conf. on Pattern
Languages of Programs (EuroPLoP ’20), 2020.
[9] M. Wöhrer and U. Zdun, “Design patterns for smart contracts in the
Ethereum ecosystem,” in 2018 IEEE Int. Conf. on Internet of Things
(iThings) and IEEE Green Computing and Communications (GreenCom)
and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE
Smart Data (SmartData), 2018, pp. 1513–1520.
[10] R. Mühlberger, S. Bachhofner, C. Di Ciccio, I. Weber, M. Wöhrer, and
U. Zdun, “Foundational oracle patterns: Connecting blockchain to the
off-chain world,” in Blockchain Forum of the Intl. Conf. on Business
Process Management (BPM), Sep. 2020.
[11] S. K. Lo, X. Xu, Y. K. Chiam, and Q. Lu, “Evaluating suitability
of applying blockchain,” in Intl. Conf. on Engineering of Complex
Computer Systems (ICECCS), 2017, pp. 158–161.
[12] X. Xu, I. Weber, and M. Staples, Architecture for blockchain applica-
tions. Springer, 2019.
[13] G. A. Lewis, P. Lago, and P. Avgeriou, “A decision model for cyber-
foraging systems,” in 2016 13th Working IEEE/IFIP Conf. on Software
Architecture (WICSA), 2016, pp. 51–60.
[14] N. B. Harrison and P. Avgeriou, “How do architecture patterns and
tactics interact? A model and annotation,” Journal of Systems and
Software, vol. 83, no. 10, pp. 1735 – 1758, 2010.
[15] J. Ladleif, I. Weber, and M. Weske, “External data monitoring using
oracles in blockchain-based process execution,” in Blockchain Forum of
the Intl. Conf. on Business Process Management (BPM), 2020.
[16] X. Xu et al., “A taxonomy of blockchain-based systems for architecture
design,” in 2017 IEEE Intl. Conf. on Software Architecture (ICSA).
IEEE, 2017, pp. 243–252.
[17] M. Weigold, J. Barzen, U. Breitenbücher, M. Falkenthal, F. Leymann,
and K. Wild, “Pattern views: Concept and tooling for interconnected
pattern languages,” arXiv preprint arXiv:2003.09127, 2020.
[18] J. Eberhardt and S. Tai, “On or off the blockchain? Insights on off-
chaining computation and data,” in Europ. Conf. on Service-Oriented
and Cloud Computing (ESOCC2017), 2017, pp. 3–15.
[19] F. Wessling and V. Gruhn, “Engineering software architectures of
blockchain-oriented applications,” in 2018 IEEE Intl. Conf. on Software
Architecture Companion (ICSA-C), Seattle, USA, Apr. 2018, pp. 45–46.
[20] M. Bartoletti and L. Pompianu, “An empirical analysis of smart con-
tracts: Platforms, applications, and design patterns,” Mar. 2017.
[21] M. Wöhrer and U. Zdun, “Smart contracts: Security patterns in the
Ethereum ecosystem and Solidity,” in Intl. Workshop on Blockchain
Oriented Software Engineering (IWBOSE), 2018, pp. 2–8.
[22] P. Zhang, J. White, D. C. Schmidt, and G. Lenz, “Applying software
patterns to address interoperability in blockchain-based healthcare apps,”
arXiv:1706.03700 [cs.CY], June 2017.
[23] D. Gross and E. Yu, “From non-functional requirements to design
through patterns,” Requirements Engineering, vol. 6, no. 1, pp. 18–36,
[24] U. Zdun, “Systematic pattern selection using pattern language grammars
and design space analysis,” Software: Practice and Experience, vol. 37,
no. 9, pp. 983–1016, 2007.
... uBaaS is a service platform that encapsulates patterns as services to generate code skeletons to facilitate the development of blockchain-based applications [13]. In [21], we proposed a decision model that assists developers and architects in selecting a set of patterns for blockchain-based applications. ...
... Third, when token release conditions are met by providing the desired product/server, the respective event is informed to the escrow smart contract. Finally, the escrow 21 validates the pre-defined conditions and releases the tokens to the seller. If the respective event is not informed to the escrow within the stipulated time or the event indicates that the product/service was not delivered as per the agreed terms, then the tokens are sent back to the buyer. ...
... The lifecycle along with the annotated patterns, provide a payment-focused systematic view of system interactions and a guide to the effective usage of the patterns in software architecture design. In future, we plan to extend our decision model to select blockchain-based patterns [21] to include payment patterns. ...
... We used our contacts to approach the microservices practitioners. We adapted the interview questions used in previous studies (e.g., [200] [198] ) to evaluate the decision models. The interviews ...
... The threats to conclusion validity affect the ability to reach correct conclusions. In order to mitigate this threat, we defined a research methodology based on the practices and guidelines used in recent studies (e.g., [200] , [198] , [199] ) to identify MSA patterns and strategies and to create and evaluate our decision models. Additionally, to ensure the reliability of our study, we have also made the Replication Package available [214] . ...
Full-text available
This thesis explored software architecture design of microservices systems in the context of DevOps and make the following novel aspects: (1) This thesis proposes a set of taxonomies of the research themes, problems, solutions, description methods, design patterns, quality attributes as well as the challenges of microservices architecture in DevOps that contributes to the software engineering body of knowledge by conducting state of the art (i.e., systematic mapping) and practice (i.e., mixed-method) studies on architecture design of microservices systems. These studies mainly identify, analyze, and classify the challenges and the solutions for microservices architecture in DevOps, design of microservices systems, as well as monitoring and testing of microservices systems. The findings of these studies can help practitioners to improve the design of microservices systems. (2) This thesis proposes a taxonomy of issues occurring in microservices systems by analyzing 1,345 issue discussions extracted from five open source microservices systems. The proposed taxonomy of issues consisting of 17 categories, 46 subcategories, and 138 types. This thesis also identified a comprehensive list of causes and mapped them to the identified issues. The identified causes consist of 7 categories, 26 subcategories, and 109 types. The proposed taxonomy and identified causes can help practitioners to avoid and address various types of issues in the architecture design of microservices systems. (3) This thesis proposes a set of decision models for selecting patterns and strategies in four MSA design areas: application decomposition into microservices, microservices security, microservices communication, and service discovery. The proposed decision models are based on the knowledge gained from the systematic mapping study, mixed-method study, exploratory study, and grey literature. The correctness and usefulness of the proposed decision models have been evaluated through semi-structured interviews with microservices practitioners. The proposed decision models can assist practitioners in selecting appropriate patterns and strategies for addressing the challenges related to the architecture design of microservices systems.
... Given that oracles are a niche area of investigation, they are not officially classified by type, and their characteristics have yet to be defined. A group of studies has been dedicated to investigating common patterns that emerge from oracle architectures, with the aim of classification and improvement [67][68][69][70][71]. Pasdar et al. [67] differentiated reputationbased and voting-based oracles, explaining how each design provides the answer to the smart contract. ...
... Specific examples are also made of blockchain applications, where data are pushed or pulled into the smart contract. Xu et al. and Mammadzada et al. built a framework to select the most appropriate oracle design (in terms of security and data management) according to different blockchain applications [32,69,71]. ...
Full-text available
Whereas the use of distributed ledger technologies has previously been limited to cryptocurrencies, other sectors—such as healthcare, supply chain, and finance—can now benefit from them because of bitcoin scripts and smart contracts. However, these applications rely on oracles to fetch data from the real world, which cannot reproduce the trustless environment provided by blockchain networks. Despite their crucial role, academic research on blockchain oracles is still in its infancy, with few contributions and a heterogeneous approach. This study undertakes a bibliometric analysis by highlighting institutions and authors that are actively contributing to the oracle literature. Investigating blockchain oracle research state of the art, research themes, research directions, and converging studies will also be highlighted to discuss, on the one hand, current advancements in the field and, on the other hand, areas that require more investigation. The results also show that although worldwide collaboration is still lacking, various authors and institutions have been working in similar directions.
... The problem space can be presented as a set of functional (FR) or non-functional requirements (NFR), whereas the solution space as a set of patterns targeting to solve the problems. We have adopted the decision model design methodology from [8] and [19], the adopted the notation method from [8] that involves the mapping of requirements and patterns, as shown in Fig. 1 [13]. An single-headed arrow from the pattern to the requirement indicates that the pattern satisfies the requirement. ...
... For instance, Grace et al. [8] proposed a decision model for cyber-foraging systems' architectural tactics. Xu et al. [19] propose a decision model for selecting appropriate patterns for blockchain-based applications. These researchers designed their decision models in extension to the series of patterns or tactics that they have previously published. ...
Federated learning is growing fast in both academia and industry to resolve data hungriness and privacy issues in machine learning. A federated learning system being widely distributed with different components and stakeholders requires software system design thinking. For instance, multiple patterns and tactics have been summarised by researchers that cover various aspects, from client management, training configuration, model deployment, etc. However, the multitude of patterns leaves the designers confused about when and which pattern to adopt or adapt. Therefore, in this paper, we present a set of decision models to assist designers and architects who have limited knowledge in federated learning, in selecting architectural patterns for federated learning architecture design. Each decision model maps functional and non-functional requirements of federated learning systems to a set of patterns. we also clarify the trade-offs that may be implicit in the patterns. We evaluated the decision model through a set of interviews with practitioners to assess the correctness and usefulness in guiding the architecture design process through various design decision options.
... Yet, it is also risky to publish specifically encrypted data on a blockchain: While conventional software and databases can regularly update their encryption algorithms to keep up with new developments and threat scenarios and also periodically re-encrypt it with a new, more secure algorithm, the immutability of a blockchain's ledger implies that historic encrypted data is exposed to all nodes without such modifications. Consequently, blockchains may pose a tempting target for future decryption attacks with brute force (Xu et al., 2021) or quantum computers (Lindsay, 2020). Even hashed identity information on a blockchain can be problematic, specifically if referred to repeatedly (Finck, 2018;Marx et al., 2018). ...
Full-text available
This position paper discusses the challenges of blockchain applications in businesses and the public sector related to an excessive degree of transparency. We first point out the types of sensitive data involved in different patterns of blockchain use cases. We then argue that the implications of blockchains’ information exposure caused by replicated transaction storage and execution go well beyond the often-mentioned conflicts with the GDPR’s “right to be forgotten” and may be more problematic than anticipated. In particular, we illustrate the trade-off between protecting sensitive information and increasing process efficiency through smart contracts. We also explore to which extent permissioned blockchains and novel applications of cryptographic technologies such as self-sovereign identities and zero-knowledge proofs can help overcome the transparency challenge and thus act as catalysts for blockchain adoption and diffusion in organizations.
... There are also empirical studies identifying the applied patterns from the perspective of blockchain ecosystem [27,28]. In our previous work, we illustrated general smart contract patterns [29], self-sovereign identity patterns [30], blockchain-based payment patterns [31], and also proposed a decision model which can assist developers and architects to select appropriate patterns for blockchain-based applications [32]. In regard to blockchain governance, many papers discuss how Bitcoin and Ethereum handled their risks, and emphasise the human coordination respecting the democracy spirit dwelling in the decentralised nature of blockchain. ...
Blockchain technology has been exploited to build next-generation applications with its decentralised nature. However, serious concerns are raised about the trustworthiness of the blockchain due to the virtue of the vulnerabilities in on-chain algorithmic mechanisms and tedious debates in the off-chain community. Accordingly, the governance of blockchain has received great attention recently to enhance the trustworthiness of all decisions directing a blockchain platform. This research domain is still immature, however, and there is a lack of systematic knowledge to guide the practitioners on how to design and implement governance methods for blockchain. Therefore, we have performed an SLR to understand the state-of-art in this topic, and extractd 14 governance patterns regarding the four layers (i.e., data, platform, application, and community) of blockchain ecosystem. To effectively use the discovered patterns, we demonstrate lifecycle stages of these four layers and involved stakeholders in blockchain ecosystem, as a guidance for effective use of the patterns, which has yet to be presented and introduced in existing works of this topic.
Blockchain Systems provide highly welcome properties such as immutability, observability, availability, and distribution for implementing smart contracts without the need for intermediaries. While the smart contract goals of observability and enforceability can easily be achieved on blockchains, the goal of privity is much harder to tackle. In the context of smart contracts on blockchains, privity aims in limiting the spread of knowledge to the participants with a contractual need-to-know. However, limiting access to data can limit the possible degrees of proactive enforcement of correct decisions and it can negatively impact their availability. Therefore, it can be required to find a proper balance between privity and enforceability or availability requirements. Designers may be forced to include additional participants (confidants) in the decision process only for the sake of enforceability or availability.In this paper, we introduce measures for assessing the impact of confidants for decisions within smart contracts on privacy. We model smart contracts in form of inter-organizational business processes and provide modeling constructs for privity requirements and the inclusion of confidants.KeywordsSmart contractsBlockchainConfidentialityPrivacyPrivityEnforceabilityDistributed oraclesMeasure
Robotic process automation (RPA) is a technology that is presented as a universal tool that solves major problems of modern businesses. It aims to reduce costs, improve quality and create customer value. However, the business reality differs from this aspiration. After interviews with managers, we found that implementation of robots does not always lead to the assumed effect and some robots are subsequently withdrawn from companies. In consequence, people take over robotized tasks to perform them manually again, and in practice, replace back robots—what we call ‘re-manualization’. Unfortunately, companies do not seem to be aware of this possibility until they experience it on their own, to the best of our knowledge, no previous research described or analysed this phenomenon so far. This lack of awareness, however, may pose risks and even be harmful for organizations. In this paper, we present an exploratory study. We used individual interviews, group discussions with managers experienced in RPA, and secondary data analysis to elaborate on the re-manualization phenomenon. As a result, we found four types of ‘cause and effect’ narrations that reflect reasons for this to occur: (1) overenthusiasm for RPA, (2) low awareness and fear of robots, (3) legal or supply change and (4) code faults.KeywordsRobotic process automationRPASoftware robotInvestmentInformation systemsWork manualization
The main aim of this paper is to present the results of a process-project maturity assessment of large organizations in Poland. The paper consists of two main parts: a theoretical part, which primarily outlines the rationale supporting the prospects and the need for an orientation towards process and project organizations, and an empirical part, presenting an attempt to integrate the MMPM and PMMM maturity models, in order to assess organizational level of process-project maturity. The empirical research carried out on a sample of 90 large organizations shows that vast majority of the organizations surveyed are characterized by low levels of process and project maturity, and 13 of the entities examined can be described, based on the assumptions adopted, as a process-project organization (level 4 of process-project maturity). Further, the research conducted has led to an outline of the factors supporting the recognition of process management as a method fundamental to the designing a process-project organization. Maturity model integration has demonstrated the levels of process and project maturity as well as a statistically positive correlation between the degree of process maturity and project maturity. The original character of this paper primarily concerns the need to fill the literature gap, consisting in the scarcity of publications describing integration of process and project management methods and the deficit of works presenting process-project maturity results.KeywordsProcess-project oriented organizationBPMProcess managementProject managementMaturity
Nowadays, blockchain systems are attracting attention in both academic and industry fields. Their main advantages are to their provided capabilities in security, and immutability. However, these systems are still immature growth, as there is a lack of templates for blockchain development. Interoperability can be considered one of the challenges while developing new blockchain systems, due to the heterogeneity of the blockchain systems infrastructure, consensus protocol, privacy level, etc. Although many organizations aim to utilize blockchain systems, they suffer from the limitations of running cross-organizational transactions over different blockchain systems. The current cross-organizational solutions depend on how to make a connection between the different organizations’ applications to reach choreography. In this paper, we will address the current interoperability challenges in blockchain systems and their impact on the running of cross-organizational transactions. Moreover, we will illustrate the usage of Model-Driven Engineering (MDE) to model the different aspects of blockchain systems. Finally, we will present an MDE-based solution to reach organizational interoperability as a basis for modeling hybrid applications that can process cross-organizational transactions.
Conference Paper
Full-text available
With the rapid evolution of technological, economic, and regulatory landscapes, contemporary blockchain platforms are all but certain to undergo major changes. Therefore, the applications that rely on them will eventually need to migrate from one blockchain instance to another to remain competitive and secure, as well as to enhance the business process, performance, cost efficiency, privacy, and regulatory compliance. However, the differences in data and smart contract representations, modes of hosting, transaction fees, as well as the need to preserve consistency, immutability, and data provenance introduce unique challenges over database migration. We first present a set of blockchain migration scenarios and data fidelity levels using an illustrative example.We then present a set of migration patterns to address those scenarios and the above data management challenges. Finally, we demonstrate how the effort, cost, and risk of migration could be minimized by choosing a suitable set of data migration patterns, data fidelity level, and proactive system design. Practical considerations and research challenges are also highlighted.
Conference Paper
Full-text available
Self-sovereign identity is a new identity management paradigm that allows entities to really have the ownership of their identity data and control their use without involving any intermediary. Blockchain is an enabling technology for building self-sovereign identity systems by providing a neutral and trustable storage and computing infrastructure, and can be viewed as a component of the systems. Both blockchain and self-sovereign identity are emerging technologies which could present a steep learning curve for architects. We collect and propose 12 design patterns for blockchain-based self-sovereign identity systems to help the architects understand and easily apply the concepts in system design. Based on the lifecycles of three main objects involved in self-sovereign identity, we categorise the patterns into three groups: key management patterns, decentralised identifier management patterns, and credential design patterns. The proposed patterns provide a systematic and holistic guide for architects to design the architecture of blockchain-based self-sovereign identity systems.
Full-text available
In blockchain-based process execution, operational aspects of business processes are encoded in smart contracts on blockchains, enabling powerful auditing and compliance capabilities due to the platforms’ trust and integrity guarantees. However, smart contracts are subject to the blockchain’s conceptual limitations, which particularly restrict the real-time integration of external data. This potentially leads to non-compliant runtime behavior of process instances when data updates are missed and conditional constraints are wrongly evaluated. In this paper, we analyze the semantics of established external data interaction patterns in business processes with regards to their support on blockchain platforms. We extend and propose various oracle-based implementation strategies to alleviate conceptual issues independent of the concrete blockchain used, and discuss their properties and merits.
Full-text available
Blockchain has evolved into a platform for decentralized applications, with beneficial properties like high integrity, transparency, and resilience against censorship and tampering. However, blockchains are closed-world systems which do not have access to external state. To overcome this limitation, oracles have been introduced in various forms and for different purposes. However so far common oracle best practices have not been dissected, classified, and studied in their fundamental aspects. In this paper, we address this gap by studying foundational blockchain oracle patterns in two foundational dimensions characterising the oracles: (i) the data flow direction, i.e., inbound and outbound data flow, from the viewpoint of the blockchain; and (ii) the initiator of the data flow, i.e., whether it is push or pull-based communication. We provide a structured description of the four patterns in detail, and discuss an implementation of these patterns based on use cases. On this basis we conduct a quantitative analysis, which results in the insight that the four different patterns are characterized by distinct performance and costs profiles.
Conference Paper
Full-text available
Blockchain has evolved into a platform for decentralized applications, with beneficial properties like high integrity, transparency, and resilience against censorship and tampering. However, blockchains are closed-world systems which do not have access to external state. To overcome this limitation, oracles have been introduced in various forms and for different purposes. However so far common oracle best practices have not been dissected, classified, and studied in their fundamental aspects. In this paper, we address this gap by studying foundational blockchain oracle patterns in two foundational dimensions characterising the oracles: (i) the data flow direction, i.e., inbound and outbound data flow, from the viewpoint of the blockchain; and (ii) the initiator of the data flow, i.e., whether it is push or pull-based communication. We provide a structured description of the four patterns in detail, and discuss an implementation of these patterns based on use cases. On this basis we conduct a quantitative analysis, which results in the insight that the four different patterns are characterized by distinct performance and costs profiles.
Conference Paper
Full-text available
In blockchain-based process execution, operational aspects of business processes are encoded in smart contracts on blockchains, enabling powerful auditing and compliance capabilities due to the platforms' trust and integrity guarantees. However, smart contracts are subject to the blockchain's conceptual limitations, which particularly restrict the real-time integration of external data. This potentially leads to non-compliant runtime behavior of process instances when data updates are missed and conditional constraints are wrongly evaluated. In this paper, we analyze the semantics of established external data interaction patterns in business processes with regards to their support on blockchain platforms. We extend and propose various oracle-based implementation strategies to alleviate conceptual issues independent of the concrete blockchain used, and discuss their properties and merits.
Technical Report
Full-text available
Trends and Scenarios for Blockchain Technology Uptake in Australia out to 2030
Patterns describe proven solutions for recurring problems. Typically, patterns in a particular domain are interrelated and can be organized in pattern languages. As real-world problems often require to combine patterns of multiple domains, different pattern languages have to be considered to address these problems. However, cross-domain knowledge about how patterns of different pattern languages relate to each other is mostly hidden in individual pattern descriptions or not documented at all. This makes it difficult to identify relevant patterns across pattern languages. To address this challenge, we introduce pattern views (i) to document the set of related patterns for a certain problem across pattern languages and (ii) to make this knowledge about combinable patterns available to others. To demonstrate the practical feasibility of pattern views, we integrated support for the concept into our pattern toolchain, the Pattern Atlas.
This book addresses what software architects and developers need to know in order to build applications based on blockchain technology, by offering an architectural view of software systems that make beneficial use of blockchains. It provides guidance on assessing the suitability of blockchain, on the roles blockchain can play in an architecture, on designing blockchain applications, and on assessing different architecture designs and tradeoffs. It also serves as a reference on blockchain design patterns and design analysis, and refers to practical examples of blockchain-based applications. The book is divided into four parts: Part I provides a general introduction to the topic and to existing blockchain platforms including Bitcoin, Ethereum, and Hyperledger Fabric, and offers examples of blockchain-based applications. Part II focuses on the functional aspects of software architecture, describing the main roles blockchain can play in an architecture, as well as its potential suitability and design process. It includes a catalogue of 15 design patterns and details how to use model-driven engineering to build blockchain-based applications. Part III covers the non-functional aspects of blockchain applications, which are cross-cutting concerns including cost, performance, security, and availability. Part IV then presents three detailed real-world use cases, offering additional insights from a practical perspective. An epilogue summarizes the book and speculates on the role blockchain and its applications can play in the future. This book focusses on the bigger picture for blockchain, covering the concepts and technical considerations in the design of blockchain-based applications. The use of mathematical formulas is limited to where they are critical. This book is primarily intended for developers, software architects and chief information officers who need to understand the basic technology, tools and methodologies to build blockchain applications. It also provides students and researchers new to this field an introduction to this hot topic.