Keynote at the BRAINS conference -- Blockchain Application Design and Development: From Architecture to Analytics

Title: Blockchain Application Design and Development: From Architecture to Analytics

Abstract: Blockchain has emerged as a decentralized platform for managing digital assets and executing ‘smart contracts’, i.e., user-defined programs. On this basis, decentralized applications (Dapps) can be developed and executed.

In this keynote talk, I will provide an overview of what architects and developers need to know in order to build blockchain-based applications, and how it relates to software services. Among others, I will cover architectural concerns and model-driven engineering for blockchain applications, particularly in relation to collaborative business processes. Additionally, I will explore analytics methods for Dapp data, including process mining. This approach offers insights into blockchain-based systems’ behavior and performance, enabling the understanding and optimization of processes and Dapps and user behavior.

Conference:
6th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS)
October 09-11, 2024

1. Blockchain Application Design and Development:
From Architecture to Analytics
BRAINSKeynote, Oct. 2024
Prof. Dr. Ingo Weber
[email protected]
http://imweber.de/
Full professor at TUM and
Director IT infrastructure & digital transformation
at Fraunhofer

2. Agenda
•Engineering Dapps
−Architecture
−Development
•Model-driven Engineering for
Dapps
•Analytics for Dapp data with
process mining
•Further Reflection

3. Agenda
•Engineering Dapps
−Architecture
−Development
•Model-driven Engineering for
Dapps
•Analytics for Dapp data with
process mining
•Further Reflection

4. XiweiXu, Ingo Weber, Mark Staples.
Architecture for Blockchain Applications.
Springer, 2019.
http://dx.doi.org/10.1007/978-3-030-03035-3
→accessible from many university networks
Book website incl. ppt slides of a corresponding course:
https://ingo-weber.github.io/blockchain-architecture/
Blockchain book
4

5. Smart contracts
−Programs deployed as data and executed in transactions on the blockchain
−Blockchain can be a computational platform (more than a simple distributed database)
−Code is deterministic and immutable once deployed
−Can invoke other smart contracts
−Can hold and transfer digital assets
Decentralized applications or dapps
−Main functionality is implemented through smart contracts
−Backend is executed in a decentralized environment
−Frontend can be hosted as a web site on a centralized server
−Interact with its backend through an API
−Could use decentralized data storage such as IPFS
Decentralised Applications and Smart Contracts
5

6. Many interesting applications for Blockchain
•Basically of interest in most lack-of-trust settings where a distributed application can
coordinate multiple parties
•Examples:
−Supply chains
−Handling of titles, e.g., land, water, vehicles
−Identity
•Many startups and initiatives from enterprises / governments
... but also many challenges
•When to use blockchain
•Trade-offs in architecture
−Downsides: cost, latency, confidentiality
−What to handle on-chain, what off-chain?
Overview
8 |

7. Blockchain as…
Functions blockchain can provide in an
application architecture
9
Architectural
Element
Communi-
cation
Mechanism
Asset
Management
and Control
Mechanism
Storage
Element
Computational
Element

8. Blockchains are Not Stand-Alone Systems
10 |
UI for humans
IoT
integration
Auxiliary
databases
Legacy
systems
Key
management
private
data
BIG DATA
Blockchain is a component

9. Compared to conventional database & script engines,
blockchains have:
(-) Confidentiality, Privacy
(+) Integrity, Non-repudiation
(+ read/ - write) Availability
(-) Modifiability
(-) Throughput / Scalability / Big Data
(+ read/ - write) Latency
Non-Functional Trade-Offs
11 |
Security: combination
of CIA properties

10. Design process
12 |
“Do you have a
blockchain problem?”

11. Evaluation of Suitability
13 |

