## 2 Backgrounds and Related Works
### Accountain  
HMBS records the execution results of state-independent stateful smart contracts in its on-chain database. At first glance, recording the execution results of smart contracts seems unnecessary, since HMBS records exactly how every smart contract will be or was executed. This is, however, a necessary task for the parallelization of smart contract execution in HMBS. It records the results of smart contracts that were executed in the shard formed by a SC and dSC pair in the accountchain (AC), which is a blockchain that can be modified to provide the results of smart contract execution that will be trusted by nodes operating outside the corresponding shard, without demanding that they execute the same smart contract themselves. Here, we note that HMBS demands that AC can be modified to record the frequently changing smart contract states in AC blocks. The creation of the state-independent stateful smart contract \(sc\) in the transaction \(t_{k}^{[\sigma,n,j]}\) of \(\mathbb{S}_{\sigma}\) block in the segment \(\mathbb{S}_{\sigma}^{[n]}\) led to the creation of the contract account \(\text{CA}_{sc}\) in AC when \(\mathbb{S}_{\sigma}^{[n]}\) is connected to the MC block \(B^{[n_{i+1}]}\). Table 1 shows a list of the information stored in the contract account \(\text{CA}_{sc}\) of \(sc\). In Table 1, \(H(sc)\), the hash value of the smart contract \(sc\), binds \(sc\) to the contract account \(\text{CA}_{sc}\), and \(loc_{sc}\) represents the location of the transaction \(t\) where \(sc\) was created in HMBS. See (13). The state data \(state_{sc}\) of \(sc\) represent the cryptocurrency balance \(bal_{sc}\) and the state-dependent variable saves internal memory \(mem_{\text{CA}_{sc}}\). When \(\text{CA}_{sc}\) is created for the first time, the target value \(w_{sc}\) in Table 1 is computed by  
\[w_{sc}=H_{\lambda}(H(sc)||loc_{sc})||0\cdots 0), \tag{24}\]  
where \(H_{\lambda}\) is the first \(\lambda\)-bit truncation of the SHA-256 hash function \(H\), where \(1\leq\lambda\leq 256\), and \(0\cdots 0\) is the all zero bitstream of length 512 bits. The input value \(q_{sc}\) in Table 1 is a bitstream of length 256 bits, which are designed to make  
\[w_{sc}=H_{\lambda}(H(sc)||loc_{sc}||q_{sc}||H(state_{sc}||h)) \tag{25}\]  
holds for \(state_{sc}||h\), where \(h\) is the hash value of the latest block at the moment when \(q_{sc}\) is computed. In other words, \(q_{sc}\) is said to be the input value of \(state_{sc}\) for \(sc\) at the moment \begin{table}
\begin{tabular}{l l} \hline \hline
**Notation** & **Description** \\ \hline \(H(sc)\) & hash value of \(sc\) \\ \hline \(loc_{sc}\) & the location where \(sc\) was created in HMBS \\ \hline \(w_{sc}\) & target value of \(sc\) \\ \hline \(state_{sc}\) & state data of \(sc\) \\ \hline \(q_{sc}\) & input value of \(state_{sc}\) for \(sc\) \\ \hline \hline \end{tabular}
\end{table} 
Table 1: A list of information stored in contract account associated with the smart contract \(sc\). specified by \(h\) if, and only if, \(q_{sc}\) satisfies (25). The parameter \(\lambda\) in (25) determines the difficulty in computing the input value \(q_{sc}\). The AC block records multiple contract accounts. Let \(\mu_{1}^{[n]},\ldots,\mu_{c^{[n]}}^{[n]}\) be a collection of bitstreams representing the contract accounts (to be recorded in AC block \(A^{[n]}\)) of smart contracts \(sc_{1},\cdots,sc_{j[n]}\), where  
\[\mu_{i}^{[n]}=H(sc_{i})||loc_{sc_{i}}||w_{sc_{i}} \tag{26}\]  
and \(\tilde{c}^{[n]}\) is the number of contract accounts to be recorded in \(A^{[n]}\). The process of block mining in AC is identical to that in MC. The mining of AC block \(A^{[n]}\) needs to find a nonce \(\rho\), which makes  
\[H(g^{[n-1]}||\mu_{1}^{[n]}||\ldots||\mu_{c^{[n]}}^{[n]}||\rho)\in\mathcal{C} _{\Delta c}, \tag{27}\]  
where \(g^{[n-1]}\) is the hash value of the latest block \(A^{[n-1]}\) in AC and \(\mathcal{C}_{\Delta c}\) represents the condition determined by the consensus algorithm of AC.