## 4 Experiments and Results Discussion
### Performance Evaluation under Different Parameters  
Through a series of experiments under normal throughput or excess throughput, we tried to explore the response time, confirmation time and throughput of submission transactions with different parameter settings. We also tested the change in the average query delay as the number of valid blocks increased. We measured these performance metrics by:  
\[T_{subResponse}=\frac{\sum_{0}^{TN}T_{remove}}{TN}-T_{input}\quad(s) \tag{21}\]  
\[\overline{T_{subResponse}}=\frac{\sum_{0}^{N_{tx}}T_{subResponse}}{N_{tx}}\quad(s)\]  
\[\overline{T_{ confirmation}}=\overline{T_{subResponse}}+T(\frac{2}{3}BPN\text{ subsequent blocks are accepted})\quad(s) \tag{22}\]  
\[TPS=\frac{Count(tx\ in(t_{i},t_{j}))}{t_{j}-t_{i}}\quad(txs/s) \tag{23}\]  
\[\overline{T_{query}}=\frac{\sum_{0}^{N_{tx}}(T_{return}-T_{input})}{N_{tx}} \quad(s) \tag{24}\]  
The response time of the submission transaction is the time gap from input to removal (when a single-step transaction or the callback transaction of a two-step transaction last exists in the transaction pools of nodes). The last removal indicates that a transaction and its corresponding block (response block) are accepted by a node after verification. We calculated the average response time for \(N_{tx}\) transactions. The confirmation time is the time gap from input to the irreversible response block, which means that \((2/3)BPN\) blocks need to be accepted by nodes after the response block. Throughput is the number of submission transactions that are responded to in a unit of time. When the maximum throughput is exceeded, the response time and confirmation time will be seriously affected. The average query delay is the average of the time gap from inputting the query to obtaining the results of \(N_{tx}\) query transactions. \begin{table}
\begin{tabular}{c l c} \hline \hline
**Conditions or Parameters** & **Description** & **Default** \\ \hline S & Block size, measured by Ethereum’s gas & 7,000,000 gas \\ bpi & Block production interval/yime window size & 3 s \\ BPN/TN & The number of block-producing nodes/total nodes & 15/150 \\ r & Offline rate of block-producing nodes & 0\% \\ epoch & Number of interval blocks for adjusting BPNs & 300 \\ A:B:C:D:E & Ratio of submission transactions: A is to submit OI in OICchain (two steps: & 1:3:3:2:1 \\  & 101,495 + 31,054 gas); B is to submit feedback in CFChain (32,504 gas); C is to submit rating in CFChain (76,260 gas); D is to sponsor in RSChain (40,063 gas); E is to commit reward solution in RSChain (two steps: 98,517 + 29,802 gas) & 4:2:2:1:1 \\ a:b:cd:e & Ratio of query transactions: a is to query OI from OICchain; b is to query a feedback item from CFChain; c is to query the \(r_{OI}\) of a developer’s OI from CFChain; d is to query query the total historical sponsorship amount of an OI from RSChain; e is to query reward amount from RSChain & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: The settings of some conditions and parameters. Without exceeding the throughput, we evenly and continuously submitted a set of submission transactions within each bpi. From Figures 9 and 10, we can see that if the bpi is at the second level, the response time or confirmation time is only related to the step of transactions. For transactions with the same number of steps, the average confirmation time tends to increase linearly. However, the impact of the bpi on the average response time is not linear until it is greater than 9 s. Through analysis of specific data, even if the transaction submission frequency is very low, some transactions may not be packaged into the current block. This situation becomes more serious when the bpi is shorter. By submitting a large number of transactions, A, B, C, D and E, at one time, Figure 11 shows that the throughput decreases as the bpi increases. Different transaction consumption leads to different throughput of each blockchain.