Abstract
Smart contracts are required to be instantiated in the predeployed stage, which consumes computation resources from then on. It is a big waste in the blockchain whose nodes are composed of IoT devices, as those devices often have limited resources (such as limited power supplies or a limited number of processes to run). Meanwhile, IoT devices are heterogeneous and different smart contracts are required. If those smart contracts are instantiated previously, numerous meaningless addresses are required. In this paper, we propose to delay the instantiation of a smart contract when used and terminate it when not used, which is similar to the life cycle of a variable. Then, a new kind of variable (the wrapping variable) is used to hide details of the instantiation and the address. The smart contract is instantiated in the construction function of the wrapping variable, or even it is delayed to the time when there are requests for it. The smart contract terminates when the variable is out of its scope. Then, different instantiation methods are proposed. Finally, we perform the qualitative comparison between the proposed approach and the predeployment method, and it demonstrates that the proposed methods optimize the life cycle of the smart contract and save calculation resources.
1. Introduction
Smart contracts are widely used in the cooperation between blockchains and IoT devices, with the aim of achieving reliability, security, and trust [1, 2]. To manage numerous IoT devices, smart contracts are used to control and configure IoT devices in a secure way [3]. For the efficient data aggregation [4] in IoT, [5] proposes an aggregation way with privacy preserved. As intrusion detection is important in IoT [6, 7], a collaborative intrusion detection based on smart contracts is proposed [8]. For the interaction with the nonblockchain system (like IoT), [9] proposes a direct interaction way without an oracle [10].
Currently, smart contracts are required to be deployed previously [11], which preinstantiates the smart contracts [12, 13]. The instance of a smart contract occupies calculation resources (including the memory, CPU, or disk space) of blockchain nodes. Even when there is no request for a smart contract, its instance is not terminated and the resources are occupied. This is suitable in the blockchain whose nodes have external power supplies (such as a PC or a server), while blockchain nodes may be composed of IoT devices [14]. The resources of IoT devices are often limited [15, 16], such as limited power supply or a limited number of processes to run. Then, it is fatal to delay or reduce requests for a smart contract to save power.
Meanwhile, a unique address [17, 18] or identifier is required to access a smart contract in the predeployment method. IoT devices are of big amount (more than 30 billion in 2020 (https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/)) and various types, which results in various smart contracts. If we instantiate those smart contracts previously, users have to use numerous meaningless addresses to interact with blockchains. Some deployment tools [19] or platforms [20, 21] facilitate the deployment process. However, this process makes the instantiation details being exposed to the callers (smart contract author or its user) and forces the callers to use the addresses of smart contracts. Figure 1 shows an example.
In this paper, we propose the methods to delay the instantiation of a smart contract after the smart contract has been deployed and to perform the destruction of a smart contract timely to save calculation resources. This way is similar to the life cycle management of a local variable. Then, we propose to use variables to wrap the instantiation steps of smart contracts. The details of the deployment of a smart contract are not exposed to the caller, which is performed in the background.
The major contributions of this paper are as follows. (1)We propose to create a smart contract instance when there are requests for it and terminate the instance when it is not used (out of its usage scope), which is similar to a local variable. It is aimed at delaying the instantiation of a smart contract and terminating a smart contract in time(2)We propose to adopt a new kind of variable to hide the details of the instantiation and termination. This kind of variety is called the wrapping variable. The caller only needs to create a wrapping variable, and in its construction, the smart contract is instantiated. When the variable is out of its scope, the smart contract terminates. It only needs to control a variable to optimize the life cycle of a smart contract. This method also facilitates one smart contract to invoke another smart contract, in which the latter is a local variable(3)We propose two instantiation methods: instant instantiation and postinstantiation. Instant instantiation creates a smart contract instance when its wrapping variable is created. Postinstantiation creates the smart contract instance when there are real invocations to the wrapping variable
The rest of this paper is organized as follows. Section 2 describes different instantiation methods. Section 3 shows the simulation results and the corresponding analysis. Section 4 gives the summary and concludes the paper.
2. Instantiation Methods
2.1. Motivation
Currently, the smart contract instantiation is done before the execution, and this procedure is called deployment. It has some disadvantages as described in Introduction. However, a smart contract can be used as the way that a variable is used—it is dynamically instantiated and terminated. It shortens the runtime of a smart contract. In this method, the instantiation is performed when there are invocations of a smart contract. When it is not used or out of its usage scope, the termination of a smart contract is performed. It also facilitates the usage of a smart contract to use a variable instead of the global address of the deployed smart contract.
2.2. Different Instantiation Methods
We can instantiate an instance beforehand or delay the instantiation when there is a function call (invocation) to the smart contract. Figure 2 shows three possible instantiation methods.
2.2.1. Preinstantiation Method
This is the currently used method, in which the instantiation is performed before the real execution. The instance is associated with an address (or other unique identifiers), which is used to look up the smart contract instance and dispatch corresponding invocations to it. However, this instance may run without any invocation for a long time (in a waiting state). When there are no invocations, the smart contract still resides in the memory until it has been obviously been terminated. It is shown in the “preinstantiation” part of Figure 2.
2.2.2. Instant Instantiation
In this method, a smart contract is instantiated when it has been called by another smart contract or a user. (1) If smart contract is invoked by smart contract , creates a variable which wraps . Variable instantiates smart contract in its constructor. Successive access to the instance of is through variable . (2) If it is called by a user, the instantiation is triggered by the blockchain platform when its user sends a transaction to trigger its function. Then, the request is passed to the newly created instance. In both cases, there is no need to give an address to the caller. Then, a new kind of variety is proposed to access the smart contract instance. In this paper, we define a new class (Java class) to stand for this kind of variable.
The instance is terminated when the variable is not required; either the calling smart contract exits or the variable is out of its scope. The scope of a variable further shortens the runtime of a smart contract instance. If we put the variable into a smaller scope, the variable lives only in this scope. There is a difference between the normal variable termination and the variable for the smart contract. The latter one requires that the execution results of the smart contract have been confirmed in the blockchain. After the confirmation, the blockchain consensus protocol enforces the correctness of this smart contract [14].
For other methods of the smart contract, the corresponding variable forwards it to the smart contract. As the smart contract is running in a different process, the method invocation is done by the interprocess communication (IPC) on each node, while this is hidden in the implementation of the variable. Figure 3 shows the relationship between the variable and the smart contract.
Instant instantiation facilitates the invocation of different smart contracts. The caller does not need to care about the instantiation and termination of a smart contract. Further, the caller is not required to access a smart contract by a string of meaningless numbers (the address of a smart contract in the predeployment method). Algorithm 1 is an example.
| ||||||||||||||||||||||||||||||||||||||
Algorithm 1. Smart contract invocation by a variable. | ||||||||||||||||||||||||||||||||||||||
From Algorithm 1, we know that instances of smart contracts SCA and SCB are created and sealed in variables at lines 12 and 16, and then, their methods are accessed by those two variables. Those variables are automatically deconstructed at the end of this scope (line 18).
2.2.3. Postinstantiation (Lazy Instantiation)
When some methods of a smart contract are invoked, the instance of the smart contract does not have to be created. For example, a caller updates a value to a smart contract continuously and no users retrieve this value. During this time, it is not necessary to have an instance. We can cache those updating methods in the variable and only instantiate the smart contract when a user tries to get the value. Figure 4 shows this process.
Postinstantiation is that a smart contract is instantiated when there is a request that its instance has to be created. The corresponding request is called the instantiation must request or method (IMR), and other requests are called the instantiation unnecessary request or method (IUR). Postinstantiation is aimed at delaying the instantiation of the smart contract. IUR requests sent before IMR are cached. Those logics are inside the variable, which is illustrated in Algorithm 2.
| ||||||||||||||||||||||||||
Algorithm 2. Handling for IMR and IUR. | ||||||||||||||||||||||||||
The postinstantiation delays the instantiation before IMR. And if the user has not sent any IMR, the instance can even be avoided. In this case, it is still traceable, as the transaction to invoke the smart contract is stored in the blockchain.
2.3. Resource Analysis
In this section, we analyze the resources (CPU and memory) saved by the dynamical instantiation and termination. We regard a smart contract () as a collection of smart contract copies () running on different nodes. The notation of denotes the smart contract copy () on different node shown as follows.
When the smart contract is instantiated, it occupies corresponding resources, such as memory and CPU. We use to denote its resources on node .
Node resources are occupied during the time from the instantiation to the termination. We use to denote the resources occupied at time ; is the time of the instantiation, and is the time of the termination. The resources over time are shown in
Suppose the time of the first invocation is and the time of the last invocation is . Then, the relationship between the invocation time and the resource occupation time is shown in
For the preinstantiated method, this may be a very long time or even there is no invocation after the smart contract has been instantiated. It occupies resources longer than the instant instantiation. The postinstantiation has the least resource occupation time, as its instantiation time () is not earlier than the time of the first IMR invocation, shown in (6). Then, we get the conclusion that the instant instantiation and the postinstantiation occupy the resource in less time than the predeployment method.
We define a variable to measure the time saved by different instantiation methods, which is shown in (7). If its value is positive, it saves the waiting time, which is the postinstantiation case. If it is close to 0, the runtime of the smart contract instance is approximately equal to the invocation last time, which is the instant instantiation case. If its value is negative, it spends time waiting for requests, which is the predeployment case.
The total runtime saved () is the summarization of all nodes which run the smart contract, shown in (8). Thus, it saves more resources in the larger blockchain networks as their node number is more.
3. Verification
In this section, we show our simulation results of different instantiation methods. As the smart contracts are required to be preinstantiated in currently available blockchains, we develop a blockchain that supports different instantiation types. It removes the requirement to preinstantiate a smart contract and keeps the procedure to put the code of a smart contract to the blockchain in the predeployment stage.
The smart contract language is Java. There are two reasons. (1) The blockchain platform is developed by Java, and all nodes have the JRE (Java runtime environment) to run the Java code. Then, it saves the steps to provide an extra runtime environment for another language. (2) It is convenient to invoke smart contracts by the reflection mechanism of Java. User-defined smart contracts can be simply invoked in this way.
We provide a class as the variable to wrap the smart contract instance. It wraps behaviors that are required for different instantiation methods. The instantiation type is set in the configuration file of the smart contract. If the instantiation type is preinstantiation, its instance is created in the code putting procedure. If it is the instant instantiation, the instance is created when its creation function is called. If it is the postinstantiation, the instance is created when the specific methods are called. Those methods have calls to a platform function call which creates the instances.
There is special handling for the termination of a variable. When a variable is out of its (definition and usage) scope, the compiler can add the corresponding code there. As we do not want to change the Java compiler, we directly put a function to terminate the smart contract instance at the end of its scope. Meanwhile, the termination function calls a function (the final checking function or FCF) which checks whether the key states of a smart contract have been sealed in the blockchain. If not sealed, FCF waits and checks. Otherwise, it exits and the smart contract destructs to release resources.
We use the file method as the interprocess communication between the process of the wrapping variable and smart contract instance as they run in different processes. The variable passes the function name and its parameters to corresponding request files, and the smart contract instance reads from those files continuously. The smart instance invokes the corresponding functions by a Java reflect mechanism.
Two kinds of verifications are carried out. (1) We perform the comparative verification between the proposed method and the preinstantiation method. It is aimed at showing the benefit of the proposed instantiation methods. (2) We also perform the verification of different instantiation methods proposed in this paper to demonstrate the advantages of different methods.
3.1. Comparison between the Preinstantiation Method and Proposed Method
We adopt the runtime of smart contracts to compare those two methods. The proposed instantiation is triggered by a transaction when the first request is sent from the user. In the preinstantiation method, the smart contract is preinstantiated in the predeployment stage and its instance keeps running from then on. Requests for both methods are sent out by a script in a random interval (the interval changes from 40 seconds to 80 seconds).
Figure 5 shows the accumulated runtime () of those two methods. The accumulated runtime is the summarization of the runtime of all instances, as shown in (9). In the proposed method, there may be several instances during a test round and thus is the summarization of the runtime of all instances. In the preinstantiation method, there is only one instance and is equal to the runtime of that instance. The runtime () of instance is from the moment of its instantiation to the moment of its termination, which contains the code execution time () and the waiting time (), as shown in (10).
From Figure 5, we see that the preinstantiation method takes more runtime than the proposed method. The reason is as follows. In (10), time of the proposed method is less than that of the preinstantiation method, because the waiting time is saved as each instance of the proposed method is terminated when not used. However, time of the proposed method is more, as it instantiates a smart contract several times, while time is much bigger than time in this verification.
At the first invocation, the preinstantiation method has taken 52 seconds more. This value is the interval between the first invocation and the preinstantiation. As there are intervals among invocations, the additional runtime taken by the preinstantiation increases. In fact, the runtime of the preinstantiation method is the time after it has been instantiated. The instance in the proposed method is only created when there is request, and it does not occupy the interval time between different smart contract instances.
3.2. Different Instantiation Methods
In this section, we verify two optimizations for the proposed methods. One is the postinstantiation, and another one is to define the variable of the smart contract instance in a smaller scope (a local variable). We combine those two optimizations and get four kinds of possible instantiation optimization, shown in Table 1.
The according codes are shown in Algorithm 3. Two smart contracts are used: smart contracts SCX and SCY. SCY does different instantiations of SCX as shown in Table 1. It results in four subtypes of SCY: SCY-A, SCY-B, SCY-C, and SCY-D. SCX has two subtypes: SCXI and SCX-Post, and the latter one is the postinstantiated. And SCX provides two methods: the first one is not an instantiation must method and the second is an instantiation must method.
We have performed 28 test rounds. In those test rounds, verifications of combinations A, B, C, and D are tested in turn. The test results are shown in Figure 6. From it, we see that smart contract SCX in type A has the longest runtime, which is shown in the first part of Figure 6. SCX is created when its according variable is created and lives until SCY-A terminates. SCX in SCY-D has the shortest runtime, which is shown in the last part of Figure 6. The reason is that SCX is created until its second method is created (the instantiation must method), and it is defined in a smaller scope, which makes it terminate early.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Algorithm 3. Different instantiation combinations. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(a)
(b)
(c)
(d)
The other two methods take less time than the first one and more time than the last one. The second one delays the instantiation time of smart contract SCX, and the third one defines smart contract SCY in a smaller scope. Then, both save the runtime.
We also demonstrate the accumulated runtime in Figure 6, which is the summarization of the runtime of the instances in previous test rounds. From it, we can see that the accumulated runtime of SCX and SCY is very close in case A, which indicates that SCX lives along with SCY. On the other hand, the curve of the accumulated runtime of SCX and SCY forms a big angle in case D, which indicates that the execution time of SCX is shorter than that of SCY and it is optimized to save the additional resource occupation time.
As the time SCY also changes with time, and to have a more comparison of how the proportion of the runtime is saved, we use another measurement, , which is the ratio of the runtime of the smart contract SCX to the runtime of smart contract SCY, referring to (11). The result is shown in Figure 7.
From Figure 7, we also see the same optimization results. In method A, SCX runs at the most time when SCY runs and has the highest , and method D has the lowest . The two left methods have the medium .
4. Conclusion
In this paper, we address the preinstantiation issues of smart contracts for IoT scenarios, in which blockchain nodes are composed of resource-limited IoT devices. We propose different instantiation methods to optimize the instantiation of a smart contract, with the aim of solving the issues of the preinstantiation (it occupies computation resources even if there is no request and requires a global address). We adopt a new kind of variable to wrap the instantiation and termination of a smart contract. The smart contract instantiates when its wrapping variable is created, and it can even delay the instantiation to the moment when an instance is a must. The termination of a smart contract is performed when the variable is out of scope. At last, we perform the corresponding verifications, which show that our proposed methods occupy fewer resources (measured by the runtime). More resources can be saved if we combined different instantiation methods.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported in part by the National Natural Science Foundation of China under Grant No. 61772352; the National Key Research and Development Project under Grant Nos. 2020YFB1711800 and 2020YFB1707900; the Science and Technology Project of Sichuan Province under Grant Nos. 2019YFG0400, 2020YFG0479, and 2020YFG0322; and the R&D Project of Chengdu City under Grant No. 2019-YF05-01790-GX.