AuditFL: A Contract-Backed Clearing Layer for Open Federated Learning

This is the preprint accepted for publication in the 4th International Conference on Federated Learning Technologies and Applications (FLTA 2026), Paris, France, 27-30 October 2026. The final version will be available in the proceedings of the conference that will be published by IEEE.

arXiv:2610.41278v1 [cs.DC] 30 Oct 2026

AuditFL: A Contract-Backed Clearing Layer for Open Federated Learning Alexandros Balla

Spyros Lalis

Department of Computer Science and Engineering Hong Kong University of Science and Technology Hong Kong SAR, China Email: aballa@cse.ust.hk

Department of Electrical and Computer Engineering University of Thessaly Volos, Greece Email: lalis@uth.gr

Abstract—Federated learning (FL) keeps raw data local, but most deployments still rely on a trusted coordinator for client admission, checkpoint distribution, update collection, aggregation, and rewards. This paper presents AuditFL, a contract-backed clearing layer for auditable FL in open settings. AuditFL keeps training and aggregation off chain, stores model artifacts in an assumed reliable off-chain artifact store, and records only content identifiers and economic state on chain. Clients reserve update tickets with deposits, publish update identifiers, and later claim refunds or rewards; the task coordinator publishes global checkpoints and finalizes rounds through deterministic settlement rules. The design does not remove the aggregator, but makes its on-chain round decisions attributable, replayable, auditable, and economically constrained. We implement AuditFL as both a deterministic state-machine prototype and a Solidity contract on a local Ethereum-compatible Anvil chain. On full MNIST with Dirichlet non-IID splits, 12 rounds, and up to 200 clients, AuditFL preserves the Plain FL learning trajectory while its overhead follows closed-form control-plane models. At 200 clients, the contract run issues 5,026 transactions, stores 2,413 off-chain artifacts (144.9 MiB), and consumes 829.7M EVM gas, dominated by per-client reserve and publish calls. Controlled dropout, invalidupdate, and artifact-unavailability stress tests reduce inclusion nearly linearly but still finalize rounds, with final-accuracy changes remaining within a few tenths of an accuracy percentage point even under high injected failure rates. Index Terms—Federated learning, blockchain, smart contracts, permissionless systems, auditable coordination.

creation, update commitments, round transitions, deposits, and rewards. A naive blockchain design is not sufficient, though. If every model tensor is stored or executed on chain, the ledger becomes a slow storage and computation bottleneck. If the ledger is permissioned, the system cannot support an open market where any client may join. If the consensus protocol is left unspecified, Sybil resistance and finality assumptions are unclear; this is especially important because open peer-to-peer systems are classically vulnerable to identity multiplication attacks [7]. These gaps are visible across blockchain-assisted FL surveys and systems, which often emphasize incentives, privacy, or application frameworks while leaving consensus assumptions and round-level state-machine details less explicit [8]–[13].

I. I NTRODUCTION

This paper presents AuditFL, a contract-backed clearing layer for open FL. The ledger orders and validates small state transitions, while model bytes remain in an assumed reliable distributed off-chain storage layer and are referenced by content identifiers. A task owner, called the task coordinator, applies the configured aggregation rule and publishes the next global checkpoint. AuditFL keeps aggregation with this designated actor, but moves round ordering, commitments, deposits, refunds, rewards, and claims into a public clearing layer. The resulting trace makes coordinator actions visible, replayable, auditable, and economically constrained.

Federated learning (FL) trains a shared model by sending computation to clients instead of moving raw data to a central server [1]–[4]. This is useful for edge devices, healthcare, finance, and cross-organization learning, where data movement is expensive, sensitive, or restricted. However, the standard FL control plane is usually centralized. A coordinator selects clients, distributes checkpoints, receives updates, aggregates them, records progress, and often controls rewards. If this coordinator is compromised or biased, it can censor participants, hide updates, manipulate aggregation, or publish a round outcome whose inputs, checkpoint, and accounting cannot be independently reconstructed. Blockchains offer a public ordering layer for distributed protocols through replicated logs, fork choice, and consensus assumptions [5], [6]. In FL, a ledger can be used to record task

The paper makes four contributions: (i) We define AuditFL as a contract-backed clearing layer for open FL, separating on-chain coordination and settlement from off-chain training, aggregation, and artifact storage. (ii) We specify the roundclearing state machine, including task listing, funding, ticket reservation with deposits, update publication, global finalization, refunds, reward entitlements, and claims. (iii) We give a layered safety and liveness argument showing how ledger ordering, confirmation depth, ticket expiry, deposits, refunds, and scoring make coordinator and client actions replayable and economically accountable under partial synchrony [14]. (iv) We implement and evaluate the clearing layer on a local Ethereumcompatible chain with a non-IID MNIST workload, measuring transactions, gas cost, artifact counts and bytes, and behavior under dropout, invalid-update, and artifact-unavailability stress.

© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

TABLE I P OSITIONING AGAINST REPRESENTATIVE BLOCKCHAIN - ASSISTED , ACCOUNTABLE , AUDITABLE , AND VERIFIABLE FL WORK . Work BlockFL [8] Biscotti [10] FedCoin [15] ChainFL [16] BlockFLA [17] BlockFLow [18] Auditable BR-FL [19] VerifBFL [20] AuditFL

