Blockchains maintain information about transactions creating and transferring digital assets. "Smart contracts" which are arbitrary, immutable code executable on a blockchain, can be used to implement complex business rules that govern transactional behavior as well as raise events which external applications can be noti ed about. However, the arbitrary and imperative nature of smart contracts and the events they raise, make their discoverability and reuse challenging. Further, events represented merely as function signatures limit the ability for more complex, semantic event detection which require richer representations such as semantic rules. In this paper, we motivate and describe our e orts towards support for semantic event detection on blockchains that are founded on (i.) a declarative, semantic data, transaction and event model and (ii.) an integrated blockchain-streaming application execution architecture. We overview our selected implementation strategy that builds on the BigChainDB blockchain engine and Apache Kafka, a large-scale streaming platform.
Blockchains typically maintain information about transactions that create or
transfer ownership of digital assets. To enable business applications with complex
business logic for governing such transactions, the concept of "smart contracts"
was introduced by blockchain platforms like Ethereum [
Abhisha Bhattacharyya, Rahul Iyer, and Kemafor Anyanwu
Imagine a digital service marketplace that allows consumers to request for
bids for speci c services and service providers to o er service bids. This scenario
can be useful in domains such as Manufacturing that are increasingly becoming
more Cloud-oriented. In large-scale or bespoke manufacturing for example, it is
common to need to outsource the manufacturing of some components. However,
in high-capital domains, a signi cant degree of con dence and trust in
capabilities and capacities of service providers is required by the service requestor. Some
ideas on using the blockchain for maintaining historical records of bids, their
fulllment, performance, etc to be leveraged for mediating automatic agreements,
has been proposed in [
Lack of Reusability: Each request-for-bid - rfb (and similarly bid) is a non-traditional blockchain transaction which would need to be implemented as a separate smart contract, even when rfbs have similarities or overlapping behavior. This is because program reuse is more challenging with imperative representations given that semantics is implicit in program behavior. The immutability of smart contracts also implies that if business conditions evolve even slightly, modifying the smart contract to capture new business logic is a major challenge.
Discoverability: In our example, a service provider would need to be aware of the existence of a smart contract requesting for a bid on services that they provide. This requires either (i.) some standardized token contract interfaces for representing speci c protocols (analogous to ERC20/721) or (ii.) some registry of smart contracts indexed by standardized metadata. However, it is unlikely that a xed set of function interfaces that comprise a token will be general enough to capture such protocols, given the variability in possible request and bid requirements (unless perhaps organized into very narrow vertical segments). Another approach that can be used to discover requests is via the events raised by smart contracts. Such events may be routed through a publish/subscribe platform like Apache Kafka (such as is done by Eventeum). However, subscribing to events requires apriori knowledge of event de nition. Unfortunately, each smart contract raises events using a function signature of its choosing. Consequently, the same event could be represented using di erent signatures which cannot all be known apriori. Secondly, how to map such events into an appropriate publishsubscribe event detection model is unclear. This is because the semantics of an event may be implicit and complex. For example, a request for bid transaction that has parameters Material as "PolyCarbonate" and Quantity as "10" can be mapped to "3D Printing" event. Such terms and relationships would need to be captured in an ontology and semantic rule engine.
Our preliminary investigation leads us to the conclusion that there are two
key requirements needed to enable detection of semantic events on blockchains:
(i.) The use of a declarative and semantic data, transaction and event model
that allows new transaction (e.g. bids) and event classes to be introduced in
a straightforward manner. The semantic-awareness requirement allows
reasoning about semantic relationships between transaction and event types. (ii.) A
processing architecture that integrates blockchains with a semantic rule engine
and publish and subscribe mechanisms, enabling detection of complex semantic
events. We are currently developing these ideas in the context of a project called
SmartChainDB. SmartChainDB extends a blockchain platform BigChainDB [