## 3 Proposed Method
### Subsequent Operations by Smart Contracts  
Once \(tx_{1}\) is disclosed in \(\hat{b}^{[i,j]}\) of \(\widehat{\mathbb{PC}}_{M}\), \(t_{M}\) checks its validity, if necessary, using the hash value recorded in \(b^{[i,j]}\) of \(\mathbb{PC}_{M}\). If the validity test fails, \(t_{M}\) disregards \(tx_{1}\), and no further actions are taken. This ensures that only valid transactions proceed, thereby maintaining the integrity of the system. On the other hand, if the validity test succeeds, \(t_{M}\) instructs  
Figure 2: Mapping between the platform chain \(\mathbb{PC}_{M}\) and the dual platform chain \(\widehat{\mathbb{PC}}_{M}\). (the smart contract specified in the output field of (9)) to request \(sc_{K}\) to verify whether the ownership of \(D_{K}\) belongs to \(u\) by executing the following transaction:  
\[tx_{2}=sc_{P}\to sc_{K}:\mathtt{Check}(D_{K}\in u), \tag{11}\]  
where the function Check returns 'True' if \(D_{K}\in u\), and 'False' otherwise. This transaction instructs \(sc_{K}\) to report the result of \(\mathtt{Check}(D_{K}\in u)\) back to \(sc_{P}\). If the return value of \(tx_{2}\) in (11) is 'True', then \(sc_{P}\) instructs one of the smart contracts in \(sc_{M}\), which is designed to act as an escrow service, to check whether the buyer \(v\) has transferred \(coin(L)\) to \(sc_{M}\) by executing  
\[tx_{3}=sc_{P}\to sc_{M}:\mathtt{Check}(v\to sc_{M}:coin(L)). \tag{12}\]  
Conversely, if the return value of \(tx_{2}\) is 'False', \(t_{M}\) disregards \(tx_{1}\) and no further actions are taken. Now, consider the case where \(v\) sends \(coin(L)\) to \(sc_{M}\), which is verifiable by the following transaction on \(\mathbb{RC}\):  
\[TX_{4}=v\to sc_{M}:coin(L),\mathtt{Cond} \tag{13}\]  
Through this transaction, \(v\) instructs \(sc_{M}\) to hold \(coin(L)\) under the conditions defined in Cond. Note that \(v\) could technically send \(coin(L)\) directly to \(u\) without using \(sc_{M}\). However, the proposed method enforces the use of \(sc_{M}\) as in \(TX_{4}\) to ensure the entire process remains visible in both \(\mathbb{PC}_{M}\) and \(\widehat{\mathbb{PC}}_{M}\). The smart contract \(sc_{M}\), specified in the output field of \(tx_{3}\) in (12), scans newly added blocks in \(\mathbb{RC}\) within a predefined time window to determine whether \(TX_{4}\) has been recorded. If it finds \(TX_{4}\), it returns 'True' to \(sc_{P}\), as specified in \(tx_{3}\). Otherwise, it returns 'False', and \(t_{M}\) disregards \(tx_{1}\), with no further action taken. Recall that the goal of \(tx_{1}\) is to transfer \(D_{K}\) from \(u\) to \(v\) at a sale price of \(coin(L)\). If both \(tx_{2}\) and \(tx_{3}\) return 'True' within the time period defined by \(T\) in Cond (see (10)), then \(sc_{P}\) proceeds to request \(sc_{K}\) to transfer \(D_{K}\) from \(u\) to \(v\), and \(sc_{M}\) to release \(coin(L)\) to \(u\) by executing  
\[tx_{5}=sc_{P}\to sc_{K}:\mathtt{Execute}(u\to v:D_{K}) \tag{14}\]  
\[tx_{6}=sc_{P}\to sc_{M}:\mathtt{Execute}(sc_{M}\to u:coin(L)) \tag{15}\]  
In response to \(tx_{5}\), \(sc_{K}\) updates the ownership of \(D_{K}\) in its internal memory from \(addr_{u}^{*}\) to \(addr_{v}^{*}\), which are the \(\mathbb{PC}_{M}\) addresses of \(u\) and \(v\), respectively. Likewise, in response to \(tx_{6}\), \(sc_{M}\) sends \(coin(L)\) to \(u\) by submitting the following transaction for registration in \(\mathbb{RC}\):  
\[TX_{7}=sc_{M}\to u:coin(L) \tag{16}\]  
The execution of \(tx_{1}\), and consequently the registration of \(tx_{2}\), \(tx_{3}\), \(tx_{5}\), \(tx_{6}\), and \(TX_{7}\), can only occur after \(tx_{1}\) is disclosed, i.e., only after \(B^{[n_{i+1}]}\), the \(\mathbb{RC}\) block finalizing the \(\mathbb{PC}_{M}\) segment containing \(tx_{1}\), has been mined. Note that \(B^{[n_{i+1}]}\) is also the starting point for the next \(\mathbb{PC}_{M}\) segment, \(b^{[i+1,1]}\), \(b^{[i+1,2]}\), \(\ldots\), \(b^{[i+1,N_{i+1}]}\).