Do I need a smart contract? – The new stack

Smart contracts are powerful, but not always necessary. When should you use them and when are they overkill?

Smart contracts are a powerful feature of distributed ledgers. These platforms can share data across enterprises, clouds, and regions, but typically their ability to transform or manipulate that data is limited. Smart contracts extend the built-in data processing capabilities by enabling the application of a wide range of data transformations and, in systems such as Vendia, also facilitate integration with existing IT infrastructure and other applications.

But like any technology, smart contracts come with their own overhead: because they are code, they must be carefully developed, with a clear software development and deployment lifecycle that includes testing. Because they’re “on chain,” development, deployment, and testing must involve the distributed ledger — or at least a trial version of it — adding to the complexity, and therefore cost, of owning and operating a smart contract.

Platforms like Vendia are working hard to minimize these costs: by allowing smart contracts to be written as containers or serverless cloud functions in any language, they eliminate the learning curve and reduce the novelty, risk and cost of development and deployment of these contracts radically. However, smart contracts require more development time than a GOFAL (good old-fashioned AWS Lambda) attached to a node as an event handler. This begs the question: when do you really need a smart contract and when is something simpler (like a GOFAL event handler) the right answer?

Deciding whether to create a smart contract or add more conventional “application logic” is similar to whether to update state using the distributed ledger or manage it at the application level. There are several questions you can ask yourself to gauge whether an operation should be on chain or off chain:

Are the parameters to the function (code) mostly on-chain values ​​and is it important that they are serialized in terms of updates?

This is a classic database ACID question: does serialization matter, or is “close enough” good enough? For example, if you’re a bank and you’re using a smart contract to calculate the interest paid into a savings account at the end of the month, it matters a lot whether the last few transactions are included in the interest calculation, so you need a smart contract vs a GOFAL.
If you are using a smart contract to estimate shipping and taxes for a shopping cart for display on a website or mobile app, having the UI update asynchronously after an addendum is added and a GOFAL is an acceptable user experience – or a GraphQL subscription is a better approach.

Does the result (response) of the function go into the chain?

This is partly a matter of serialization and partly just a matter of convenience: if the only purpose of executing the code in question is to generate one or more mutations, it probably makes more sense to model it as a smart contract and run the system automatically to let integrate these mutations into the ledger. By using a smart contract, the relationship between the parts in the ledger remains transparent: the invocation, execution and resulting effects of the smart contract can all be linked together by the system. Conversely, simply executing a mutation in application logic requires a different way of understanding (and debugging when something goes wrong) how it was related to the trigger and what the results might have been. So if the function doesn’t generate mutations, or if it does generate mutations but they have nothing to do with on-chain parameters, then modeling it as a smart contract is less convincing. In our example above, the calculation of interest on a savings account will generate a new deposit into that account that needs to be carefully synchronized with other account activity, so it makes sense to model the calculation as a smart contract. Our opposite example, showing taxes and shipping costs for a shopping cart, only has “pixels” as an output, so again it’s less convincing as a smart contract (and makes more sense as normal application logic).

Is contract execution itself a critical step for auditing, transparency, or trust?

When a smart contract emulates a real-world agreement, it can be important to record the fact that it was executed. For example, if you are using a smart contract to model the transfer of ownership of a vehicle, such as a car, from one owner to another, then the transfer of ownership is just as important as recording the old and new owners. Rather than having a different value to an owner of a particular vehicle implicitly indicate that the transaction took place, recording the actual transfer of ownership as contract execution increases transparency by recording the activity itself and not just its outcome(s). In our running counter example, calculating and displaying taxes and shipping costs for a shopping cart isn’t interesting to document per se—all that matters is the result (the pixels on the webpage or mobile screen are updated).

Who must trust the result?

In our running counter example, it is very likely that the website or mobile app is owned and operated by a single participant and is therefore modeled as a customer of one or more nodes in the ledger with the same owner. “Trust” isn’t really an issue here – multiple nodes, if any, are used to model geo-replication for low-latency access or to make the application multi-cloud available. Conversely, if a bank calculates interest using one node while its auditor ensures SOC compliance using another node in a shared ledger, the auditor cannot “just trust” the bank – they want to be able to verify the interest calculation logic check and verify that it was applied at the right time. If the ledger proves that the smart contract used to calculate interest was executed at the right time and with the right (immutable) code, the cost and complexity of the verification process is radically simplified, as the verifier only needs to validate the ledger technology once , instead of having to do so, evaluate and determine the trustworthiness of each individual bank’s IT infrastructure stack each year. Conversely, in our running counter example, none of the business partners are likely to care about the tax and shipping notification UI on the shopping cart web or mobile app, so there are no complex trust issues to solve and the application logic is sufficient.

Are there additional ceremonies related to the code?

Contract execution is important, but only one step in a lifecycle: in the real world, creating, updating, and discarding 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 may be important to allow all parties involved to inspect code for new or changed contracts. Here, the presence of ledgers and the ability to offer built-in guarantees, such as For example, validating that the code submitted for review really represents the code that will be executed at a later time to invoke a smart contract greatly enhances the achievement of these results. While the parties could enter into a series of point-to-point or mutually executed paper contracts and communications to validate executed contract updates, it is obviously more efficient to keep “things computers are good at” in computers than to keep them to focus on Zoom coordination meetings and emails lawyers etc if changes need to be made which could be handled more automated. In our running example, an accountant likely needs to be alerted when a bank updates its interest calculation methodology, while a website that decides to offer a new shipping discount may not be of interest to business partners in the company’s supply chain.

Modeling applications that share data across enterprises, clouds, and regions requires many decisions, not the least of which is what to model at the distributed ledger and data sharing platform level versus the application logic. We hope this article has been helpful in looking at smart contracts versus event handlers and other application-level features, and we look forward to hearing your thoughts!

Featured image via Unsplash.