EDSC: An Event-Driven Smart Contract Platform

The advent of Bitcoin, in late 2008, demonstrated how a digital payment system could be implemented using a novel decentralized public data structure, i.e., a blockchain  [1]. Additionally, Bitcoin also incorporated a built-in scripting framework that could be used for controlling the tokens, storing data, and specifying logic on the blockchain itself. This was a decentralized implementation of smart contracts  [2]. Smart contracts are essentially pieces of code that enforce the terms and procedures of an agreement or protocol digitally. However, Bitcoin’s smart contract functionality was limited in its application, and it was not until the introduction of Ethereum  [3] that smart contracts took center stage in the cryptocurrency arena. Ethereum offered an integral Turing-complete programming language to create blockchain-based smart contracts, allowing for their employment in a wide range of potential use cases  [4].

Presently, smart contracts continue to grow in their utility and outreach. Since the launch of Ethereum, many alternative smart contract platforms have also emerged, which have gained considerable adaption and sizeable user bases  [5] [6] [7] [8] [9]. The majority of these platforms aim to overcome or readdress Ethereum’s limitations and trade-offs, e.g., achieving higher throughput, decreasing computation costs, deploying a different consensus mechanism, etc. Although initially limited to token control and on-chain data access, smart contracts today are increasingly interfacing with real-world data and events, rapidly extending their application sphere. This interaction is enabled through oracles  [10] [11], which are services designed to provide external information in the smart contract environment. To avoid a single point of compromise for such integration, many recent oracle projects  [12] [13] [14] are adapting a decentralized approach for collecting and aggregating data.

Despite numerous innovations and advancements, the smart contract ecosystem’s evolution has been stifled by various impediments, mostly prevailing in transaction performance (e.g., latency, throughput) and scalability domains. Although several projects  [15] [16] [17] have sought to address these concerns through imaginative solutions like sharding and execution parallelization; many complex design challenges remain unsolved for practical purposes. With the recent unprecedented growth of decentralized financial services (DeFi), an ever-increasing percentage of smart contracts are interfacing with oracle networks to fetch real-world information  [18]. Since this interfacing is accomplished through two-way transactions on most platforms, the trend is bound to further burden an already congested system  [19].

In the smart contract space, most existing popular platforms conform to the transaction-driven execution model. This means that all contract executions on these platforms are triggered by initiating transactions on the system through non-contract accounts. In this paper, we present an alternative smart contract platform design built on the event-driven execution model. The event-driven architecture pattern is a simple yet powerful distributed architecture pattern, proven to produce highly scalable and adaptable applications. The model enables communication by allowing participants to publish notifications of occurring events, along with subscribing to events of interest and being asynchronously notified of their occurrence by the system. The event-based methodology has previously been extensively studied in the context of systems and software engineering [20] [21] [22]. We reason that a smart contract platform framework centered around the publish/subscribe paradigm will be a good fit for many emerging smart contract applications that demand or can benefit from timely execution. We also demonstrate that it will be, by design, better positioned to address the aforementioned issues hampering the ecosystem’s progression.

This paper intends to describe an event-driven smart contract platform’s architectural layout and implementation. We use the Ethereum architecture as the base template and outline the modifications required in its design to actualize our system. The rationale for this approach is that we assume most readers to be acquainted with Ethereum’s mechanics, given that it is one of the most widely used smart contract platform to date. This familiarity, we hope, will allow the readers to draw parallels between the two models while enabling us to communicate our design succinctly. It is worth mentioning that although presented using Ethereum as the reference, the concept of event-driven smart contracts illustrated in this work can be extended to other smart contract platforms, consensus protocols, and programming models with trivial adjustments. The proposed design also has numerous advantages over the prior art that attempted to support events in the application layer. To the best of our knowledge, the proposed system is the first smart contract platform designed upon the event-driven execution model. We hope that our work will inspire further research in the direction of applying the event-driven communication paradigm to blockchains.

To summarize, the main contributions of the work and paper are: (i) We propose an event-driven smart contract platform with native support for real-time event processing. (ii) We provide the design of an event-based system using Ethereum as a reference target. (iii) We describe the design’s advantages in potential use cases and comment on its security aspects. (iv) We have performed an implementation using the Golang Ethereum client and conducted experiments where performance modeling results show on average a 2.2 to 4.6 times reduction in total latency of event triggered smart contracts, which demonstrates its effectiveness for supporting contracts that demand timely execution based on events.