12. Architecting applications on Blockchain:
•Book
•Taxonomy and design process
•“Cost of Distrust”: how much more expensive is blockchain?
−On some blockchains, cost and throuhgput are tightly linked
•Availability analysis from viewpoint of dapps
•Latency: simulation under changes
•Multi-tenant applications on blockchain
Model-driven development of smart contracts
•Business process execution (including the tools Caterpillar and Lorikeet)
•Model-based generation of code for data structures, non-fungible and fungible tokens, and UI components
•Data extraction and analytics, e.g. Process Mining on blockchain data
Blockchain Patterns – reusable experience & inspiration
•https://research.csiro.au/blockchainpatterns/
…
Work with my former and current teams
14 |

13. Pattern Collection (Chapter 7, Blockchain book)
Interaction with
External World
Centralized
Oracle
Decentralized
Oracle
Voting
Legal and
Smart
Contract Pair
Reverse
Oracle
Data
Management
Off-chain
Data Storage
State
Channel
Encrypting
On-chain
Data
Tokenisation
Security
Dynamic
Authorization
Multiple
Authorization
X-
confirmation
Security
Deposit
Contract
Structural
Patterns
Contract
Registry
Embedded
Permission
Data
Contract
Factory
Contract
Incentive
Execution
Deployment
Semi-dapp
dapp
Mixed on and
off-chain
Purely on-
chain

14. On-chainOff-chain
Blockchain
Registry
Contract
Contract1
name --> addr
name --> addr
name --> addr
Contract2
Contract3
Contract3’
X Solution
•On-chain registry contract maintains a mapping
between user-defined names and contract addresses
•Registry contract address is publicized off-chain
•Invoker retrieves the latest version from registry
−Or registry forwards call to the latest version contract
•Upgrade contract by replacing the old contract
address with new contract address in the registry
Pattern 14: Contract Registry
21

15. Solution
•Data store is isolated from the rest of the code
−Avoid moving data during upgrades of smart contracts
•Strict definition or a loosely typed flat store
−Depends on data store size and change frequency
•More generic and flexible data structure can be used
by other contracts
−Less likely to require changes
Pattern 15: Data Contract
22

16. Agenda
•Engineering Dapps
−Architecture
−Development
•Model-driven Engineering for
Dapps
•Analytics for Dapp data with
process mining
•Further Reflection

17. Analogy: Java program
•Smart contract code: a class
•Deployed contract: an object
Many software design patterns still apply, e.g., Factory
•Code is deterministic, i.e., same state/inputs result in the same state changes/outputs
−However, state may not be deterministic from viewpoint of the caller (e.g. block number)
Why can smart contract execution be trustworthy?
•A contract is deployed as data in a transaction and thus immutable
•All their inputs are through transactions and the current state
•Their code is deterministic
•The results of transactions (including function calls) are captured in the state and receipt
trees, which are part of the consensus
−If other nodes get a different result, they would reject a proposed block
Smart Contracts in general
25

18. Code is immutable!
Consequences:
•Follow all security best practices
•Test heavily
•Do code reviews
•Build in features for updating as needed and acceptable for the user base
−Governance for updates, e.g.: updates will become active only after 1 week / 1 month, …
•Understand all (relevant) parts of the blockchain system – if you get it wrong, there is
no safety net
•Design includes potentially hard trade-offs between confidentiality and transparency,
though patterns exist for resolving parts of those
General remarks about developing smart contracts

19. Keep an eye on “cost”, even on private networks
•Cost reflects effort, and that impacts all blockchain networks
•Tamper-proof, immutable, lasting storage tends to be most expensive
→ Space-efficient encoding of variables helps
Blockchain ensures integrity of data and
computation, but not data quality
One approach for data from
outside objects: check
digital-physical parity*
•Example: food traceability
* Sin Kuang Lo, Xiwei Xu, Chen Wang, Ingo Weber,
Paul Rimba, Qinghua Lu, and Mark Staples.
Digital-physical parity for food fraud detection.
In ICBC'19: International Conference on Blockchain,
San Diego, CA, USA, June 2019.
Some General Observations
29

