Original: Verifiable FederatedMachine Learning
Revised: Verifiable Federated Learning

Original: Anonymous Author(s)

Original: AffiliationAddress email

Original: Abstract
Revised: Abstract

Original: In Federated Learning (FL) a significant body of research has focused on defendingagainst malicious clients.
Revised: In Federated Learning (FL) a significant body of research has focused on defending against malicious clients.

Original: However, clients are not the only party that can behavemaliciously.
Revised: However, clients are not the only party that can behave maliciously.

Original: The aggregator itself may tamper the model to bias it towards certainoutputs, or adapt the weights to aid in reconstructing a client’s private data.
Revised: The aggregator itself may tamper the model to bias it towards certain outputs, or adapt the weights to aid in reconstructing a client’s private data.

Original: Inthis work we tackle the open problem of efficient verification of the computationsperformed by the aggregator in FL.
Revised: In this work we tackle the open problem of efficient verification of the computations performed by the aggregator in FL.

Original: We develop a novel protocol which throughusing binding commitments prevents an aggregator from modifying the resultingmodel and only permits the aggregator to sum the supplied weights.
Revised: We develop a novel protocol which through using binding commitments prevents an aggregator from modifying the resulting model, and only permits the aggregator to sum the supplied weights.

Original: We provideproof of correctness for our protocol demonstrating that any tampering by anaggregator will be detected.
Revised: We provide proof of correctness for our protocol demonstrating that any tampering by an aggregator will be detected.

Original: Additionally, we evaluate our protocol’s overheadson three datasets, and show that even for large neural networks with millions ofparameters the commitments can be computed in under 20 seconds
Revised: Additionally, we evaluate our protocol’s overheads on three datasets, and show that even for large neural networks with millions of parameters the commitments can be computed in under 20 seconds.

Original:  Introduction
Revised:  Introduction

Original: Federated Learning (FL) is a new paradigm for training machine learning (ML) models in a decentralised fashion.
Revised: Federated Learning (FL) is a new paradigm for training machine learning (ML) models in a decentralised fashion.

Original: Clients, who collect and hold data, will locally train ML models.
Revised: Clients, who collect and hold data, will locally train ML models.

Original: Once local traininghas been completed, the updated models are sent to the aggregator to be combined.
Revised: Once local training has been completed, the updated models are sent to the aggregator to be combined.

Original: There has been a large amount of research examining how to protect FL systems against maliciousclients, for example, by using robust aggregation schemes [1], examining client behaviour over awindow of time [2], or leveraging certification algorithms [3, 4].
Revised: There has been a large amount of research examining how to protect FL systems against malicious clients, for example, by using robust aggregation schemes [1], examining client behaviour over a window of time [2] or leveraging certification algorithms [3, 4].

Original: However, clients are not the only party that could misbehave in FL.
Revised: However, clients are not the only party that could misbehave.

Original: The aggregator itself may haveobjectives which do not align with the clients: for example, inthe case of product recommendation,a service provider can have higher profits on certain items, and hence bias a  aggregated model torecommend higher profit items, rather than those which would be the optimal recommendation for aclient.
Revised: The aggregator itself may tamper with the aggregated model. For example, in product recommendation a service provider wishes to optimise for maximum profits, while a client wishes to see items that fulfils their criteria while minimising expense. Therefore, clients may wish to verify that a service provider is not biasing the aggregated model towards more expensive products.

Original: Additionally, a malicious aggregator can adapt the weights to create so called “trap weights”to launch data reconstruction attacks against a client [5].
Revised: Alternatively, a malicious aggregator can adapt the weights to create so called “trap weights” to launch data reconstruction attacks against a client [5].

Original: Hence, a client’s ability to verify that anaggregator performed the operations it claimed to conduct is of significant security importance.
Revised: Hence, a client’s ability to verify that an aggregator performed the operations it claimed to conduct is of significant security importance.

Original: This threat model of a malicious aggregator has a significantly more limited body of researchcompared to the traditional malicious client threat model.
Revised: This threat model of a malicious aggregator has a significantly more limited body of research compared to the traditional malicious client threat model.

Original: Papers have proposed homomorphichashes [6] or setups based on Pallier encryption [7, 8].
Revised: Papers have proposed homomorphic hashes [6] or setups based on Pallier encryption [7, 8].

Original: In this work, we propose a lightweightverification protocol we call Verification Via Commitments (VVC) that enables clients to verifythe aggregator, even when it colludes with malicious clients.
Revised: In this work, we propose a lightweight verification protocol we call Verification Via Commitments (VVC) that enables clients to verify the aggregator, even when it colludes with malicious clients.

Original: More precisely, our contribution is alightweight protocol that:
Revised: More precisely, our contribution is a lightweight protocol that:

Original: • Enables clients to verify that the aggregator correctly performed sums over the supplied weights and that the weights have not been tampered with.
Revised: • Enables clients to verify that the aggregator correctly performed sums over the supplied weights and that the weights have not been tampered with.

Original: • Is resistant to a configurable number of colluding clients with a malicious aggregator via Shamir’s Secret Sharing.
Revised: • Is resistant to a configurable number of colluding clients with a malicious aggregator via Shamir’s Secret Sharing.