In recent years, the advancement of blockchains, smart contracts, and decentralized infrastructures have created an emerging frontier that combines traditional concepts of event-driven systems with blockchains. As such, there have been ongoing efforts to harness the benefits of this paradigm in blockchain-based smart contracts. Oracles and subscription-based payment models have sought to achieve this but have encountered limitations. Currently, oracle systems typically follow a pull-based model with the client contract requesting data from an off-chain source. Present designs favor off-chain implementations to incorporate the event-based subscription model and then interact with the blockchain.

We take as a case study the implementation of the IBM blockchain, which is built on Hyperledger [23]. Prior work by Hull [24] shows how event-based processing is used for data-centric applications. The commercial implementation and offering by IBM [25] uses Java micro-services to listen for events form the blockchain using OpenLiberty. Blockchain provides the integrity of the process, whereas the java micro-service layer and OpenLiberty ensure it can have event-based transactions. However, apart from the implementation layer, it does not use the smart-contracts for any event-based transactions. Another commercial offering is provided by Amazon [26], which uses the Hyperledger Fabric and Ethereum as the underlying layer. Their implementation allows three distinct kinds of events to interact with the blockchain network, namely: (i) Block event, which occurs when a new block is added to the ledger; (ii) Transaction event and; (iii) Chaincode event, which can hold conditions for triggering events. The triggering mechanism for these events relies on AWS Fargate to act as an event listener and then on Amazon Simple Queue Services to be processed by lambdas. Just like IBM, Amazon’s implementation also relies on a layer of auxiliary services to enable event-driven architecture.

Recent works remedying this limitation include EventWarden  [27], where the authors propose a decentralized event-driven proxy that can interact with Ethereum-like blockchain networks and pass the transactions. This approach eliminates the use of auxiliary services similar to what IBM and Amazon were employing since this can be implemented directly onto the Ethereum network. It allows a user to create a proxy smart contract describing an event into the contract. Anyone in the blockchain network can trigger a release of the reserved transaction by calling the proxy contract and showing that the concerned event has been recorded into blockchain logs.

Another recent work Ethereum Alarm Clock  [28] allows a user to deploy a request contract with a future time limit on the Ethereum network. However, this project supports only one type of event, the arrival of a predefined time-frame. Work by Chao and Palanisamy  [29] takes a similar approach to handle only events based on time.

In contrast, this paper tackles the fundamental limitations seen in  [25, 26, 28, 29] by proposing a smart contract platform based on the event-driven execution model, complete with a pub-sub scheme, which can be applied as a modification on the present Ethereum architecture or blockchains with smart contract support.

EDSC is built on the event-driven execution model using the publish/subscribe communication paradigm. In the publish/subscribe interaction scheme, components subscribe to events of interest, or to a pattern of events, and are subsequently asynchronously notified by the system when any event published matches their registered interest. In order to incorporate this paradigm into a smart contract platform, the platform design should provide the following basic features to the participating smart contracts and external accounts:

• •

  Event Definition: Any external account or smart contract in the system is able to define/register new and unique event types in the system. This is analogous to defining a class in an object-oriented programming paradigm.

• •

  Event Subscription: Any smart contract in the system is able to subscribe or unsubscribe to a particular event type that is already defined in the system. At the time of subscription, the subscriber contract may specify additional logic that will be used by the system to evaluate whether to invoke it in response to the event of interest’s occurrence in the system.

• •

  Event Publishing: Any smart contract is able to publish an event that has already been defined in the system.

In order to provision the three fundamental features mentioned above, the smart contract system needs to incorporate the following functionality specific to the event-driven execution model:

• •

  Event Definition Maintenance: The event templates are saved immutably in the system. This may be achieved in practice by referencing the event definitions on the blockchain itself, similar to how smart contract code is stored on-chain by reference in Ethereum.

• •

  Subscription Information Maintenance: The subscription information is also saved immutably in the system. This can also be achieved in practice by referencing the subscription information on the blockchain itself, similar to how smart contract code is stored on-chain by reference in Ethereum.

• •

  Event Matching: Every time a published event is processed, the system determines all the smart contracts which are subscribed to that particular event. The system also evaluates the corresponding subscription logics of all those subscriptions to determine which smart contracts to invoke in response to the publishing event.

• •

  Event Queueing: Based on the event matching, the system queues all the matching subscribed smart contracts for execution. Since the system is asynchronous, there are no guarantees as to when the subscription triggers will be executed. The system guarantees the queueing of these executions.

Since the publish/subscribe method is an anonymous and indirect communication paradigm, the system decouples the communicating entities i.e., the smart contracts in space and execution flow:

• •

  Space Decoupling: The publishing and the subscribing smart contracts do not need to know each other since they are not required to address each other for communication. Hence, the event publisher does not maintain a record of all the smart contracts which will be evoked in response to its event publication. Likewise, the subscriber may subscribe to events from multiple sources without specifying them individually.