20. Keep an eye on “cost”, even on private networks
•Cost reflects effort, and that impacts all blockchain networks
•Tamper-proof, immutable, lasting storage tends to be most expensive
→ Space-efficient encoding of variables helps
Blockchain ensures integrity of data and
computation, but not data quality
One approach for data from
outside objects: check
digital-physical parity*
•Example: food traceability
* Sin Kuang Lo, Xiwei Xu, Chen Wang, Ingo Weber,
Paul Rimba, Qinghua Lu, and Mark Staples.
Digital-physical parity for food fraud detection.
In ICBC'19: International Conference on Blockchain,
San Diego, CA, USA, June 2019.
Some General Observations
30
X

21. Agenda
•Engineering Dapps
−Architecture
−Development
•Model-driven Engineering for
Dapps
•Analytics for Dapp data with
process mining
•Further Reflection

22. Model-driven engineering (MDE):
•A methodology for using models at various levels of abstraction and for different purposes during software
development
•Low-level models: production code can be directly derived from the models
•High-level models: means of communication between business owners and developers implementing a
system
•Intermediate levels can support model-based system analysis or system management tools
•Any level: generate a code skeleton or early version of the code
•Can cover static structures (like data models) or dynamic behavior (activity sequences)
Advantages in the blockchain context:
•Code generation can implement best practices and well-tested building blocks
−Code can adhere to blockchain “standards” (like ERC-20, ERC-721, …)
•Models can be independent of specific blockchain technologies or platforms
•Models are often easier to understand than code – particularly useful in communicating with business
partners about smart contracts
−Facilitates building trust
Model-driven Engineering & Blockchain
32

23. Integration of business processes across organizations: a
key driver of productivity gains
Collaborative process execution
•Doable when there is trust – supply chains can be tightly
integrated
•Problematic when involved organizations have a lack of trust in
each other
→ if 3+ parties should collaborate, where to execute the process
that ties them together?
−Can any participant be trusted with operating an authoritative database?
Cross-organizational processes: by now a common use
case for blockchain applications
MDE for Business Processes on Blockchain – Motivation
33

24. Motivation: example for collaborative business
process
34
Issues:
-Knowing the
status, tracking
correct
execution
-Handling
payments
-Resolving
conflicts

25. Goal: execute collaborative business processes as smart
contracts on blockchain
−Translate (enriched) BPMN process models to smart contract code
→ Model-driven engineering (MDE)
−Triggers act as bridge between Enterprise world and blockchain
−Smart contract provides:
−Independent, global process monitoring
−Process enforcement: messages are only accepted if they are expected, given the
state of the process, and only if sent from the participant playing the respective role
−Automatic payments & escrow
−Data transformation
Original Approach (BPM 2016) in a Nutshell
35

26. Extensions from the base approach
46
Optimized execution:
Process reduction based on
Petri Net representation,
space-optimized encoding
using bit vectors
MDE for smart contract-based
process implementation:
Lorikeet
BPMS execution
engine on blockchain:
Caterpillar
Transparency vs.
confidentiality: not all-or-
nothing
- Off-chain storage + ABE:
Attribute-Based Encryption
- Layer 2 / Process Channels
Dynamic role assignment:
- Policies specify who gets to
propose changes, who votes
on proposals and quora
Controlled flexibility:
- Changes to process
implementations, e.g.,
replacing subprocesses
- Policies as per above
Combining process and
data/token models
Code generation vs.
interpretation
and different modelling styles

27. Combining process and data/token models
47
Generated code implements
secure methods for payment,
escrow of money and assets,
asset swaps, etc.

28. SLR & Taxonomy: process execution on blockchain
48

29. 51
Execution cost of a single
process instance execution at
the date of publication and in
early 2023. Excluding initial
deployment and configuration
cost. Not meant to compare
cost-effectiveness of
approaches.
Cost on Public Ethereum
in early 2023

30. Tooling: Lorikeet at Design Time
56