Original: • Maintains high Federated Learning accuracy and is scalable to large neural networks,typically handling millions of parameters in under 20 seconds.
Revised: • Maintains high Federated Learning accuracy and is scalable to large neural networks, typically handling millions of parameters in under 20 seconds.

Original:  Related Works
Revised:  Related Works

Original: Reducing the trust placed in cloud services for machine learning has a growing body of work as ML models are being deployed and trained in an ever more distributed fashion.
Revised: Reducing the trust placed in cloud services for ML has a growing body of work as ML models are being deployed and trained in an ever more distributed fashion.

Original: One of the earlyworks in this area is SafetyNets [9] which used an Interactive Proof(IP) protocol [10] to verify that aneural network’s forward pass was correctly executed by a service provider.
Revised: An early work in this area is SafetyNets [9] which used an Interactive Proof protocol [10] to verify that a neural network’s forward pass was correctly executed by a service provider.

Original: Converting this style ofverification for FL aggregation will require the aggregator and clients needing to communicate manytimes for the verification to be carried out.
Revised: Converting this style of verification for FL aggregation requires the aggregator and clients needing to communicate many times for the verification protocol.

Original: Hence, alternative strategies more suited to FL have sincebeen developed [11].
Revised: Hence, alternative strategies more suited to FL have since been developed [11].

Original: One strand of research has used the idea of homomorphic hash functions [6, 12], which can provideverification that an aggregator has correctly performed a sum of supplied gradients, albeit withnon-trivial overhead in verification time.
Revised: One strand of research has used the idea of homomorphic hash functions [6, 12], which can provide verification that an aggregator has correctly performed a sum of supplied gradients, albeit with non-trivial overhead in verification time.

Original: Alternative strategies have been proposed in [13] withclients encrypting gradients using a pseudorandom generator and Lagrange interpolation, togetherwith the Chinese Remainder Theorem.
Revised: Alternative strategies have been proposed in [13] with clients encrypting gradients using a pseudorandom generator and Lagrange interpolation, together with the Chinese Remainder Theorem.

Original: The aggregator only sees, and operates on, the encryptedgradients and the clients perform verification by unpacking the aggregated ciphertext they receive.
Revised: The aggregator only sees, and operates on, the encrypted gradients and the clients perform verification by unpacking the aggregated ciphertext they receive.

Original: The above works make the assumption that malicious clients can try and collude with the aggregatorto break the verification schemes.
Revised: The above works make the assumption that malicious clients can try and collude with the aggregator to break the verification schemes.

Original: Hence, they often use a trusted third party to initialise the initialkey generation.
Revised: Hence, they often use a trusted third party to initialise the initial key generation.

Original: This requirement has been relaxed other works such as [7, 14] but often carries somepenalty: for example in [7] the clients are assumed to be honest and not collude with the aggregator.
Revised: This requirement has been relaxed other works such as [7, 14] but often carries some penalty: for example in [7] the clients are assumed to be honest and not collude with the aggregator.

Original: Recent works have started looking at ways to reduce the trust in a key-generator, for example [12]assumes a key-generator that is truthful but inquisitive.
Revised: Recent works have started looking at ways to reduce the trust in a key-generator, for example [12] assumes a key-generator that is truthful but inquisitive.

Original:  Verification Via Commitments (VVC) protocol
Revised:  Verification Via Commitments (VVC) protocol

Original: We present Verification Via Commitments (VVC), a novel and lightweight verification protocol thatcan be applied to FL.
Revised: We present Verification Via Commitments (VVC), a novel and lightweight verification protocol that can be applied to FL.

Original: Our protocol allows clients to continuously, or periodically, verify that theaggregator performs the aggregation correctly over the supplied weights and that the weights werenot tampered with.
Revised: Our protocol allows clients to continuously, or periodically, verify that the aggregator performs the aggregation correctly over the supplied weights and that the weights were not tampered with.

Original: Our protocol also enables clients to verify the aggregator computation even whenit colludes with some clients, up to a maximum of all clients minus one.
Revised: Our protocol also enables clients to verify the aggregator computation even when it colludes with some clients, up to a maximum of all clients minus one.

Original: In the following sections, we describe how our protocol works, and the Cryptographic primitives used.
Revised: In the following sections, we describe how our protocol works, and the Cryptographic primitives used.

Original: We present the components that are part of the system and all the operations that must be performedto train a FL model and verify that it has been calculated correctly.
Revised: We present the components that are part of the system and all the operations that must be performed to train a FL model and verify that it has been calculated correctly.

Original: 3.1 Cryptographic Primitives3.1.1 Pedersen Commitments
Revised: 3.1 Cryptographic Primitives 3.1.1 Pedersen Commitments

Original: Our protocol is based on the Pedersen commitment scheme [15].
Revised: Our protocol is based on the Pedersen commitment scheme [15].

Original: A commitment scheme is acryptographic primitive that, using a secret random value, allows one to commit a given value.
Revised: A commitment scheme is a cryptographic primitive that, using a secret random value, allows one to commit a given value.

