## 2 Backgrounds and Related Works
### Smart Contracts  
In this study, smart contracts are classified into the following three types according to the scope of the execution effect on the blockchain state. When given as the following functions:  
* **stateless** smart contract uses and returns state-independent input and output, respectively,
* **state-independent stateful** smart contract uses a state-independent input and returns a state-dependent output, and
* **state-dependent stateful** smart contract uses state-dependent input and output, respectively. We can execute the stateless smart contract independently from other smart contracts since the execution of the stateless smart contract does not affect them and is not affected by them. Thus, we can execute the stateless smart contract in any shard without updating the blockchain state. On the other hand, we can execute the state-independent stateful smart contract out of order, but we must update the execution result to the blockchain state before we execute state-dependent stateful smart contracts. This restriction also holds for the state-dependent stateful smart contract. Moreover, we must execute the state-dependent stateful smart contract with full knowledge of the blockchain state. Thus indicates that the execution of a series of state-dependent stateful smart contracts must be carried out in series. A suggestion that derives this study on the parallelization of smart contract execution is that the user must execute the smart contract that is programmed for parallelization if he or she wishes to benefit from the parallel computation. For the execution result of a smart contract in one shard to be recognized in the entire blockchain network without updating the state, that smart contract must be programmed to be stateless. On the other hand, the state-independent stateful smart contract can be executed in one shard, but the state needs to be immediately updated according to the execution result. As mentioned earlier, state-dependent stateful smart contracts cannot benefit from parallelization through sharding. In other words, parallelizing smart contract execution must avoid using state-dependent stateful smart contracts as much as possible. The creation of a new smart contract \(sc\) is achieved by recording the following transaction on HMBS:  
\[t:x\to \begin{cases}addr_{zero}:sc,id,\eta,\\addr_{1}:v-\eta\end{cases} ||\;\;\;\mathcal{DS}_{sk(\mathcal{X})}, \tag{13}\]  
where \(x\) is the UC, \(addr_{zero}\) is the special address whose bits are all 0, \(id\) represents which class (stateless, state-independent stateful, or state-dependent stateful) \(sc\) belongs to, \(\eta>0\) represents the HMBS cryptocurrency value as a fee to a miner for including the transaction \(t\) in his or her block, \(v\) is the value of UC \(x\), and \(addr_{1}\) is the address of UC, which receives the change \(v-\eta\). Here, we note that the transaction \(t\) in (13) must be recorded in the shard in which \(x\in\mathcal{S}_{i}\). When the smart contract \(sc\) is created by the blockchain registration of the transaction \(t\) in (13), a _Contract Account_ (CA) of \(sc\) is created. CA of \(sc\) has the address \(addr_{sc}\)the cryptocurrency balance \(bal_{sc}\), and the internal memory \(mem_{sc}\) to save data for its state-dependent variables. Here, \(addr_{sc}\) is the combination of the \(addr\) and \(loc\) (see (4)) of the UC used to create the smart contract \(sc\). Here, we note that UC used to create the smart contract \(sc\) is destroyed immediately after being spent, so smart contracts with duplicated addresses cannot exist. The execution of the stateless or state-independent stateful smart contract \(sc\) is requested by registering the following transaction, which spends a UC \(x\) to send the fund to the contract account address \(addr_{sc}\) to HMBS:  
\[t:x\rightarrow \begin{cases}addr_{sc}:\theta,\epsilon,\\addr_{1}:v-\theta-\epsilon,\\addr_{2}\end{cases}