## 4 Proposed Protocol
### Reputation Management
Additionally, the reputation system is designed to identify trainers who submit low-quality updates, typically caused by connectivity issues. Such issues result in submitting broken update chunks that may lead to lower-than-expected accuracy. To ensure model consistency, the system is engineered to select only trainers with stable performance. During the evaluation phase in Section 4.6, voters detect low-accuracy updates and vote to reject them. The sum of votes with the accept, reject, and negative

votes reflects the results of the experiments, demonstrating that the system effectively filters out inconsistent trainers and malicious actors from the FL scheme. ### Reward Gain

The correlation between reward and reputation (Figures 7(a)-d and 7(a)-d) shows that maintaining reputation is essential to preventing an account ban. As shown in the ten iterations, participants with higher reputation values experience exponential increases in rewards. Compared to the first test with equal reputation values, the malicious participants' rewards start higher than those of honest ones. However, since the malicious trainer-submitted models are low in quality, their scores are lower than average and are subject to punishment. This results in a decrease in their reputation and leads to them being banned. When participants are banned, their accounts are frozen, temporarily preventing their deposited tokens from being withdrawn. This measure discourages participants from creating multiple accounts, as participants would need to stake tokens again to join. The reward system incentivizes trainers and voters to participate honestly in the schemes, as their rewards directly correlate with their reputations. Moreover, participants have a responsibility to maintain the tokens that they deposited at the start. Figure 8: The above two figures depict the average reputation values of malicious vs. non-malicious trainers at the end of each iteration, (**a**) starting with equal reputation values, compared to (**b**) malicious trainers having higher starting values. The below two figures depict the average reputation values of malicious vs. non-malicious voters at the end of each iteration, (**c**) starting with equal reputation values, compared to (**d**) malicious voters having higher starting values. ### Gas Fee

The following tests were conducted using the Truffle testing library in a local Ganache environment. It has been verified that all of the implemented methods comply with the Ethereum gas limit standard of 30 million per block [35], rendering them feasible for execution on Ethereum networks. The gas usage values reported in Table 3 are calculated per unit, with each unit corresponding to a single instance of the method being executed. Each method serves a specific function in the smart contract, such as adding a new participant or updating global accuracy for the next iteration. For instance, \"calculateReputation\" calculates a participant's new reputation at the end of an iteration, and \"setReputation\" is used to update the value in the chain. It is important to note that the total number of transactions required for each method in a federated learning task depends heavily on the number of participating clients. \begin{table}
\begin{tabular}{l l l} \hline \hline \multicolumn{3}{c}{**Gas Fee Metrics**} \\ \hline
**Methods** & **Gas Usage per Tx** & **\% Limit** \\ \hline addParticipant & 301.020 & 1.003 \\ calculateReputation & 154.796 & 0.516 \\ setGlobalAccuracy & 26.646 & 0.089 \\ setReputation & 27.366 & 0.091 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: The table displays the gas usage of methods used in the experiment. Figure 9: The above two figures depict the average reward values of malicious vs. non-malicious trainers at the end of each iteration, **(a)** starting with equal reputation values compared to **(b)** malicious trainers having higher starting values.