Original: Onlyparties knowing both values can open the commitment.
Revised: Only parties knowing both values can open the commitment.

Original: The Pedersen Commitment scheme is a homomorphic commitment based on the discrete logarithmproblem over a cyclic group G .
Revised: The Pedersen Commitment scheme is a homomorphic commitment based on the discrete logarithm problem over a cyclic group G .

Original: We base our approach on modular arithmetic and consider thecase where G is a sub-group G of order q of Z p , where p , q are both (large) primes and q dividesp − 1 .
Revised: We base our approach on modular arithmetic and consider the case where G is a sub-group G of order q of Z p , where p , q are both (large) primes and q divides p − 1 .

Original: The Pedersen Commitment scheme uses two random generators of G , g, and h  to compute thecommitment of a value.
Revised: The Pedersen Commitment scheme uses two random generators of G , g and h , to compute the commitment of a value.

Original: A committer chooses a value w , a random value r , and computes the commitment:
Revised: A committer chooses a value w , a random value r , and computes the commitment:

Original: [Equation]
Revised: [Equation]

Original: The commitment c can be opened only by revealing both w and r .
Revised: The commitment c can be opened only by revealing both w and r .

Original: No one can open the commitmentwithout knowing both w and r unless it can compute log g ( h ) which requires solving the discretelog problem over G .
Revised: No one can open the commitment without knowing both w and r unless it can compute log g ( h ) which requires solving the discrete log problem over G .

Original: The aggregator is prevented from changing w to a malicious value w ′ unless it can solve r ′ =
Revised: The aggregator is prevented from changing w to a malicious value w ′ unless it can solve r ′ =

Original: log h
Revised: log h

Original: ( c ∗ g − w ′ ) which is computationally infeasible.
Revised: ( c ∗ g − w ′ ) which is computationally infeasible.

Original: We say that the Pedersen
Revised: We say that the Pedersen

Original: Commitment scheme is perfectly hiding and computationally binding.
Revised: Commitment scheme is perfectly hiding and computationally binding.

Original: 3.1.2 Shamir secret Sharing
Revised: 3.1.2 Shamir Secret Sharing

Original: Our protocol uses Shamir’s Secret Sharing (SSS) [16], also known as the ( k, n ) -threshold scheme,to share a secret value between clients.
Revised: Our protocol uses Shamir’s Secret Sharing (SSS) [16], also known as the ( k, n ) -threshold scheme, to share a secret value between clients.

Original: The purpose of SSS is to partition the data D that mustbe maintained secret into n pieces, called shares.
Revised: The purpose of SSS is to partition the data D that must be maintained secret into n pieces, called shares.

Original: The knowledge of k or more shares makes Dcomputable, but the knowledge of any k − 1 or fewer pieces leaves D undetermined.
Revised: The knowledge of k or more shares makes D computable, but the knowledge of any k − 1 or fewer pieces leaves D undetermined.

Original: SSS is basedon polynomial interpolation in a 2-dimensional plane.
Revised: SSS is based on polynomial interpolation in a 2-dimensional plane.

Original: It consists of the computation of a polynomialq ( x ) of degree k − 1 where the constant term q (0) is D , and other terms are random.
Revised: It consists of the computation of a polynomial q ( x ) of degree k − 1 where the constant term q (0) is D , and other terms are random.

Original: Given anysubset of k shares is possible to find the polynomial by interpolation and compute the secret D .
Revised: Given any subset of k shares is possible to find the polynomial by interpolation and compute the secret D .

Original: Onthe other hand, knowledge of k − 1 values is not sufficient to compute the secret.
Revised: On the other hand, knowledge of k − 1 values is not sufficient to compute the secret.

Original: SSS is based on modular arithmetic using integers modulo p as polynomial coefficients, where p is aprime number.
Revised: SSS is based on modular arithmetic using integers modulo p as polynomial coefficients, where p is a prime number.

Original: An adversary that obtains k − 1 shares can compute, for each possible secret value D ′in the interval [0 , p ) one and only one polynomial q ′ ( x ) of degree k − 1 such that q ′ (0) =
Revised: An adversary that obtains k − 1 shares can compute, for each possible secret value D ′ in the interval [0 , p ) one and only one polynomial q ′ ( x ) of degree k − 1 such that q ′ (0) =

Original: D ′ .
Revised: D ′ .

Original: Thesep polynomials are equally likely; the attacker obtains nothing about the real value of the secret D .
Revised: These p polynomials are equally likely; the attacker obtains nothing about the real value of the secret D .

Original: 3.2 Protocol
Revised: 3.2 Protocol

Original: We assume the presence of a trusted generator that computes the necessary protocol materials (publicparameters and random values) and distributes them to the appropriate parties participating in theprotocol execution.
Revised: We assume the presence of a trusted generator that computes the necessary protocol materials (public parameters and random values) and distributes them to the appropriate parties participating in the protocol execution.

Original: The trusted generator produces the public parameters g , h , and q that clients need to compute andverify a commitment, as described in Algorithm 1.
Revised: The trusted generator produces the public parameters g , h , and q that clients need to compute and verify a commitment, as described in Algorithm 1.

