![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](https://image.slidesharecdn.com/2024-10brainskeynote-241011122246-7696c09f/85/Keynote-at-the-BRAINS-conference-Blockchain-Application-Design-and-Development-From-Architecture-to-Analytics-35-320.jpg)
![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!](https://image.slidesharecdn.com/2024-10brainskeynote-241011122246-7696c09f/85/Keynote-at-the-BRAINS-conference-Blockchain-Application-Design-and-Development-From-Architecture-to-Analytics-37-320.jpg)
Keynote at the BRAINS conference -- Blockchain Application Design and Development: From Architecture to Analytics
- 1. Blockchain Application Design and Development: From Architecture to Analytics BRAINS Keynote, Oct. 2024 Prof. Dr. Ingo Weber ingo.weber@tum.de 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. Xiwei Xu, 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?”
- 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-chain Off-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
- 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
- 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: 73 Smart contract Smart contract Smart contract Smart contract Logging Contract Smart 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 ingo.weber@tum.de http://imweber.de/ Full professor at TUM and Director IT infrastructure & digital transformation at Fraunhofer