# Secure Data Sharing in Federated Learning through Blockchain-Based Aggregation
## 3 EIFFeL Framework and Security Analysis
### Scheme Architecture and Workflow  
As mentioned previously, EIFFeL consists of a public bulletin board \(\mathcal{B}\), a single server \(\mathcal{S}\), and \(n\) clients, \(\mathcal{C}_{i}\) (\(1\leq i\leq n\)). It is designed to tolerate a limited number of malicious \(m<\left\lfloor\frac{u}{2}\right\rfloor\). A high-level sketch of the interactions among a client and other entities is shown in Figure 2 while a detailed description of the EIFFeL scheme is shown in Figures 3 and 4. Note that, for simplicity, we only show one client in the diagram. The numbering of the iteration steps corresponds to the description in Figure 4. In order to ensure (1) privacy for all honest clients, and (2) input integrity, where the server is motivated to verify if all individual updates are well-formed, all clients function as verifiers for each other, while the server also participates collectively in this role. Verification remains achievable even in the presence of \(m\) malicious clients. To achieve the designated security guarantees, EIFFeL relies on several cryptographic building blocks (we omit the detailed definition of algorithms; refer to [16] for the full definitions), with each serving a specific purpose in enhancing the scheme's security:  
* [PERSON]'s \(t\)-out-of-\(n\) secret sharing scheme [22]: This cryptographic method facilitates the distribution of a secret among \(n\) participants, and it requires at least \(t\) participants (the threshold) to collectively reconstruct the original secret. Two algorithms are defined, \(SS.Share(\cdot)\) is for generating secret sharing and \(SS.recon(\cdot)\) is for reconstructing the secret. Assuming \(m\) malicious clients, \(t\) is set as \(m+1\) in EIFFeL. * Reed-Solomon error correcting code [23]: It is an error-correcting code used in digital communication and data storage. Reed-Solomon codes add redundant symbols to the original data, allowing the receiver to detect and correct errors during transmission. EIFFeL uses the \([n,m+1,n-m]\) Reed-Solomon error correcting code, where any set of shares containing \(m<\left\lfloor\frac{u}{3}\right\rfloor\) malicious shares can be used to recover the secret with \(robustRecon(\cdot)\). * Key agreement protocol: It enables two or more parties to agree upon a shared secret key. It involves three algorithms: \(KA.param(\cdot)\) is used to generate the parameters, \(KA.gen(\cdot)\) is used to generate a public/private key pair, and \(KA.agree(\cdot)\) is used to agree on a common secret key. * Authenticated encryption: A cryptographic process that combines encryption and message authentication to guarantee the integrity and confidentiality of transmitted data. It includes the algorithms of key generation \(AE.gen(\cdot)\), encryption \(AE.enc(\cdot)\), and decryption \(AE.dec(\cdot)\). * Secret-shared non-interactive proofs (SNIPs) [24]: These are cryptographic protocols that allow multiple parties to jointly prove the truth of a statement without revealing their individual inputs. These proofs are constructed in such a way that the validity of the statement can be verified without requiring interaction between the parties. A public validation predicate \(Valid(\cdot)\) is defined to conduct the integrity check. The EIFFeL framework includes a setup phase and a model training phase. In the model training phase, each training epoch consists of four primary steps, as summarized in Figure 1: (1) local model training, (2) model parameter sharing, (3) model parameter aggregation, and (4) model update. We briefly recap the set and training phases in Figure 3 and Figure 4, respectively, which visually encapsulate the essence of its mechanism. * All parties are given the security parameter, \(k\), the number of clients, \(n\), the threshold for malicious clients, \(m\), and a field \(\mathbb{F}\) for secret sharing usage.