Original: In each round, it generates a random value foreach client.
Revised: In each round, it generates a random value for each client.

Original: It computes the secret for the round by summing all the generated random values andsplits it into multiple shares (based on the number of clients) using the SSS protocol.
Revised: It computes the secret for the round by summing all the generated random values and splits it into multiple shares (based on the number of clients) using the SSS protocol.

Original: The trustedgenerator, for each round, sends each client a random value necessary to compute commitments, theshares required to recompute the round’s secret to verify the aggregator commitment, and the numberof clients that participates in the round.
Revised: The trusted generator, for each round, sends each client a random value necessary to compute commitments, the shares required to recompute the round’s secret to verify the aggregator commitment, and the number of clients that participates in the round.

Original: If the number of clients per round is pre-known, the trusted generator can pre-generate random valuesand pre-compute shares in the protocol setup phase and distribute them before the protocol starts.
Revised: If the number of clients per round is pre-known, the trusted generator can pre-generate random values and pre-compute shares in the protocol setup phase and distribute them before the protocol starts.

Original: We present an example in Figure 1.
Revised: We present an example in Figure 1.

Original: We describe the protocol in a single round since the behavior ofthe system’s involved parties is the same for all rounds.
Revised: We describe the protocol in a single round since the behavior of the system’s involved parties is the same for all rounds.

Original: Our protocol consists of three different phases.
Revised: Our protocol consists of three different phases.

Original: In the first phase, each client trains the FL model onits local data and computes a commitment for each parameter in the model using the random value itreceived from the trusted environment.
Revised: In the first phase, each client trains the FL model on its local data and computes a commitment for each parameter in the model using the random value it received from the trusted environment.

Original: The computation of commitments is described in Algorithm 1.
Revised: The computation of commitments is described in Algorithm 1.

Original: Then, all the clients send the aggregator their FL parameters and the computed commitments.
Revised: Then, all the clients send the aggregator their FL parameters and the computed commitments.

Original: Inthe second phase, the aggregator sums all the weights, multiplies all the commitments, and sendsback the results to clients.
Revised: In the second phase, the aggregator sums all the weights, multiplies all the commitments, and sends back the results to clients.

Original: In the third and last phase, clients verify that the aggregator correctlycomputed the global FL parameters. Firstly, clients re-compute the secret using SSS, exchanging atleast k shares between them. Secondly, a client computes the commitment of the weight calculatedby the aggregator using the re-computed secret. Then it compares the computed commitment withthe product of commitments received by the aggregator.
Revised: In the third and last phase, clients verify that the aggregator correctly

Original: Each client is convinced that the aggregatordid the operation correctly if the two commitments are equal.

Original: Finally, a client will divide the weightsreceived from the aggregator by the number of clients participating in the round.

Original: Function public_parameters_generation() :
Revised: Function public_parameters_generation() :

Original: Choose p , q random primes such that q divides p − 1 , G q is the unique subgroup of Z ∗ p of order q , g
Revised: Choose p , q random primes such that q divides p − 1 , G q is the unique subgroup of Z ∗ p of order q , g

Original: and h are generators of G q .
Revised: and h are generators of G q .

Original: Select g, h ∈ G q .
Revised: Select g, h ∈ G q .

Original: Choose number of participating clients.
Revised: Choose number of participating clients.

Original: n return g , h , q , n
Revised: n return g , h , q , n

Original: Function parameters_generation( n ) :
Revised: Function parameters_generation( n ) :

Original: The Trusted Entity selects a random number r i for each client, and it computes the sum r = n (cid:88) i =
Revised: The Trusted Entity selects a random number r i for each client, and it computes the sum r = n (cid:88) i =

Original: r i .
Revised: r i .

Original: Then it computes n shares using the Shamir( k , secret) threshold scheme [17], where n is the number of clients and k is the necessary number of shares to recompute the secret r .
Revised: Then it computes n shares using the Shamir( k , secret) threshold scheme [17], where n is the number of clients and k is the necessary number of shares to recompute the secret r .

Original: return r i , share i
Revised: return r i , share i

Original: Function commit( g , h , q , w i , r i ) :
Revised: Function commit( g , h , q , w i , r i ) :

Original: Each client computes:
Revised: Each client computes:

Original: [Equation]
Revised: [Equation]

Original: (3) return com i
Revised: (3) return com i

Original: Function aggregate( [ w i ] , [ com i ] ) :
Revised: Function aggregate( [ w i ] , [ com i ] ) :

Original: The Aggregator computes:
Revised: The Aggregator computes:

Original: [Equation]
Revised: [Equation]

Revised: (cid:88)

Revised: [Equation]

Revised: (cid:89)

Revised: [Equation]

Original:  return s , c
Revised: (4) return s , c

Original: Function compute_secret( [ share i ] ) :
Revised: Function compute_secret( [ share i ] ) :

Original: Each client computes the secret ( secret = r ) using the Shamir( k , secret) threshold scheme [17].
Revised: Each client computes the secret ( secret = r ) using the Shamir( k , secret) threshold scheme [17].

Original: Each client uses his own share and k − 1 shares obtained from other clients.
Revised: Each client uses his own share and k − 1 shares obtained from other clients.