Open Commit. Partic. Econ. Contract Fault/ Main emphasis admit. refs.* bond settle. cost attack focus △ ✓ △ – – – – – ✓

– ✓ – – ✓ ✓ ✓ ✓ ✓

– – – – ✓ ✓ △ ✓ ✓

– – ✓ – ✓ ✓ △ ✓ ✓

– – – △ ✓ ✓ – △ ✓

– ✓ – – ✓ ✓ ✓ ✓ ✓

block-generation latency private/secure P2P FL Shapley-based payments on-chain model storage/aggregation backdoor accountability accountable rewards Byzantine-robust audit zk-verifiable FL auditable round clearing

✓ = explicit focus; △ = partial or adjacent support; – = not central in the cited work. * Cryptographic commitments or content identifiers for model/update objects; open admission excludes pre-approved clients.

II. R ELATED W ORK AND P OSITIONING

Table I positions AuditFL against representative systems. The comparison is feature-oriented: it records whether a work explicitly emphasizes a feature as part of its design or evaluation, not whether that feature could be added. Unlike accountable, Byzantine-robust, or verifiable FL systems that audit contribution quality or aggregation correctness, AuditFL audits the clearing layer around each round: ticketed admission, update commitments, deterministic settlement of the submitted finalization record, refunds, claims, and contract execution cost.

FL was introduced as a practical way to train on decentralized client data using iterative model averaging [1]. Later system work clarified that real FL deployments require scheduling, retry logic, guided participant selection, benchmarking infrastructure, secure aggregation, device availability handling, production control-plane engineering, and robustness to statistical and systems heterogeneity [2]–[4], [21]–[23]. Those works do not attempt to make client admission or round finalization III. S YSTEM M ODEL AND D ESIGN G OALS permissionless. They usually assume an operator-controlled service. Our work keeps the FL computation model, but A. Roles and Assumptions moves task creation, update admission, round transitions, and The system has three active roles. The task coordinator accounting into a public ledger state machine. creates the FL task, funds the reward pool, retrieves revealed BlockFL studies the latency consequences of replacing a updates, applies the configured aggregation rule, publishes central FL coordinator with block generation [8]. Biscotti the new global checkpoint, and finalizes each round. This uses blockchain and cryptographic primitives for private is the conventional FL aggregator role; AuditFL does not and secure peer-to-peer FL, while FedCoin and ChainFL remove it, but makes its round-level actions public, replayable, explore blockchain-based incentives or decentralized model and economically constrained. Clients read the current model coordination [10], [15], [16]. BlockFLA is closest to our state, reserve tickets, train on local data, make update artifacts accountability motivation: it records SHA-256 hashes, deposits, available through the assumed off-chain artifact store, publish and penalties for detected backdoor attackers through a hybrid update content identifiers on chain, and claim any resulting blockchain design [17]. refund or reward. The ledger layer provides authenticated Accountable, auditable, and verifiable FL systems address ordering and deterministic validation for signatures, balances, adjacent trust problems. BlockFLow uses smart contracts and nonces, round indices, ticket ownership, deadlines, rate limits, auditing mechanisms to reward agents based on contribution identifier syntax, and state transitions. quality [18]. Auditable Byzantine-robust FL studies auditabilThe task coordinator is designated but auditable: AuditFL ity at the robust-aggregation layer [19], while verifiable-FL decentralizes participation, ordering, and accounting, while systems target cryptographic checks of aggregation or training keeping aggregation execution with a visible task owner whose correctness [20], [24]. AuditFL is complementary: it focuses round-level actions are recorded in the public trace. on the round-clearing control plane, namely ticketed admission, We assume partial synchrony for a deployed permissionless update commitments, deterministic settlement of the submitted ledger: before an unknown stabilization time, messages may be finalization record, refund/claim settlement, and measured delayed, but after stabilization honest messages are delivered contract execution cost. within a bounded delay [14]. The adversary may create Other BC-FL systems focus on privacy-preserved data many client identities, submit malformed content identifiers, sharing in Industrial IoT or secure/incentive FL settings [9], withhold off-chain artifacts, attempt model poisoning, misreport [25]. Surveys confirm that blockchain-assisted FL has been metrics, and, in a proof-of-stake (PoS) deployment, corrupt studied across decentralization, incentives, storage, privacy, less than half of the bonded stake. A task coordinator may security, and application settings, while scalability, storage also behave strategically by omitting available updates or using pressure, consensus assumptions, and adversarial participation a weak scoring rule. The adversary cannot forge standard remain recurring open issues [11]–[13], [26]–[28]. digital signatures or find collisions in the content hashes

used by identifiers. Public consensus security is a deployment assumption; AuditFL specifies the clearing-layer rules that execute above a ledger satisfying these assumptions. Threats are separated by layer. Consensus faults may delay, censor, fork, or reorder ledger events within the assumed consensus bounds. Clearing-layer faults include malformed identifiers, low-quality updates, unavailable artifacts, selective omission, or weak scoring. These faults affect inclusion, settlement, and auditability, but not block validity: invalid or unavailable updates are skipped and settled by policy, and the ledger never fetches tensors.

TABLE II AUDIT FL TRANSACTION OBJECTS . Object

Main effect and checks

