Smart Contracts — Borrowing from OOA and SOA
OOA (Object Oriented Architecture) introduced the concept of packaging data and behavior into Classes and Objects based on the principles of nature. Abstraction, inheritance, polymorphism, encapsulation, typing, concurrency and persistence are core properties of Objects.
In the early 2000s, Services and Service Oriented Architectures introduced a paradigm shift in designing enterprise applications. Services allowed reuse of investment in existing IT assets to meet changing business needs, thus enabling messaging and interoperability between intra-enterprise and inter-enterprise applications. Monolithic applications were decomposed down into business functions and wrapped with service interfaces or messages. Services denoted a higher level of abstraction that could map to functions and procedures within multiple applications.
Services are characterized by well defined “Service Contracts” and exhibit the following properties:
- Autonomous
- Standards based Interface
- Atomic
- Stateless
- Composable
- Loosely Coupled
- Location Independent
- Dynamic Discovery and Binding
- Isolation
- Policy Driven
Services are classified into base or foundational services such as business, entity, technical and management. Fine grained services perform a single function, and many such can be composed into higher level business services. Above all services have to monitored and governed since they are shared assets between enterprises.
Trust, data immutability, transparency and decentralization are the core underpinnings for the next generation of digital transformations, and blockchain and smart contracts are central to that shift.
There are several similarities between Service Contracts and Smart Contracts and their supporting platforms i.e. the ESB and the Blockchain Network respectively.
What are Smart Contracts?
Smart Contracts are business logic that execute on the blockchain. They expose business functions that can be invoked by a client to record data on the ledger or query such data. Smart Contracts are written in programming languages such as Go, Solidity, JavaScript and Kotlin. Smart Contracts usually record bare minimum information necessary to support transparency and trust required between members of the business network.
Well designed Smart Contracts share the same characteristics as Services shown in the list above. Smart contracts also have properties similar to “Classes & Objects”.
Properties of Smart Contracts
Smart contracts are granular and right sized, just enough to support a business function. An Invoice Contract for example provides basic functions to record and query data associated with an invoice that proves its authenticity and view the change history. Similarly, an ERC20 contract provides functions such as mint, send, balance, burn or redeem tokens.
Contracts are autonomous which allows them to be independently created, modified, deployed, maintained and governed.
They are stateless since every invocation of a transaction on a contract is independent of the previous one, and no transaction state is saved. They can however be programmed to receive a state as input or retrieve it from the world state in the persistent ledger. It is a good practice to design smart contracts as loosely coupled objects with no dependencies on other contracts.
They are location transparent and can be accessed by their “contract address” irrespective of where they are deployed. They are also independent of the language in which they have been coded.
Transactions on the blockchain are atomic by nature and are executed from start to completion independent of any other contract. Composite Smart Contracts will have to build in compensating transactions or be driven by workflow logic from the outside by the client.
Smart Contracts are self describing and have well defined contract interfaces. Discovery of smart contracts can be possible using a registry of some sort such as a Mongo collection where contract metadata must be pre-registered. Clients can discover contracts by performing a lookup on the registry. Anonymous discovery between contracts can be facilitated by a “Registry Smart Contract” whose address is known to the contract but hidden from the client.
The lifecycle of contracts is governed by policies. Some blockchains allow upgrade of the contracts like Hyperledger Fabric, while others like Ethereum treat a new version of the contract as new deployment. In Ethereum, contracts could be designed by splitting the Business Logic and the Data Recording Logic into separate contracts. New versions of the Business Contract can be deployed but connecting to the same Data Contract.
Contract addresses can be virtualized by using proxy contracts. This could protect clients from changes to smart contracts, thus providing backward and forward compatibility.
Composite Smart Contracts
Smart Contracts can be composed into higher level Composite Smart Contracts. For example the order, ship-notice and invoice smart contracts could be combined into a composite Order-Tracking Contract.
Summary
Smart Contracts can borrow from the same principles as Object Oriented Analysis and Design, and Service Oriented Architecture. The Blockchain serves as an Enterprise Contract Bus reacting to external events and triggering Smart Contracts. Applying appropriate design principles can ensure re-usability and extensibility of contracts. Some references used here include “Object Oriented Design with Applications by Grady Booch” and “Applied SOA by Michael Rosen et al”.
The ideas and opinions expressed in this article do not necessarily reflect the views of Chainyard or its leadership. Chainyard is a company that specializes in blockchain technology and helps organizations realize business networks from idea to production.