Slides for A Decision Model for Choosing Patterns in Blockchain-based Applications talk at Colombo Blockchain Meetup (June 2021) based on paper presented at 18th IEEE Int. Conf. on Software Architecture (ICSA 2021)

1. Australia’s National Science Agency
A Decision Model
for Choosing
Patterns in
Blockchain-based
Applications
CSIRO Data61
Xiwei Xu, Dilum
Bandara, Qinghua Lu,
Ingo Weber, Len Bass,
and Liming Zhu
18th IEEE Int. Conf. on Software
Architecture (ICSA 2021)

2. Blockchain Patterns
Data Management Patterns
Data Migration Patterns
Self-Sovereign Identity Patterns
Smart Contract Patterns
Security Patterns
Interacting with External World
Deployment Patterns
Payment Patterns
2 | Australia's National Science Agency
https://research.csiro.au/blockchainpatterns/

3. • Selecting a collection of patterns is
non-trivial
• Distinct pattern collections
• Lacks details on relationships among
patterns
• Fragmented trade-off analysis
• Can a decision model guide the
selection of blockchain patterns?
• Assists developers & architects in selecting
patterns for blockchain-based applications
• Pattern’s quality trade-offs
• Relationship among patterns
Motivation
3 |
EuroPLoP ’18, July 4–8, 2018, Irsee, Germany Xiwei Xu, Cesare Pautasso, Liming Zhu, Qinghua Lu, and Ingo Weber
2 PATTERN X: ORACLE
Summary: Introduce the state of external systems into the closed
blockchain execution environment through the oracle. Fig. 1 is a
graphical representation of the pattern with the external oracle
solution approach.
Context: From the softwarearchitectureperspective, blockchain
can beviewed asacomponent or connector within alarge software
system. In the case the blockchain is used as a distributed database
for moregeneral purposesother than nancial services, theapplica-
tionsbuilt on blockchain might need to interact with other external
systems. Thus, the validation of transactions on blockchain might
depend on states of external systems.
Problem: Theexecution environment of ablockchain isself-contained.
It can only access information present in the data and transactions
on the blockchain. Smart contracts running on blockchain are pure
functions by design. The state of external systems are not directly
accessible to smart contracts. Yet, function calls in smart contracts
sometimes need to access state of the external world.
How can function calls in smart contracts beenabled to access
the state of the external world from within smart contracts?
Forces: Theproblem requiresto balance the following forces:
• Closed environment. Blockchain is a secure, self-contained
environment, which isisolated from external systems. Smart
contractson blockchain cannot read thestatesof theexternal
systems.
• Connectivity. In addition to thedatafound on theblockchain,
general-purposeapplicationsmight requireinformation from
external systems, for example, context information like geo-
location information, or weather data from a Web API1.
• Long-term availability and validity. While transactions on
blockchain are immutable, the external state used to vali-
date a transaction may change or even disappear after the
transactions wereoriginally appended to the blockchain.
Solution: Toconnect theclosedexecution environment of blockchain
with the external world, a oracle is introduced to evaluate condi-
tions that cannot be expressed in a smart contract running within
the blockchain environment. A oracle is a trusted third party that
provides thesmart contracts with information about the external
world. When validation of a transaction depends on external state,
the oracle is requested to check the external state and to provide
the result to the validator (miner), which then takes the result pro-
vided by the oracle into account when validating the transaction.
The oracle can be implemented inside a blockchain network as a
smart contract with external state being injected into the oracle
periodically by an o -chain injector. Later, other smart contracts
can access the data from the oracle smart contract. A oracle can
be also implemented as a server outside the blockchain. Such an
external oracle needs the permission to sign transactions using its
own key pair on-demand. Extra mechanisms might be needed to
improvetrustworthiness of the oracle, for example, a distributed
oracle based on multiple servers and M-of-N multiple signature.
Through using oracle, thevalidation of transactions isbased on the
authentication of the oracle, rather than the external state.
1https://openweathermap.org/api
On-chain Off-chain
Blockchain
Oracle
Other components in system
Oracle
Injector
Validation
result
Figure 1: Oracle Pattern
Consequences:
Bene ts:
• Connectivity.Theclosedexecution environment of blockchain
is ĂIJconnectedĂİ with external world through the oracle.
The applications based on blockchain can access external
states through the oracle and use the external states to vali-
date transactions.
Drawbacks:
• Trust. Using oracle introduces a trusted third party into the
system. Theoracle selected to verify theexternal stateneeds
to be trusted by all the participants involved in relevant
transactions.
• Validity. The external states injected into the transactions
can not be fully validated by miners. Thus, when miners
validate the transaction including external state, they rely
on the oracle to check the validity of the information from
external world. Long-term availability and validity. It could
happen that while transactions are immutable, the external
stateused to validatethem may changeafter thetransactions
wereoriginally appended to the blockchain.
Related patterns: ReverseOracle(Section [Y])
Known uses:
• Oracle in Bitcoin is an instance of this pattern 2. Oracle
is a server outside the Bitcoin blockchain network, which
can evaluate user-de ned expressions based on the external
state.
• Orisi3 on Bitcoin maintains a set of independent oracles.
Orisi allowsthe participants involved in a transaction to se-
lect aset of oraclesand de nethevalueof M beforeinitiating
aconditional transaction.
• Gnosis4 is a decentralized prediction market that allows
users to choose any oracle they trust, such asanother user
or a web service, e.g. , for weather forecasts.
2https://en.bitcoin.it/wiki/Contract#Example_4:_Using_external_state
3http://orisi.org/
4https://gnosis.pm/
Australia's National Science Agency