Original: return secret
Revised: return secret

Original: Function verify( secret , c , s n ) :
Revised: Function verify( secret , c , s n ) :

Original: Each client computes:
Revised: Each client computes:

Original: [Equation]
Revised: [Equation]

Revised: q (5)

Original: If com = c accept the computation and perform w = s/n , otherwise reject.
Revised: If com = c accept the computation and perform w = s/n , otherwise reject.

Original: return
Revised: return

Original: Algorithm 1: 
Revised: Algorithm 1: computed the global FL parameters. Firstly, clients re-compute the secret using SSS, exchanging at least k shares between them. Secondly, a client computes the commitment of the weight calculated by the aggregator using the re-computed secret. Then it compares the computed commitment with the product of commitments received by the aggregator.

Revised: Each client is convinced that the aggregator did the operation correctly if the two commitments are equal.

Revised: Finally, a client will divide the weights received from the aggregator by the number of clients participating in the round.

Original: Clients do not need to verify the aggregator computation each round.
Revised: Clients do not need to verify the aggregator computation each round.

Original: They can verify it later orperiodically, storing the round’s secret and the values computed by the aggregator.
Revised: They can verify it later or periodically, storing the round’s secret and the values computed by the aggregator.

Original: 3.3 Security considerations
Revised: 3.3 Security considerations

Original: Malicious Aggregator We present proof that our protocol enables clients to discover a maliciousaggregator that cheats or tampers the weights.
Revised: Malicious Aggregator We present proof that our protocol enables clients to discover a malicious aggregator that cheats or tampers the weights.

Original: We consider a scenario where an untrusted aggregatortampers the weights, thus performing the aggregation incorrectly.
Revised: We consider a scenario where an untrusted aggregator tampers the weights, thus performing the aggregation incorrectly.

Original: We focus on Phases 2 and 3 of ourprotocol, where the aggregator can operate.
Revised: We focus on Phases 2 and 3 of our protocol, where the aggregator can operate.

Original: The malicious aggregator receives the clients’ parameters and commitments, sums all the weights,and multiplies all the commitments.
Revised: The malicious aggregator receives the clients’ parameters and commitments, sums all the weights, and multiplies all the commitments.

Original: The malicious aggregator has two possibilities to cheat.
Revised: The malicious aggregator has two possibilities to cheat.

Original: Thefirst is to replace one or more clients’ parameters to make the training of the global FL model fail ortamper with the model in such a way to fulfill an attack objective.
Revised: The first is to replace one or more clients’ parameters to make the training of the global FL model fail or tamper with the model in such a way to fulfill an attack objective.

Original: The second way is to replace oneor more clients’ parameters and re-compute the product of commitments c .
Revised: The second way is to replace one or more clients’ parameters and re-compute the product of commitments c .

Original: In the first scenario, the aggregator sends back to clients the product of commitments c and a newvalue for the sum of parameters s ′ such that it differs from the correct sum s , i.e. s ′ ̸
Revised: In the first scenario, the aggregator sends back to clients the product of commitments c and a new value for the sum of parameters s ′ such that it differs from the correct sum s , i.e. s ′ ̸

Original: = s .
Revised: = s .

Original: Then eachclient re-computes the secret r and perform the commitment com=
Revised: Then each client re-computes the secret r and perform the commitment com

Original:  g s ′ ∗ h r .
Revised: = g s ′ ∗ h r .

Original: Taking into accountthat s ′ ̸
Revised: Taking into account that s ′ ̸

Original: = s , the commitment will be com
Revised: = s , the commitment will be com

Original: ̸ = c , allowing a client to discover the wrong computation.
Revised: ̸ = c , allowing a client to discover the wrong computation.

Original: In the second scenario we assume that the aggregator can compute a new commitment c ′ =
Revised: In the second scenario we assume that the aggregator can compute a new commitment c ′ =

Original: g s ′ ∗ h r ′ ,such that c ′ =
Revised: g s ′ ∗ h r ′ , such that c ′ =

Original: c is valid.
Revised: c is valid.

Original: In our protocol c = (cid:81) ni
Revised: In our protocol c = (cid:81) ni

Original: =1 com i = (cid:81) ni
Revised: =1 com i = (cid:81) ni

Original: =

Revised: =

Original: g w i ∗ h
Revised: g w i ∗ h

Original: r
Revised: r

Original: i = g w 1 ∗ h r 1 ∗ . . .
Revised: i = g w 1 ∗ h r 1 ∗ . . .

Original: ∗ g w n ∗h r n = g ( w 1 + ... + w n ) ∗ h ( r 1 + ... + r n ) =
Revised: ∗ g w n ∗ h r n = g ( w 1 + ... + w n ) ∗ h ( r 1 + ... + r n ) =

Original: g s ∗ h r that is equal to a Pedersen Commitment.
Revised: g s ∗ h r that is equal to a Pedersen Commitment.

Original: Since we tookinto account an aggregator able to generate a c ′ =
Revised: Since we took into account an aggregator able to generate a c ′ =

Original: c , so, it can generate two Pedersen Commitmentsc ′ =
Revised: c , so, it can generate two Pedersen Commitments c ′ =