• •

  Time Decoupling: There is no provision for the publisher or the subscriber to run within any time constraint. The subscriber execution can be queued for a later time window (depending on future events).

• •

  Execution Flow Decoupling: The inherently asynchronous communication decouples execution flow from inter-contract communication. A smart contract is not blocked when sending a notification to an external contract. The system can handle the subscriber execution in response to the notification by running it concurrently or queueing it for later. The subscriber and publisher of events do not have to be synchronized in their execution.

Based on our basic design framework from Section  III, the proposed smart contract system will offer attractive advantages to the ever-evolving ecosystem of smart contracts:

• •

  Lower Fee for All: We reason that the proposed platform will result in a majority of the system participants having to pay a lower gas fee for their executions, especially in a system that is highly interfaced with external oracle systems through oracle contracts. User smart contracts only pay for the gas for executing themselves. In other words, the transaction cost, which is now the cost of putting the event on-chain, is shared by all the subscribers collectively.

• •

  Improved Security: Ethereum smart contracts developed in Solidity have been marred with security issues centered around reentrancy and unexpected reverts [30]. This is because, by design, an Ethereum transaction has to complete the contract execution in the current as well as called contracts before the transaction is considered complete. On the other hand, the event-driven paradigm is free from such vulnerabilities, since events are asynchronously published without waiting for the subscriber contracts to run. This offers better security guarantees.

• •

  Less Network Clogging: Having multiple smart contracts subscribe to a single event translates to lesser network usage as opposed to smart contracts requiring transactions to be broadcasted every time they need to execute or interface with an oracle provider. Also, only a single event needs to be recorded on-chain as opposed to multiple transactions. This is beneficial for freeing up vital network bandwidth, which has recently been clogged  [19].

• •

  Better Scalability: We also claim that an event-driven system based on the proposed basic design is better positioned for employing parallel-processing and sharding solutions for scalability. This is because all executions are restricted in context to the currently executing contract, and event-based subscription triggering occurs asynchronously. All events can be posted to a shared global non-sharded trie for inter-shard communication borrowing from a similar concept in the Zilliqa project [16].

We present the detailed design of the event-driven smart contract system based on the current Ethereum design framework. The rationale for this approach is that Ethereum is arguably the simplest and unarguably the most widely adopted smart platform to date. Using Ethereum’s design as the base reference will allow the readers to grasp the design proposals clearly and draw parallels between the two approaches. Note that the design presented is general and independent of any specific platform.

The event-driven smart contract platform design offers numerous security benefits over a traditional transaction-driven model. For instance, when EDSC is integrated with Ethereum, the system can prevent inter-smart contract communication-related vulnerabilities, including reentrancy and denial-of-service attacks [30]. Since the proposed design provides execution flow decoupling, smart contract execution independence and atomicity, these vulnerabilities are no longer present in such a design. Aside from these vulnerabilities at the programming and toolchain layer, EDSC can also mitigate vulnerabilities arising from transaction ordering dependence [31]. EDSC achieves this by enforcing an order for event processing and subscription execution based on the gas fee. This design choice also provides the additional benefit of not having to put smart contract generated events on-chain and allows for reduced block confirmation times. Below, we discuss some attack scenarios and mitigation approaches.

Denial-of-service (DoS) is a realistic risk for public blockchains. For instance, an attacker may try to flood the event processing module with event messages, or launch starvation attacks by polluting the event buffer. These attacks can be mitigated with a variety of countermeasures, for instance, imposing a limit on event update and event creation rates for an account. In addition, event publishing also has a gas cost associated with it, which is paid by the publishers, to discourage them from publishing events unnecessarily. Depending on the gas limit of an event, a registered event can be kept in the system for only a bounded number of blocks (limit can be re-fueled later by the creator with a transaction). Similarly, generating a new subscription/event definition and deploying a new contract also have an associated gas fee, which the event publisher must pay analogous to Ethereum’s associated gas fee for deploying a new contract. These fees serve as a deterrent against spamming and DoS attacks on the system. Furthermore, event manager enforces that for each event and user account, there is a maximum number of transactions that can be triggered in each epoch, which prevents event buffer pollution. To further mitigate the risk of event publishers spamming the system, EDSC allows subscribers to use variables like the Event Rate and Block Rate as well as the Subscription Logic expression to control their frequency of subscription execution.

