When Are Smart Contracts Overkill?
Smart contracts are a powerful feature of distributed ledgers. These platforms can share data across companies, clouds and geographies, but typically their ability to transform or manipulate that data is limited. Smart contracts expand the built-in data handling capabilities of the platform itself by enabling a broad range of data transformations to be applied, and in systems like Vendia, can also make it easy to integrate with existing IT infrastructure and other applications when those computations require coordinating with multiple existing systems.
What Are Event Handlers?
Event handling is a powerful architectural design pattern that allows systems to be loosely coupled. Distributed ledgers fit neatly into this pattern: When a block of transactions is committed, the ledger can “fire” an event through any number of cloud integration mechanisms (queues, streaming data records, cloud function invocation, event hubs, cloud choreography steps, etc.) Event handlers make it easy to integrate two or more systems together — in this case, integrating one of the nodes in a distributed ledger with other elements of an application or system.
Of course there are other architectural patterns that connect code with ledgers, such as polling; to keep things simple the remainder of this article, we’ll use “event handler” as a stand-in for “all the ways in which you can integrate code with the information in a distributed ledger that are not smart contracts.”
Smart Contracts Versus Event Handlers
The decision to use a smart contract versus an event handler matters — it affects everything from trust between parties to how data security is handled. Smart contracts are typically shared, and that sharing has great benefits (trust, agreement) but also comes with costs — updates to the contract, for instance, usually need to be coordinated and confirmed among multiple parties, complicating the process of development and the resulting “on chain” deployment. While Vendia makes writing smart contracts flexible by allowing them to be expressed in any language, there are still more “ceremonies” involved in managing them versus conventional application code owned by a single party.
Conversely, event handlers and conventional application logic have limitations when it comes to interoperating with other parties: Because they are part of a company’s private IT infrastructure, they aren’t as likely to be trusted by others, and their execution may not be tightly synchronized with the activities of other parties.
How do you know when to use which? Smart contracts make the most sense when they synchronize executable policies or analyses among multiple parties. Event handlers, by contrast, are a great way for a single party to integrate with the rest of their application infrastructure. Here are four questions you can ask yourself to help gauge whether an operation should be “on chain” (smart contract) versus “off chain” (event handler).
To make this checklist even more concrete, we’ll use a running example: A bank and a credit card issuer like Visa that needs to jointly handle a user’s credit card, including computing monthly interest on the account.
- Who needs to trust the outcome?
The most critical question to consider is whether the computation needs to be a single source of truth. Event handlers and conventional application logic suffice when a single participant is interested in the outcome. But if multiple parties depend on the outcome, then a smart contract is usually needed. In our running example, calculating and applying the monthly interest to the credit card needs to be a single source of truth — it would be a disaster if the bank and the issuer disagreed on how much interest to apply to the account! Conversely, if the bank wants to display the current balance to the user through the bank’s website or the issuer wants to run an internal report, they only care about their individual systems, not each other, and implementing website UIs and reporting software doesn’t require the consent or even the awareness of the other party.
- Are the inputs (parameters) or outputs (results) of the computation on chain and serialized with other updates?
This is a classic database ACID question: Does serialization matter, or is “close enough” good enough? In our example, interest computation is a transaction that needs to be correctly serialized with the user’s credit card purchases — missing a purchase or including it twice would cause great harm. Conversely, if a website showing recent transactions updates once a minute versus once a second, it doesn’t affect correctness (though it may have an impact on customer satisfaction!) Smart contracts are the better answer if they are intended to be part of the ongoing transaction stream because they keep the inputs, outputs, and processing all connected together. Conversely, if information just needs to be conveyed to other parts of the software architecture, then event handlers or other conventional data integration approaches are sufficient.
- Is the execution of the contract itself a critical step for auditing, transparency, or trust?
When a smart contract emulates a real-world agreement, recording the fact that it executed, along with its parameters, can be important. In our running example, the interest transaction on a credit card is itself one of the most important transactions, and the fact that it was applied is important for both the bank and the issuer to track. Just seeing the user’s balance become higher would raise eyebrows: Both parties need to know why and when the balance was adjusted. Conversely, the bank doesn’t care when the issuer runs an internal report, and the issuer isn’t responsible for what the bank displays on its website.
- Are there additional ceremonies related to the code?
Smart contract execution is important, but it’s only one step in a life cycle: In the real world, creating, updating and deprecating smart contracts are also important steps. These “CRUD” operations on smart contracts can have important additional benefits and consequences in a shared ledger — for example, it might be important to allow code inspection for new or changed contracts among all the parties involved. Here, the presence of the ledger and the ability for it to offer built-in guarantees, such as validating that the code shared for inspection truly represents the code executed at a later time to invoke a smart contract, dramatically simplifies achieving these outcomes. While the parties could engage in a series of point-to-point or mutually executed paper contracts and communications to validate executed contract updates, keeping “things computers do well” inside the computers is obviously more efficient than devolving to Zoom coordination meetings, emails with lawyers, etc. when changes need to be made that could be handled in a more automated fashion. In our running example, if the Fed increases interest rates and the credit card markets follow suit, the bank, the issuer and the auditors for both parties need to all agree that the interest calculation is changing (and when that change should take place). The “meta transaction” of alternating the smart contract’s computation is vital in establishing the validity of all future interest transactions.
The following table summarizes some of the key elements in choosing between an event handler and a smart contract:
| Feature / Aspect | Event Handler | Smart Contract |
| Ownership | Single participant | Two or more (often all) participants |
| Development overhead | Low | Medium |
| Data format and security | Participant decides | Determined by the platform |
| Choice of language | Any | Any (on Vendia); highly restrictive on other platforms |
| Serialized, on-chain transactions | No | Yes |
| Execution is tamperproof and auditable | No | Yes |
| Updates are managed… | Off chain by participant | On chain, among all interested parties |
| Option to use serverless? | Yes | Yes on Vendia; no on other chains |
Learning More
Modeling applications that share data across companies, clouds and geographies involve many decisions, not least of which is what to model at the level of the distributed ledger and data-sharing platform versus in application logic. We hope this article has been helpful in thinking about smart contracts versus event handlers and other application-level functionality, and we look forward to hearing your thoughts!