Original: g s ′ ∗ h r ′ and c
Revised: g s ′ ∗ h r ′ and c

Original: = g s ∗ h r
Revised: = g s ∗ h r

Original: such that c ′ =
Revised: such that c ′ =

Original: c with s ′ ̸
Revised: c with s ′ ̸

Original: = s and r ′ ̸
Revised: = s and r ′ ̸

Original: = r .
Revised: = r .

Original: However, if we consider [15], where the authors prove that is not possible to obtain a Pedersen
Revised: However, if we consider [15], where the authors prove that is not possible to obtain a Pedersen

Original: Commitment c ′ =
Revised: Commitment c ′ =

Original: c with s ′ ̸
Revised: c with s ′ ̸

Original: = s and r ′ ̸
Revised: = s and r ′ ̸

Original: = r , by extension in our protocol there does not exist anaggregator which is able to generate a new c ′ =
Revised: = r , by extension in our protocol there does not exist an aggregator which is able to generate a new c ′ =

Original: c .
Revised: c .

Original: Other byzantine behavior can be proven from theaggregator, for example it can try to open the commitments knowing s to create a new commitmentsuch that c ′ =
Revised: Other byzantine behavior can be proven from the aggregator, for example it can try to open the commitments knowing s to create a new commitment such that c ′ =

Original: g s ∗ h r ′ and c
Revised: g s ∗ h r ′ and c

Original: = g s ∗ h r .
Revised: = g s ∗ h r .

Original: Formal proofs are omitted for space constraints.
Revised: Formal proofs are omitted for space constraints.

Original: Malicious Aggregator with colluding clients We present proof that our protocol is resistant toa certain number of colluding clients with a malicious aggregator.
Revised: Malicious Aggregator with colluding clients We present proof that our protocol is resistant to a certain number of colluding clients with a malicious aggregator.

Original: We consider a scenario wheremalicious clients cooperate with the aggregator to aid it in forging a tampered global FL model.
Revised: We consider a scenario where malicious clients cooperate with the aggregator to aid it in forging a tampered global FL model.

Original: Multiple clientscan cooperate to re-compute the secret before the aggregation and send it to theaggregator who can quickly invalidate the protocol by replacing s with a s ′ and computing a newc = g s ′ ∗ h r .
Revised: Multiple clients cooperate to re-compute the secret before the aggregation and send it to the aggregator who can quickly invalidate the protocol by replacing s with a s ′ and computing a new c = g s ′ ∗ h r .

Original: In our protocol we introduced the SSS [17] protocol with the configurable parameter k , as presentedin Sections 3.1 and 3.2.
Revised: In our protocol we introduced the SSS [17] protocol with the configurable parameter k , as presented in Sections 3.1 and 3.2.

Original: Given the existence of k , the aggregator must cooperate with at least kclients to obtain the secret before the aggregation to invalidate the model successfully.
Revised: Given the existence of k , the aggregator must cooperate with at least k clients to obtain the secret before the aggregation to invalidate the model successfully.

Original: In SSS k is aconfigurable parameter, so it is possible to set it large enough (up to k = n − 1 ) to avoid the clients’collaboration.
Revised: In SSS k is a configurable parameter, so it is possible to set it large enough (up to k = n − 1 ) to avoid the clients’ collaboration.

Original: So, for FL cases subjected to a low number of malicious clients a smaller k can beselected, improving the computational performance.
Revised: So, for FL cases subjected to a low number of malicious clients a smaller k can be selected, improving the computational performance.

Original: Instead, scenarios with many malicious clientsshould set a large k at the cost of increased computational overhead.
Revised: Instead, scenarios with many malicious clients should set a large k at the cost of increased computational overhead.

Original: We evaluated the correlationbetween the value of k and the system’s performance in Appendix B.
Revised: We evaluated the correlation between the value of k and the system’s performance in Appendix B.

Original: If the aggregator cooperates with k − 1 clients, it can obtain at most k − 1 shares.
Revised: If the aggregator cooperates with k − 1 clients, it can obtain at most k − 1 shares.

Original: With the k − 1shares, or any possible combination of them, it can construct one and only one polynomial q ′ ( x ) ofdegree k − 1 such that q ′ (0) = secret ′ with secret ̸ = secret ′ .
Revised: With the k −shares, or any possible combination of them, it can construct one and only one polynomial q ′ ( x ) of degree k − 1 such that q ′ (0) = secret ′ with secret ̸ = secret ′ .

Original: As presented in 3.1.2, the polynomialterms are computed modulo p , so there are p possible polynomials that are equally likely so that theadversary can learn nothing about the value of the secret.
Revised: As presented in 3.1.2, the polynomial terms are computed modulo p , so there are p possible polynomials that are equally likely so that the adversary can learn nothing about the value of the secret.

Original:  Experiments 
Revised:  Experiments 4.1 Federated Learning Accuracy Evaluation

Original: 4.1 Federated Learning Accuracy Evaluation

Original: Due to the common requirement in cryptography for all values to be integers, the neural networkweights require rounding to a lower precision in order for commits to be computed.
Revised: Due to the common requirement in cryptography for all values to be integers, the neural network weights require rounding to a lower precision in order for commits to be computed.