Malicious market exploiting and related cheating behaviors are another type of threats. In many DeFi applications such as DEX, a smart contract is applied to execute financial transactions. Such systems are exposed to various market-exploiting behaviors (e.g., frontrunning) [32]. Similar market-exploiting behaviors may pose a risk to EDSC. For instance, when a node observes an event update where financial value can be extracted, the node may send a shortcut message that registers to the event or updates its event registration to boost its priority in the event buffer. Similarly, when a miner detects an opportunity that value is extractable, the miner may be incentivized to directly insert a new event subscription or modify existing subscriptions. Since miner controls event processing, the miner may take advantage of this position to order events or transactions generated from event subscriptions in a particular epoch in ways to extract values besides block reward and transaction fees. In EDSC framework, such attacks are prevented by the global event subscription state. The event subscription state is protected with Merkle hash tree and the root hash is included as part of block header. Updates to the global event subscription state are initiated through on-chain transactions and confirmed using the underlying blockchain consensus mechanism. The EDSC system enforces minimal delay for changes to the global event subscription state to be effective (minimal block delay). When a block is propagated and received by a peer, the peer will validate the transactions that are triggered by events according to the global event subscription state. This means that any foul play or dishonest manipulation of event triggered transactions can be detected by other peers and the block will be rejected.

EDSC is also susceptible to “freeloading” risk, i.e., freeloaders in the system can observe the events being published and copy the payload and publish the same events themselves at a lower subscription fee. This problem also exists for oracle systems like ChainLink [12]. Several methods can be applied to address this issue. For instance, ChainLink uses a commitment scheme to prevent such attack, which can be easily incorporated into EDSC.

Since EDSC can be implemented on any smart contract platform, vulnerabilities that are present in smart contract itself are not considered. We summarize all the security analysis in TABLE V.

We conducted experiments with the extended clients and BlockSim modeling tool. The implemented model of BlockSim for Ethereum has been validated using real data  [35]. The model takes a set of parameters as inputs. These current implementation of Ethereum baseline model compromises of 12.42s block interval and 2.3s block delay  [35]. The model is configured to use the same parameters as currently in Ethereum. The results are based on averages of independent simulation runs of 10,000 blocks. We compare EDSC smart contract delay with the baseline delay of oracle contract based design. The delay is measured as the time when event update is sent by an oracle node to the time that the transaction of a triggered smart contract is added to a block of the longest global chain.

As indicated by the results, EDSC achieves shorter delay for running contracts that subscribe to events, on average often less than time of block interval. In contrast, the baseline model incurs delay longer than three blocks (similar delays observed in Ethereum contracts in real life using oracle contracts: +3 block delays - see Figure 8). This pattern is observed under different block intervals, varying from 8s to 60s.

Both block delay and event/transaction delay can affect the latency between the event update and inclusion of transactions from the triggered contracts. One can assume that this latency likely increases when either block delay or event/transaction delay grows larger. Results in Figure5 and 6 confirm this hypothesis. However, delays in the baseline model appear to be more affected negatively by block delay or transaction delay increase as illustrated by the expanding distance between EDSC delay and the baseline model delay.

Other factors may also have influences on latency of event driven contracts. Block size is one such factor. As suggested by results in Figure7, decreasing block size will negatively impact contract latency under both models. However, the latency benefit of the EDSC model over the baseline is not affected.

On average, delays under the EDSC model could be from 2.2 to 4.6 times less than the delays of the baseline model (depending on block interval, block delay, etc), which demonstrates its effectiveness for supporting contracts that demand timely execution based on events.

The event-driven paradigm is, by design, a better fit for many emerging smart contract applications. The event-triggered execution, asynchronous communication, and contract execution independence and atomicity features are particularly instrumental in building scalable, adaptable, and easy to maintain applications on the smart contract enabled blockchains. The paradigm also enables these applications to be more reactive to external or internal triggers without overloading the system. In particular, financial applications like algorithmic trading, deploying financial instruments, real-time analysis, or digital asset management are naturally suited for the event-based model. The model also has been proven instrumental in a diverse application range consisting of supply chain management, online betting, oracle systems, gaming, etc.  [36]. Here we elaborate on the design’s benefits by discussing two broad real-world smart contract use cases.

We proposed the concept for a novel event-driven smart contract platform with built-in event processing support on the blockchain. We presented a basic design as well as implementation of such a system in practice and commented on its potential benefits to smart contract use cases. We also presented analysis on its security aspects. Experiment results based on BlockSim extension are shown to illustrate performance advantages of event driven smart contract model. Being the first attempt to combine the two avenues of blockchain-based smart contracts and event-driven design, our work paves the way for future research on the subject in various directions. Future work can explore the application of this paradigm to implementing a sharding solution for scalability.