## 3 Proposed Methodology
### Consensus Mechanism in OSCMS
#### 3.5.4 Incentive Tactic  
A general incentive tactic is that each valid block brings fixed rewards. However, the number of blocks produced by a miner does not affect the rewards brought by each block, which is not conducive to promoting miners to produce as many blocks as possible. Using an exponential function reward can improve it.  
For each blockchain, the current number of blocks produced by each miner in the \(k\)-th epoch is recorded in each block header:  
\[\textit{miner\_workload}=\{\{\textit{miner}_{1},\textit{number}_{1}\},\{ \textit{miner}_{2},\textit{number}_{2}\},\{\textit{miner}_{3},\textit{number}_{ 3}\},...,\{\textit{miner}_{d},\textit{number}_{d}\}\} \tag{18}\]  
It is necessary to count each miner's workload, which is the sum of \(\textit{miner\_workload}\) recorded in the endpoint (the last block in the \(k\)-th epoch) of three blockchains. According to Sections 3.5.2 and 3.5.3, the election result recorded in a checkpoint is irreversible after the endpoint and can be used securely. As shown in Figure 8, before the checkpoints in the OICChain and CFChain are produced, it must be confirmed that the endpoint in the RSCChain exists. Similarly, after \(d\) blocks in the \((k+1)\)-th epoch, the \(\textit{miner\_workload}\) recorded in the previous endpoint can be reached by a consensus of the new miners and used securely. When the \((2d+1)\)-th block in the \((k+1)\)-th epoch is produced (countpoint) in the RSCChain, it must be confirmed that the \(d\)-th block in the \((k+1)\)-th epoch exists in the OICChain and CFChain. In countpoint of RSCChain, the total workload in three blockchains can be counted and recorded. Only when a valid block is produced in each time window will the corresponding relationship between blocks and time windows be as shown in Figure 8. Otherwise, there will be some synchronization waiting, which does not affect the above steps. The mutual confirmation of the block heights keeps the blockchains synchronized during epoch switching, so that the shared election results are within the timelines.  
After a round of consensus on the countpoint of RSCChain, that is, after the \(3d\)-th block in the \((k+1)\)-th epoch, tokens are awarded exponentially:  
\[reward(m)=\alpha^{m} \tag{19}\]  
where \(m\) is the total number of blocks actually produced by a miner in three blockchains in the \(k\) -th epoch. \(\alpha\) can be calculated by:  
\[\alpha^{m_{max}}=\beta m^{max} \tag{20}\]  
where \(\beta\) is rewards for a valid block in conventional linear reward schemes. If each miner has produced a valid block in each allocated time window, \(m\) will be \(m_{max}\).  
The voters of the miner will obtain 20% of its rewards according to the proportion of votes.  
Delegates can vote for a malicious or too slothful delegate in blocks they produce and collect votes from other blocks. Once a node has \((2/3)d\) votes in a blockchain, the number of this miner in \(miner\_workload\) recorded in the current block header is \(-1\) and no time window will be allocated to it thereafter. This will reduce some invalid waiting. Although it is only removed from delegates of this blockchain, miners with \(-1\) record will not be rewarded and lose the deposit when counting in countpoint.