Source-linked AI summary
AuditFL: A Contract-Backed Clearing Layer for Open Federated Learning
Alexandros Balla, Spyros Lalis
TL;DR
Centralized FL coordinators control admission, update handling, aggregation, and rewards, making round outcomes difficult to reconstruct independently. AuditFL records round commitments and settlement on chain while leaving training, aggregation, and artifacts off chain. Its MNIST evaluation reports preservation of the Plain FL learning trajectory, with measured control-plane costs and stress tests that still finalize rounds.
Problem
Centralized FL coordinators control admission, checkpoints, updates, aggregation, and rewards, while their decisions may be difficult to reconstruct independently.
Source: §I · p. 1Method
AuditFL records round ordering, commitments, deposits, refunds, rewards, and claims on chain while keeping training, aggregation, and model artifacts off chain.
Source: §I · p. 1Results
On non-IID MNIST, AuditFL preserves the Plain FL learning trajectory, and at N = 200 the contract run consumes 829.7M gas, with reserve and publish calls dominating cost.
Source: B. Full-MNIST Scaling Results (clean… · p. 6, §IX · p. 7Takeaways & Limitations
AuditFL makes coordinator round decisions attributable and replayable while retaining aggregation with the designated task coordinator.
Source: §I · p. 1The evaluation uses a local Anvil chain and artifact store and does not measure public-network delay or cryptographically enforce aggregation correctness.
Source: §IX · p. 8
Abstract
from arXiv · showhide
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, invalid-update, 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.
I. INTRODUCTION
AuditFL addresses the trust and reconstruction limits of centralized FL control planes with an on-chain clearing layer for open participation. It keeps training, aggregation, and model artifacts off chain while recording round decisions and settlement on chain.
I. INTRODUCTION
- A centralized FL coordinator can censor participants, hide updates, manipulate aggregation, or publish outcomes whose inputs and accounting cannot be independently reconstructed.FL keeps raw data local, but deployments commonly centralize admission, checkpoint distribution, update collection, aggregation, records, and rewards.Source: §I · p. 1
- Storing model tensors or executing their computation on chain creates a storage and computation bottleneck, while permissioned ledgers exclude open client participation.The introduction also identifies unspecified consensus assumptions as a source of uncertainty about Sybil resistance and finality.Source: §I · p. 1
- Blockchain-assisted FL surveys and systems often emphasize incentives, privacy, or application frameworks while leaving consensus assumptions and round-level state-machine details less explicit.AuditFL specifies a clearing state machine and evaluates its implementation, including stress tests.Source: §I · p. 1
- AuditFL separates on-chain coordination and settlement from off-chain training, aggregation, and artifact storage, while making coordinator actions visible, replayable, auditable, and economically constrained.The task coordinator still applies the aggregation rule and publishes checkpoints; the ledger records small state transitions and content identifiers.Source: §I · p. 1
II. RELATED WORK AND POSITIONING
Prior FL systems commonly assume an operator-controlled service, while related blockchain and audit systems target other functions or trust layers. AuditFL focuses on public round clearing but retains a designated, auditable task coordinator under explicit ledger and adversary assumptions.
II. RELATED WORK AND POSITIONING
- Earlier FL system work addresses scheduling, retries, participant selection, secure aggregation, device availability, and heterogeneity, but generally assumes an operator-controlled service rather than permissionless admission and finalization.BlockFL studies coordinator replacement latency; Biscotti targets private peer-to-peer FL, while FedCoin and ChainFL explore incentives or decentralized coordination,,,.Source: §II · p. 2
- AuditFL complements systems auditing contribution quality or aggregation correctness by focusing on ticketed admission, update commitments, deterministic settlement, refunds, claims, and contract cost.The comparison is feature-oriented: it records features explicitly emphasized in a work's design or evaluation, not everything that could be added.Source: §II · p. 2
A. Roles and Assumptions
- The task coordinator remains the conventional aggregator, applying the configured rule and publishing checkpoints, while its round-level actions become public, replayable, and economically constrained.Clients reserve tickets, train locally, publish update identifiers, and claim refunds or rewards; the ledger validates ordering and state transitions.Source: A. Roles and Assumptions · p. 2
- The deployment assumes partial synchrony and, for PoS, an adversary controlling less than half of bonded stake; signature forgery and content-hash collisions are excluded.AuditFL specifies clearing rules above a ledger that satisfies the stated consensus assumptions.Source: A. Roles and Assumptions · pp. 2–3
- Malformed identifiers, unavailable artifacts, selective omission, and weak scoring affect inclusion, settlement, and auditability, but invalid or unavailable updates are skipped without invalidating blocks.The ledger does not fetch model tensors.Source: A. Roles and Assumptions · p. 3
B. Design Goals and Non-Goals
AuditFL aims for open coordination, minimal consensus dependencies, replayable round accounting, and economic resistance to spam. Its workflow separates ledger-controlled transitions from off-chain artifact handling and learning, while its stated scope excludes complete privacy and poisoning defense.
B. Design Goals and Non-Goals
- The design goals are open participation without central admission, block validation independent of ML or storage fetches, replayable round-level economic outcomes, and deposits or fees that make spam costly.Auditors use public chain state and retrievable content identifiers to replay the control flow and verify the economic outcome.Source: B. Design Goals and Non-Goals · p. 3
- AuditFL is not a complete privacy or poisoning defense: raw data remain local, but updates may leak information and malicious updates may affect the learned model.The passage identifies secure aggregation, differential privacy, and robust aggregation as complementary mechanisms for stronger guarantees.Source: B. Design Goals and Non-Goals · p. 3
A. Round Workflow
- Clients lock deposits, train locally, and publish update identifiers; the coordinator retrieves and aggregates eligible updates before submitting a global update for deterministic settlement.Listing, funding, ticket reservation, publication, finalization, and claims form the round workflow.Source: A. Round Workflow · p. 3
- The ledger orders and validates state transitions, the off-chain artifact layer serves model bytes, and training, scoring, validation, and aggregation run off chain; invalid or unavailable updates are skipped by policy rather than blocking progress.The transaction-object table inventories the protocol's transaction types.Source: A. Round Workflow · p. 3, Table II · p. 3
B. Transaction State Machine
AuditFL uses deterministic ledger rules to constrain round transitions and settle deposits and rewards while leaving aggregation off chain. Its settlement arithmetic accounts for funds, but does not establish that the task-specific scoring policy is correct.
B. Transaction State Machine
- A global update must match the current round and reference only revealed tickets; replaying ordered transactions enforces these state transitions atomically.Listings precede funding and updates, and publications must use live, unrevealed tickets for the same model and round.Source: B. Transaction State Machine · p. 3
C. Tickets, Refunds, and Payouts
- A ticket locks a deposit: nonpublication, unavailable artifacts, or failed basic checks forfeit it, while a retrievable, valid artifact earns a refund even without a reward.Reward payments depend on the contribution score, separately from the deposit refund.Source: C. Tickets, Refunds, and Payouts · p. 3
- The coordinator assigns nonnegative update scores, and the listing-time payout exponent γ ranges from 1 to 2, with larger values concentrating rewards on higher-scoring updates.An included update with a zero score or a zero denominator receives no payout.Source: C. Tickets, Refunds, and Payouts · pp. 3–4
- The round workflow keeps tensors outside contract execution, putting only identifiers and economic state on chain.Solid arrows represent control transactions and accounting state; dashed arrows represent off-chain artifact transfers.Source: Figure 1 · p. 4
- At finalization, the coordinator aggregates off chain while the ledger checks identifiers, array alignment, and settlement state rather than tensor bytes.The finalization rule separates the coordinator's aggregation from the ledger's checks.Source: Figure 2 · p. 4
- The ledger enforces settlement arithmetic, not the correctness of the task-specific scoring policy; without public validation or a committed evaluation procedure, auditors can check only consistency with submitted scores and rules.Funded rewards and locked deposits are accounted for through entitlements, forfeitures, remaining pool balances, or charged fees.Source: C. Tickets, Refunds, and Payouts · p. 4
A. PoS Longest-Chain Deployment Model
The deployment model uses stake-weighted proposer eligibility and a longest-valid-chain fork choice, with writes treated as stable after a configurable confirmation depth. The ledger interface is not tied to one specific PoS implementation.
A. PoS Longest-Chain Deployment Model
- In each slot, validator eligibility to propose a block is stake-weighted, and splitting the same stake across identities does not increase expected eligibility.The longest valid chain is selected, with a deterministic tie-breaker for multiple valid blocks.Source: A. PoS Longest-Chain Deployment Model · p. 4
- Waiting for k confirmations reduces reorganization risk but increases round latency; the latency model also links latency to block-producing stages, slot duration, and proposer eligibility.The model describes lower confirmation depth and moderate proposer density as reducing latency, while high proposer density increases fork contention.Source: A. PoS Longest-Chain Deployment Model · pp. 4–5
- AuditFL requires open transaction submission, stake-weighted Sybil resistance, ordered confirmed transitions, and probabilistic finality, but not a specific PoS implementation.A public longest-chain ledger, a chain with BFT finality, or another ledger with authenticated ordering and stable confirmed writes can instantiate the transaction model.Source: A. PoS Longest-Chain Deployment Model · p. 5
B. Off-Chain Storage Interface
AuditFL stores artifacts off chain and records identifiers and state transitions on the ledger, relying on an assumed reliable storage layer. Its security discussion separates ledger-enforced settlement and replayability from learning integrity, which remains partly dependent on the coordinator and task-specific rules.
B. Off-Chain Storage Interface
- AuditFL assumes distributed off-chain storage can retrieve artifacts by content identifier during the round window; the ledger checks identifier format and binding, not artifact bytes.Participants and auditors retrieve artifacts outside consensus and verify that bytes match their published identifiers.Source: B. Off-Chain Storage Interface · p. 5
- Storing identifiers and state deltas instead of tensors keeps blocks small, and slow or missing content does not halt consensus.If an update cannot be retrieved before aggregation closes, the coordinator omits it and the refund policy determines the economic outcome.Source: B. Off-Chain Storage Interface · p. 5
VI. SECURITY AND CORRECTNESS DISCUSSION
- Confirmation depth keeps the FL layer from acting on tentative history; displaced writes are retried, while nonces and idempotent checks prevent duplicate state effects.The consensus layer targets common prefix, chain growth, and chain quality under partial synchrony and an honest majority of stake.Source: §VI · p. 5
- Clearing-layer invariants prevent unlisted models, stale rounds, and unrevealed tickets from being finalized, while explicit pools and entitlements govern economic transfers.Fees, locked deposits, and intent caps make reservation spam costly and bound outstanding ticket reservations, but do not guarantee Sybil-proof reward fairness or truthful scoring.Source: §VI · p. 5
- AuditFL does not prevent poisoned tensors or selective inclusion; robust aggregation remains task-specific, and updates may leak information even though raw data stay off the ledger.Secure aggregation and differential privacy are compatible model-specific options.Source: §VI · p. 5
- An auditor can fetch included artifacts, check serialization and shape, recompute public scores when validation data are available, rerun the deterministic aggregator, and check the resulting identifier.Refund and reward entitlements can also be recomputed from the recorded refunds and scores.Source: §VI · p. 5
- AuditFL makes round transitions and payouts publicly accountable, but it does not prove the aggregation outcome is optimal or cryptographically enforce aggregation correctness.Scoring can also be replayed when validation data or a committed evaluation oracle are available.Source: §VI · p. 5
VII. PROTOTYPE IMPLEMENTATION
The prototype combines a deterministic in-memory state machine with a Solidity contract on a local Anvil chain, using Python clients and a coordinator with local content-addressed artifact storage. The evaluation compares AuditFL with Plain FL under matched learning conditions and measures control-plane costs and trajectory preservation.
VII. PROTOTYPE IMPLEMENTATION
- The Solidity prototype runs on a local Ethereum-compatible Anvil chain, measuring application-level clearing logic and contract execution cost rather than public-chain consensus behavior.A deterministic in-memory backend supports fast debugging and controlled tests.Source: §VII · p. 5
- The BCFLCoordinator contract implements listing, funding, ticket reservation, update publication, round finalization, and claims while storing coordination metadata and entitlements.It also stores ticket and reward-pool state and content identifiers.Source: §VII · p. 5
- Gas is reported as a proxy for contract execution cost, not monetary deployment cost, which depends on the network's gas price.Ethereum-compatible contracts execute in the EVM, where gas meters transaction computation and storage work.Source: §VII · p. 6
- The task coordinator fetches retrievable updates, filters invalid shapes, aggregates valid updates using the Plain FL baseline's FedAvg-style rule, and finalizes the next checkpoint on chain.Clients train locally and publish identifiers for updates stored in a local SHA-256 content-addressed artifact store.Source: §VII · p. 6
VIII. EVALUATION
- The evaluation measures execution, transaction-count model agreement, gas, artifact-volume scaling, and preservation of the Plain FL learning trajectory across two backends.Both backends use the same Python client and coordinator logic and the same local content-addressed artifact store.Source: §VIII · p. 6
- Experiments use the full 70,000-example MNIST dataset for 12 rounds, with Dirichlet non-IID client splits at α = 0.4 when there is more than one client.The runs vary client counts up to 200 and match Plain FL and AuditFL on data split, model, local-training rule, rounds, and aggregation rule.Source: §VIII · p. 6
A. Overhead Model
AuditFL keeps tensors off chain while adding a ledger control plane. Its clean-run transaction and artifact-write quantities are expressed as functions of client and round counts.
A. Overhead Model
- Tapp = 1 + R × (2N + 2) + N gives the application transaction count for a run with one listing, R rounds, and one claim per client.The measured receipt count adds one contract-deployment transaction.Source: A. Overhead Model · p. 6
- Tmeasured = 1 + R × (2N + 2) + N + 1 includes the contract-deployment transaction in measured receipts.The application transaction count is given separately by Tapp.Source: A. Overhead Model · p. 6
- Each clean run writes one initial global model, R × N client-update artifacts, and R updated global-model artifacts.This is the artifact-count quantity compared with clean scaling measurements.Source: A. Overhead Model · p. 6
B. Full-MNIST Scaling Results (clean runs, no failures)
On clean MNIST runs, measured receipt and artifact counts match the analytical model across tested client counts. At 200 clients, contract costs and artifact volumes are substantial; injected failures reduce inclusion but rounds still finalize and accuracy shifts remain small.
B. Full-MNIST Scaling Results (clean runs, no failures)
- At N = 200, measured receipts reach 5,026 transactions and stored artifacts reach 2,413, matching their analytical models exactly.Across tested client counts, receipt counts match the model; artifacts rise from 25 at N = 1 to 2,413 at N = 200.Source: B. Full-MNIST Scaling Results (clean… · p. 6
- At N = 200, the contract run consumes 829.7M gas; publishUpdate and reserveTicket together account for approximately 87.1% of execution cost.They consume 408.7M and 314.3M gas, respectively; each participating client makes one reserve and one publish call per round.Source: B. Full-MNIST Scaling Results (clean… · p. 6
- At N = 200, off-chain artifact bytes occupy 144.9 MiB versus 0.163 MiB for committed SHA-256 identifier strings, a ratio of approximately 887×.Fig. 4 reports committed identifier bytes and off-chain artifact bytes on MNIST with R = 12.Source: B. Full-MNIST Scaling Results (clean… · p. 6, Figure 4 · p. 7
- Under dropout, invalid updates, and artifact unavailability, inclusion falls approximately linearly without preventing round finalization; about 25 updates per round remain included at 50% failures.The controlled stress tests use N = 50, R = 12, three seeds, and failure rates from 0% to 50%.Source: C. Controlled Failure Stress · p. 7, Figure 5 · p. 7
- Final-accuracy changes relative to Plain FL remain within a few tenths of an accuracy percentage point, even under high injected failure rates.The tests are stress tests, not comparisons establishing that one fault type is systematically more harmful.Source: C. Controlled Failure Stress · p. 7, Figure 6 · p. 7
IX. CONCLUSION
AuditFL keeps training, aggregation, and model artifacts off chain while recording round commitments and settlement on chain. Clean MNIST runs preserve the Plain FL learning trajectory; controlled failures reduce inclusion without preventing finalization, while the evaluation remains limited to local infrastructure and does not cryptographically enforce aggregation correctness.
IX. CONCLUSION
- Clean MNIST runs preserve the Plain FL learning trajectory while recording ticketed admission, update commitments, round transitions, refunds, rewards, and claims on chain.Training, aggregation, and model artifacts remain off chain.Source: §IX · p. 7
- Measured transaction and artifact counts match the analytical model, while per-client reserve and publish calls dominate EVM gas.Controlled failures reduce inclusion without preventing round finalization.Source: §IX · p. 8
- Evaluation uses a local Anvil chain and local artifact store, measuring neither public-network delay nor cryptographic enforcement of aggregation correctness.Future work includes public-network measurements, larger FL workloads, replicated artifact storage, and stronger or verifiable aggregation mechanisms.Source: §IX · p. 8