31. Approach:
•Model data structure (variables, types) –not for fungible tokens
•Model relationships to other types / tokens
•Select features
→Code is generated –deploy or customize
Feature examples:
•Fungible tokens:
−Can be minted? Burnt? By whom?
•Non-fungible tokens
−Include standard method(s) for sale
−One contract for all tokens or one per token?
Code generated is compliant with standards
→interface syntax and semantics
MDE for data structures and tokens
57

32. Agenda
•Engineering Dapps
−Architecture
−Development
•Model-driven Engineering for
Dapps
•Analytics for Dapp data with
process mining
•Further Reflection

33. Process mining can be used to understand how users / clients and software interact
•Also for blockchain applications
But: understanding log data from blockchain is hard
•Example: which timestamp to use for a given transaction?
Our approach: develop tools (BlockXES / ELF / BLF) to extract
data from blockchain applications, a.o. for process mining
•Can be used on any blockchain application, designed with or without process-awareness
•ELF adds logging capability
•BLF extends the scope to make the tool blockchain-independent; plugins for Ethereum and
Hyperledger Fabric implemented, more to come
Process Mining / Analytics
62

34. ELF Overview
63
For data analytics
Standard log files
For process mining

35. Augur is a prediction and betting marketplace on public Ethereum BC
•Example market: “Will Donald Trump win the presidential election 2020?”
We looked at ~2700 markets (~22k events) created on Augur v1.0
One discovered process model (unfiltered):
Process Mining analyses we performed:
•Exploration
•Process Discovery
•Conformance Checking
Augur case study [9]
64
Dispute
handling
Creation
Trading
Initial
report
Settlement

36. 65
Timing patterns

37. Conformance checking means comparing a normative model against event logs
To obtain the normative model, we relied on the Augur white paper, their UI and
further explanations, but filtered activities such that the model only used events
present in the log
We also verified and contextualized our findings by interviewing Augur’s lead
architect
One conformance checking result:
Augur case study [9] continued
66
This is a bug in the smart contracts!

38. Forsage: a “matrix-based” investment scheme
67

39. Second case: Forsage
68

40. What is Forsage?
69

41. Data: 13.4 M events in 1.06 M traces
Marketing claim: regardless of when you enter, you can always profit
→ Not true, and about 90% of users* made a loss (*simplifying assumption: 1:1 match of users to accounts)
→ 3 of 4 claims debunked through our case study
Second case study: Forsage
70

42. Shed light on application dynamics and money flow
•Forsage is a Ponzi scheme
The Forsage documentation does not reflect code execution in detail, Augur contained a bug
•We unveiled this through conformance checking and drill-downs
•Forsage: not transparent
Compare behaviour of users, e.g. successful and unsuccessful users
•Recommended strategy for users → how to benefit from a Ponzi scheme ;-)
•4 data sets available, in XES: https://ingo-weber.github.io/dapp-data/
•New paper forthcoming:
Richard Hobeck, Christopher Klinkmüller, H.M.N. Dilum Bandara, Ingo Weber, and Wil van der Aalst. On
the suitability of process mining for enhancing transparency of blockchain applications. Business &
Information Systems Engineering journal (BISE), June 2024. In press, accepted.
Conclusion so far
71
Is it useful to do process mining on blockchain data?
→ In two cases (Augur and Forsage) we found: yes

43. Traditional approach:
Single case notion at a time (e.g., user)
Object-centric approach:
Multiple entities (objects) the process can revolve around
(e.g., user, contract type, order, etc.)
→ There might not be one consistent case notion throughout the DApp
Hobeck, R., Weber, I. (2023). Towards Object-Centric Process Mining for Blockchain Applications
Object-centric process mining
72

44. Ideal scenario:
73Smart contract Smart contract Smart contract Smart contract
LoggingContractSmart contract Smart contract Smart contract Smart contract
More common
scenario:Smart contract
Motivation for object-centric process mining

45. Revisiting the Augur dispute:
Single case notion (market) Object-centric (market and order)
Object-centric process mining
74
*discovered based on additional data compared to
single-case notion example

