Smart contracts execute on blockchains or off-chain and store results on the blockchain. The decentralized nature of blockchains is seen by many as an important characteristic of blockchains. [Heo 2003] characterized information systems in multiple dimensions and distinguished decentralized and distributed aspects; where decentralized computing is characterized by a number of isolated processors with highly decentralized processing and low connectivity; distributed computing is characterized by a number of networked processors with highly decentralized processing and high connectivity. More recently, ISO TC 307 has been developing standards on distributed ledger technologies and offers definitions [ISO 2019] to distinguish between distributed and decentralized systems. A distributed system is a system in which components located on networked computers communicate and coordinate their actions by interacting with each other. A decentralized system is a distributed system wherein control is distributed among the persons or organizations participating in the operation of the system; Noting that in a decentralized system, the distribution of control among persons or organizations participating in the system is determined by the system’s design. A Distributed Ledger (DL) is shared across a set of nodes and synchronized between the nodes using a consensus mechanism. A DL is designed to be tamper resistant, append-only and immutable containing confirmed and validated transactions [ISO 2019]. A DL, as the name suggests, is a distributed record of transactions, maintained by consensus among a network of peer to peer nodes (possibly geographically dispersed) [Kuhn 2019]. Smart contracts, then execute in a decentralized manner on the blockchain (or DL) or record their results in the blockchain (or DL), and smart contract transactions could span multiple platforms. The Entity-Relationship diagram below should help disambiguate this terminology.
Smart contracts execute in the context of a decentralized computing model, but the degree of distributed control differs by the design of the underlying blockchains (primarily the consensus mechanism). Ethereum and bitcoin have a monolithic execution model, where all participating nodes store all the state and execute every computation. This monolithic execution model has significant performance impacts. One group of proposals to improve performance is sharding. Sharding aims to split the state into shards which are distributed among groups of nodes. Performance improves if a transaction is localized entirely within a shard; recompilation problems can arise if the transaction is spread across shards [Chohan 2019]. Another proposed solution is Directed Acyclic Graphs (DAGs), which frames the ledger not as a set of blocks on a chain, but rather as leaves out of multiple branches. A general-purpose decentralized computing platform could be designed with a modular execution-model with secure specialized modules, for building decentralized applications that are currently insecure or impossible to implement with smart contracts [Alp 2019]. The computational environment can thus be seen as a spectrum between computing everything on all the nodes in a blockchain, computing on some of the nodes of a blockchain (with different options on how that subset of computational nodes are selected) , or computing offchain. Executing computational logic (e.g. the EVM) is but one aspect of a computing model. Computation requires also storage and communication aspects. In Ethereum the storage aspects are supported by IPFS and Swarm. Whisper has been proposed for decentalized messaging; but has achieved only limited support in Ethereum deployments.
As many researchers and practitioners are discussing blockchain, some of them are raising the question about the fundamental difference between blockchain and traditional database [Chowdhury 2018]. There is a striking resemblance with the flow of a transaction in a distributed database; the major difference being the consensus protocol: databases use two-phase commit or Paxos, whereas blockchains use Byzantine tolerant protocols or variants thereof. [Dinh 2018]. The table below summarizes the differences between decentralized blockchains and centralized databases. Centralized databases have significant performance advantages and are often optimized for specific types of data (e.g., relational databases optimized for keyed data in tables ) .
From a distributed computing perspective, a smart contract resembles an object (in an object-oriented programming language). A (smart contract) object encapsulates long-lived state, a constructor to initialize that state, and one or more functions (methods) to manage that state. Smart contracts can call one another’s functions. Smart contracts are run and verified in a distributed fashion in Ethereum; the solidity smart contract semantics, however, suggest that one can think of smart contracts as of sequential programs. Smart contracts’ concurrent executions can span multiple blockchain transactions (within the same block or in multiple blocks) and thereby violate desired safety properties. Accounts using smart contracts in a blockchain are like threads using concurrent objects in shared memory [Sergey 2017]. Reentrancy and recursive calls are examples of complex behavior enabled in smart contracts (and these underlay some well-known and expensive hacks of smart contracts) where solutions exist from concurrent computing; e.g., a monitor (a well-known design pattern in concurrent programming identified in the 1970s). A monitor is an object with a built-in mutex lock, which is acquired automatically when a method is called and released when the method returns. The correctness of a monitor implementation is determined by reasoning about the monitor invariant, an assertion that holds whenever no thread is executing in the monitor. The invariant can be violated while a thread is holding the monitor lock, but it must be restored when the thread releases the lock, either by returning from a method, or by suspending via wait() [Herlihy 2019]. Concurrent programming design patterns can help make identify and resolve many of the concurrency issues with smart contracts. Smart contracts also seem to fit the object-oriented view point with tokens emerging as more specific smart contracts with some standardized behaviors.
Service Oriented Computing is another modern software architectural paradigm where define services are software components that can be integrated into more complex distributed applications. Components encapsulate data to be fetched and visualized or integrated and/or application logic to be interacted with. [Daniel 2019] distinguishes the following smart contract types: generic contracts (implementing the application logic), libraries (stateless code meant for reuse), data contracts providing data storage services inside the blockchain), oracles (delivering data services from outside the blockchain). Integrating components requires common behavior patterns e.g. push, pull, or business-protocol based interactions. Ethereum supports transactions ( by users of the blockchain), events (enable a contract to push information to the outside world), calls ( messages to other contracts), and delegate calls ( invoking libraries). Data in Ethereum transactions and events is encoded using the Application Binary Interface (ABI), which specifies how functions are called and data are formatted. Clients either serialize data in a binary format on their own, or by using a suitable library function. The construct that gets closest to a description of Ethereum smart contracts is the so-called “ABI in JSON” interface description produced by the Solidity compiler [Daniel 2019]. Several challenges remain to fully enable service orientation via smart contracts including search discovery and reuse, cost awareness, performance, interoperability, standardization and composition. A related software paradigm is microservices. Microservices are small and autonomous services deployed independently, with a single and clearly defined purpose. [Tonelli 2019] provides an example of implementing some functionality as a set of smart contract microservices.
The database, object orientation, and service orientation viewpoints provide mainstream academic computer science perspectives on smart contracts; but what perspectives do practitioners actually need when developing smart contracts? [Bosu 2019] surveyed developers to capture their perspective on developing software for blockchains compared to non-blockchain environments. They noted that data stored in a blockchain is immutable (in other domains, there are several mechanisms to fix errors later by altering data); altering a blockchain ledger is almost impossible. Compared to the most non- blockchain applications that operate on centralized and/or hosted environments, dapps operate on a complex, secured, distributed and decentralized network. Blockchains use public key cryptography and cryptographic hash functions to store and verify transactions; cryptography is difficult to master and very few other domains require similar in-depth knowledge of cryptography as the blockchain domain. Moreover, knowledge of networking and networking security is required when developing for a distributed environment. The decentralized control environment also requires familiarity with consensus mechanisms, and the application itself may require domain specific knowledge (e.g. from finance industry). The developer requirement of having knowledge about diverse technological areas is a factor constraining software developers of smart contracts.
The smart contract computing context is quite complex, requiring in-depth knowledge of multiple disciplines (cryptography, networking, consensus mechanisms) and domain specific knowledge for the application. Traditional computing perspectives like databases, object orientation, concurrency, service orientation, etc., can provide some structure and alleviate some software development problems, but do not replace the need for application specific domains and in-depth blockchain implementation knowledge regarding cryptography, networking and consensus mechanisms. Much of the challenges comes from the early maturity of the implementations and the wide variety of different proposals. As the market develops, the range of practical alternative blockchains should narrow, tools improve, and the requisite body of knowledge stabilize; indeed these become prerequisites for enabling smart contracts to scale accessibility to a broader range of software developers.
References
[Alp 2019] E. Alp, et. al., “Rethinking General-Purpose Decentralized Computing.” Proc. of the Workshop on Hot Topics in Operating Systems. ACM, 2019.
[Bosu 2019] A. Bosu, et al., “Understanding the motivations, challenges and needs of blockchain software developers: A survey.” Empirical Software Engineering 24.4 (2019): 2636-2673.
[Chohan 2019] U. Chohan, “The Limits to Blockchain? Scaling vs. Decentralization.” (2019) SSRN.
[Chowdhury 2018] M. Chowdhury, et al., “Blockchain versus database: a critical analysis.” 17th Int’l Conf. on Trust, Security and Privacy in Computing and Communications/12th Int’l Conf. on Big Data Science and Engineering (TrustCom/BigDataSE). IEEE, 2018.
[Daniel 2019] F. Daniel, & L. Guida, “A service-oriented perspective on blockchain smart contracts.” IEEE Internet Computing 23.1 (2019): 46-53.
[Dinh 2018] T. Dinh, et al., “Untangling blockchain: A data processing view of blockchain systems.” IEEE Trans. on Knowledge and Data Engineering 30.7 (2018): 1366-1385.
[Heo 2003] J. Heo, & I. Han, “Performance measure of information systems (IS) in evolving computing environments: an empirical investigation.” Information & Management 40.4 (2003): 243-256.
[Herlihy 2019] M. Herlihy, “Blockchains from a distributed computing perspective.” Commun. ACM 62.2 (2019): 78-85.
[ISO 2019] ISO/DIS 22739 “Blockchain and distributed ledger technologies — Terminology”
[Sergey 2017] I.Sergey, & A. Hobor. “A concurrent perspective on smart contracts.” Int’l Conf. on Financial Cryptography and Data Security. Springer, Cham, 2017.
[Tonelli 2019] R. Tonelli, et al., “Implementing a microservices system with blockchain smart contracts.” 2019 IEEE Int’l Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, 2019.