## 3 Proposed Methodology
### Consensus Mechanism in OSCMS
#### 3.5.2 Delegate Elections  
The P2P network, composed of all nodes in the blockchain system, constitutes the whole network environment. The set of all nodes is expressed as \(N\), whose size is \(n(n>0)\), each node is expressed as \(N_{i}(i\in[1,n],N_{i}\in N)\) and all but unidentified users can be voters. We use \(N^{C}\) to represent the set of all candidate nodes, with its size as \(c(c\leqslant n,N^{C}\in N)\). \(N^{D}\) represents delegate node sets with size \(d(d\leqslant c,N^{D}\in N^{C})\), who are miners in this epoch. DPoS requires a \(3f+1\) fault tolerance [56]. We assume the majority of miners (i.e., more than \(2/3\)) are honest and will produce blocks in their time windows (except for when obtaining election results or counting rewards), meaning that the network can operate securely. In the triple-blockchain architecture of the OSCMS, each blockchain carries out a DPoS consensus independently, only utilizing the irreversibility of blocks in DPoS to share election results, without changing the Byzantine fault tolerance and robustness of DPoS. The white paper [21] analyzes the working principle and robustness of the DPoS consensus algorithm, which can be fully utilized by the consensus mechanism in the OSCMS. Only RSCChain needs to set tokens to solve fund transfer transactions, as delegates are elected through tokens in it. The election process includes voting and selecting the top \(d\) nodes as delegates. We use a voting smart contract to implement voting, which is pre-deployed in the RSCChain. The brief pseudo code is shown in Algorithm 7. Miners in the first epoch are recorded in three genesis blocks. Without losing generality, we discuss the election process in the \(k\)-th epoch, which can be analogized to other epochs. Step 1: Node \(N_{i}(N_{i}\in N^{C})\) calls the applyCandidate method with a fixed deposit amount. This transaction is broadcast to the blockchain network. Step 2: Current miners pre-verify it, that is, call the RPC interface of the OIChain locally to query whether \(N_{i}\) has the developer identity. If this transaction is not discarded due to a failure of pre-verification, it will be executed. If \(N_{i}\) is already a candidate or the deposit is not enough, the call fails. After passing, this candidate will be added to currentRecord and epoch_Record. Step 3: Node \(N_{i}\) can call the exitCandidate method to exit the candidate. Step 4: If \(N_{i}\) is one of the current miners, the transaction will be discarded by the miners. We avoid the same node producing blocks in two consecutive epochs, so \(N_{i}\) can exit in the next epoch. If \(N_{i}\) is not the candidate, the call fails. Otherwise, the deposit tokens of \(N_{i}\) and relevant voters will be returned, and the candidate and voting records will be deleted. Step 5: For candidate \(N_{i}\), any node with identity can call the vote or withdrawVote method repeatedly, and the total deposit of a voter cannot exceed a certain value. Before that, voters can refer to the decentralized reputation of candidates in the OSCMS. Step 6: If the above transactions are executed successfully, currentRecord and epoch_Record will be updated. Historical records can be used for reward distribution. These four methods are prohibited from being called during the first \(3d\) blocks and the last \(d\) blocks of each epoch. The total amount of tokens voted by all voters for \(N_{i}\) will be counted in totalVotedToken:  
\[V_{i}=currentRecord.candidate\_voteInfo[N_{i}] \tag{16}\]  
\[totalVotedToken=\sum_{V_{i},\mathit{voters}}V_{i}.\mathit{voter}token[ voter] \tag{17}\]  
Step 7: When the miner produces the checkpoint (the \(d\)-th block from bottom in the \(k\)-th epoch), according to the descending order of totalVotedToken, \(d\) candidates excluding current miners will be new delegates \(N^{D}\) of the next epoch and recorded in this block header. If subsequent miners obtain the same \(N^{D}\), they will continue to produce blocks until the epoch switches and new miners start working.