Original: Concretely,this means that a copy of the weights is encoded in an integer format by fixing the precision to agiven level, and multiplying by 10 b where b is the appropriate power to give an integer result.
Revised: Concretely, this means that a copy of the weights is encoded in an integer format by fixing the precision to a given level, and multiplying by 10 b where b is the appropriate power to give an integer result.

Original: Aswe can only verify to a fixed level of precision the weights which are sent to the aggregator arecorrespondingly rounded to the appropriate level.
Revised: As we can only verify to a fixed level of precision the weights which are sent to the aggregator are correspondingly rounded to the appropriate level.

Original: We empirically analysed the effect of this onthree different datasets MNIST, CIFAR, and Merged-FEMNIST [18].
Revised: We empirically analysed the effect of this on three different datasets MNIST, CIFAR, and Merged-FEMNIST from the LEAF benchmark [18, 19].

Original: The Merged-FEMNIST is thefederated version of the original extended MNIST dataset [19], while merging classes correspondingto upper and lower case letters with semantically identical inputs.
Revised: The Merged-FEMNIST is the federated version of the original extended MNIST dataset [19], while merging classes corresponding to upper and lower case letters with semantically identical inputs.

Original: Following the original protocol in[18] we merged classes C, I, J, K, L, M, O, P, S, U, V, W, X, Y and  Z with their lower case versionsresulting in a 47 class dataset.
Revised: Following the original protocol in [18] we merged classes C, I, J, K, L, M, O, P, S, U, V, W, X, Y and [Table] Z with their lower case versions resulting in a 47 class dataset.

Original: Full experimental description (model architecture, learning rates, etc)are found in Appendix A.
Revised: Full experimental description (model architecture, learning rates, etc) are found in Appendix A.

Original: We analysed the accuracy difference over precision values of 2 , 4 , 6 , and 8 decimal places (DP) onthe three datasets considered.
Revised: We analysed the accuracy difference over precision values of 2 , 4 , 6 , and 8 decimal places (DP) on the three datasets considered.

Original: Over this range of precision of 4 decimal places or higher was sufficientto retain the original accuracy: differences between the original and rounded neural networks are allwithin a single standard deviation of each other, as show in Table[-
 [Table]-]
Revised: Over this range of precision of 4 decimal places or higher was sufficient to retain the original accuracy: differences between the original and rounded neural networks are all within a single standard deviation of each other, as show in Table[-
 [Table]-]

Original: 4.1.1 Time Evaluation
Revised: 4.1.1 Time Evaluation

Original: Performing cryptographic operations over large neural networks can incur computationaloverhead.
Revised: Performing cryptographic operations over large neural networks can incur computational overhead.

Original: We perform a sweep of the time it takes to compute commitments overall the weights in neural networks of various sizes.
Revised: We perform a sweep of the time it takes to compute commitments over all the weights in neural networks of various sizes.

Original: The results are in Figure 2.
Revised: The results are in Figure 2.

Original: It is only with the very largest keysizes at high levels of precision thatthe time requirement could be of concern.
Revised: It is only with the very largest key sizes at high levels of precision that the time requirement could be of concern.

Original: It is not unususal for cryptographic verification systems to requirelonger overhead, e.g [6] requires closeto 100 seconds with just 5000 parameters.
Revised: It is not unususal for cryptographic verification systems to require longer overhead, e.g [6] requires close to 100 seconds with just 5000 parameters.

Original: By comparison with our methodcan scale to millions of parameters using less time: with a key size of 1024and avoiding excess precision the timeis kept to below 20 seconds for 2 . 5million weights.
Revised: By comparison with our method can scale to millions of parameters using less time: with a key size ofand avoiding excess precision the time is kept to below 20 seconds for 2 .million weights.

Original: The security of thecommitments needs to only be keptto the expected time of a FL roundand so using key sizes in the range of512-1024 will provide the required security.
Revised: The security of the commitments needs to only be kept to the expected time of a FL round and so using key sizes in the range of 512-1024 will provide the required security.

Original: After a FL round has ended theclients will have the commits from theaggregator and so breaking the security of the commits at that point will not enable the aggregator to tamper with the protocol.
Revised: After a FL round has ended the clients will have the commits from the aggregator and so breaking the security of the commits at that point will not enable the aggregator to tamper with the protocol.

Original:  Conclusion
Revised:  Conclusion

Original: In this paper we have presented Verification Via Commitments (VVC) a new protocol based on the
Revised: In this paper we have presented Verification Via Commitments (VVC) a new protocol based on the

Original: Pedersen Commitment scheme to verify that an aggregator has correctly combined the providedweights and has not tampered with the resulting neural network.
Revised: Pedersen Commitment scheme to verify that an aggregator has correctly combined the provided weights and has not tampered with the resulting neural network.

Original: Or protocol does not interfere withthe neural network performance, can be simply implemented, and is computationally lightweight bycryptographic standards.
Revised: Or protocol does not interfere with the neural network performance, can be simply implemented, and is computationally lightweight by cryptographic standards.

Revised: Acknowledgments