Creates a task with model identifier, initial content identifier, deadlines, deposits, and immutable rules. FundingTx Adds tokens to the reward pool after signer, balance, and amount checks. UpdateIntentTx Reserves a ticket, locks a deposit, and enforces per-account caps. UpdatePublishTx Binds a live unrevealed ticket to an update content identifier. GlobalUpdateTx Finalizes the round with global identifier, included tickets, refunds, and scores; advances the round and credits entitlements. ClaimTx Debits an entitlement and credits the claimant balance. ListingTx

B. Design Goals and Non-Goals The first goal is open coordination: clients and validators are skipped and settled by policy rather than blocking round should not need prior admission by a central authority. The progress. second goal is minimal consensus: block validation should not depend on ML libraries, GPU kernels, or off-chain storage B. Transaction State Machine fetches. The third goal is round auditability: from public chain Table II lists the transaction objects. All validators execute state and retrievable content identifiers, an auditor should the same deterministic state machine. A model must be listed be able to replay the round-level control flow and verify before it can be funded or updated. A publication must reference the economic outcome. The fourth goal is economic spam a live unrevealed ticket created by an earlier intent for the same resistance: wasting publication slots or withholding content model and round. A global update must match the current round should cost deposits or fees, aligning with recent incentive- and can only reference tickets that are already revealed. These oriented FL and BC-FL discussions [29]. invariants prevent hidden updates, double publication, stale AuditFL is not a complete privacy or poisoning-defense finalization, and unreserved update spam. mechanism. Raw data remain local, but model updates may Validators also apply a strict replay rule. Admission checks still leak information, and malicious updates may still affect are useful for mempool hygiene, but block validity is decided the learned model. Stronger guarantees require complementary by re-executing the ordered transactions from the parent state. mechanisms such as secure aggregation [30], differential A block that admits a transaction in the mempool can still be privacy [2], and robust aggregation [31]–[33]. invalid if another transaction in the same block consumes the relevant balance, advances the round, or reveals the ticket first. IV. P ROTOCOL This is why the protocol treats every state transition as atomic and why repeated calls use nonces and idempotent checks. A. Round Workflow Fig. 1 summarizes one training round. The task coordinator C. Tickets, Refunds, and Payouts first uploads an initial checkpoint to off-chain storage and A ticket reserves one update-publication slot for the current submits a ListingTx that binds a modelID to an initial round and requires the client to lock a deposit. If a client content identifier and an immutable rule set, including deadreserves a ticket but never publishes an update identifier, the lines, deposits, and the aggregation/scoring policy. The task deposit is forfeited. If the client publishes an identifier whose coordinator then funds the reward pool with FundingTx. artifact is retrievable and passes the rule-declared serialization A client reads the current round, locks a deposit through and shape checks, the deposit is refundable even when the UpdateIntentTx, receives a ticket, trains locally, uploads update earns no reward. If the artifact is unavailable or fails the update to off-chain storage, and binds the ticket to these basic validity checks, the deposit is forfeited. Thus, the an update identifier through UpdatePublishTx. At the deposit prices reservation and unusable-update behavior, while deadline, the task coordinator fetches retrievable revealed reward payments depend on the contribution score. updates, filters invalid shapes, scores candidates, aggregates The task coordinator assigns a nonnegative score sj to each eligible updates, uploads the new global checkpoint, and included update j. One illustrative rule is submits GlobalUpdateTx. The ledger state machine then advances the round, records the latest global identifier, credits sj = max(0, ∆j )wj , (1) rewards, and marks refundable deposits, which clients withdraw through ClaimTx. where ∆j is the improvement of candidate update j over the The key separation is between ordering, artifact retrieval, previous global model on the task coordinator’s validation set, and learning. The ledger orders and validates round-level state and wj is a capped proxy for the client’s local sample size. For transitions; the off-chain artifact layer serves model bytes; and a fixed task, let Rr be the reward pool for round r, let Ir be the training, scoring, validation, and aggregation execute off chain set of updates included in that round, and let γ ∈ [1, 2] be the according to the task rules. Invalid or unavailable updates listing-time payout exponent, with larger values concentrating

Fig. 1. AuditFL round workflow. Solid arrows denote control transactions and accounting state, while dashed arrows denote off-chain artifact transfers. Only identifiers and economic state enter the chain; tensors stay outside contract execution.

Round finalization rule. For a fixed task and round r: (1) read all round-r tickets from the k-deep chain view and identify the revealed subset; (2) sort revealed tickets by identifier; (3) fetch referenced updates with bounded retries; (4) add usable revealed tickets to refunds[]; (5) add shape-valid and score-positive updates to included[] and scores[]; (6) aggregate included updates off chain; (7) upload the global checkpoint and submit GlobalUpdateTx; (8) the ledger advances r only if referenced tickets are valid, submitted arrays align, and unresolved tickets are settled according to policy.

otherwise, the auditor can verify only that payouts, refunds, forfeitures, and claims are consistent with the submitted scores and on-chain rules. Within a confirmed round, every funded reward and locked deposit is accounted for through a reward entitlement, refund entitlement, forfeiture destination, remaining pool balance, or explicitly charged fee.

Fig. 2. Round finalization rule. The task coordinator aggregates off chain; the ledger checks identifiers, array alignment, and settlement state, not tensor bytes.

For a permissionless proof-of-stake (PoS) ledger, time is divided into slots. In slot t, validator i with stake sti and total stake ST may be eligible to propose a block according to stake-weighted randomness:

rewards on higher-scoring updates. The payout for an included update j ∈ Ir is payj = Rr P

sγj

γ, u∈Ir su

(2)

with zero payout when sj = 0 or the denominator is zero. The ledger enforces settlement arithmetic rather than the correctness of the task-specific scoring policy. It applies the submitted score vector s = (sj )j∈Ir , whose entries correspond to the included ticket identifiers in the finalized round, together with the declared rule parameters. When the listing exposes a public validation set or a committed evaluation procedure, an auditor can recompute scores and reward entitlements;

V. L EDGER AND A RTIFACT A SSUMPTIONS A. PoS Longest-Chain Deployment Model

sti , (3) ST where τ controls the expected proposer density. Splitting the same stake across many identities does not increase expected eligibility, because leader probability follows total stake rather than identity count. If multiple valid blocks are observed, fork choice selects the longest valid chain, with a deterministic tie-breaker. Protocol participants that depend on a ledger write, such as clients waiting for ticket confirmation or the task coordinator waiting to finalize a round, treat the write as stable after k confirmations. Larger k reduces reorganization risk but Pr[i proposes a block in slot t] ≈ τ

increases round latency. If a round depends on Br blockproducing stages, the expected latency can be approximated as ∆ Lround ≈ (Br + k) , (4) p(n, τ )

AuditFL assumes a reliable distributed off-chain storage layer that stores and retrieves model artifacts by content identifier during the relevant round window. The ledger never stores tensors and never fetches artifact bytes during validation. It only checks that submitted identifiers are syntactically well formed and bound to the correct ticket or round transition. Clients, task coordinators, and auditors retrieve artifacts outside consensus and verify that the bytes match the published identifiers. Systems such as IPFS [34] illustrate one possible substrate, but the storage protocol itself is outside the scope of AuditFL. This interface has two advantages. First, blocks stay small because they contain content identifiers, ticket IDs, scores, and state deltas rather than tensors. Second, slow or missing offchain content does not halt consensus. If an update cannot be retrieved before aggregation closes, the task coordinator omits it and the refund policy decides the economic outcome.

outstanding ticket reservations; they do not, by themselves, guarantee Sybil-proof reward fairness or truthful contribution scoring. Learning integrity is intentionally separated from consensus. Byzantine clients can still submit poisoned tensors, and the task coordinator can choose weak validation rules or selectively include updates. AuditFL can enforce basic wellformedness checks, such as serialization and shape checks, while leaving robust aggregation to the task-specific aggregation rule. Stronger aggregation rules such as Krum, coordinate-wise median, trimmed mean, or recent robust FL methods can be inserted without changing the ledger state machine [31]–[33]. Privacy is also model-dependent. Raw data never enter the ledger, but updates can leak information through gradients or membership signals; secure aggregation and differential privacy remain compatible model-specific options [2], [30], [36]–[38]. A complete round has a replay path. An auditor starts from the confirmed listing rules, previous global content identifier, and revealed tickets. For each included update, the auditor fetches the referenced artifact, checks serialization and shape rules, recomputes public scores when the validation data are available, reruns the deterministic aggregator, and checks that the resulting bytes hash to the accepted globalCID or equivalent identifier. The auditor can also recompute refund and reward entitlements from refunds[] and scores[]. This is weaker than a cryptographic proof of correct aggregation, but stronger than trusting a silent coordinator: deviations leave public evidence. AuditFL narrows, rather than removes, trust in the task coordinator. It does not prove that the selected aggregation outcome is optimal, but it prevents silent history rewrites, hidden updates, and arbitrary reward minting because round transitions and payouts are anchored in the ledger. When validation data or a committed evaluation oracle are available, scoring can also be replayed. Thus, the security claim is detectability and accountability, not cryptographic enforcement of aggregation correctness.

VI. S ECURITY AND C ORRECTNESS D ISCUSSION

VII. P ROTOTYPE I MPLEMENTATION

where ∆ is slot duration, n is the number of equal-stake validators, and p(n, τ ) = 1 − (1 − τ /n)n is the probability that at least one validator is eligible in a slot. This model is intentionally simple, but it explains why lower confirmation depth and moderate τ reduce latency, while high proposer density increases fork contention. AuditFL only requires the ledger interface exposed by this model: open transaction submission, stake-weighted Sybil resistance, an ordered log of confirmed state transitions, and probabilistic finality. The clearing-layer protocol does not depend on a specific PoS implementation; a public longestchain ledger, a chain with BFT finality, or another ledger providing authenticated ordering and stable confirmed writes can instantiate the same transaction model. B. Off-Chain Storage Interface

The consensus layer targets common prefix, chain growth, and chain quality under partial synchrony and honest majority of stake [6], [35]. Confirmation depth prevents the FL layer from acting on tentative history. If a publication or global update is displaced before depth k, the caller retries against the new canonical state. Transaction nonces and idempotent checks prevent duplicated state effects. Clearing-layer safety follows from causality invariants. A valid GlobalUpdateTx cannot name an unlisted model, cannot finalize an old round, and cannot include tickets that were not revealed. Economic safety follows from explicit pools and entitlements: deposits and rewards move only through deterministic transfers, and the settlement invariant in Sec. IV-C accounts for each funded reward and locked deposit. Validator equivocation can be made slashable because conflicting signed messages provide evidence. Transaction fees, locked deposits, and intent caps make reservation spam costly and bound

