## 3 Proposed Method
### Smart Contract-Guided Transaction Registration  
In the previous section, we proposed constructing \(\mathbb{PC}_{M}\) as a sidechain of \(\mathbb{RC}\), where \(t_{M}\), the designated miner of the platform chain \(\mathbb{PC}_{M}\), holds minimal influence. This design serves to mitigate arbitrary behavior by \(t_{M}\). In this section, we introduce an additional safeguard against misuse: smart-contract-guided transaction registration. To enhance clarity, we now present a concrete example. Assume that the digital asset traded in DATP \(M\) is derived from a specific type of physical asset. Specifically, let \(D_{K}\) represent the digitized ownership of certain rights associated with a physical asset, denoted by \(PA_{K}\), which is uniquely identified by \(K\). Let \(sc_{K}\) denote the smart contract deployed on \(\mathbb{PC}_{M}\) to manage \(D_{K}\). Suppose user \(u\) owns \(D_{K}\). This means that \(u\) can generate a valid digital signature using the private key corresponding to the public key linked to \(D_{K}\). In this case, \(D_{K}\) is uniquely represented by a blockchain token, and \(sc_{K}\) ensures that \(u\) retains exclusive control over it. The specific enforcement mechanism depends not only on the physical properties of \(PA_{K}\) but also on the legal status of \(D_{K}\). For instance, if \(PA_{K}\) is an electric vehicle and \(D_{K}\) represents the right to operate it, then \(sc_{K}\) may enforce ownership by allowing only users with a valid digital signature linked to \(D_{K}\) to start the engine of \(PA_{K}\). This paper does not elaborate on the exact mechanism through which \(sc_{K}\) enforces the ownership of \(D_{K}\). Furthermore, the process of blockchain tokenization for \(D_{K}\) is beyond the scope of this work. For a detailed discussion on blockchain tokenization, see [21]. Figure 1: Anchoring of platform chain segments to the reference chain. The proposed method restricts the transactions that can be registered on \(\mathbb{PC}_{M}\) to those that request specific operations from \(sc_{P}\), a set of predefined smart contracts announced in (6), as well as additional operation requests or public disclosures of results generated during the execution of these smart contracts. In other words, this approach limits the transactions registered on \(\mathbb{PC}_{M}\) to predefined operations, thereby simplifying the procedures required to verify their validity. For example, suppose that \(u\) agrees to transfer their ownership of \(D_{K}\) to \(v\) in exchange for \(coin(L)\), which represents \(L\) units of \(coin\). To complete this transaction, \(u\) must execute a predefined smart contract \(sc_{P}\) on \(\mathbb{PC}_{M}\), which is designed to transfer ownership of the \(\mathbb{PC}_{M}\) tokens, by submitting the following transaction for registration on \(\mathbb{PC}_{M}\),  
\[tx_{1}=u\to sc_{P}:\texttt{Cond},n,r \tag{9}\]  
where \(n\) is a nonce used to prevent \(tx_{1}\) from being replayed, and \(r\) is a random number chosen by \(u\) to ensure that \(tx_{1}\) cannot be predicted from its hash value. The reason for this will be explained in the next section. Here, recall that the digital signature \(DS_{u}(tx_{1})\) by \(u\) on \(tx_{1}\) is omitted for simplicity. This transaction triggers the execution of \(sc_{P}\) under the predefined conditions \(\texttt{Cond}\), which include details such as the digital asset \(D_{K}\), the addresses of the seller \(u\) and the buyer \(v\) in both \(\mathbb{RC}\) and \(\mathbb{PC}_{M}\), the sale price \(coin(L)\), and the time limit \(T\). We represent these dependencies as follows:  
\[\texttt{Cond}=\texttt{Cond}(D_{K},u,v,u^{*},v^{*},L,T), \tag{10}\]  
where, for clarity, \(u\) and \(v\) denote the addresses of the participants in \(\mathbb{RC}\), while \(u^{*}\) and \(v^{*}\) represent their corresponding addresses in \(\mathbb{PC}_{M}\). The procedures following the registration of \(tx_{1}\) will be discussed in the next section.