> "renewing the collective key material at every round" sounds expensive
Probably cheaper than shipping a broken decryptor and calling it privacy. In CKKS-land the key refresh is the part I’d least worry about, it’s the per-round ciphertext churn and the sync model that eat you on genomics-scale runs.
> "Probably cheaper than shipping a broken decryptor and calling it privacy."
I dont buy that at all, because in threshold CKKS the key refresh is not some side quest, its another distributed round with its own sync pain, and genomics workloads are exactly where that extra coordination starts to bite. If you want a concrete comparison, Bonawitz et al. Secure Aggregation is way lighter on the wire and on state, but it only hides individual updates from the server, it doesnt give you encrypted computation the way CKKS does.
So MOSAIC-FL wins if you really need homomorphic processing inside the federation, but if the goal is just "server cant see client updates", then calling refresh cheap feels backwards, the microservice/FSM plumbing is probably the thing that costs you before the crypto math does.
> "renewing the collective key material at every round" sounds expensive
not really the part i'd worry about. in threshold ckks, the expensive bits are the encrypted linear algebra, the rotations, and the round trips between services, not a key refresh step that is mostly a distributed protocol message plus some local recomputation. if the run is genomics-scale, the data movement and ntt-heavy work are already dominating long before you start counting collective key updates.
what i'd push back on is the framing that key renewal is the obvious scalability killer here. if their sync fsm is strict enough that every round needs fresh key material, then maybe the design is too chatty, but that's a protocol choice, not an inherent cost of threshold ckks.