4. 4 |
Blockchain-Based Application Design
Australia's National Science Agency

5. 5 |
Approach
Create Decision
Models
• 5 design aspects
• Identified selection
paths based on
related patterns
• Derived quality
impacts & trade-offs
from forces &
consequences
Evaluate
• Correctness,
completeness, &
usefulness
• Interviewed 6 domain
experts
• 3 from industry
• 3 from academia
• 2-5 years
experience in
multiple projects
Refine Models
• More precise
explanations of
quality trade-offs
• Included/excluded a
few patterns
• Improved definition
of graphical notation
Australia's National Science Agency

6. 6 |
Decision Model Notation
Australia's National Science Agency

7. 7 |
Data Management
– On-chain
• Main quality measures
• Integrity
• Consistency
• Transparency
• Performance
• Cost efficiency
Australia's National Science Agency

8. 8 |
Performance
• Main quality measures
• Integrity
• Transparency
• Performance
• Cost efficiency
Australia's National Science Agency

9. 9 |
Data Management –
Off-chain
• Main quality measures
• Privacy
• Flexibility
Australia's National Science Agency

10. 10 |
Security – Authentication
• Main quality measures
• Integrity
• Transparency
• Upgradability
• Interoperability
• Privacy
• Recoverability
Australia's National Science Agency

11. 11 |
Security – Authorization
• Main quality measures
• Security
• Flexibility
• Lost key tolerance
• Interoperability
Australia's National Science Agency

12. 12 |
Oracle
• Main quality measures
• Performance
• Availability
• Data credibility
• Cost efficiency
• Transparency
Australia's National Science Agency

13. 13 |
Smart Contract
• Main quality measures
• Performance
• Security
• Cost efficiency
• Modifiability
• Consistency
Australia's National Science Agency

14. Interview Results
14 |
Overall feedback: 5/6 positive, 1/6 neutral
Usefulness
+ Guided tour for pattern investigation
+ Graphical illustrations bring
structure into the design process
+ Useful for understanding rationale of
design decisions, evaluation, &
documentation
- Not novice friendly
- Difficult to compare against a single
NFP
Completeness
+ Focus on application design
- Missing patterns
• Deployment, Configuration,
Governance, Legal concerns
Improvement
• Automated design tool
• Real-world case studies
Australia's National Science Agency

15. Summary
15 |
• Contribution
• Decision models that assist developers &
architects in selecting patterns for
blockchain-based applications
• Future work
• On-line decision tool
• Collect feedback through pattern website
to improve decision models iteratively
https://research.csiro.au/blockchainpatterns/
Australia's National Science Agency

16. Australia’s National Science Agency
Dilum.Bandara
@ieee.org
linkedin.com/in/dilumb/