Revised: This work has been partially supported by the MORE project (grant agreement 957345), funded by the EU Horizon 2020 program

Original: Appendix A FL Setup
Revised: Appendix A FL Setup

Original: Here we detail the experimental configuration of the FL setups we used for Section 4.
Revised: Here we detail the experimental configuration of the FL setups we used for Section 4.

Original: We use thefollowing notation to describe our models: Conv ( s w ,s h ) C x W x H for a convolutional layer with272 C output channels, and a kernel of width W and height H .
Revised: We use the following notation to describe our models: Conv ( s w ,s h ) C x W x H for a convolutional layer with C output channels, and a kernel of width W and height H .

Original: The stride size in width and height isgiven by s w and s h respectively.
Revised: The stride size in width and height is given by s w and s h respectively.

Original: Likewise MaxPool ( s w ,s h ) W x H for a maxpool layer with a kernelof width W and height H .
Revised: Likewise MaxPool ( s w ,s h ) W x H for a maxpool layer with a kernel of width W and height H .

Original: The stride size in width and height is given by s w and s h respectively.
Revised: The stride size in width and height is given by s w and s h respectively.

Original: Dropout( P ) indicates a dropout layer with dropout probability P .
Revised: Dropout( P ) indicates a dropout layer with dropout probability P .

Original: Additionally, FC N indicates a fully connected layer with N outputs.
Revised: Additionally, FC N indicates a fully connected layer with N outputs.

Original: A.1 MNIST
Revised: A.1 MNIST

Original: For the MNIST dataset we used the following neural network:
Revised: For the MNIST dataset we used the following neural network:

Original: [Equation]
Revised: [Equation]

Original: In the MNIST dataset was randomly split between 20 clients, and each round 10 clients participatedfor a total of 50 FL training rounds.
Revised: In the MNIST dataset was randomly split between 20 clients, and each round 10 clients participated for a total of 50 FL training rounds.

Original: We use 20% of the original training data as the validation set.
Revised: We use 20% of the original training data as the validation set.

Original: We used SGD as the optimiser with a learning rate of 0.01 and batch size of 32.
Revised: We used SGD as the optimiser with a learning rate of 0.01 and batch size of 32.

Original: Each FL round aparticipating client locally trains for one epoch before dispatching their updated weights.
Revised: Each FL round a participating client locally trains for one epoch before dispatching their updated weights.

Original: A.2 CIFAR
Revised: A.2 CIFAR

Original: For the CIFAR dataset we used a VGG style network with the following architecture:
Revised: For the CIFAR dataset we used a VGG style network with the following architecture:

Original: [Equation]
Revised: [Equation]

Original: In the CIFAR dataset was randomly split between 50 clients, and each round 10 clients participatedfor a total of 3500 FL training rounds.
Revised: In the CIFAR dataset was randomly split between 50 clients, and each round 10 clients participated for a total of 3500 FL training rounds.

Original: We use 20% of the original training data as the validation set.
Revised: We use 20% of the original training data as the validation set.

Original: We used SGD as the optimiser with a learning rate of 0.01 and batch size of 32.
Revised: We used SGD as the optimiser with a learning rate of 0.01 and batch size of 32.

Original: Each FL round aparticipating client locally trains for one epoch before dispatching their updated weights.
Revised: Each FL round a participating client locally trains for one epoch before dispatching their updated weights.

Original: A.3 Merged-FEMNIST
Revised: A.3 Merged-FEMNIST

Original: For the Merged-MNIST dataset we used the following neural network from the work in [19]:[Equation] [Equation] 32x5x
Revised: For the Merged-MNIST dataset we used the following neural network from the work in [19]:

Original: [Equation]

Original: [Equation]
Revised: [Equation]

Original: 64x5x [Equation] [Equation] The Merged-FEMNIST is formed by merging classes corresponding to certain upper and lower caseletters as described in [18] and is the data is divided into clients following the procedure in [19].
Revised: The Merged-FEMNIST is formed by merging classes corresponding to certain upper and lower case letters as described in [18] and is the data is divided into clients following the procedure in [19].

Original: Each round 5 clients participated for a total of 3000 FL training rounds.
Revised: Each round 5 clients participated for a total of 3000 FL training rounds.

Original: We use 20% of the originaltraining data as the validation set.
Revised: We use 20% of the original training data as the validation set.

Original: We used SGD as the optimiser with a learning rate of 0.01 andbatch size of 10.
Revised: We used SGD as the optimiser with a learning rate of 0.01 and batch size of 10.

Original: Each FL round a participating client locally trains for one epoch before dispatchingtheir updated weights.
Revised: Each FL round a participating client locally trains for one epoch before dispatching their updated weights.

Original: Appendix B Secret Share Times
Revised: Appendix B Secret Share Times

Original: Here we show supplementary results illustrating the time required by a client to compute the secretbased on 1) the total number of clients the secret is split over and 2) the number of malicious clientsthat are present in the system.
Revised: Here we show supplementary results illustrating the time required by a client to compute the secret based on 1) the total number of clients the secret is split over and 2) the number of malicious clients that are present in the system.

Original: [Figure]
Revised: [Figure]