# Smart Contract Design Pattern for Processing Logically Coherent Transaction Types
###### Abstract  
Recent research shows that the source code of smart contracts is often cloned. The processing of related types of transactions in blockchain networks results in the implementation of many similar smart contracts. The rules verifying transactions are therefore duplicated many times. The article introduces the _Adapt_ v2.0 smart contract design pattern. The design pattern employs a distinct configuration for each transaction type, and verification rule objects are shared among configurations. The redundancy of logical conditions was eliminated at two levels. Firstly, it is possible to combine similar smart contracts into one. Secondly, a configuration in a smart contract reuses verification rule objects at runtime. As a result, only one object is instantiated for each verification rule. It allows for the effective use of operating memory by the smart contract. The article presents the implementation of the pattern using object-oriented and functional programming mechanisms. Applying the pattern ensures the self-adaptability of a smart contract to any number of transaction types. The performance tests were carried out for various numbers of verification rules in a smart contract and a different number of checked transactions. The obtained evaluation time of 10,000,000 transactions is less than 0.25 s.  
blockchain; smart contract; object-oriented programming; functional programming; design pattern +
Footnote †: journal: Applied  
threat in smart contracts is a reentrancy attack. The authors propose using _Mutex Pattern_ or _Checks-Effects-Intenactions Pattern_ to eliminate that smart contract vulnerability. In the area of efficiency, Six et al. [5] pointed out patterns that enhance execution, storage, and redundancy aspects, e.g., _Incentive Execution_, _Limit Storage_, and _Avoid Redundant Operations_. In addition, researchers work on different ways to execute smart contracts on blockchain networks. Recently, Liu et al. [6] proposed parallel processing of transactions that increased the level of throughput. Design patterns are constantly evolving. Gupta et al. [7] proposed Proxy Smart Contracts that serve as intermediaries in the execution of the actual smart contracts. That pattern is used for the communication of on-chain smart contracts with off-chain services. Another software design pattern that has been employed for blockchain smart contracts is the _Delegation Pattern_. Kim et al. [8] have applied it to the construction of updatable smart contracts to provide federated authentication schemes. Additionally, _Proxy_ and _Delegation_ patterns are typically used in the upgrading mechanism of Ethereum smart contracts [9]. A different manner of standardizing the design of smart contracts is applying templates. Chu et al. [10] review works that not only identify vulnerabilities, but also offer mechanisms and tools to eliminate them. They show the currently developed mechanisms used to repair vulnerabilities of smart contracts operating in off-chain and on-chain modes. However, the currently developed design patterns for smart contracts do not cover the subject of their reconfiguration, in particular the possibility of adapting to various types of processed transactions. A smart contract can perform the same operation for logically consistent but different types of transactions. That may include, e.g., on-chain and off-chain transactions, authentication and authorization in the system for different roles, in-community and cross-community energy transfers, and domestic and foreign contract management for the cross-border labor market. Hence, a need to define a smart contract design pattern that would enable operations on various types of transactions. Gorski presented the design pattern for reconfigurable smart contracts in [11]. However, it only allowed operation on two types of transactions. In addition, the reconfiguration of the smart contract entailed the need to create new objects of verification rule classes. As a result, it engaged the garbage collector every time the transaction type changed.