In our prototype1 , we instantiate the ledger interface as a Solidity smart contract executed on a local Ethereumcompatible Anvil chain. This evaluates the application-level clearing logic and contract execution cost, not public-chain consensus behavior. AuditFL also includes a deterministic in-memory statemachine backend used for fast debugging and controlled tests. The Solidity backend deploys a BCFLCoordinator contract that implements the core coordination calls: createListing, fundRound, reserveTicket, publishUpdate, finalizeRound, and claim. The contract stores only coordination metadata, ticket state, reward-pool state, content identifiers, and entitlements. 1 An artifact repository containing the Solidity contract, experiment runners, plotting scripts, and paper-result CSVs is available at https://anonymous.4open.science/r/AuditFL-6BE3.

200M 0k

1k

1 + R(2N + 2) + N + 1

0k 0M

0k 0

25

50

75

100

125

150

175

0

200

0

clients

VIII. E VALUATION We evaluate AuditFL as a control-plane system along five dimensions: (i) end-to-end execution; (ii) agreement between measured transaction counts and a simple analytical model; (iii) EVM execution cost, measured in gas; (iv) off-chain artifact-volume scaling; and (v) preservation of the Plain FL learning trajectory. We use two backends: a Solidity BCFLCoordinator contract on a local Ethereum-compatible Anvil chain for transaction and gas measurement, and a deterministic state-machine backend for controlled failure stress. Both use the same Python client and task coordinator logic and the same local SHA-256 content-addressed artifact store. We run experiments on the full 70,000-MNIST dataset loaded through OpenML [41], [42], varying the number of clients N ∈ {1, 2, 5, 10, 15, 20, 30, 40, 50, 75, 100, 150, 200}. For each run, we construct a stratified split with 42,000 training examples, 10,500 validation examples, and 17,500 held-out test examples. Client data are drawn only from the training partition; the task coordinator uses the validation partition for update scoring, and final accuracy is reported on the held-out test partition. Each run performs R = 12 FL rounds. For N > 1, the training partition is distributed non-IID among clients using a Dirichlet distribution with α = 0.4. For every client count, Plain FL and AuditFL use the same split, model, local-training rule, number of rounds, and aggregation rule. Thus, any difference between the two runs comes from AuditFL coordination and settlement rather than from the learning rule. The measured on-chain call structure depends on rounds, participating clients, identifiers, and settlement operations, while larger learning workloads primarily affect off-chain computation and, when model size changes, artifact volume.

(a)(c)Gas breakdown byby contract call calls Gas dominated per-client

(b) Ar

reserveTicket publishUpdate finalizeRound other

600M

2

10 550000

MiB, log scale gas / client-round

800M

gas used

In Ethereum-compatible chains, smart contracts execute inside the Ethereum Virtual Machine (EVM), while gas is the unit used to meter computational and storage work performed by a transaction [39]. We report gas as a proxy for smartcontract execution cost, not as a monetary deployment cost, because monetary cost depends on the gas price of a particular network. The client and task coordinator processes are written in Python. Clients read the current round, reserve tickets, train local models, serialize updates, place update bytes in a local SHA-256 content-addressed artifact store [40], and publish the resulting identifier. The task coordinator fetches retrievable updates, filters invalid shapes, aggregates valid updates using the same FedAvg-style rule as the Plain FL baseline [1], writes the next global model to the artifact store, and finalizes the round on chain.

400M

200M

101 500000 100 450000 10−1 400000 10−2 350000

reserve+publish ≈ 87.1% at N=200 0M

10−3 0

25

50

75

100

125

150

175

0

200

clients

Fig. 3. Contract execution cost on MNIST with R = 12.

For a complete run with one listing transaction, R rounds, and one claim per client, the application transaction count is Tapp = 1 + R × (2N + 2) + N.

(6)

The measured receipt count additionally includes one contractdeployment transaction: Tmeasured = 1 + R × (2N + 2) + N + 1.

(7)

Off-chain artifact writes are also predictable. Each clean run stores one initial global model, R × N client-update artifacts, and R updated global-model artifacts: Pput = 1 + R × (N + 1).

(8)

This is the artifact-count quantity compared against the clean scaling measurements. B. Full-MNIST Scaling Results (clean runs, no failures)

Measured receipt counts match the analytical model for every tested client count. With R = 12, the receipt count increases from 51 transactions at N = 1 to 5,026 at N = 200 clients, matching 2 + R × (2N + 2) + N . Stored artifact counts also match the analytical model exactly, increasing from 25 artifacts at N = 1 to 2,413 at N = 200, matching 1 + R × (N + 1). Fig. 3 reports the gas breakdown. At N = 200, the contract run consumes 829.7M gas: publishUpdate accounts for 408.7M gas and reserveTicket for 314.3M gas, together accounting for approximately 87.1% of total execution cost. This follows directly from the protocol structure, since each participating client reserves one ticket and publishes one update identifier per round, whereas finalizeRound is invoked once per round. As a further consistency check, the implementation explicitly verifies that the settlement invariant A. Overhead Model in Sec. IV-C holds in every run. Let N be the number of clients and R the number of Fig. 4 reports off-chain artifact-volume scaling. At N = rounds. Plain FL transfers model and update tensors, but does 200, artifact bytes occupy 144.9 MiB, whereas the committed not maintain a public economic log. AuditFL leaves tensors SHA-256 identifier strings occupy only 0.163 MiB, a ratio off chain and adds a ledger control plane. In a clean fullof approximately 887×. This supports the design choice of participation round, the application transactions are keeping tensors off chain while committing only identifiers Tround = 1fund +Nreserve +Npublish +1finalize = 2N +2. (5) and coordination state on chain.

