## 5 Proposed Approach and System
### Local Computation
Therefore, on-chain activities were evaluated through systematic gas utilization assessments, which aligned with transaction processing requirements. Under EIP-1559 specifications, the maximum block gas capacity has been raised from 15 million units to 30 million, although standard operational targets are typically maintained at approximately 15 million units. Moreover, the gas consumption caused by the transactions mined in one block cannot exceed the block gas limit. To avoid reaching the gas limit, we split the submit() and aggregate() functions up and imposed restrictions on the number of gradients published in one transaction to 200. As shown in Table 4, we measured each operation's computational consumption in gas. The deployment of the smart contract necessitates an expenditure of \(3,602,173\) gas units. The framework initially configures authorized addresses within the permissioned blockchain network to restrict unauthorized participation, requiring \(208,906\) gas units for this setup phase. Prospective participants must complete blockchain registration by

Figure 8: Communication comparison between PPBFL and PPML. (**a**) Device side. (**b**) Server side. Figure 7: Computation comparison between PPBFL and PPML. (**a**) Device side. (**b**) Server side. submitting cryptographic public keys, accompanied by Non-Interactive Zero-Knowledge (NIZK) validation credentials, with the blockchain's verification and storage of these keys demanding \(157,970\) gas per registration instance. The subsequent phase involves devices transmitting gradient data to the blockchain network, with transaction processing capacities handling batches of up to \(200\) gradients at a gas expenditure of \(17,224,780\) per computational transaction. Following complete cipher-text submissions from all participants, the blockchain executes aggregation operations to derive global gradient parameters, with each aggregation transaction consuming \(26,843,542\) gas units. ## 9 Discussion

In this section, we first assess the functionality of our proposed scheme by comparing it with several related works. Subsequently, we summarize the performance of our PPBFL. ### Functionality

First, the functionality of our PPBFL was evaluated in comparison to several state-of-the-art approaches, including SL [10], BFLC [24], Krum [17], FLTrust [31], Bift [33], LearningChain [25], SL\(+\)HE [15], PPML [16], and Securenn [29]. As illustrated in Table 5, SL [10] replaces the traditional server with a blockchain framework to mitigate the risks associated with single points of failure (SPFs), as well as potential malicious behaviors exhibited by servers. Note that the security level includes passive security and active security; here, passive security refers to ensuring the security of the devices when the attackers are honest-but-curious (i.e., the attacker only performs passive attacks such as inference attacks), while active security refers to ensuring the security of devices when the attackers are malicious-and-curious (i.e., the attacker not only carries out passive attacks, but also actively performs malicious behaviors such as poisoning attacks). The DP-based LearningChain [25], HE-based SL\(+\)HE [15], and MPC-based schemes [16; 29] consistently safeguard device privacy through their secure frameworks. Obviously, the above schemes can be categorized as passive security, as they do not consider of defending against poisoning attacks. Meanwhile, the Krum [17], FLTrust [31], and Bift [33] frameworks are capable of defending against poisoning attacks but cannot protect device privacy. Therefore, these schemes cannot be categorized as either passive or active security. In contrast to all of the above-mentioned schemes, our PPBFL employs our MPC-based actively secure evaluation protocol to achieve active security, not only protecting the privacy of devices but also preventing poisoning attacks.