46. Agenda
•Engineering Dapps
−Architecture
−Development
•Model-driven Engineering for
Dapps
•Analytics for Dapp data with
process mining
•Further Reflection

47. •New tradeoffs based on new tech
- New platforms like Algorand
- MARTSIA / CAKE / Process Channels
→ different tradeoffs regarding
confidentiality (privacy) and transparency
Fabian Stiehle and Ingo Weber. The cost of executing business processes on next-generation blockchains: The case of Algorand. In Blockchain Forum
of the International Conference on Business Process Management (BPM), September 2024.
Edoardo Marangone, Claudio Di Ciccio, Daniele Friolo, Eugenio Nerio Nemmi, Daniele Venturi, and Ingo Weber. MARTSIA: enabling data confidentiality
for blockchain-based process execution. In EDOC'23: IEEE International Conference Enterprise Design, Operations, and Computing, Groningen,
Netherlands, October 2023.
Edoardo Marangone, Claudio Di Ciccio, and Ingo Weber. Fine-grained data access control for collaborative process execution on blockchain. In
Blockchain Forum of the International Conference on Business Process Management (BPM), September 2022.
Fabian Stiehle and Ingo Weber. Process channels: A new layer for process enactment based on blockchain state channels. In BPM'23: International
Conference on Business Process Management, pages 198-215, Utrecht, Netherlands, September 2023.
Further Reflection

48. •New tradeoffs based on new tech
- New platforms like Algorand
- MARTSIA / CAKE / Process Channels
- PoS solved Energy Problem in principle (but not in Bitcoin)
Ethereum:
−Go-live of PoS in Sep. 2022
−Estimated reduction of energy by about 99.98%
−Source of figure: https://ethereum.org/en/energy-consumption/

Further Reflection

49. •New tradeoffs based on new tech
- New platforms like Algorand
- MARTSIA / CAKE / Process Channels
- PoS solved Energy Problem in principle (but not in Bitcoin)
Ethereum:
−Go-live of PoS in Sep. 2022
−Estimated reduction of energy by about 99.98%
−Source of figure: https://ethereum.org/en/energy-consumption/

Further Reflection

50. •New tradeoffs based on new tech
•Internet of value
Further Reflection

51. •New tradeoffs based on new tech
•Internet of value -> assets of value, hence application focus on DeFi
•Link to Generative AI: provenance / lineage in high demand
−Kamala & Donald
•Spectrum of (de)centralization
−Uber analogy
Further Reflection

52. •New tradeoffs based on new tech
•Internet of value
•Spectrum of (de)centralization
Further Reflection

53. (De)centralization Continuum*
82
Fully Centralized System Blockchain-based System
-logically centralized,
-organizationally decentralized,
-physically distributed **
→ Decentralization is not a
single dimension
*Fabian Stiehle, Finn Klessascheck, Martin Kjäer, and Ingo Weber. Business in the age of platform economics: Managing decentralised business
processes beyond blockchain. In Innov8BPM'24: International Workshop on Managing Process Innovation and Value Creation in the Era of Digital
Transformation at BPM'24, September 2024.
**Ingo Weber and Mark Staples. Programmable money: next-generation blockchain-based conditional payments. Digital Finance (DFIN),
4(2):109-125, September 2022.
?

54. •New tradeoffs based on new tech
•Internet of value
•Spectrum of (de)centralization
-Uber analogy
-What means of (self-)correction are built in?
→ Slight clash with immutability
See update patterns
Further Reflection

55. •New tradeoffs based on new tech
•Internet of value
•Spectrum of (de)centralization
•Generative AI: provenance / lineage in high demand
to counter deep fakes
Further Reflection

56. Blockchain Application Design and Development:
From Architecture to Analytics
BRAINS Keynote, Oct. 2024
Prof. Dr. Ingo Weber
[email protected]
http://imweber.de/
Full professor at TUM and
Director IT infrastructure & digital transformation
at Fraunhofer