Smart Contracts are Neither Smart nor are they Contracts

The founder of Ethereum, Vitalik Buterin, aptly noted in an October 2018 Tweet that “ To be clear, at this point I quite regret adopting the term “smart contracts”. I should have called them something more boring and technical, perhaps something like “persistent scripts”. See

To be clear, at this point I quite regret adopting the term "smart contracts". I should have called them something more boring and technical, perhaps something like "persistent scripts".

— vitalik.eth (@VitalikButerin) October 13, 2018

Vitalik was more than right, especially when it comes to smart contracts running on enterprise blockchains.

Smart contracts in public blockchains offer a much stronger value proposition than those running on enterprise blockchains.  Public blockchain smart contracts enable parties to transact with any other party — whether that party is known or anonymous. Public blockchains allow parties to transact without any membership rules and by default without the constraints of legal frameworks and central authorities.

Permissioned Enterprise Blockchains and anything that runs on them are more limited in value; they don’t support the revolution of blockchain that eliminates central authority and they are not byzantine fault tolerant. Nonetheless, Enterprise Blockchains can add substantial evolutionary value (See Blockchain Unraveled; Determining its Suitability for Your Organization ) especially with payments, asset tracking, and provenance use cases.   And these use cases — like most logic running on blockchains —  are powered by smart contracts.

As noted in our recently published research note Managing the Risks of Enterprise Blockchain Smart Contracts , smart contracts automate and accelerate outward-facing business processes. But users must be aware of the many risks associated with smart contracts and mitigate these risks by designing controls into their applications and processes.

Our note goes through the key challenges and recommendations for smart contracts – here is a sample:

Challenges

• Often, the benefits and logic of smart contracts are not understood by all parties. Reversing the effects of immutable transactions on blockchain ledgers is very difficult.
• Smart contracts can execute forever if there are no mechanisms in place to stop them. Bugs, errors or malicious actors can trigger undesirable results that are hard to correct.
• Users are unaware of the need for umbrella legal frameworks across network members. Users require clear, documented and agreed-upon governance rules regarding blockchain participation and smart contract applications.

Recommendations:

• Evaluate your need for smart contracts, as opposed to regular scripts and traditional contracts. You will often incur more technical cost than automation and security benefits.
• Map linkages between business events and smart contracts. Put a process in place across business partners for retiring and replacing obsolete smart contracts, ensuring that you accurately reflect current business agreements.
• Implement clear legal frameworks across the blockchain network and smart contract participants. Ensure you have a clear well-documented governance process that establishes exactly what you need to do if things go wrong.

Smart Contract Framework

Our note outlines a framework with three distinct layers that must be considered when implementing and maintaining smart contracts. (See Figure 1)

• Business layer — which governs the business relationship
• Event integration layer — which translates between business actions and blockchain transactions
• Smart contract layer — validates and immutably records transactions onto the blockchain

Figure 1. Three Layers of Enterprise Smart Contract Environments

Are Smart Contracts Even Necessary?

At the outset, users must determine if their organization has a use case that crosses organizational boundaries and will benefit from a distributed ledger and the smart contracts that operate on them. Legacy database technology should be used in instances where there are no inherent organizational trust issues across network participants, and there is no requirement for a shared, immutable system of record.

It follows that smart contracts should not be used for an internal use case because there should not be any trust issues within an organization, where authority is centralized. (There is however always a risk of malicious or self-interested insiders who put their own needs ahead of the organization. Both permissioned blockchains and legacy data systems require extra controls to detect anomalous users and transactions).

Gartner published a decision tree to guide the DLT blockchain technology evaluation. This should serve as the starting point for application leaders who embark on this technology journey (see “Assessing the Optimal Blockchain Technology for your Use Case”).

Bottom Line

Smart contracts automate distributed processes that run on distributed ledgers. Your organization will only benefit from a smart contract if the intended use cases require the distribution and shared technology ownership supported by the enterprise (permissioned) blockchain DLT.

DLT and smart contracts can be a good technology choice if your organization needs:

• To do business with otherwise untrusted parties
• To share assets and information with competitors
• To trade physical or digital assets
• To transfer legal ownership of an asset with minimal overhead

Gartner research shows that most companies experimenting with blockchain do not have a clear use case that leverages the unique benefits of blockchain. These organizations have not yet defined success criteria for their blockchain projects so they remain unsure if their projects are succeeding or failing.

Like they say – “if you can’t measure it, you can’t manage it.”  So before you get involved with enterprise blockchain smart contracts, make sure you know how to measure their success and why you need them.