0

200M 0k

175

20

1 + R(N + 1)

0k 0M 0

200

0

25 25 50 50

75 75 100 100 125 125 150 150 175 175

0

200 200

0

25

50

75

clients clients

(b) Artifact(c) bytes vs.per committed identifier bytes Tensors dominate identifiers (d) Gas client-round stabilizes 120

101 500000

KiB / client-round

MiB, log scale gas / client-round

10 550000

0

10 450000 10−1 400000

110 100

−2

10 350000

artifact bytes ≈ 887× identifiers at N=200

345710

0

80 70

0

25 25 50 50

75 75 100 100 125 125 150 150 175 175

200 200

clients clients

175

200

Dropout Invalid updates Storage failure

40

30

20

61.8

10

0

25

50

75

100

125

150

175

0.10

Across all runs, AuditFL matches exactly the corresponding (a) Included updates accuracy of Plain FL. This is because both protocols execute 50 Dropout the same learning rule over the same included updates. Invalid In both updates failure cases, final test accuracy ranges from 89.65% at N Storage = 1 to 40 89.21% at N = 200 clients. Note that the variation across client counts results from the the differences in non-IID data 30 partitioning (this varies depending on the number of clients). 20

C. Controlled Failure Stress

0.00 −0.05 −0.10 −0.15 −0.20 −0.25 −0.30

200

10

20

30

40

50

Injected failure rate (%)

Fig. 4. Committed identifier bytes and off-chain artifact bytes on MNIST with R = 12.

0.05

clients

0 0

Mean included updates / round

200

90

60

10−3 175

150

50

Fig. 5. Mean included updates per round under injected failures. (b) Learning impact 0.10

Accuracy gap vs Plain FL (pp)

1% at N=200

125

(d) Storage (a) perIncluded client-round updates 130

artifact bytes identifier bytes

2

Mean included updates / round

tl calls

100

clients

Accuracy gap vs Plain FL (pp)

+ 2) + N + 1

0.05 0.00 −0.05 −0.10 −0.15 −0.20

We run controlled state-machine stress tests on MNIST with −0.25 Dropout 10 Invalid updates N = 50, R = 12, three seeds, and artificially induced failure −0.30 Storage failure rates from 0% to 50%. We test three fault modes. (i) In client 0 0 10 publish 20 an update 30 for the 40 round. 50 0 10 20 30 40 50 dropout, selected clients do not Injected failure rate (%) Injected failure rate (%) (ii) In invalid update, selected clients publish updates that fail the rule-declared validity checks before aggregation. (iii) In artifact unavailability, the update identifier is published but Fig. 6. Final test-accuracy difference relative to Plain FL under different injected failure modes. The plotted value is AuditFL under failure minus Plain the referenced artifact cannot be retrieved during aggregation. FL, in accuracy percentage points. In these experiments, we use the state-machine backend because the tests concern inclusion, update validity, artifact availability, and round completion rather than EVM execution slightly higher final accuracy. Small positive values can occur cost. Artifact-unavailability injections deliberately relax the because the client data are non-IID, so excluding some updates nominal reliable-storage assumption in order to test whether may occasionally remove noisy or less useful contributions. the clearing layer continues to make progress when referenced Overall, the observed changes remain within a few tenths of updates cannot be retrieved. Very high failure rates, e.g., above an accuracy percentage point, even under high injected failure 30%, are included only as extreme stress conditions, not as rates. Note that these experiments are intended as stress tests expected operating points. of round completion and learning degradation, rather than to Fig. 5 shows that client dropout, invalid updates, and artifact compare the fault mechanisms to establish whether one is unavailability reduce inclusion approximately linearly but do systematically more harmful than the others. With only three not prevent round finalization. The similar inclusion curves seeds, we interpret the observed differences as small variations follow from the common aggregation-level consequence of across failure realizations rather than evidence that one fault these faults: dropout prevents an update from being published, type is systematically more damaging than another. invalid updates are filtered before aggregation, and unavailable IX. C ONCLUSION artifacts cannot be retrieved; in each case, the affected contribuAuditFL is a contract-backed clearing layer for open federtion is excluded. Even at 50% injected failures, approximately ated learning. It records ticketed admission, update commit25 updates per round remain included. Fig. 6 reports the final test-accuracy difference between ments, round transitions, refunds, rewards, and claims on chain each failure run and the corresponding Plain FL run. Negative while keeping model artifacts, training, and aggregation off values mean that the failure run achieved lower final accuracy chain. On MNIST with non-IID client partitions, the prototype than Plain FL, while positive values mean that it achieved preserves the Plain FL learning trajectory in clean runs,

0

