## 4 Results
### Threat Analysis  
**Double UC spending in SC**: Suppose that a malicious user attempts to spend or has already spent a UC \(x\) by requesting that a \(x\)-spending transaction \(t_{1}\) is included in the SC block \(b_{\sigma}^{[n]}\) of the SC segment \(\mathbb{S}_{\sigma}^{[n]}\). Let \(t_{0}\) be the transaction that was used to spend the UC \(x\). For each UC, the proposed method specifies the SC in which it can be spent. In other words, \(x\)-spending transactions \(t_{0}\) and \(t_{1}\) must be recorded in some SC blocks in \(\mathbb{S}_{\sigma}\). Thus, the serial block-chaining structure in the SC \(\mathbb{S}_{\sigma}\) makes nodes in the \(\mathbb{S}_{\sigma}\) network ignore \(t_{1}\)'s request to be included in the SC block by knowing that \(t_{0}\) was already included in \(\mathbb{S}_{\sigma}\). **Double UC spending in MC**: In HMBS, the block chaining structure in MC is identical to that in SC. Thus, no user can spend UC twice in MC. **Haste UC spending in SC**: Suppose that a user attempts to spend a UC \(x\), which was designed to be spendable in \(\mathbb{S}_{\sigma}\) but was created in \(\mathbb{S}_{\sigma^{\prime}}\
eq\mathbb{S}_{\sigma}\). Let \(t\), \(b_{\sigma}^{[n]}\), and \(\mathbb{S}_{\sigma}^{[n]}\) be the planned transaction: to spend \(x\) in SC \(\mathbb{S}_{\sigma}\), the SC block to which \(t\) belongs, and the SC segment in which \(b_{\sigma}^{[n]}\) is to be recorded, respectively. Let \(t^{\prime}\) and \(\mathbb{S}_{\sigma^{\prime}}^{[n^{\prime}]}\) be the transaction that created the UC \(x\) in SC \(\mathbb{S}_{\sigma^{\prime}}\) and the SC segment in which \(t^{\prime}\) was recorded, respectively. In this case, the user can sephd the UC \(x\) through the transaction \(t\) if, and only if, the SC segment \(\mathbb{S}_{\sigma^{\prime}}^{[n^{\prime}]}\) was already connected to MC before the SC segment \(\mathbb{S}_{\sigma}^{[n]}\) was branched out  
Figure 1: The process of updating the state data of a state-dependent stateful smart contract \(sc\) in HMBS. from MC. In other words, the UC \(x\) isnot spendable until its creation is reported to the MC network. We now consider the case when the SC segment \(\mathbb{S}_{\sigma^{\prime}}^{[n^{\prime}]}\) is not yet connected to MC, while blocks in the SC segment \(\mathbb{S}_{\sigma^{\prime}}^{[n]}\) are being mined. We assume that the transaction \(t^{\prime}\) was recorded in \(\mathbb{S}_{\sigma^{\prime}}^{[n^{\prime}]}\), that is, the UC \(x\) was already created. In this case, it is possible that some miners in the \(\mathbb{S}_{\sigma}\) network might know the creation of the UC \(x\) in SC \(\mathbb{S}_{\sigma^{\prime}}\). HMBS, however, demands that miners in all SC networks determine the validity of the transaction \(t\) based on \(\mathbb{S}_{\sigma}\) blocks preceding \(b_{\sigma}^{[n,\bar{\bar{\sigma}}]}\) (the SC block to which \(t\) belongs) and the MC blocks preceding the MC block \(B^{[n]}\), from which the SC segment \(\mathbb{S}_{\sigma^{\prime}}^{[n]}\) is branched out. Since the transaction \(t^{\prime}\) is neither in \(\mathbb{S}_{\sigma}\) blocks preceding \(b_{\sigma}^{[n,\bar{\bar{\sigma}}]}\) nor in the MC blocks preceding the MC block \(B^{[n]}\), miners in the \(\mathbb{S}_{\sigma}\) network would regard the UC \(x\) as not yet created, and hence not spendable. It explains why the haste UC spending (the spending of a UC not known to whole nodes in the SC network where the UC can be spent) is not possible. **Haste UC spending in MC**: In HMBS, any UCs designed to be spendable in MC are only spendable after they are reported to MC and only through transactions in MC. This explains why the haste UC spending is not possible. **Replay of smart contract execution**: In HMBS, any smart contract execution in SC must be triggered by spending UCs. See (14). Thus, it is impossible to replay smart contract execution in SC. The same argument and results also hold for the replay of smart contract execution in MC.