## 3 Proposed Method
### Dual Platform Chain  
The subsequent actions for transaction \(tx_{1}\) in (9) are sequentially executed by pre-determined smart contracts once all conditions in (10) have been satisfied. However, for these actions to proceed, \(tx_{1}\) must first be registered in \(\mathbb{PC}_{M}\) by \(t_{M}\). To prevent \(t_{M}\) from selectively rejecting transactions for personal gain, the proposed method initially records only the hash value \(H(tx_{1})\) in \(\mathbb{PC}_{M}\) at the request of its creator (in the case of \(tx_{1}\), by \(u\)). Then, \(tx_{1}\) is disclosed in the _dual platform chain_\(\widehat{\mathbb{PC}}_{M}\) immediately after the \(\mathbb{PC}_{M}\) segment containing \(H(tx_{1})\) is connected to \(\mathbb{RC}\). Here, the dual platform chain \(\widehat{\mathbb{PC}}_{M}\) is defined as a sidechain of \(\mathbb{RC}\) with the same structure as \(\mathbb{PC}_{M}\), where the correspondence between \(\mathbb{PC}_{M}\) and \(\widehat{\mathbb{PC}}_{M}\) is established as follows: If a hash value \(H(tx)\) is registered in block \(b^{[i,j]}\) of \(\mathbb{PC}_{M}\), then transaction \(tx\) is disclosed in the corresponding block \(\hat{b}^{[i,j]}\) of \(\widehat{\mathbb{PC}}_{M}\). Conversely, if transaction \(tx\) is directly registered in block \(b^{[i,j]}\) of \(\mathbb{PC}_{M}\) without hashing, it is also placed in the corresponding block \(\hat{b}^{[i,j]}\) of \(\widehat{\mathbb{PC}}_{M}\). Figure 2 illustrates this scenario; each block \(b^{[i,j]}\) in \(\mathbb{PC}_{M}\) corresponds to a block \(b^{[i,j]}\) in \(\widehat{\mathbb{PC}}_{M}\) that discloses the transaction content associated with the hash values recorded in \(\mathbb{PC}_{M}\). To further explain how the proposed method prevents \(t_{M}\) from selectively rejecting or delaying the registration of certain transactions, let \(b^{[i,j]}\) be the \(\mathbb{PC}_{M}\) block containing \(H(tx_{1})\) in (9), and let \(B^{[i_{n+1}]}\) be the \(\mathbb{RC}\) block at which the \(\mathbb{PC}_{M}\) segment containing \(b^{[i,j]}\) ends. Once this segment of \(\mathbb{PC}_{M}\) is connected to \(B^{[i_{n+1}]}\), modifying or removing \(H(tx_{1})\) becomes virtually impossible, as it would require altering \(B^{[i_{n+1}]}\) and all subsequent blocksin \(\mathbb{RC}\). Additionally, the use of the random number \(r\) in (9) ensures that \(t_{M}\) cannot infer the content of \(tx_{1}\) from \(H(tx_{1})\) alone, thus providing no basis for selectively rejecting or delaying its registration. It is also worth noting that not all transactions are initially registered as hash values in \(\mathbb{PC}_{M}\). For example, transactions explicitly requested by their creator to be directly registered in \(\mathbb{PC}_{M}\), transactions generated by \(t_{M}\), and transactions occurring between smart contracts must be disclosed. Furthermore, any transaction intended for public visibility from the outset can be directly registered in \(\mathbb{PC}_{M}\). To make the process of disclosing transactions in \(\widehat{\mathbb{PC}}_{M}\) autonomous, the proposed method uses an independent entity \(D\) from \(t_{M}\), whose role is to store hashed transactions \(H(tx)\) and corresponding transactions \(tx\) uploaded from users, and to disclose \(tx\) in \(\widehat{\mathbb{PC}}_{M}\), after the \(\mathbb{PC}_{M}\) block containing \(H(tx)\) is connect to \(\mathbb{RC}\). Notice that the disclose of \(tx\) does not need help from \(t_{M}\). Anyone can provide the transaction, as long as its hash value matches the one in \(\mathbb{PC}_{M}\). The data warehouse \(D\) can make itself independent from \(t_{M}\) by providing a neutral mechanism that allows an anonymous uploading of \(H(tx)\) and \(E(tx)\) (the encryption of \(tx\) by a user) and the conditional decryption of \(E(tx)\) after the \(\mathbb{PC}_{M}\) block containing \(H(tx)\) is connected to \(\mathbb{RC}\).