measured transaction and artifact counts match the analytical model, per-client reserve/publish calls dominate EVM gas, and controlled failures reduce inclusion without preventing round finalization. The evaluation measures clearing-layer behavior on a local Anvil chain and a local content-addressed artifact store; it does not measure public-network delay or cryptographically enforce aggregation correctness. Future work includes public-network measurements, larger FL workloads, replicated artifact storage, and stronger or verifiable aggregation mechanisms. R EFERENCES [1] H. B. McMahan, E. Moore, D. Ramage, S. Hampson, and B. A. y Arcas, “Communication-efficient learning of deep networks from decentralized data,” in Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS), ser. Proceedings of Machine Learning Research, vol. 54, 2017, pp. 1273–1282. [2] P. Kairouz, H. B. McMahan, B. Avent, A. Bellet, M. Bennis, A. N. Bhagoji, K. Bonawitz et al., “Advances and open problems in federated learning,” Foundations and Trends in Machine Learning, vol. 14, no. 1–2, pp. 1–210, 2021. [3] K. Bonawitz, H. Eichner, W. Grieskamp, D. Huba, A. Ingerman, V. Ivanov, C. Kiddon, J. Konecny, S. Mazzocchi, H. B. McMahan, T. V. Overveldt, D. Petrou, D. Ramage, and J. Roselander, “Towards federated learning at scale: System design,” in Proceedings of Machine Learning and Systems (MLSys), vol. 1, 2019, pp. 374–388. [4] T. Li, A. K. Sahu, A. Talwalkar, and V. Smith, “Federated learning: Challenges, methods, and future directions,” IEEE Signal Processing Magazine, vol. 37, no. 3, pp. 50–60, 2020. [5] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” White paper, 2008. [6] J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone protocol: Analysis and applications,” in Advances in Cryptology – EUROCRYPT 2015, ser. Lecture Notes in Computer Science, vol. 9057. Springer, 2015, pp. 281–310. [7] J. R. Douceur, “The sybil attack,” in Peer-to-Peer Systems, First International Workshop, IPTPS 2002, ser. Lecture Notes in Computer Science, vol. 2429. Springer, 2002, pp. 251–260. [8] H. Kim, J. Park, M. Bennis, and S.-L. Kim, “Blockchained on-device federated learning,” IEEE Communications Letters, vol. 24, no. 6, pp. 1279–1283, 2020. [9] Y. Lu, X. Huang, Y. Dai, S. Maharjan, and Y. Zhang, “Blockchain and federated learning for privacy-preserved data sharing in industrial IoT,” IEEE Transactions on Industrial Informatics, vol. 16, no. 6, pp. 4177–4186, 2020. [10] M. Shayan, C. Fung, C. J. M. Yoon, and I. Beschastnikh, “Biscotti: A blockchain system for private and secure federated learning,” IEEE Transactions on Parallel and Distributed Systems, vol. 32, no. 7, pp. 1513–1525, 2021. [11] Y. Qu, M. P. Uddin, C. Gan, Y. Xiang, L. Gao, and J. Yearwood, “Blockchain-enabled federated learning: A survey,” ACM Computing Surveys, vol. 55, no. 4, pp. 1–35, 2022. [12] J. Huang, L. Kong, G. Chen, Q. Xiang, X. Chen, and X. Liu, “Blockchainbased federated learning: A systematic survey,” IEEE Network, vol. 37, no. 6, pp. 150–157, 2023. [13] Z. Wang, Q. Hu, M. Xu, Y. Zhuang, Y. Wang, and X. Cheng, “A systematic survey of blockchained federated learning,” 2024, arXiv:2110.02182. [14] C. Dwork, N. Lynch, and L. Stockmeyer, “Consensus in the presence of partial synchrony,” Journal of the ACM, vol. 35, no. 2, pp. 288–323, 1988. [15] Y. Liu, Z. Ai, S. Sun, S. Zhang, Z. Liu, and H. Yu, “FedCoin: A peerto-peer payment system for federated learning,” in Federated Learning: Privacy and Incentive. Springer, 2020, pp. 125–138. [16] C. Korkmaz, H. E. Kocas, A. Uysal, A. Masry, Ö. Özkasap, and B. Akgün, “Chain FL: Decentralized federated machine learning via blockchain,” in 2020 Second International Conference on Blockchain Computing and Applications (BCCA). IEEE, 2020, pp. 140–146. [17] H. B. Desai, M. S. Ozdayi, and M. Kantarcioglu, “BlockFLA: Accountable federated learning via hybrid blockchain architecture,” in Proceedings of the Eleventh ACM Conference on Data and Application Security and Privacy, ser. CODASPY ’21. ACM, 2021, pp. 101–112.

