Smart Contract Decision Model

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

The structural design of a smart contract impacts its execution cost. On a public blockchain, the cost of deploying a smart contract depends on the size of the smart contract(s). Further, additional fees need to be paid to embed data on a smart contract. Thus, the data storage fee is proportional to the size of the smart contract and its state. Besides, different structural designs of smart contracts may affect performance because of computational complexity and the required number of transactions to trigger relevant functions. The smart contract decision model is illustrated below.

The overall design goal of this decision model is to engineer multiple smart contracts. Different patterns could be selected to manage multiple smart contracts according to what they are expected to achieve. To maintain a central registry of all smart contracts related to an application, an on-chain contract registry could be used. Such a registry can maintain the mapping between user-defined symbolic names and blockchain addresses of smart contracts. The smart contract associated with a registered symbolic name could be upgraded by deploying a new version of the contract without breaking the dependencies with other smart contracts. When multiple contracts are different or customized instances of a standard smart contract are used, a factory contract could be used to generate smart contract instances from a contract template already deployed on the blockchain. A contract registry can be used to further record all the contract instances generated by a contract factory. A proxy contract enables upgradable smart contracts and access control on contract invocation. All the contract invocation calls go through the proxy, which in turn redirects the transaction to the latest version of the smart contract using a delegated call. Once a new version of the smart contract is deployed, the proxy could be updated to refer to the new contract. A proxy contract can serve other purposes, like enabling fee-less (aka., gas-less) transactions in public blockchains, where a transaction calls the proxy smart contract with a small or no transaction fee, which in turn pays a higher transaction fee from its account balance while making the delegated call.

The data contract pattern follows the software design principle of separating data from the business logic. A data contract embeds data and provides function calls to perform CRUD (Create, Read, Update, and Delete) operations on embedded data via authorized transactions. Similar to most of the on-chain patterns, the size of the data on-chain is restricted by the transaction and block size. The data contract pattern increase cost due to the increased size of smart contract code and added complexity in executing them.

Smart contracts are event-based programs that cannot execute autonomously. A transaction or another smart contract must trigger the state-changing functions defined in a smart contract. We may also want to run auxiliary functions asynchronously to perform tasks such as automatic dividend payouts and clean up expired records. To trigger such auxiliary functions, the incentive execution pattern could be used to provide a reward to the caller of the contract function. To further guarantee the execution of auxiliary functions, their logic could be integrated into regular functions calls using the embedded into other functions pattern.