Froglet update: making federated learning rounds inspectable
Signed training steps, local data access, and the limits of the current prototype.
By Armanas Povilionis-Muradian
On this page
At a glance
I’m extending Froglet’s signed execution workflow to federated learning: silo-local training, model updates tied to signed receipts, and inspectable aggregation. This development note separates the implemented experiments from claims about privacy, hosted availability and production readiness.
I want a federated learning round to leave a record that remains useful after the coordinator has stopped running. Another participant should be able to inspect the requested computation, the provider that accepted it, and the result that provider signed.
That is the direction of the latest Froglet work: applying its signed deals and receipts to training across separately operated data silos.
This is a development update, dated 16 October 2026. The FL additions are local development work, with a guide already online. They are not yet part of the published v0.4.7-beta.1 release.
What has changed around the computation
Froglet has become more explicit about the steps around sharing a service: identifying an exact workload revision, declaring its execution limits, checking how it can be reached, and retaining signed evidence of an invocation. The public runtime and the companion marketplace services have separate responsibilities. Discovery, availability, execution and verification each need their own evidence.
The public browser beta provides a bounded entry point for trying Wasm computation and inspecting its evidence. Its documented scope is small, free compute and recovery examples. That scope should be kept separate from the new FL experiments and from claims about an operational training consortium.
For FL, the useful connection is straightforward. A training step can be offered and requested as bounded work. Its input and returned output can be bound into the same Kernel artifact chain, while the learning algorithm stays above that contract.
A round with something to inspect
The current reference path uses silo-local SQLite data and a Wasm training workload. Each provider grants access to a configured database handle through its host capability policy. The FL training request carries model parameters and round settings; the workload reads its cohort locally and returns a model update and associated metadata.
The coordinator checks the signed artifact relationships and the returned payload's hash before aggregation. For sample-weighted FedAvg, the aggregation is the familiar model-averaging step:
Here, is the number of examples reported by participant , and is its locally updated model. The implementation uses integer micro-units for its small deterministic examples.
Diagram
Diagram source
---
config:
htmlLabels: false
---
flowchart LR
C["Coordinator"] --> A["Silo A: local training"]
C --> B["Silo B: local training"]
A --> V["Verify receipts and updates"]
B --> V
V --> G["Aggregate next model"]A receipt gives the exchange an attributable record. It binds a provider's statement about the result to the agreed request. Checking that chain does not independently establish that the provider trained honestly, used genuine data, or produced a useful model. Those are further questions for evaluation, governance and, where needed, stronger execution assurances.
The FL capabilities being explored
The development implementation extends beyond a single averaging loop:
| Area | Current development work | Verification boundary |
|---|---|---|
| Training | Local SGD and evaluation, weighted FedAvg, small MLP and LoRA examples, and vertical split-learning steps | Synthetic, small-scale reference workloads; no clinical or foundation-model training claim |
| Aggregation | Coordinate median, trimmed mean, MultiKrum, update clipping and contribution scoring | Experimental defenses and allocation rules; no general guarantee against malicious participants |
| Privacy mechanisms | Pairwise masking and dropout recovery, cohort commitments, clipping/noise experiments and privacy-accounting records | Prototype mechanisms requiring a separately reviewed threat model |
| Integration | Flower and NVIDIA FLARE adapter paths, plus GPU execution experiments | These paths need their own framework and hardware evidence; CPU tests do not establish GPU behavior |
The point of these experiments is to expose the agreements around a round: which workload was requested, which inputs were committed to, what a provider returned, and which rule the coordinator used to combine updates.
Local data is only one part of privacy
Keeping training records at a participant's site is useful, but model updates can themselves reveal information. Zhu, Liu and Han's gradient-leakage experiments are a concrete reason to treat that boundary carefully.
The current reference setup uses coordinator-controlled masking material and reproducible, caller-seeded noise. Its privacy-budget history is supplied through the coordinator's request. Those choices help test the arithmetic and evidence flow; they do not establish secrecy from the coordinator, production differential privacy, or a budget that a silo independently preserves across restarts.
Independent key custody, durable silo-owned policy and reviewed randomness/accounting remain necessary work before making those assurances. A signed receipt can make a claim inspectable. It cannot turn an unproven privacy claim into a proven one.
What I am checking next
A focused local check passed 14 SDK and numerical-reference tests during this review. Flower and NVIDIA FLARE were not installed in that environment.
A separate local run completed five FedAvg rounds across three synthetic silos, with signed result-chain checks. It used existing development binaries, disposable local processes and mock payment handling. This establishes a working path for those artifacts; it does not establish independently operated deployment, real settlement or hardware acceleration.
The next milestone I care about is a reproducible, released FL example with independently operated participants, explicit privacy assumptions, and evidence that another person can verify without trusting the coordinator's summary. Small synthetic experiments are useful for developing that path. Clinical validity, privacy qualification and production readiness need their own evidence.