[18] V. Mugunthan, R. Rahman, and L. Kagal, “Blockflow: An accountable and privacy-preserving solution for federated learning,” 2020. [Online]. Available: https://arxiv.org/abs/2007.03856 [19] Y. Liang, Y. Li, and B.-S. Shin, “Auditable federated learning with byzantine robustness,” IEEE Transactions on Computational Social Systems, vol. 11, no. 6, pp. 8191–8203, 2024. [20] A. A. Bellachia, M. A. Bouchiha, Y. Ghamri-Doudane, and M. Rabah, “Verifbfl: Leveraging zk-snarks for a verifiable blockchained federated learning,” 2025. [Online]. Available: https://arxiv.org/abs/2501.04319 [21] T. Li, A. K. Sahu, M. Zaheer, M. Sanjabi, A. Talwalkar, and V. Smith, “Federated optimization in heterogeneous networks,” in Proceedings of Machine Learning and Systems (MLSys), vol. 2, 2020, pp. 429–450. [22] F. Lai, X. Zhu, H. V. Madhyastha, and M. Chowdhury, “Oort: Efficient federated learning via guided participant selection,” in 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI). USENIX Association, 2021, pp. 19–35. [23] F. Lai, Y. Dai, S. S. Singapuram, J. Liu, X. Zhu, H. V. Madhyastha, and M. Chowdhury, “Fedscale: Benchmarking model and system performance of federated learning at scale,” in Proceedings of the 39th International Conference on Machine Learning (ICML), ser. Proceedings of Machine Learning Research, vol. 162, 2022, pp. 11 814–11 827. [24] A. Fu, X. Zhang, N. Xiong, Y. Gao, H. Wang, and J. Zhang, “Vfl: A verifiable federated learning with privacy-preserving for big data in industrial iot,” IEEE Transactions on Industrial Informatics, vol. 18, no. 5, pp. 3316–3326, 2022. [25] Y. Xu, Z. Lu, K. Gai, Q. Duan, J. Lin, J. Wu, and K.-K. R. Choo, “BESIFL: Blockchain-empowered secure and incentive federated learning paradigm in IoT,” IEEE Internet of Things Journal, vol. 10, no. 8, pp. 6561–6573, 2023. [26] W. Ning, Y. Zhu, C. Song, H. Li, L. Zhu, J. Xie, T. Chen, T. Xu, X. Xu, and J. Gao, “Blockchain-based federated learning: A survey and new perspectives,” Applied Sciences, vol. 14, no. 20, p. 9459, 2024. [27] H. Zhang, S. Jiang, and S. Xuan, “Decentralized federated learning based on blockchain: Concepts, framework, and challenges,” Computer Communications, vol. 216, pp. 140–150, 2024. [28] E. Hallaji, R. Razavi-Far, M. Saif, B. Wang, and Q. Yang, “Decentralized federated learning: A survey on security and privacy,” IEEE Transactions on Big Data, vol. 10, no. 2, pp. 194–213, 2024. [29] Y. Zhan, J. Zhang, Z. Hong, L. Wu, P. Li, and S. Guo, “A survey of incentive mechanism design for federated learning,” IEEE Transactions on Emerging Topics in Computing, 2021. [30] K. Bonawitz, V. Ivanov, B. Kreuter, A. Marcedone, H. B. McMahan, S. Patel, D. Ramage, A. Segal, and K. Seth, “Practical secure aggregation for privacy-preserving machine learning,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2017, pp. 1175–1191. [31] P. Blanchard, E. M. E. Mhamdi, R. Guerraoui, and J. Stainer, “Machine learning with adversaries: Byzantine tolerant gradient descent,” in Advances in Neural Information Processing Systems (NeurIPS), 2017, pp. 119–129. [32] D. Yin, Y. Chen, R. Kannan, and P. Bartlett, “Byzantine-robust distributed learning: Towards optimal statistical rates,” in Proceedings of the 35th International Conference on Machine Learning (ICML), ser. Proceedings of Machine Learning Research, vol. 80, 2018, pp. 5650–5659. [33] K. Pillutla, S. M. Kakade, and Z. Harchaoui, “Robust aggregation for federated learning,” IEEE Transactions on Signal Processing, vol. 70, pp. 1142–1154, 2022. [34] J. Benet, “IPFS – content addressed, versioned, P2P file system,” 2014, arXiv:1407.3561. [35] A. Kiayias, A. Russell, B. David, and R. Oliynykov, “Ouroboros: A provably secure proof-of-stake blockchain protocol,” in Advances in Cryptology – CRYPTO 2017, ser. Lecture Notes in Computer Science, vol. 10401. Springer, 2017, pp. 357–388. [36] L. Zhu, Z. Liu, and S. Han, “Deep leakage from gradients,” 2019, arXiv:1906.08935. [37] L. Melis, C. Song, E. D. Cristofaro, and V. Shmatikov, “Exploiting unintended feature leakage in collaborative learning,” in 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019, pp. 691–706. [38] R. Shokri, M. Stronati, C. Song, and V. Shmatikov, “Membership inference attacks against machine learning models,” in 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017, pp. 3–18. [39] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum Yellow Paper, 2014, available at https://ethereum.github.io/yellowpaper/paper.pdf.

[40] National Institute of Standards and Technology, “Secure hash standard (SHS),” National Institute of Standards and Technology, Tech. Rep. FIPS PUB 180-4, 2015. [41] Y. LeCun, L. Bottou, Y. Bengio, and P. Haffner, “Gradient-based learning applied to document recognition,” Proceedings of the IEEE, vol. 86, no. 11, pp. 2278–2324, 1998. [42] J. Vanschoren, J. N. van Rijn, B. Bischl, and L. Torgo, “OpenML: Networked science in machine learning,” ACM SIGKDD Explorations Newsletter, vol. 15, no. 2, pp. 49–60, 2014.

Related documents

• Toward provably private learning from federated data#1319209
• Toward verifiably private learning from federated data#1106193
• Turning Privacy-preserving Mechanisms against Federated Learning#177333
• ALDP-FL for adaptive local differential privacy in federated learning#1226487
• Exploring privacy mechanisms and metrics in federated learning#400574