{"id":"9a001cf9-2a76-4d24-949e-316bc21f274c","arxiv_id":"2501.06953","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":2,"one_line_summary":"ByzSFL combines partial homomorphic encryption with zk-SNARKs to let clients prove FLTrust aggregation weights in secure federated learning, claiming large speedups, but the protocol math and evaluation are not yet coherent.","lead":"This paper proposes ByzSFL, a secure federated learning system in which clients use zero-knowledge proofs to show their aggregation weights are computed correctly without revealing their private updates. The system claims large speedups over fully homomorphic encryption, but the protocol math and the experiments do not yet support the Byzantine-robustness claim.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claimed FLTrust equivalence fails because Figure 4 computes the reference update g* only once in Setup and never refreshes it, so trust scores in later rounds are scored against a stale validation gradient.","rationale":"We examined the central claim and the reader's attack. The H/TS algebra is not flawed: FLTrust's rule is a weighted average of server-norm-normalized client updates using trust scores as weights, so sum(TS_i * ||g*||/||g_i|| * g_i)/sum(TS_i) is exactly the FLTrust update. The load-bearing problem is instead the single-shot computation of g*. In FLTrust the server update is recomputed each round from the current global model; Figure 4 sends g* only at Setup, and the per-round SE step never refreshes it. This breaks the equivalence with FLTrust and the robustness argument. A secondary concern is the ZKP public-input specification: Figure 5 lists only g* as public input, which would leave C(H_i) and C(TS_i) unbound unless the Circom circuit includes them; the text in Section 5.4 suggests they are intended public inputs, but this ambiguity should be resolved before any implementation is trusted. No artifacts or attack experiments are provided, so the protocol's claimed robustness is unsupported even aside from these issues.","tokens_in":20,"tokens_out":15320,"duration_ms":210105,"concrete_test":"Run the Figure 4 protocol as written (g* computed once from beta_0) on MNIST with 10 honest clients for 50 rounds, then rerun the same protocol but have SE recompute g* from the current model and broadcast it each round. If the fixed-g* variant's test accuracy is materially lower or fails to converge, the protocol is not FLTrust-equivalent as claimed.","verdict_should_be":"REJECT","load_bearing_attack":"Figure 4's Setup step 2 has Server SE compute g* by Equation 2 and send it to each client, but the per-round SE step only computes beta_new and sends it back; g* is never recomputed. In FLTrust, the server's reference update is the validation gradient at the current global model and must be refreshed every round (Cao et al. [1], Algorithm 1). With a fixed g*, a client's cosine similarity in round t is measured against the gradient at beta_0, not at beta_t. This is not 'mathematically equivalent' to FLTrust, and the inherited Byzantine-robustness guarantee does not follow: after the first few rounds, honest clients whose updates align with the current validation gradient can receive low trust scores, while an adversary who exploits the stale direction could retain disproportionate influence. The reader's specific worry about H/TS not reducing to FLTrust appears to be a misreading: FLTrust's aggregation is a trust-score-weighted average of the per-client updates normalized to the server-update norm, which is exactly H/TS. The real failure is the un-refreshed anchor, not the normalization algebra.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes ByzSFL, a two-server secure federated learning system that combines Paillier partially homomorphic encryption with zk-SNARKs to verify client-computed FLTrust aggregation weights. Clients encrypt local updates and trust scores, the aggregation server SC homomorphically sums them, and the encryption server SE decrypts and applies the update beta_new = beta_new + alpha * H/TS. The paper claims this is mathematically equivalent to FLTrust, reports an approximately 85x to 100x speedup over an FHE baseline and RoFL, and presents timing and bandwidth experiments on MNIST. The evaluation contains only runtime and communication measurements; no accuracy or Byzantine-attack experiments are reported.","tokens_in":20831,"tokens_out":7904,"duration_ms":78683,"significance":"If the protocol worked as claimed, it would be a useful engineering contribution: outsourcing trust-score computation to clients while using PHE plus zk-SNARKs to verify it addresses a real gap in secure federated learning. The dual-server DuoAgg architecture and the proposed Circom gadget library are concrete steps toward practical Byzantine-robust secure aggregation, and the reported benchmarks, if corrected and reproduced, would be valuable. However, as written, the protocol is not FLTrust-equivalent because the server's reference update is never refreshed, and the evaluation does not demonstrate Byzantine robustness at all. The significance is therefore conditional on substantial revision.","major_comments":[{"comment":"The claimed mathematical equivalence with FLTrust fails because the reference update g* is computed once during Setup (Figure 4, Setup step 2) and is never recomputed in the per-round loop. In FLTrust (Cao et al., Algorithm 1), the server's reference update is the validation gradient at the current global model and must be refreshed every round. With a fixed g*, client trust scores in later rounds are cosine similarities against the gradient at beta_0, not at the current beta_t, so the protocol is not equivalent to FLTrust and the inherited Byzantine-robustness guarantee does not follow. This is load-bearing for the paper's central claim. I note that the specific H/TS normalization algebra in Equations (4) and (5) is consistent with the FLTrust weighted average; the problem is the stale anchor, not the normalization. The authors should either recompute and redistribute g* each round and state this explicitly, or prove that a fixed g* preserves FLTrust's guarantees, which seems unlikely.","section":"Section 5.3, Figure 4"},{"comment":"The paper claims that ByzSFL \"ensures robust model training even in the presence of malicious participants,\" but Section 6 reports no experiments with malicious clients and no accuracy or model-utility measurements. The only experimental results are timing and bandwidth numbers in Tables 1-3 and Figure 6. There is no end-to-end training accuracy curve, no comparison of ByzSFL versus FLTrust under the same attack model, and no demonstration that the proposed protocol preserves model performance under Byzantine clients. This missing evaluation leaves the central robustness claim untested.","section":"Section 6"},{"comment":"The reported \"38 seconds per round\" for ByzSFL is inconsistent with Table 1: the 19K-parameter row shows a total of 13.08 seconds, and no row in the table reports 38 seconds. Furthermore, several totals in Table 1 do not match the sum of the listed components (e.g., for 9K parameters the components sum to 8.30 seconds, not 8.51; for 38K parameters they sum to 25.24 seconds, not 15.89). These numerical inconsistencies undermine the quantitative speedup claim and must be corrected before the efficiency comparison can be assessed.","section":"Section 6.3, Table 1"},{"comment":"The security analysis is informal and does not state or prove the properties required for the central claim. The composed protocol needs a precise argument for ZKP soundness (a client cannot produce a valid proof for a trust score not derived from its encrypted update), zero-knowledge for the Paillier encryption and the trust-score computation, and privacy for honest clients under the stated no-collusion assumptions. Section 5.5 gives narrative discussion but no theorems. In addition, Setup step 1 of Figure 4 sends the validation dataset D* to every client. This is unnecessary for the protocol and leaks the server's trusted dataset; if D* is meant to be public, the authors should say so explicitly and explain why this does not weaken the FLTrust trust anchor.","section":"Section 3.3, Figure 4, Section 5.5"}],"minor_comments":[{"comment":"Setup step 1 says \"Server SC sends initial model beta_0...\" but according to Section 3.2 and Figure 2 this should be Server SE; the figure caption also contains the typo \"Protocal.\"","section":"Figure 4"},{"comment":"The speedup is described as \"approximately 100 times faster\" in the abstract and contributions, while Section 6.3 says \"approximately 85 times\" and the conclusion says \"85x.\" These numbers should be reconciled.","section":"Abstract, Section 1, Section 8"},{"comment":"The sentence \"In Section 5.4, we demonstrate how to use our newly developed gadget library...\" refers to the current section; it should be rephrased, and the actual circuit construction described there should be explicitly tied to the gadget library.","section":"Section 5.4"},{"comment":"The fixed-point arithmetic conversion is mentioned but the scaling factor and its status as a public parameter are not specified; this matters because it affects the precision of cosine similarity and L2-norm computations inside the R1CS circuit.","section":"Section 5.4"},{"comment":"Equation (6) writes E(TS_i * g_i), while the protocol and Figure 4 use H_i = tilde_TS_i * g_i and C(H_i). The notation should be aligned so that the encrypted quantity is unambiguous.","section":"Equations (4)-(6), Figure 4"}],"recommendation":"major_revision","confidential_remarks":"The underlying idea is worth pursuing, and the H/TS normalization issue raised in one reading of the paper is not actually the main problem: the algebra matches FLTrust. The serious issue is that the protocol as written never refreshes the server's reference update g*, so the claimed equivalence to FLTrust fails. Since this can be fixed by a protocol change and by adding the missing accuracy/robustness experiments, I am not recommending rejection, but the revision will need to be substantial and the benchmarks re-run and corrected."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nThe headline: ByzSFL is a real engineering attempt to add Byzantine robustness to secure FL, but as written its central claim—that it implements FLTrust securely—fails because the reference update g* is computed once in Setup and never refreshed. That is the issue to focus on, not the normalization algebra, which the reader's report misread.\n\nWhat's genuinely there: the dual-server SC/SE split is sensible, and the idea of having clients compute their own FLTrust weights and prove them with Groth16 zk-SNARKs over Paillier ciphertexts is a plausible way to avoid FHE. The Circom gadget library is a useful practical contribution, and the timing experiments, however rough, do suggest the PHE+zk-SNARK route can beat an FHE baseline by a large margin. The threat model is stated carefully, and the limitation section is honest about the privacy leak when there are few clients.\n\nThe soft spots, in order of severity. First, the stale g*. In Figure 4, g* is sent to clients once at setup. FLTrust recomputes the server reference gradient against the current model each round; here after a few rounds honest clients' updates are scored against a gradient from beta_0, so their trust scores become arbitrary, and an adversary who knows the stale direction can keep a high weight. The paper's own Section 4 description says SE 'derives the reference update' each round, so Figure 4 seems to be a mistake—but as written, the protocol is not FLTrust, and the robustness guarantee does not follow. This is load-bearing. A corrected version that recomputes and redistributes g* per round could plausibly work, with added communication cost.\n\nSecond, the evaluation never demonstrates robustness. There are no attack experiments, no accuracy/learning curves under Byzantine clients, and no comparison with the one directly relevant prior work, reference [31] (low-cost ZKP for robust secure FL). That omission hurts the novelty claim. Third, there are several data-quality problems: the abstract says 100x speedup while the conclusion says 85x; Table 1's 38k total is inconsistent with its row entries; and the 38s/round vs 3224s/round FHE numbers appear only in a figure with no cost model in the text.\n\nOverall: the paper is not ready to accept, but the idea is not wrong-headed and the flaw is identifiable and fixable. Send it to review, and push the authors toward a per-round g*, a real robustness evaluation, and a discussion of [31]. A serious referee will find this worth the time.","headline":"The core FLTrust-equivalence claim does not hold up because g* is pinned at setup and never refreshed; the architecture is plausible but this flaw is load-bearing.","tokens_in":21402,"tokens_out":5750,"would_cite":false,"duration_ms":51447,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper presents ByzSFL as the first system to make Byzantine-robust secure aggregation practical in secure federated learning, by moving trust-score computation to clients and proving it with zero-knowledge proofs.","keywords":["secure federated learning","Byzantine robustness","zero-knowledge proofs","zk-SNARKs","partially homomorphic encryption","FLTrust","secure aggregation","input validation"],"falsifier":"Evaluate both sides of the asserted equivalence on a concrete vector pair: take g* = (1,0) and g_i = (2,2), compute the paper's H/TS update using Equations (4)–(5), and compute FLTrust's original update on the same inputs; if the two vectors differ, the Section 5.3 equivalence—and with it the inherited robustness guarantee—is false.","tokens_in":20369,"feed_emoji":"⚡","tokens_out":11582,"duration_ms":109981,"temperature":0.7,"pith_summary":"The paper sets out to close a gap in secure federated learning: encrypted aggregation protects privacy but has no practical way to defend against malicious clients. ByzSFL is designed as the first system to combine Byzantine-robust aggregation with encrypted model updates, by having each client compute its own FLTrust aggregation weight and prove with a zero-knowledge proof that the weight follows from its encrypted update. The claimed payoff is that an otherwise expensive secure-aggregation pipeline becomes about 100 times faster than the fully homomorphic alternative, while inheriting FLTrust's tolerance for a large fraction of malicious clients. The paper also introduces DuoAgg, a two-server setup that lets the aggregation server work only on encrypted additions.","feed_headline":"ByzSFL: 100x faster Byzantine-robust secure federated learning","feed_subtitle":"Clients prove their aggregation weights in zero knowledge, so encrypted updates keep FLTrust's robustness at a fraction of the cost.","key_machinery":"The machinery that carries the argument is the combination of DuoAgg, a two-server secure aggregation framework, and a Circom-based zk-SNARK gadget library for the operators FLTrust needs. DuoAgg assigns the aggregation server SC only Paillier addition on ciphertexts, while the encryption server SE handles key generation, decryption, and the reference update g*. The gadget library—cosine similarity, L2 norms, min/max, vector arithmetic, and additive homomorphic encryption—lets each client prove in zero knowledge that its TSi, \\tilde{TS}_i, and H_i were computed correctly without revealing g_i. That replaces the expensive FHE evaluation of trust scores with verifiable plaintext computation on the client side, which is what yields the speedup.","core_discovery":"The central claim, stated by the authors, is that ByzSFL is the first system to achieve highly efficient Byzantine-robust secure aggregation in secure federated learning. The protocol keeps FLTrust's robustness while encrypting intermediate updates: each client i computes its trust score TSi = max(0, g*·gi/(||g*|| ||gi||)), the normalized score \\tilde{TS}_i = TSi ||g*||/||gi||, and H_i = \\tilde{TS}_i g_i, encrypts H_i and TSi with Paillier encryption, and attaches a zk-SNARK proving these values come from its local update. The server SC verifies each proof, adds the encrypted H_i and TSi over all accepted clients, and SE decrypts and sets \\beta_{new} = \\beta_{new} + \\$\\alpha$ H/TS. The authors assert that this reorganized computation is mathematically equivalent to FLTrust's original aggregation, so FLTrust's resilience—reported to survive over 90% malicious clients—is inherited; they report a per-round runtime of 38s versus 3224s for an FHE baseline on 19K parameters.","pith_inferences":["Editorial inference: the asserted equivalence between the paper's H/TS update and FLTrust's original rule is independently checkable; computing both sides on a toy gradient pair would settle whether the inherited robustness guarantee actually follows.","Editorial inference: because the gadget library already covers median, mean, Krum-style distances, and range constraints, the same DuoAgg architecture could likely wrap other plaintext robust-aggregation rules, not just FLTrust.","Editorial inference: the practical viability hinges on the no-collusion two-server assumption; in deployment, SC and SE would need to be operated by separate organizations or audited to deter collusion.","Editorial inference: a natural next benchmark would run ByzSFL under model-poisoning attacks on a larger model and compare final accuracy to plaintext FLTrust, checking how much fixed-point quantization and the trust-score aggregation form erode the robustness."],"forward_implications":["If the mathematical equivalence holds, FLTrust's Byzantine-robustness guarantee—including its reported tolerance for more than 90% malicious clients—becomes available inside encrypted aggregation.","The protocol's proof size stays at 803 bytes regardless of model size, so verification time on the aggregation server stays roughly constant as the model grows.","A two-server setup with no SC–SE collusion means no single server ever sees both individual ciphertexts and the decryption key, reducing the trust needed compared to single-server masking or FHE designs.","On the MNIST benchmark with 19K parameters, ByzSFL is about 85 times faster than the CKKS-based FHE protocol (38s vs 3224s per round) and faster than RoFL with L2 or L∞ norm regularization."],"supporting_citations":[{"why":"Supplies the FLTrust trust-score definition and the Byzantine-robust aggregation rule that ByzSFL claims to preserve.","marker":"[1]"},{"why":"Provides the RoFL secure-aggregation baseline with verifiable norm bounds that ByzSFL compares against and outperforms.","marker":"[10]"},{"why":"Defines ACORN, the input-validation-in-secure-aggregation line of work that ByzSFL extends from norm checks to FLTrust.","marker":"[8]"},{"why":"Provides EIFFeL, a secure federated learning integrity scheme whose communication costs serve as a comparison point.","marker":"[19]"},{"why":"Specifies Groth16, the zk-SNARK protocol chosen for constant-size proofs and fast verification.","marker":"[29]"},{"why":"Provides Circom, the language used to build the gadget library for the zk-SNARK circuit.","marker":"[40]"},{"why":"Defines CKKS, the FHE scheme used in the baseline protocol whose per-round runtime is the main efficiency comparison.","marker":"[25]"}],"fun_headline_variants":["ByzSFL: Zero-knowledge proofs make secure FL robust and 100x faster","ByzSFL: 100x speedup for Byzantine-robust secure aggregation","Zero-knowledge proofs slash Byzantine-robust secure FL cost","First Byzantine-robust secure FL with practical zero-knowledge proofs","ByzSFL: Secure aggregation with Byzantine resilience at 100x speed"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole robustness guarantee stands on the claim that dividing the sum of normalized trust-score-weighted updates by the sum of raw trust scores reproduces FLTrust's aggregation rule exactly; if that equality is false, the Byzantine-robustness guarantee may not transfer.","fun_headline_variants_meta":{"raw":{"variants":["ByzSFL: Zero-knowledge proofs make secure FL robust and 100x faster","ByzSFL: 100x speedup for Byzantine-robust secure aggregation","Zero-knowledge proofs slash Byzantine-robust secure FL cost","First Byzantine-robust secure FL with practical zero-knowledge proofs","ByzSFL: Secure aggregation with Byzantine resilience at 100x speed"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000239,"raw_usage":{"total_tokens":1568,"prompt_tokens":1050,"completion_tokens":518,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":666,"completion_tokens_details":{"reasoning_tokens":427}},"tokens_in":666,"tokens_out":518,"duration_ms":4595,"temperature":1.0,"reasoning_tokens":427,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T20:50:20.527272+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Evaluate both sides of the asserted equivalence on a concrete vector pair: take g* = (1,0) and g_i = (2,2), compute the paper's H/TS update using Equations (4)–(5), and compute FLTrust's original update on the same inputs; if the two vectors differ, the Section 5.3 equivalence—and with it the inherited robustness guarantee—is false.","supporting_citations":[{"cited_title":"ACORN: input validation for secure aggregation,","cited_arxiv_id":null,"evidence_quote":"Defines ACORN, the input-validation-in-secure-aggregation line of work that ByzSFL extends from norm checks to FLTrust."},{"cited_title":"Eiffel: Ensuring integrity for federated learning,","cited_arxiv_id":null,"evidence_quote":"Provides EIFFeL, a secure federated learning integrity scheme whose communication costs serve as a comparison point."},{"cited_title":"On the size of pairing-based non-interactive arguments,","cited_arxiv_id":null,"evidence_quote":"Specifies Groth16, the zk-SNARK protocol chosen for constant-size proofs and fast verification."},{"cited_title":"Bulletproofs: Short proofs for confidential transactions and more,","cited_arxiv_id":null,"evidence_quote":"Provides Circom, the language used to build the gadget library for the zk-SNARK circuit."},{"cited_title":"Homomorphic en- cryption for arithmetic of approximate numbers,","cited_arxiv_id":null,"evidence_quote":"Defines CKKS, the FHE scheme used in the baseline protocol whose per-round runtime is the main efficiency comparison."}],"review_version":1}