Blockchain-Based Federated Learning verbindet zwei Technologien, die unterschiedliche Probleme lösen. Federated Learning ermöglicht mehreren Teilnehmern, ein gemeinsames Modell des maschinellen Lernens zu trainieren, ohne ihre Rohdaten an einer zentralen Stelle zusammenzuführen. Eine Blockchain stellt dagegen ein verteiltes, kryptografisch abgesichertes Register bereit, in dem berechtigte Netzwerkteilnehmer Transaktionen, Zustandsänderungen und Entscheidungen nachvollziehbar dokumentieren können. BCFL entsteht, wenn die Blockchain nicht nur als nachträgliches Protokoll, sondern als aktive Vertrauens-, Koordinations- oder Governance-Schicht des föderierten Lernprozesses eingesetzt wird.

Im Umfeld der Quantentechnologie besitzt BCFL zwei klar voneinander zu trennende Bedeutungen. Erstens kann eine Blockchain die Zusammenarbeit verteilter Quantencomputer, Quantensimulatoren und hybrider quantenklassischer Lernmodelle organisieren. Zweitens müssen BCFL-Systeme langfristig gegen kryptografische Angriffe vorbereitet werden, die durch leistungsfähige Quantencomputer möglich werden könnten. Die erste Richtung betrifft Quantum Federated Learning. Die zweite betrifft Post-Quanten-Kryptografie und gegebenenfalls quantengesicherte Kommunikation. Beide Richtungen können in einer Architektur zusammengeführt werden, sind aber technisch nicht identisch.

Die entscheidende Frage lautet daher nicht, ob Blockchain, Federated Learning und Quantencomputing gemeinsam besonders modern erscheinen. Entscheidend ist, ob jede Komponente ein konkretes Problem löst, das mit einer einfacheren Architektur nicht ebenso gut beherrscht werden kann. BCFL ist nur dann sinnvoll, wenn mehrere voneinander unabhängige Parteien gemeinsam lernen müssen, keine uneingeschränkt vertrauenswürdige Zentralinstanz vorhanden ist und Nachvollziehbarkeit, Manipulationsschutz oder organisationsübergreifende Regeln tatsächlich benötigt werden.

Einleitung

Ausgangslage

Moderne Lernsysteme benötigen große und vielfältige Datenbestände. In vielen relevanten Bereichen liegen diese Daten jedoch nicht in einem gemeinsamen Rechenzentrum. Krankenhäuser verwalten Patientendaten getrennt, Banken schützen Transaktionsinformationen, Industrieunternehmen halten Produktionsdaten unter Verschluss, und Forschungsinstitute arbeiten mit proprietären Messreihen. Auch Quantencomputer werden gegenwärtig meist als getrennte Cloud-Ressourcen oder institutionelle Forschungsanlagen betrieben. Eine zentrale Zusammenführung aller Daten scheitert daher häufig an Datenschutz, Geschäftsgeheimnissen, regulatorischen Anforderungen, technischen Übertragungskosten oder mangelndem Vertrauen.

Federated Learning setzt genau an diesem Punkt an. Die Daten verbleiben grundsätzlich bei den jeweiligen Teilnehmern. Jeder Teilnehmer trainiert lokal eine Modellkopie und übermittelt nur ein Modellupdate, beispielsweise Parameter, Gradienten oder abgeleitete statistische Informationen. Ein Koordinator verbindet diese Updates zu einem globalen Modell. Der Ansatz reduziert die Notwendigkeit, Rohdaten zu übertragen, beseitigt aber nicht alle Datenschutz- und Sicherheitsprobleme. Modellupdates können Informationen über lokale Trainingsdaten enthalten, manipuliert werden oder aus fehlerhaften Berechnungen stammen.

Das klassische Federated Learning verwendet häufig einen zentralen Aggregationsserver. Dieser Server verteilt das globale Modell, nimmt lokale Updates entgegen und berechnet die nächste Modellversion. Dadurch entsteht ein klarer Kontrollpunkt, aber auch ein zentraler Ausfall-, Angriffs- und Vertrauenspunkt. In einer einzigen Organisation kann dieses Modell ausreichend sein. Zwischen konkurrierenden Unternehmen, Behörden, Kliniken oder Forschungseinrichtungen stellt sich jedoch die Frage, wer den Server kontrolliert, wer die Regeln festlegt und wie nachträglich überprüft werden kann, welche Updates akzeptiert oder verworfen wurden.

Problemstellung

BCFL adressiert vor allem das fehlende gemeinsame Vertrauen zwischen mehreren Beteiligten. Die Blockchain kann registrieren, wer an einer Trainingsrunde teilgenommen hat, welche Modellversion als Ausgangspunkt diente, welcher Hashwert zu einem Update gehört, welche Prüfungen durchgeführt wurden und welches globale Modell schließlich freigegeben wurde. Smart Contracts können formale Regeln automatisieren, etwa die Zulassung eines Teilnehmers, die Frist für ein Update, die Berechnung eines Reputationswertes oder die Freigabe einer Vergütung.

Diese Funktionen lösen jedoch nicht automatisch das Lernproblem. Eine Blockchain erkennt nicht von selbst, ob ein lokaler Datensatz korrekt, repräsentativ oder manipuliert ist. Sie kann auch nicht allein beurteilen, ob ein Modellupdate mathematisch sinnvoll ist. Sie dokumentiert und erzwingt Regeln, die zuvor definiert wurden. Sind die Regeln unvollständig, die Eingabedaten falsch oder die Bewertungsmethoden angreifbar, wird lediglich ein fehlerhafter Zustand dauerhaft und nachvollziehbar gespeichert.

Einordnung in die Quantentechnologie

Die Quantentechnologie erweitert diese Problemstellung. Quantum Machine Learning nutzt Quantenprozessoren oder quantenmechanisch inspirierte Verfahren, um Lernaufgaben zu bearbeiten. In heutigen Systemen dominieren hybride Architekturen: Klassische Rechner übernehmen Datenvorbereitung, Optimierung und Steuerung, während ein parametrisierter Quantenschaltkreis einen begrenzten Teil der Modellberechnung ausführt. Sind mehrere solche Systeme auf verschiedene Institutionen verteilt, kann Quantum Federated Learning ihre lokalen Trainingsbeiträge zusammenführen.

Eine Blockchain kann dabei Modell- und Schaltungsversionen registrieren, Zugriffsrechte auf Quantenhardware verwalten, Mess- und Kalibrierungsdaten referenzieren oder Kosten zwischen mehreren Anbietern abrechnen. Gleichzeitig entsteht ein langfristiges Sicherheitsproblem: Viele etablierte Blockchains und Identitätssysteme verwenden digitale Signaturen, deren Sicherheit durch ausreichend leistungsfähige Quantencomputer gefährdet werden könnte. Ein quantentechnologisches BCFL-System muss daher nicht nur Quantenmodelle koordinieren, sondern seine eigene kryptografische Grundlage migrationsfähig gestalten.

Ziel der Abhandlung

Diese Abhandlung erklärt die technische Struktur von BCFL, seine Rolle innerhalb der Quantentechnologie sowie seine Sicherheits- und Leistungsgrenzen. Im Mittelpunkt stehen die tatsächlichen Funktionen der Blockchain, der Ablauf eines föderierten Trainings, die Integration quantenbasierter Modelle und die Vorbereitung auf post-quanten-kryptografische Anforderungen. Die Darstellung vermeidet die verbreitete Annahme, dass die Kombination mehrerer komplexer Technologien automatisch einen Vorteil erzeugt. Ein Vorteil muss durch messbare Verbesserungen bei Vertrauen, Datenschutz, Robustheit, Rechenleistung oder Governance belegt werden.

Grundlagen des Federated Learning

Grundprinzip

Federated Learning ist ein Verfahren des verteilten maschinellen Lernens. Mehrere Clients oder Organisationen trainieren ein gemeinsames Modell auf ihren lokalen Daten, ohne diese Daten unmittelbar an einen zentralen Datenspeicher zu übertragen. Jeder Client erhält eine aktuelle Modellversion, führt lokale Optimierungsschritte aus und sendet anschließend ein Update zurück. Die lokalen Updates werden aggregiert und bilden die Grundlage der nächsten globalen Modellversion.

Das gemeinsame Optimierungsziel lässt sich als gewichtete Summe lokaler Zielfunktionen ausdrücken:

\(F(w) = \sum_{k=1}^{K} \frac{n_k}{n} F_k(w)\)

Dabei bezeichnet \(w\) die globalen Modellparameter, \(K\) die Zahl der Teilnehmer, \(n_k\) die Zahl der Trainingsbeispiele des Teilnehmers \(k\) und \(n = \sum_{k=1}^{K} n_k\) die Gesamtzahl der berücksichtigten Beispiele. Die lokale Zielfunktion kann als mittlerer Verlust über den lokalen Datensatz formuliert werden:

\(F_k(w) = \frac{1}{n_k} \sum_{i=1}^{n_k} \ell(w; x_i, y_i)\)

Der Ausdruck \(\ell(w; x_i, y_i)\) beschreibt den Verlust des Modells für ein lokales Beispiel mit Eingabe \(x_i\) und Zielwert \(y_i\). Das Ziel besteht darin, Parameter zu finden, die den globalen Verlust minimieren:

\(w^* = \arg\min_w F(w)\)

Typischer Trainingsablauf

Eine Trainingsrunde beginnt mit der Auswahl geeigneter Clients. Der Server übermittelt ihnen die aktuelle Modellversion. Jeder ausgewählte Client trainiert dieses Modell für eine begrenzte Zahl lokaler Schritte. Anschließend sendet er die aktualisierten Parameter oder die Differenz zur Ausgangsversion zurück. Der Server prüft die Updates, aggregiert sie und veröffentlicht das neue globale Modell.

Beim verbreiteten Federated Averaging wird die neue globale Modellversion als gewichteter Mittelwert lokaler Modelle berechnet:

\(w_{t+1} = \sum_{k=1}^{K_t} \frac{n_k}{\sum_{j=1}^{K_t} n_j} w_{t+1}^{(k)}\)

Hier bezeichnet \(t\) die Trainingsrunde, \(K_t\) die in dieser Runde berücksichtigten Teilnehmer und \(w_{t+1}^{(k)}\) das lokal aktualisierte Modell des Teilnehmers \(k\). Die Gewichtung nach Datenmenge ist einfach und häufig wirksam, kann aber Teilnehmer mit großen Datensätzen dominieren lassen. Sie sagt zudem nichts über Datenqualität, Fairness oder Vertrauenswürdigkeit aus.

Cross-Device und Cross-Silo

Beim Cross-Device Federated Learning nehmen sehr viele Endgeräte teil. Die Geräte sind nur zeitweise verfügbar, verfügen über begrenzte Energie und Rechenleistung und können unzuverlässige Netzwerkverbindungen besitzen. Die zentrale Herausforderung liegt in Skalierung, Client-Auswahl und Kommunikation.

Beim Cross-Silo Federated Learning kooperieren dagegen wenige, meist bekannte Organisationen. Die Teilnehmer verfügen über stabilere Infrastruktur und größere Datensätze. Dafür sind Governance, Haftung, Auditierbarkeit und organisationsübergreifendes Vertrauen wichtiger. BCFL eignet sich deshalb besonders für Cross-Silo-Szenarien, weil eine permissioned Blockchain mit identifizierten Mitgliedern und gemeinsam vereinbarten Regeln praktikabler ist als ein öffentliches, anonymes Netzwerk.

Datenheterogenität

Die lokalen Daten sind häufig nicht identisch verteilt. Eine Klinik behandelt andere Patientengruppen als eine andere Klinik, ein Produktionsstandort verwendet andere Maschinen, und ein Finanzinstitut besitzt ein anderes Kundenprofil als seine Partner. Diese Nichtgleichverteilung kann dazu führen, dass lokale Updates in unterschiedliche Richtungen weisen und das globale Modell langsamer oder instabil konvergiert.

Zusätzlich unterscheiden sich Datenmengen, Messqualität, Beschriftungsstandards und zeitliche Aktualität. Ein rein mengenbasierter Mittelwert kann deshalb unangemessen sein. Robuste Aggregationsverfahren, Qualitätsmetriken, personalisierte Modelle oder gruppenspezifische Gewichtungen sind mögliche Gegenmaßnahmen. Die Blockchain kann dokumentieren, welche Gewichtungsregel angewendet wurde, sie kann die statistische Eignung dieser Regel jedoch nicht garantieren.

Datenschutzgrenzen

Federated Learning wird häufig als datenschutzfreundlich bezeichnet, weil Rohdaten lokal bleiben. Diese Aussage ist nur teilweise richtig. Gradienten und Parameteränderungen können Rückschlüsse auf einzelne Trainingsbeispiele, Klassenverteilungen oder Eigenschaften lokaler Datensätze ermöglichen. Angreifer können versuchen, Eingaben zu rekonstruieren oder die Mitgliedschaft einer Person in einem Trainingsdatensatz zu erkennen.

Deshalb werden zusätzliche Schutzmechanismen benötigt. Secure Aggregation verhindert, dass der Aggregator einzelne Updates im Klartext sieht. Differential Privacy begrenzt den Einfluss einzelner Beispiele durch Beschränkung und Zufallsrauschen. Homomorphe Verschlüsselung ermöglicht ausgewählte Berechnungen auf verschlüsselten Werten. Trusted Execution Environments isolieren Aggregationscode in geschützten Hardwarebereichen. Jede Maßnahme erzeugt zusätzlichen Rechen-, Kommunikations- oder Genauigkeitsaufwand.

Typische Angriffe

Bei Data Poisoning verändert ein Angreifer lokale Trainingsdaten, um das globale Modell zu verschlechtern oder eine gezielte Fehlfunktion einzubauen. Beim Model Poisoning manipuliert er direkt das Modellupdate. Backdoor-Angriffe sollen ein Modell im normalen Betrieb unauffällig halten, aber bei einem bestimmten Muster eine gewünschte falsche Ausgabe erzeugen. Sybil-Angriffe vervielfachen künstlich die Zahl kontrollierter Identitäten. Free-Rider liefern nutzlose oder kopierte Updates, um ohne echte Leistung eine Belohnung zu erhalten.

Ein zentrales Problem besteht darin, dass ein formal korrekt signiertes Update dennoch schädlich sein kann. Kryptografische Authentizität beweist nur, wer eine Nachricht signiert hat und dass sie nach der Signatur nicht verändert wurde. Sie beweist nicht, dass der Inhalt richtig ist. BCFL muss deshalb kryptografische Nachweise mit statistischer Prüfung, robusten Aggregationsverfahren und klaren Sanktionen verbinden.

Technische Grundlagen der Blockchain

Verteiltes Register

Eine Blockchain ist ein verteiltes Register, dessen Einträge in einer festgelegten Reihenfolge gespeichert und kryptografisch miteinander verknüpft werden. Mehrere Netzwerkknoten halten Kopien des Registers. Neue Transaktionen werden nach einem Konsensverfahren validiert und in einen neuen Block aufgenommen. Jeder Block enthält typischerweise einen Verweis auf den Hashwert des vorherigen Blocks. Wird ein älterer Eintrag verändert, ändern sich die nachfolgenden Hashbeziehungen und die Manipulation wird erkennbar.

Diese Eigenschaft wird häufig als Unveränderlichkeit bezeichnet. Präziser ist der Begriff Manipulationsresistenz. Eine Blockchain ist nicht durch Naturgesetz unveränderbar. Ihre Sicherheit hängt von Konsensregeln, Teilnehmerstruktur, kryptografischen Verfahren und Kontrolle über die Validierungsknoten ab. In kleinen privaten Netzwerken kann eine ausreichend mächtige Koalition den Verlauf unter Umständen verändern. Die Architektur muss daher zum Bedrohungsmodell passen.

Kryptografische Bausteine

Hashfunktionen bilden Daten beliebiger Länge auf einen Wert fester Länge ab. Für einen Datensatz \(m\) wird ein Hashwert berechnet:

\(h = H(m)\)

Eine sichere kryptografische Hashfunktion soll es praktisch unmöglich machen, aus \(h\) den ursprünglichen Datensatz zu bestimmen oder zwei verschiedene Datensätze mit demselben Hashwert gezielt zu erzeugen. In BCFL kann der Hashwert eines Modellartefakts auf der Blockchain gespeichert werden, während das große Modell selbst außerhalb der Blockchain liegt. Später lässt sich prüfen, ob ein bereitgestelltes Modell mit dem registrierten Hashwert übereinstimmt.

Digitale Signaturen binden eine Nachricht an einen privaten Schlüssel. Ein Teilnehmer signiert beispielsweise den Hashwert seines Modellupdates. Andere Teilnehmer prüfen die Signatur mit dem zugehörigen öffentlichen Schlüssel. Dadurch werden Authentizität und Integrität unterstützt. Die Vertraulichkeit des Updates entsteht dadurch nicht; dafür ist eine gesonderte Verschlüsselung erforderlich.

Öffentliche und permissioned Blockchains

Öffentliche Blockchains erlauben meist eine offene Teilnahme und benötigen Konsensmechanismen, die auch mit unbekannten oder wirtschaftlich motivierten Teilnehmern funktionieren. Sie bieten eine hohe Offenheit, verursachen aber häufig größere Latenzen, variable Gebühren und unerwünschte Transparenz.

Permissioned Blockchains beschränken Teilnahme, Validierung und Datenzugriff auf autorisierte Mitglieder. In einem Konsortium aus Kliniken, Banken oder Forschungsinstituten können Identitäten über Zertifikate und organisatorische Verträge abgesichert werden. Dadurch sind effizientere Konsensverfahren möglich. Zugleich bleibt die Governance anspruchsvoll: Es muss festgelegt werden, wer neue Mitglieder aufnimmt, Software aktualisiert, Schlüssel widerruft und Streitfälle entscheidet.

Konsensmechanismen

Ein Konsensmechanismus sorgt dafür, dass die berechtigten Knoten einen gemeinsamen Registerzustand akzeptieren. Proof of Work ist für viele institutionelle BCFL-Systeme ungeeignet, weil Energieverbrauch, Bestätigungszeit und offene Konkurrenz keinen sachlichen Vorteil bieten. Proof of Stake kann für öffentliche Netze relevant sein, erfordert aber ein wirtschaftliches Einsatz- und Sanktionsmodell.

Für Konsortialnetze sind Byzantine-Fault-Tolerant-Verfahren oder Proof-of-Authority-ähnliche Modelle häufig näherliegend. Bei klassischen byzantinischen Konsensannahmen kann ein System mit \(3f + 1\) Replikaten bis zu \(f\) fehlerhafte oder bösartige Replikate tolerieren. Diese Grenze gilt nicht pauschal für jedes Protokoll, zeigt aber den Zusammenhang zwischen Teilnehmerzahl und Fehlertoleranz.

Smart Contracts

Smart Contracts sind Programme, die innerhalb der Blockchain-Umgebung nach festgelegten Regeln ausgeführt werden. In BCFL können sie Trainingsrunden eröffnen, Fristen überwachen, Identitäten prüfen, Hashwerte registrieren, Abstimmungen auswerten oder Vergütungen freigeben. Ihr Vorteil liegt in der gemeinsamen, reproduzierbaren Ausführung. Kein einzelner Teilnehmer kann die Regeln einer abgeschlossenen Transaktion nachträglich stillschweigend ändern.

Smart Contracts sind jedoch nur so zuverlässig wie ihr Code und ihre Eingaben. Programmierfehler, unklare Zustandsübergänge oder fehlerhafte externe Informationen können zu falschen Ergebnissen führen. Zudem sind komplexe mathematische Modellprüfungen innerhalb einer Blockchain oft zu teuer. Deshalb werden rechenintensive Analysen meist außerhalb der Kette ausgeführt und nur ihre Ergebnisse oder Nachweise registriert.

On-Chain und Off-Chain

Ein praktikables BCFL-System speichert nicht jedes Modellupdate vollständig auf der Blockchain. Moderne Modelle können Millionen oder Milliarden Parameter enthalten. Eine dauerhafte Replikation auf allen Blockchain-Knoten wäre ineffizient und könnte sensible Informationen offenlegen. On-Chain gehören daher vor allem kompakte Kontrollinformationen: Hashwerte, Zeitstempel, Teilnehmerkennungen, Zustimmungen, Prüfergebnisse, Modellversionsnummern und Verweise auf externe Speicher.

Off-Chain werden große Modellartefakte, verschlüsselte Updates, Protokolldateien und detaillierte Messdaten gespeichert. Die Blockchain verankert deren Integrität. Dieses Muster reduziert Speicher- und Konsenskosten, erzeugt aber neue Anforderungen an Verfügbarkeit, Zugriffskontrolle und Löschung der externen Daten. Ein Hashwert beweist nur, dass ein Artefakt unverändert ist; er sorgt nicht dafür, dass das Artefakt erreichbar bleibt.

Architektur von Blockchain-Based Federated Learning

Begriffsbestimmung

BCFL ist kein einzelner standardisierter Algorithmus, sondern eine Klasse von Systemarchitekturen. Gemeinsam ist ihnen, dass ein föderierter Lernprozess mit einer Blockchain oder einem vergleichbaren verteilten Register verbunden wird. Die Blockchain kann unterschiedliche Aufgaben übernehmen: Identitäten verwalten, Trainingsrunden koordinieren, Modellversionen verankern, Aggregationsentscheidungen dokumentieren, Beiträge bewerten oder Anreize verteilen.

Der Grad der Dezentralisierung ist variabel. Manche Systeme behalten einen zentralen Aggregator und nutzen die Blockchain lediglich als Prüfregister. Andere verteilen die Aggregation auf mehrere Validatoren. Wieder andere lassen Teilnehmer über Modellvorschläge abstimmen. BCFL darf deshalb nicht automatisch mit vollständig dezentralem Lernen gleichgesetzt werden.

Beteiligte Rollen

Ein BCFL-System umfasst typischerweise Datenbesitzer, Trainingsclients, Aggregatoren, Validatoren, Blockchain-Knoten, Speicheranbieter und Governance-Mitglieder. Eine Organisation kann mehrere Rollen erfüllen, doch eine klare Trennung erleichtert Kontrolle und Haftung. Der Datenbesitzer bestimmt, welche lokalen Daten für das Training verwendet werden dürfen. Der Trainingsclient führt die lokale Optimierung aus. Der Aggregator verbindet akzeptierte Updates. Validatoren prüfen Signaturen, Formate, Plausibilität und gegebenenfalls Modellqualität. Blockchain-Knoten führen das Register und die Smart Contracts aus.

Im quantentechnologischen Umfeld kommen weitere Rollen hinzu: Betreiber von Quantenhardware, Anbieter von Quantensimulatoren, Kalibrierungsdienste und klassische Optimierungsserver. Da heutige Quantenprozessoren empfindlich auf Rauschen und Kalibrierungsänderungen reagieren, kann die verwendete Hardwarekonfiguration für die Interpretation eines Updates wesentlich sein.

Lebenszyklus einer Trainingsrunde

Registrierung und Zulassung

Vor dem Training werden Organisationen und technische Knoten registriert. Eine Zertifizierungsstelle oder ein Konsortium bestätigt ihre Identität und Rolle. Smart Contracts können festlegen, welche Modellaufgaben ein Teilnehmer bearbeiten darf, welche Softwareversion verlangt wird und welche Nachweise vorliegen müssen. In sensiblen Umgebungen kann zusätzlich eine Hardware-Attestierung erforderlich sein.

Veröffentlichung der Aufgabe

Die Trainingsaufgabe beschreibt das Ausgangsmodell, die Verlustfunktion, erlaubte Hyperparameter, Fristen, Datenschutzvorgaben und Qualitätsmetriken. Das eigentliche Modell liegt meist außerhalb der Blockchain. Sein Hashwert und seine Versionsnummer werden On-Chain registriert. Jeder Client kann dadurch prüfen, ob er mit der freigegebenen Ausgangsversion arbeitet.

Lokales Training

Der Client lädt das Modell, prüft dessen Integrität und trainiert es auf den lokalen Daten. Das lokale Update kann als Parameterdifferenz formuliert werden:

\(\Delta w_k = w_k^{\mathrm{local}} - w_t\)

Vor der Übermittlung kann das Update begrenzt, komprimiert, verschlüsselt oder mit Zufallsrauschen versehen werden. Der Client signiert die zugehörigen Metadaten. Sensible Details über den lokalen Datensatz sollten nicht dauerhaft in die Blockchain geschrieben werden.

Prüfung und Aggregation

Validatoren prüfen zunächst formale Eigenschaften: gültige Identität, richtige Modellversion, fristgerechte Einreichung und korrekte Signatur. Danach folgen statistische Prüfungen. Dazu gehören Normgrenzen, Ähnlichkeitsanalysen, Tests auf ungewöhnliche Richtungen oder Bewertungen an einem Referenzdatensatz. Ein mögliches Kriterium ist die Begrenzung der Update-Norm:

\(\Delta \widetilde{w}_k = \Delta w_k \cdot \min\left(1, \frac{C}{||\Delta w_k||_2}\right)\)

Der Grenzwert \(C\) verhindert, dass ein einzelnes Update einen beliebig großen Einfluss erhält. Er schützt jedoch nicht sicher vor koordinierten oder subtilen Angriffen. Akzeptierte Updates werden anschließend aggregiert.

Freigabe und Verankerung

Nach der Aggregation wird das neue globale Modell geprüft. Die Blockchain speichert dessen Hashwert, die verwendete Aggregationsregel, die Liste oder einen datensparsamen Nachweis der berücksichtigten Beiträge sowie das Ergebnis der Validierung. Das Modell selbst wird in einem kontrollierten Repository abgelegt. Erst wenn die Freigabebedingungen erfüllt sind, beginnt die nächste Runde.

Aggregationsmodelle

Zentraler Aggregator mit Blockchain-Audit

Diese Variante verändert das klassische Federated Learning am wenigsten. Ein zentraler Server berechnet das globale Modell, während die Blockchain Eingaben, Entscheidungen und Ergebnis-Hashwerte protokolliert. Der Vorteil liegt in hoher Rechenleistung und geringer Komplexität. Der Nachteil besteht darin, dass der Aggregator weiterhin manipulieren, ausfallen oder einzelne Updates einsehen kann, sofern keine zusätzliche sichere Aggregation verwendet wird.

Mehrere Aggregatoren

Mehrere unabhängige Aggregatoren berechnen das Ergebnis getrennt. Stimmen ihre Hashwerte überein, kann das Modell freigegeben werden. Bei Abweichungen startet ein Prüfprozess. Diese Redundanz erhöht die Fehlertoleranz, vervielfacht aber Rechenaufwand und Datenübertragung. Außerdem müssen alle Aggregatoren Zugriff auf die erforderlichen Updates erhalten, was das Datenschutzrisiko vergrößern kann.

Aggregation in geschützten Ausführungsumgebungen

Eine weitere Variante führt die Aggregation in Trusted Execution Environments aus. Die Blockchain verwaltet Attestierungen, Aufgaben und Ergebnisnachweise. Dadurch soll verhindert werden, dass Betreiber des Aggregationsknotens den geschützten Speicher auslesen oder den Code unbemerkt verändern. Solche Umgebungen verschieben Vertrauen auf Hardwarehersteller und Attestierungsinfrastruktur. Seitenkanalangriffe und Implementierungsfehler bleiben möglich.

Verifizierbare externe Berechnung

Bei verifizierbarer Berechnung führt ein externer Dienst die Aggregation aus und liefert zusätzlich einen kryptografischen Nachweis, dass die vereinbarte Funktion korrekt angewendet wurde. Die Blockchain prüft den Nachweis statt die vollständige Berechnung zu wiederholen. Dieser Ansatz kann hohe Effizienz mit Kontrolle verbinden, ist für große Modelle aber technisch anspruchsvoll.

Reputation und Anreize

Ein Reputationssystem bewertet die bisherige Zuverlässigkeit eines Teilnehmers. Kriterien können fristgerechte Lieferung, technische Verfügbarkeit, Ähnlichkeit zu akzeptierten Updates und gemessener Beitrag zur Modellqualität sein. Ein vereinfachtes Update einer Reputation könnte lauten:

\(r_k^{(t+1)} = \alpha r_k^{(t)} + (1-\alpha) q_k^{(t)}\)

Dabei ist \(r_k^{(t)}\) die bisherige Reputation, \(q_k^{(t)}\) eine Qualitätsbewertung der aktuellen Runde und \(\alpha\) ein Gewicht für die Vergangenheit. Ein solches System ist leicht zu manipulieren, wenn die Qualitätsbewertung unzuverlässig ist. Neue Teilnehmer können benachteiligt werden, etablierte Teilnehmer können trotz aktueller Fehler bevorzugt bleiben, und mehrere Akteure können sich gegenseitig aufwerten.

Anreize sind besonders relevant, wenn Teilnehmer Kosten für Rechenzeit, Quantenhardware oder Datenpflege tragen. Smart Contracts können Vergütungen nach einer vereinbarten Beitragsmetrik verteilen. Eine faire Beitragsmessung ist jedoch schwierig. Der Nutzen eines Updates hängt von anderen Updates, der Reihenfolge der Aggregation und dem Validierungsdatensatz ab. Exakte spieltheoretische Verfahren sind bei vielen Teilnehmern oft zu teuer. Praktische Systeme verwenden daher Näherungen und müssen deren Verzerrungen offenlegen.

Modellprovenienz

Modellprovenienz bezeichnet die nachvollziehbare Herkunft und Entwicklung eines Modells. Ein BCFL-Provenienzregister kann festhalten, welche globale Version als Ausgangspunkt diente, welche Organisationen Updates einreichten, welche Prüfungen bestanden wurden und welche Aggregationsregel zur neuen Version führte. Dadurch lässt sich ein Fehler später einer Trainingsrunde zuordnen.

Die Blockchain sollte dabei keine sensiblen Datensatzdetails offenlegen. Sinnvoll sind pseudonyme oder organisationsbezogene Kennungen, Hashwerte von freigegebenen Beschreibungen und Verweise auf zugriffsgeschützte Nachweise. Provenienz erhöht Verantwortlichkeit, ersetzt aber keine inhaltliche Qualitätskontrolle.

Identitäts- und Schlüsselmanagement

Ein institutionelles BCFL-System benötigt einen vollständigen Lebenszyklus für digitale Identitäten. Dazu gehören Ausgabe, Speicherung, Rotation, Sperrung und Wiederherstellung von Schlüsseln. Wird ein privater Schlüssel kompromittiert, können Angreifer formal gültige Updates einreichen. Die Blockchain dokumentiert dann zwar die Signatur, ordnet sie aber der kompromittierten Identität zu.

Deshalb müssen Schlüssel in geschützten Modulen gespeichert, regelmäßig erneuert und bei Verdacht sofort widerrufen werden. Für langfristige Systeme ist Krypto-Agilität entscheidend: Signatur- und Schlüsselaustauschverfahren müssen austauschbar sein, ohne den gesamten Lernprozess neu zu entwickeln.

BCFL im Bereich der Quantentechnologie

Quantum Machine Learning

Quantum Machine Learning untersucht Lernverfahren, die Quantencomputer als Rechenkomponente nutzen oder quantenmechanische Daten verarbeiten. Ein verbreitetes Modell ist der parametrisierte Quantenschaltkreis. Ein klassischer Parametervektor steuert Quantengatter, ein Anfangszustand wird transformiert und eine Messung liefert einen Erwartungswert. Vereinfacht gilt:

\(f_{\theta}(x) = \langle 0 | U_{\theta}^{\dagger}(x) O U_{\theta}(x) | 0 \rangle\)

Dabei kodiert \(U_{\theta}(x)\) Eingabedaten und trainierbare Parameter in einen Quantenschaltkreis, während \(O\) eine Messobservable bezeichnet. Ein klassischer Optimierer verändert \(\theta\), um eine Verlustfunktion zu minimieren. Der Ablauf ist hybrid, weil Schaltkreisausführung und Messung auf Quantenhardware stattfinden, die Parameteroptimierung aber meist klassisch erfolgt.

Heutige Quantenhardware besitzt begrenzte Qubit-Zahlen, Rauschen, kurze Kohärenzzeiten und schwankende Kalibrierung. Daher werden kleine Schaltkreise, Fehlerminderung und viele Wiederholungsmessungen benötigt. Ein theoretisch ausdrucksstarkes Quantenmodell ist nicht automatisch schneller oder genauer als ein klassisches Modell. Ein belastbarer Quantenvorteil verlangt einen fairen Vergleich mit starken klassischen Baselines unter realistischen Hardwarekosten.

Quantum Federated Learning

Quantum Federated Learning überträgt das föderierte Trainingsprinzip auf Quantenmodelle oder hybride quantenklassische Modelle. Mehrere Clients trainieren lokale Parameter, während ihre Rohdaten oder Quantenzustände vor Ort bleiben. Anschließend werden klassische Parameter oder abgeleitete Messwerte aggregiert. In vielen vorgeschlagenen Architekturen werden keine Qubits zwischen den Clients übertragen; die Kommunikation bleibt klassisch.

Für einen parametrierten Quantenschaltkreis kann die globale Parameteraggregation analog zu Federated Averaging erfolgen:

\(\theta_{t+1} = \sum_{k=1}^{K_t} \frac{n_k}{\sum_{j=1}^{K_t} n_j} \theta_{t+1}^{(k)}\)

Diese einfache Mittelung funktioniert nur, wenn alle Teilnehmer dieselbe Schaltungsstruktur und kompatible Parametrisierungen verwenden. Unterschiedliche Hardwaretopologien, Gate-Sätze oder Rauschprofile können dazu führen, dass identische Parameter auf verschiedenen Geräten nicht dieselbe Modellwirkung besitzen. Dann müssen Kalibrierung, Fehlerminderung oder hardwareabhängige Personalisierung berücksichtigt werden.

Formen quantenföderierter Systeme

Klassische Daten und Quantenmodell

Die lokalen Daten sind klassisch, etwa Bilder, Messwerte oder Transaktionen. Jeder Client kodiert sie in einen Quantenschaltkreis und trainiert ein Quanten- oder Hybridmodell. Diese Form ist gegenwärtig am einfachsten zu simulieren und experimentell zu testen. Die Datenkodierung kann jedoch einen erheblichen Teil des Gesamtaufwands verursachen.

Quantendaten und Quantenmodell

Die lokalen Daten bestehen aus Quantenzuständen, beispielsweise aus Sensorik, Quantenkommunikation oder Experimenten. Da unbekannte Quantenzustände nicht beliebig kopiert werden können, ist eine zentrale Sammlung besonders schwierig. Föderiertes Lernen kann stattdessen trainierbare Schaltungsparameter austauschen. Das Szenario ist konzeptionell wichtig, aber technisch deutlich anspruchsvoller als das Training mit klassischen Datensätzen.

Hybride Modelle

Ein hybrides Modell kombiniert klassische neuronale Schichten mit einer kleinen Quantenschicht. Klassische Komponenten extrahieren Merkmale, der Quantenschaltkreis transformiert einen kompakten Merkmalsvektor, und eine klassische Ausgabeschicht erzeugt die Vorhersage. Solche Modelle passen besser zu gegenwärtiger Hardware, weil nur ein kleiner Teil der Berechnung auf dem Quantenprozessor stattfindet.

Rolle der Blockchain in Quantum Federated Learning

Die Blockchain kann in QFL dieselben Vertrauensaufgaben übernehmen wie in klassischem BCFL, ergänzt um quantenspezifische Metadaten. Dazu gehören Schaltungsbeschreibung, Hardwaretyp, Kalibrierungszeitpunkt, Zahl der Messwiederholungen, Fehlerminderungsverfahren und verwendete Compilerkonfiguration. Diese Angaben beeinflussen die Reproduzierbarkeit eines Ergebnisses.

Darüber hinaus kann ein Konsortium knappe Quantenressourcen verwalten. Smart Contracts können Rechenkontingente zuweisen, Prioritäten festlegen, Kosten erfassen und den Abschluss eines Auftrags dokumentieren. Die eigentliche Quantenberechnung findet außerhalb der Blockchain statt. Das Register verwaltet nur Auftrag, Nachweis und Ergebnisreferenz.

Beispiel einer BCFL-QFL-Architektur

Mehrere Forschungsinstitute verfügen über lokale Datensätze und Zugriff auf unterschiedliche Quantencomputer. Das Konsortium veröffentlicht ein gemeinsames Hybridmodell. Dessen klassische Gewichte, Quantenschaltung und erlaubte Trainingskonfiguration werden versioniert. Jeder Teilnehmer führt lokale Trainingsschritte aus und erzeugt ein signiertes Update.

Vor der Aggregation werden die Updates auf formale Gültigkeit, ungewöhnliche Parameteränderungen und Leistung an einem gemeinsam vereinbarten Testverfahren geprüft. Die Blockchain registriert die akzeptierten Update-Hashwerte. Ein Aggregationsdienst berechnet die neue Modellversion. Mehrere Validatoren bestätigen den Ergebnis-Hashwert. Erst danach wird das Modell als gültige globale Version freigegeben.

Die Architektur schafft Nachvollziehbarkeit, aber sie beweist nicht, dass ein Quantenmodell einen Vorteil besitzt. Dieser muss separat durch Experimente bewertet werden. Notwendig sind gleiche Datenaufteilung, vergleichbare Parameterzahl, identisches Trainingsbudget und eine starke klassische Referenz.

Parameter-Shift und Trainingskosten

Gradienten parametrisierter Quantenschaltungen können für bestimmte Gatter mit der Parameter-Shift-Regel bestimmt werden:

\(\frac{\partial f(\theta)}{\partial \theta_j} = \frac{1}{2}\left[f\left(\theta_j + \frac{\pi}{2}\right) - f\left(\theta_j - \frac{\pi}{2}\right)\right]\)

Für jeden Parameter werden zusätzliche Schaltkreisausführungen benötigt. Jede Ausführung muss häufig vielfach gemessen werden, um einen Erwartungswert zu schätzen. Bei vielen Clients, Parametern und Trainingsrunden kann der Aufwand stark wachsen. BCFL fügt zusätzlich Signaturprüfung, Blockchain-Konsens und Protokollierung hinzu. Eine sinnvolle Architektur muss deshalb quantenmechanische Messkosten und Blockchain-Overhead gemeinsam betrachten.

Kein automatischer Quantenvorteil

Die Verbindung von Blockchain und QFL erzeugt keinen Quantenvorteil. Die Blockchain ist überwiegend eine klassische Infrastruktur. Ihr Konsens wird nicht dadurch schneller, dass ein Quantenmodell trainiert wird. Umgekehrt verbessert die Blockchain nicht automatisch die Vorhersagequalität eines Quantenmodells. Sie kann Vertrauen, Auditierbarkeit und Koordination verbessern.

Ein behaupteter Vorteil muss präzise benannt werden: geringere Modellgröße, weniger Kommunikationsrunden, höhere Genauigkeit, bessere Robustheit oder schnellere Optimierung. Danach ist zu messen, ob der Vorteil auch unter realen Hardwarefehlern, Datenheterogenität und Sicherheitskosten bestehen bleibt.

Sicherheit, Datenschutz und Quantenbedrohungen

Sicherheitsziele

Ein BCFL-System muss mehrere Ziele gleichzeitig erfüllen. Vertraulichkeit schützt Daten und Updates vor unberechtigtem Lesen. Integrität verhindert unbemerkte Veränderungen. Authentizität ordnet Nachrichten einer Identität zu. Verfügbarkeit stellt sicher, dass Training und Modellzugriff fortgesetzt werden können. Nachvollziehbarkeit dokumentiert Entscheidungen. Verantwortlichkeit ermöglicht, Regelverstöße einer Organisation oder technischen Rolle zuzuordnen.

Zwischen diesen Zielen bestehen Konflikte. Eine vollständig transparente Blockchain erleichtert Audits, kann aber Metadaten oder Modellinformationen offenlegen. Starke Verschlüsselung verbessert Vertraulichkeit, erschwert jedoch Qualitätsprüfung und Fehlersuche. Dauerhafte Speicherung unterstützt Provenienz, kollidiert aber mit Löschanforderungen. Die Architektur muss diese Zielkonflikte ausdrücklich lösen.

Schutzwirkung der Blockchain

Die Blockchain kann nachweisen, dass ein bestimmter Hashwert zu einem bestimmten Zeitpunkt registriert wurde. Sie kann verhindern, dass ein einzelner Administrator Trainingsprotokolle unbemerkt umschreibt. Sie kann gemeinsam vereinbarte Smart-Contract-Regeln ausführen und mehrere Validatoren an der Freigabe beteiligen. Damit stärkt sie Integrität, Reihenfolge und organisationsübergreifende Kontrolle.

Sie schützt jedoch nicht vor einem Client, der falsche Daten verwendet und daraus ein formal korrektes Update erzeugt. Sie verhindert auch keine Rekonstruktionsangriffe auf öffentlich sichtbare Gradienten. Ein schädliches Update bleibt schädlich, selbst wenn sein Hashwert korrekt und dauerhaft gespeichert wurde.

Secure Aggregation

Secure Aggregation soll dem Aggregator nur die Summe oder den Mittelwert mehrerer Updates offenlegen, nicht die einzelnen Beiträge. Vereinfacht soll der Aggregator den Wert

\(S = \sum_{k=1}^{K} \Delta w_k\)

erhalten, ohne ein einzelnes \(\Delta w_k\) lesen zu können. Praktische Protokolle verwenden Maskierungen, Schlüsselaustausch und Verfahren zur Behandlung ausfallender Teilnehmer. Die Blockchain kann Teilnehmerlisten, Protokollphasen und Ergebnis-Hashwerte verwalten, sollte aber die vertraulichen Einzelupdates nicht offen speichern.

Secure Aggregation erschwert zugleich die Erkennung schädlicher Beiträge, weil Validatoren keine einzelnen Updates untersuchen können. Deshalb werden robuste Aggregation, vertrauliche Ausführungsumgebungen oder kryptografische Nachweise benötigt. Datenschutz und Angriffserkennung müssen gemeinsam entworfen werden.

Differential Privacy

Differential Privacy begrenzt, wie stark sich die Ausgabe eines Verfahrens ändert, wenn ein einzelner Datensatz hinzugefügt oder entfernt wird. Für benachbarte Datensätze \(D\) und \(D'\) gilt für einen randomisierten Mechanismus \(M\) näherungsweise:

\(P(M(D) \in S) \leq e^{\epsilon} P(M(D') \in S) + \delta\)

Die Parameter \(\epsilon\) und \(\delta\) beschreiben den Datenschutzrahmen. Kleinere Werte bedeuten in der Regel stärkeren Schutz, können aber die Modellgenauigkeit verschlechtern. Die Blockchain kann das verwendete Datenschutzbudget und die genehmigten Konfigurationen dokumentieren. Sie darf jedoch keine sensiblen Zwischenwerte speichern, die den Schutz wieder unterlaufen.

Homomorphe Verschlüsselung und Mehrparteienberechnung

Homomorphe Verschlüsselung erlaubt bestimmte Operationen auf verschlüsselten Daten. Der Aggregator kann verschlüsselte Updates addieren, ohne sie zu entschlüsseln. Erst ein berechtigter gemeinsamer Prozess entschlüsselt das Gesamtergebnis. Mehrparteienberechnung verteilt Geheimnisse auf mehrere Parteien, sodass keine einzelne Partei allein über alle Informationen verfügt.

Beide Ansätze können starke Vertraulichkeit bieten, verursachen aber erheblichen Rechen- und Kommunikationsaufwand. In Verbindung mit Quantenhardware und Blockchain kann die Gesamtsystemkomplexität schnell unpraktisch werden. Daher ist zu prüfen, welche Daten wirklich geschützt werden müssen und welche Funktionen durch einfachere organisatorische Kontrollen abgesichert werden können.

Poisoning und robuste Aggregation

Robuste Aggregationsverfahren versuchen, Ausreißer und koordinierte Manipulationen zu begrenzen. Statt eines einfachen Mittelwerts können komponentenweise Medianwerte, getrimmte Mittelwerte oder distanzbasierte Auswahlverfahren verwendet werden. Kein Verfahren ist universell sicher. Starke Datenheterogenität kann ehrliche Updates wie Ausreißer erscheinen lassen, während gut abgestimmte Angreifer unauffällig bleiben.

Die Blockchain kann dokumentieren, welches Verfahren und welche Parameter verwendet wurden. Ein Reputationssystem kann wiederholt verdächtige Teilnehmer herabstufen. Dennoch müssen Fehlentscheidungen anfechtbar sein, da ein automatischer Ausschluss einer Organisation rechtliche und wirtschaftliche Folgen haben kann.

Quantenangriffe auf die Kryptografie

Leistungsfähige fehlertolerante Quantencomputer könnten mit Shors Algorithmus bestimmte Probleme effizient lösen, auf denen verbreitete asymmetrische Kryptosysteme beruhen. Betroffen wären insbesondere viele heute genutzte Verfahren für digitale Signaturen und Schlüsselaustausch. Für BCFL ist dies kritisch, weil Identitäten, Update-Signaturen und Governance-Entscheidungen langfristig überprüfbar bleiben sollen.

Grovers Algorithmus bietet für unstrukturierte Suche eine quadratische Beschleunigung. Für symmetrische Schlüssel und Hashfunktionen bedeutet dies vor allem, dass ausreichend große Sicherheitsparameter gewählt werden müssen. Die Auswirkungen unterscheiden sich daher deutlich von denen auf RSA- oder elliptische Kurvenverfahren.

Post-Quanten-Kryptografie

Post-Quanten-Kryptografie verwendet klassische Algorithmen, die gegen bekannte Angriffe klassischer und quantenbasierter Rechner widerstandsfähig sein sollen. Für BCFL sind vor allem Schlüsselkapselung und digitale Signaturen relevant. Die 2024 veröffentlichten NIST-Standards umfassen ML-KEM für Schlüsselkapselung sowie ML-DSA und SLH-DSA für digitale Signaturen.

Eine Migration ist nicht nur ein Austausch von Bibliotheken. Post-quanten-sichere Schlüssel und Signaturen können größer sein und dadurch Transaktionsgröße, Speicherbedarf und Latenz erhöhen. Smart Contracts, Zertifikate, Hardwaremodule und Identitätsdienste müssen kompatibel sein. Historische Signaturen bleiben zudem nach dem Ende ihrer kryptografischen Sicherheit problematisch. Langfristige Systeme benötigen daher Erneuerungs- und Nachsignierungsstrategien.

Krypto-Agilität

Krypto-Agilität bedeutet, dass kryptografische Verfahren ausgetauscht werden können, ohne die gesamte Anwendung neu zu entwerfen. Ein BCFL-System sollte Algorithmuskennungen, Schlüsselversionen, Gültigkeitszeiträume und Migrationsregeln ausdrücklich unterstützen. Während einer Übergangsphase können klassische und post-quanten-sichere Signaturen parallel verlangt werden.

Die Governance muss festlegen, wer einen Wechsel auslöst und wie kompromittierte Schlüssel behandelt werden. Da mehrere Organisationen beteiligt sind, darf die Migration nicht von einer einzelnen Partei abhängen. Die Blockchain kann den Übergang dokumentieren, aber die sichere Verteilung neuer Schlüssel bleibt eine eigenständige Aufgabe.

Quantum Key Distribution

Quantum Key Distribution nutzt quantenmechanische Eigenschaften, um Schlüsselmaterial zwischen zwei Endpunkten auszutauschen und Abhörversuche unter geeigneten Bedingungen erkennbar zu machen. Sie kann Kommunikationsverbindungen zwischen Rechenzentren oder Quantenknoten ergänzen. QKD ersetzt jedoch keine digitale Identität, keine Zugriffskontrolle und keine sichere Endpunktsoftware.

Für weit verteilte Edge-Geräte ist QKD wegen spezieller Hardware, Reichweitenbegrenzungen und Netzanforderungen meist nicht praktikabel. In einem kleinen Verbund hochwertiger Forschungs- oder Finanzrechenzentren kann sie dagegen als zusätzliche Schicht eingesetzt werden. Post-Quanten-Kryptografie bleibt trotzdem wichtig, weil Signaturen, Softwareverteilung und viele Kommunikationswege nicht allein durch QKD geschützt werden.

Datenschutzrechtliche Konsequenzen

Eine Blockchain sollte keine personenbezogenen Trainingsdaten, ungeschützten Modellupdates oder detaillierten Gesundheitsinformationen enthalten. Selbst Hashwerte können problematisch sein, wenn sie eindeutig auf bekannte Datensätze verweisen oder mit weiteren Informationen verknüpft werden. Zudem erschwert ein dauerhaft repliziertes Register Löschung und Berichtigung.

Eine datenschutzgerechte Architektur minimiert On-Chain-Daten, verwendet kontrollierte Zugriffsrechte und legt sensible Inhalte in löschbaren Off-Chain-Speichern ab. Rollen, Zwecke, Aufbewahrungsfristen und Verantwortlichkeiten müssen vertraglich und technisch festgelegt werden. Die technische Bezeichnung als Blockchain hebt rechtliche Pflichten nicht auf.

Potenzielle Anwendungsfelder

Medizin und Pharmaforschung

Kliniken, Labore und pharmazeutische Unternehmen besitzen hochwertige, aber besonders sensible Daten. Federated Learning kann gemeinsame Diagnose-, Prognose- oder Wirkstoffmodelle ermöglichen, ohne Rohdaten zentral zusammenzuführen. BCFL ergänzt eine organisationsübergreifende Dokumentation: Welche Institution beteiligte sich, welche Modellversion wurde verwendet, welche Prüfung fand statt und wann wurde ein Modell für einen klinischen oder wissenschaftlichen Zweck freigegeben?

Quantum Federated Learning könnte in Zukunft hybride Modelle für medizinische Bildanalyse, Moleküleigenschaften oder Optimierungsaufgaben einbeziehen. Gegenwärtig muss jedoch geprüft werden, ob eine Quantenschicht tatsächlich einen messbaren Vorteil gegenüber klassischen Modellen liefert. In medizinischen Anwendungen sind Nachvollziehbarkeit, Validierung und Reproduzierbarkeit wichtiger als technologische Neuheit.

Finanzwirtschaft

Banken und Zahlungsdienstleister können gemeinsam Betrugs-, Geldwäsche- oder Risikomodelle trainieren, ohne vollständige Kundentransaktionen auszutauschen. Eine permissioned Blockchain kann Teilnehmer identifizieren, Modellstände dokumentieren und Freigaben mehrerer Institute verlangen. Smart Contracts können die Einhaltung gemeinsamer Trainingsregeln kontrollieren.

Quantenbasierte Modelle werden für bestimmte Optimierungs- und Klassifikationsprobleme untersucht. Gleichzeitig ist die Finanzwirtschaft auf langlebige digitale Signaturen angewiesen. Post-quanten-sichere BCFL-Architekturen sind daher unabhängig davon relevant, ob das Lernmodell selbst quantenbasiert ist.

Quantenchemie und Materialforschung

Unternehmen und Forschungseinrichtungen erzeugen Daten aus Simulationen, Experimenten und Quantenchemie. Diese Daten können wertvolles geistiges Eigentum enthalten. Ein föderierter Ansatz erlaubt gemeinsames Lernen, während die Datensätze lokal bleiben. Die Blockchain kann Beiträge, Schaltungsversionen und Nutzungsrechte nachvollziehbar machen.

Besonders interessant sind hybride Modelle, bei denen Quantenalgorithmen molekulare Zustände oder Energieeigenschaften berechnen und klassische Lernverfahren daraus Vorhersagen ableiten. BCFL kann die Zusammenarbeit koordinieren, ersetzt aber weder physikalische Validierung noch die Prüfung der Messqualität.

Industrie und vorausschauende Wartung

Mehrere Produktionsstandorte oder Hersteller können Modelle zur Fehlererkennung und Wartungsplanung trainieren. Lokale Maschinendaten müssen das Werk nicht verlassen. Die Blockchain dokumentiert, welche Modellversion an welchem Standort eingesetzt wurde und aus welchen freigegebenen Trainingsrunden sie stammt.

Für industrielle Edge-Geräte ist eine schwere Blockchain- und Quanteninfrastruktur meist ungeeignet. Sinnvoller ist eine hierarchische Architektur: Geräte trainieren oder sammeln lokal, leistungsfähige Standortserver aggregieren, und nur kompakte Nachweise gelangen in ein Konsortialregister.

Quantensensorik und Energienetze

Quantensensoren können hochpräzise Messdaten für Magnetfelder, Zeit, Beschleunigung oder Gravitation erzeugen. Sind solche Sensoren auf mehrere Betreiber verteilt, kann Federated Learning gemeinsame Auswertungsmodelle trainieren. BCFL kann Messkampagnen, Modellversionen und Zugriffsrechte koordinieren.

In Energienetzen kommen zusätzlich hohe Anforderungen an Verfügbarkeit und Echtzeitfähigkeit hinzu. Blockchain-Konsens darf Steuerungsentscheidungen nicht unnötig verzögern. Sicherheitskritische Echtzeitfunktionen sollten lokal oder in speziell ausgelegten Kontrollsystemen verbleiben; die Blockchain eignet sich eher für Audit, Abrechnung und verzögerungstolerante Modellverwaltung.

Kriterien für einen sinnvollen Einsatz

BCFL ist nicht erforderlich, wenn eine vertrauenswürdige Organisation alle Teilnehmer kontrolliert und ein normaler Audit-Log genügt. Es ist auch ungeeignet, wenn extrem geringe Latenz wichtiger ist als organisationsübergreifende Nachvollziehbarkeit. Vor einer Einführung sind fünf Fragen zu beantworten: Gibt es mehrere unabhängige Parteien? Fehlt eine gemeinsam akzeptierte Zentralinstanz? Müssen Entscheidungen manipulationsresistent dokumentiert werden? Können sensible Daten und große Modelle Off-Chain bleiben? Übersteigt der Nutzen den zusätzlichen Betriebsaufwand?

Für die Quantenkomponente kommt eine sechste Frage hinzu: Löst der Quantenanteil ein konkretes Rechen- oder Datenproblem besser als eine optimierte klassische Methode? Ohne belastbaren Nachweis sollte er als Forschungsmodul und nicht als produktionskritische Grundlage behandelt werden.

Leistungsfähigkeit und Bewertungsmethoden

Lernbezogene Kennzahlen

Die Modellqualität wird mit aufgabenspezifischen Kennzahlen bewertet, etwa Genauigkeit, Präzision, Trefferquote, Fehlermaß oder Kalibrierung. Bei ungleich verteilten Daten reicht ein globaler Mittelwert nicht aus. Zusätzlich sollten Ergebnisse je Teilnehmergruppe, Datenquelle und relevanter Minderheitsklasse betrachtet werden.

Die Konvergenz wird über Trainingsrunden, lokale Schritte und tatsächlich ausgeführte Berechnungen gemessen. Eine geringere Zahl an Kommunikationsrunden ist nur dann ein Vorteil, wenn lokale Rechenkosten und Modellqualität vergleichbar bleiben.

Systembezogene Kennzahlen

Wichtige Systemmetriken sind End-to-End-Latenz einer Trainingsrunde, Transaktionsdurchsatz, Blockchain-Bestätigungszeit, übertragenes Datenvolumen, Speicherwachstum und Ausfallverhalten. Die gesamte Rundendauer kann vereinfacht zerlegt werden:

\(T_{\mathrm{round}} = T_{\mathrm{distribution}} + T_{\mathrm{local}} + T_{\mathrm{protection}} + T_{\mathrm{validation}} + T_{\mathrm{consensus}} + T_{\mathrm{aggregation}}\)

Eine Optimierung nur des Blockchain-Konsenses reicht nicht, wenn Quantenjobs oder lokale Trainingsschritte den größten Zeitanteil verursachen. Umgekehrt kann ein schneller Lernalgorithmus durch langsame Bestätigungen ausgebremst werden.

Kommunikations- und Speicherkosten

Der Kommunikationsaufwand hängt von Modellgröße, Teilnehmerzahl und Rundenzahl ab. Ohne Kompression ergibt sich näherungsweise:

\(C_{\mathrm{comm}} \approx R \cdot K \cdot S_{\mathrm{update}}\)

Dabei stehen \(R\) für die Zahl der Runden, \(K\) für die durchschnittliche Zahl aktiver Teilnehmer und \(S_{\mathrm{update}}\) für die Größe eines Updates. Blockchain-Transaktionen kommen zusätzlich hinzu, sollten aber nur kompakte Metadaten enthalten.

Quantenbezogene Kennzahlen

Bei QFL müssen Qubit-Zahl, Schaltungstiefe, Gate-Fehler, Messwiederholungen, Laufzeit und Warteschlangen berücksichtigt werden. Entscheidend ist nicht allein die Zahl physischer Qubits, sondern die Qualität der tatsächlich nutzbaren Berechnung. Auch die Schwankung zwischen verschiedenen Kalibrierungsständen muss erfasst werden.

Ein fairer Vergleich verlangt ein klassisches Modell mit ähnlicher Kapazität, identische Datenaufteilung und ein transparentes Rechenbudget. Wird ein Quantenmodell nur mit einem schwachen klassischen Modell verglichen, ist die Aussagekraft gering.

Sicherheitsbewertung

Sicherheitsversuche sollten verschiedene Angreifer modellieren: einzelne bösartige Clients, kolludierende Teilnehmer, kompromittierte Validatoren, fehlerhafte Aggregatoren und externe Netzwerkangreifer. Zu messen sind Erkennungsrate, Fehlalarmrate, Qualitätsverlust und Wiederherstellungszeit. Ein System ist nicht robust, wenn es Angriffe erkennt, dabei aber viele ehrliche Teilnehmer ausschließt oder das Modell unbrauchbar macht.

Notwendige Vergleichsarchitekturen

Eine vollständige Evaluation vergleicht mindestens zentralisiertes Lernen, klassisches Federated Learning, dezentrales Federated Learning ohne Blockchain und BCFL. Bei Quantentechnologie kommen ein klassisches BCFL-Modell, QFL ohne Blockchain und blockchain-gestütztes QFL hinzu. Nur so lässt sich erkennen, welcher Systembestandteil einen beobachteten Effekt verursacht.

Grenzen und offene Probleme

Skalierbarkeit und Latenz

Jede zusätzliche Blockchain-Transaktion erzeugt Validierung, Konsens und Speicherung. Werden alle lokalen Updates vollständig On-Chain verarbeitet, wächst der Aufwand schnell über praktikable Grenzen hinaus. Permissioned Netzwerke reduzieren diese Belastung, beseitigen sie aber nicht. Batch-Verarbeitung, Off-Chain-Speicher und seltenere Verankerung sind deshalb zentrale Entwurfsprinzipien.

Daten- und Hardwareheterogenität

Unterschiedliche Datenverteilungen erschweren die Aggregation. In QFL kommen unterschiedliche Quantengeräte, Compiler, Gate-Sätze und Rauschprofile hinzu. Ein Parametervektor kann auf zwei Geräten verschiedene effektive Modelle erzeugen. Standardisierte Schnittstellen und hardwarebezogene Metadaten sind notwendig, reichen aber bei stark abweichender Hardware möglicherweise nicht aus.

Oracle-Problem

Eine Blockchain kennt nur Daten, die ihr über Transaktionen oder externe Dienste mitgeteilt werden. Ob ein Client tatsächlich die vereinbarte Trainingsmethode ausgeführt hat, muss durch Attestierung, Nachweise oder unabhängige Tests abgesichert werden. Ein fehlerhaftes Oracle kann falsche Qualitätswerte liefern, die anschließend korrekt und dauerhaft verarbeitet werden.

Governance und Haftung

Technischer Konsens ist nicht gleichbedeutend mit rechtlicher Verantwortung. Ein Konsortium muss festlegen, wer für ein fehlerhaftes Modell haftet, wer Teilnehmer ausschließen darf und wie Smart Contracts geändert werden. Unveränderliche Regeln sind problematisch, wenn Gesetze, Sicherheitsanforderungen oder wissenschaftliche Erkenntnisse sich ändern. Gute Governance benötigt deshalb kontrollierte Aktualisierungsverfahren und transparente Entscheidungsrechte.

Energie- und Ressourcenbedarf

BCFL kombiniert lokales Training, kryptografische Schutzverfahren, verteilte Validierung und Datenspeicherung. QFL ergänzt wiederholte Quantenschaltkreisausführungen und klassische Optimierung. Der Gesamtressourcenbedarf kann den Nutzen übersteigen. Energieeffizienz muss als End-to-End-Kennzahl betrachtet werden, nicht nur anhand des Konsensmechanismus.

Begrenzte Reife der Quantenhardware

Viele QFL-Ergebnisse beruhen auf Simulationen oder kleinen Demonstrationen. Simulationen sind wissenschaftlich wertvoll, bilden aber Warteschlangen, Kalibrierungsschwankungen und reale Messfehler nur begrenzt ab. Produktive BCFL-Systeme sollten den Quantenanteil modular halten, damit klassische Ersatzverfahren verfügbar bleiben.

Komplexität als Sicherheitsrisiko

Jede zusätzliche Schicht schafft neue Schnittstellen und Fehlerquellen. Federated Learning, Smart Contracts, sichere Aggregation, Post-Quanten-Kryptografie und Quantenhardware besitzen jeweils eigene Bedrohungsmodelle. Werden sie ohne klare Systemgrenzen kombiniert, kann die Gesamtarchitektur weniger sicher sein als ihre Einzelkomponenten vermuten lassen.

Fehlender universeller Quantenvorteil

Es gibt keinen allgemeinen Beweis, dass Quantum Machine Learning für praktische föderierte Aufgaben grundsätzlich schneller, genauer oder sparsamer ist. Vorteile können auf bestimmte Datenstrukturen, Modelle oder Hardwarebedingungen beschränkt sein. Aussagen über Quantenvorteile müssen daher eng formuliert und reproduzierbar belegt werden.

Forschungs- und Entwicklungsperspektiven

Leichtgewichtige BCFL-Architekturen

Zukünftige Systeme werden voraussichtlich nur prüfrelevante Ereignisse On-Chain speichern. Modellupdates können komprimiert, gruppiert und außerhalb der Blockchain verarbeitet werden. Hierarchische Architekturen verbinden lokale Edge-Aggregation mit einem schlanken Konsortialregister.

Verifizierbares Training

Ein wichtiges Forschungsziel ist der Nachweis, dass lokale oder externe Berechnungen gemäß einer vereinbarten Methode ausgeführt wurden, ohne sensible Daten offenzulegen. Zero-Knowledge-Nachweise, verifizierbare Berechnung und Hardware-Attestierung können dazu beitragen. Für große Lernmodelle müssen diese Verfahren jedoch deutlich effizienter werden.

Post-quanten-sichere Migration

BCFL-Plattformen sollten neue Identitäten bereits mit migrationsfähigen Kryptoschnittstellen entwerfen. Forschung wird benötigt, um große post-quanten-sichere Signaturen, Blockchain-Speicher und hohe Transaktionsraten besser auszubalancieren. Ebenso wichtig sind Verfahren zur langfristigen Erneuerung historischer Nachweise.

Standardisierung

Interoperable Modellformate, einheitliche Provenienzschemas, standardisierte Rollen und gemeinsame Sicherheitsprofile würden den Vergleich von BCFL-Systemen erleichtern. Für QFL werden zusätzlich portable Schaltungsbeschreibungen, hardwarebezogene Qualitätsangaben und nachvollziehbare Benchmarks benötigt.

Reproduzierbare Quantenexperimente

Zukünftige Studien sollten Quellcode, Datenaufteilung, Schaltungsstruktur, Kalibrierungsdaten und klassische Baselines offenlegen. Ergebnisse auf Simulatoren und realer Hardware sind getrennt auszuweisen. Ein positiver Einzelfall genügt nicht; entscheidend sind Wiederholbarkeit und Stabilität unter verschiedenen Daten- und Hardwarebedingungen.

Adaptive Governance

Reputation, Teilnehmerauswahl und Aggregationsregeln könnten dynamisch an beobachtete Risiken angepasst werden. Diese Anpassung darf nicht intransparent erfolgen. Jede Regeländerung muss versioniert, begründet und prüfbar sein. Governance wird damit zu einem technischen und organisatorischen Bestandteil des Lernsystems.

Schlussfolgerung

Blockchain-Based Federated Learning ist eine Architektur für gemeinsames maschinelles Lernen zwischen mehreren Parteien, die ihre Rohdaten nicht zentral zusammenführen und keiner einzelnen Instanz uneingeschränkt vertrauen wollen. Federated Learning übernimmt das verteilte Training. Die Blockchain schafft ein gemeinsames Register für Identitäten, Modellversionen, Freigaben, Prüfungen und Regeln. Smart Contracts können wiederkehrende Abläufe automatisieren, aber weder Datenqualität noch Modellrichtigkeit selbstständig erkennen.

Der größte Nutzen von BCFL liegt in Cross-Silo-Szenarien mit bekannten Organisationen, langfristiger Zusammenarbeit und hohen Anforderungen an Auditierbarkeit. Eine permissioned Blockchain ist dort meist geeigneter als eine öffentliche Blockchain. Große Modelle und sensible Updates gehören grundsätzlich in kontrollierte Off-Chain-Speicher; On-Chain sollten nur kompakte, datensparsame Nachweise liegen.

Im Bereich der Quantentechnologie kann BCFL verteilte Quanten- und Hybridmodelle koordinieren, Quantenrechenzeit verwalten und die Herkunft von Schaltungen, Parametern und Messergebnissen dokumentieren. Diese Funktionen schaffen keinen automatischen Quantenvorteil. Ein solcher Vorteil muss gegenüber optimierten klassischen Verfahren experimentell nachgewiesen werden. Gegenwärtige Quantenhardware bleibt begrenzt, fehleranfällig und teuer. Deshalb sollten Quantenkomponenten modular, austauschbar und klar von der Vertrauensschicht getrennt werden.

Unabhängig vom Einsatz eines Quantenmodells muss die kryptografische Infrastruktur auf zukünftige Quantenangriffe vorbereitet werden. Post-Quanten-Kryptografie, Krypto-Agilität und ein geregelter Schlüsselwechsel sind für langlebige BCFL-Systeme wesentlich. QKD kann ausgewählte Verbindungen ergänzen, ersetzt aber weder digitale Signaturen noch sichere Endpunkte.

BCFL ist somit keine universelle Verbesserung des Federated Learning. Es ist eine gezielte Lösung für Systeme, in denen mehrere unabhängige Parteien gemeinsame Regeln, überprüfbare Modellprovenienz und verteilte Kontrolle benötigen. Die Architektur ist gerechtfertigt, wenn diese Vorteile messbar größer sind als zusätzlicher Rechenaufwand, Latenz, Governance-Komplexität und neue Angriffsflächen. Die entscheidende Entwicklungsaufgabe besteht nicht darin, möglichst viele Technologien zu verbinden, sondern jede Komponente auf einen klaren, nachweisbaren Nutzen zu begrenzen.

Mit freundlichen Grüßen Jörg-Owe Schneppat

Anhang

Wissenschaftliche Zeitschriften und Artikel

Die folgende Auswahl verbindet grundlegende Arbeiten zum Federated Learning mit spezialisierter Primär- und Übersichtsliteratur zu Blockchain-Based Federated Learning sowie Quantum Federated Learning. Für die Abhandlung sollten grundlegende Verfahren, konkrete BCFL-Architekturen und quantentechnologische Erweiterungen getrennt ausgewertet werden. Dadurch bleibt erkennbar, welche Aussagen auf etablierten Verfahren beruhen und welche noch Gegenstand aktueller Forschung sind.

Grundlegende Primärliteratur zu Federated Learning

  • H. Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson und Blaise Agüera y Arcas: Communication-Efficient Learning of Deep Networks from Decentralized Data, Proceedings of the 20th International Conference on Artificial Intelligence and Statistics, PMLR, 2017.
    • Diese Arbeit gehört zur grundlegenden Primärliteratur des modernen Federated Learning. Sie führt den als Federated Averaging bekannten Ansatz für das iterative Training verteilter Modelle ein und untersucht dessen Kommunikationsaufwand unter nicht unabhängig und identisch verteilten lokalen Daten. In einer BCFL-Abhandlung eignet sich die Quelle zur Erklärung des klassischen Trainingsablaufs, der lokalen Modellaktualisierung und der gewichteten Aggregation. Sie bildet zugleich den notwendigen Vergleichspunkt für die Frage, welche zusätzlichen Funktionen eine Blockchain tatsächlich übernimmt.
  • Peter Kairouz et al.: Advances and Open Problems in Federated Learning, Foundations and Trends in Machine Learning, Band 14, Ausgaben 1–2, 2021.
    • Die umfangreiche Monographie in Zeitschriftenform systematisiert die zentralen Forschungsfragen des Federated Learning. Behandelt werden unter anderem statistische Heterogenität, Kommunikationseffizienz, Datenschutz, Sicherheit, Fairness, Personalisierung und verteilte Optimierung. Für die Abhandlung ist die Quelle besonders wichtig, um Probleme des klassischen Federated Learning nicht vorschnell als Blockchain-Probleme darzustellen. Sie ermöglicht eine fachlich saubere Trennung zwischen Herausforderungen des Lernalgorithmus und Herausforderungen der organisationsübergreifenden Koordination.
  • Keith Bonawitz et al.: Practical Secure Aggregation for Privacy-Preserving Machine Learning, Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017.
    • Die Arbeit beschreibt ein praktisch einsetzbares Verfahren zur sicheren Aggregation hochdimensionaler Modellupdates. Ein Aggregator kann dabei eine Summe aus Teilnehmerbeiträgen berechnen, ohne die einzelnen Beiträge im Klartext einsehen zu müssen. Diese Quelle ist für BCFL besonders relevant, weil eine Blockchain allein keine Vertraulichkeit der Modellupdates gewährleistet. Sie kann in der Abhandlung verwendet werden, um zu zeigen, warum Blockchain-Protokollierung mit zusätzlichen kryptografischen Datenschutzverfahren kombiniert werden muss.

Grundlegende Primärliteratur zu Blockchain-Based Federated Learning

  • Hyesung Kim, Jihong Park, Mehdi Bennis und Seong-Lyun Kim: Blockchained On-Device Federated Learning, IEEE Communications Letters, Band 24, Ausgabe 6, 2020.
    • Diese frühe Primärarbeit entwickelt eine als BlockFL bezeichnete Architektur, in der lokale Modellupdates über eine Blockchain ausgetauscht und verifiziert werden. Besonders wertvoll ist die Untersuchung der End-to-End-Latenz aus lokaler Berechnung, Kommunikation, Blockerzeugung und Konsens. Die Quelle kann für die technische Herleitung des BCFL-Grundmodells und für die Diskussion verwendet werden, weshalb die Blockerzeugungsrate nicht unabhängig vom Lernprozess gewählt werden darf.
  • Youyang Qu, Md Palash Uddin, Chenquan Gan, Yong Xiang, Longxiang Gao und John Yearwood: Blockchain-Enabled Federated Learning: A Survey, ACM Computing Surveys, Band 55, Ausgabe 4, Artikel 70, 2022.
    • Diese Überblicksarbeit gehört zu den zentralen wissenschaftlichen Quellen für die systematische Untersuchung von BCFL. Sie ordnet bestehende Architekturen, Konsensmodelle, Sicherheitsmechanismen und Anwendungsbereiche ein und arbeitet technische Herausforderungen wie Skalierbarkeit, Datenschutz und Kommunikationskosten heraus. In der Abhandlung eignet sie sich als Ausgangspunkt für die Taxonomie von BCFL-Systemen und für den Vergleich verschiedener Integrationsformen von Blockchain und Federated Learning.
  • Mohamed Abdur Rahman, M. Shamim Hossain, Mohammad Saiful Islam, Nabil Ali Alrajeh und Ghulam Muhammad: Secure and Provenance Enhanced Internet of Health Things Framework: A Blockchain Managed Federated Learning Approach, IEEE Access, Band 8, 2020.
    • Die Arbeit entwickelt eine anwendungsorientierte BCFL-Architektur für das Internet of Health Things. Smart Contracts verwalten unter anderem Trainingspläne, Authentifizierung, Vertrauenswerte, Modellverteilung und Provenienzinformationen. Die Quelle eignet sich zur Untersuchung eines konkreten Cross-Silo- und Edge-Szenarios, in dem Datenschutz, Modellherkunft und organisationsübergreifende Kontrolle gemeinsam betrachtet werden. Sie sollte zugleich kritisch daraufhin ausgewertet werden, welche Aufgaben tatsächlich von der Blockchain und welche von zusätzlichen Schutzverfahren übernommen werden.
  • Sin Kit Lo, Yue Liu, Qinghua Lu, Chen Wang, Xiwei Xu, Hye-Young Paik und Liming Zhu: Towards Trustworthy AI: Blockchain-Based Architecture Design for Accountability and Fairness of Federated Learning Systems, IEEE Internet of Things Journal, 2022.
    • Diese Primärarbeit untersucht BCFL aus der Perspektive vertrauenswürdiger künstlicher Intelligenz. Im Mittelpunkt stehen eine Smart-Contract-basierte Registrierung der Daten- und Modellprovenienz sowie die Verbesserung der Fairness bei heterogenen Teilnehmerdaten. Für die Abhandlung ist sie besonders geeignet, um nachzuweisen, dass Blockchain nicht nur für Zahlungen oder Konsens eingesetzt werden kann, sondern auch als Governance- und Rechenschaftsschicht eines föderierten Lernsystems.

Spezialisierte Übersichtsarbeiten zu Sicherheit, Datenschutz und Systemarchitektur

  • Asad Qammar, Afsana Karim, Huansheng Ning et al.: Securing Federated Learning with Blockchain: A Systematic Literature Review, Artificial Intelligence Review, Band 56, 2023.
    • Die systematische Literaturübersicht untersucht, welche Sicherheits- und Datenschutzprobleme des Federated Learning durch Blockchain-Mechanismen adressiert werden können und welche neuen Risiken durch die Integration entstehen. Sie behandelt unter anderem Poisoning, Free-Riding, Denial-of-Service, Reputationsmechanismen, Smart Contracts und unterschiedliche Blockchain-Plattformen. Die Quelle eignet sich für eine kritische Sicherheitsanalyse und verhindert die vereinfachende Aussage, eine Blockchain löse sämtliche Vertrauens- und Datenschutzprobleme automatisch.
  • Ji Liu, Chunlu Chen, Yu Li, Lin Sun, Yulun Song, Jingbo Zhou, Bo Jing und Dejing Dou: Enhancing Trust and Privacy in Distributed Networks: A Comprehensive Survey on Blockchain-Based Federated Learning, Knowledge and Information Systems, 2024.
    • Diese spezialisierte Übersicht entwickelt eine Taxonomie dezentraler, getrennter und reputationsbasierter BCFL-Architekturen. Sie behandelt allgemeine Systemmodelle, Datenschutzmechanismen und Anwendungen in sicherheitskritischen Bereichen. Für die Abhandlung ist sie als aktuelle Recherchegrundlage geeignet, um Architekturvarianten, offene Forschungsfragen und den Übergang von frühen BlockFL-Modellen zu differenzierteren BCFL-Systemen darzustellen.
  • Zeju Cai, Jianguo Chen, Yuting Fan, Zibin Zheng und Keqin Li: Blockchain-Empowered Federated Learning: Benefits, Challenges, and Solutions, IEEE Transactions on Big Data, 2025.
    • Die Arbeit untersucht systematisch, warum Blockchain in Federated-Learning-Systeme integriert wird und welche zusätzlichen Anforderungen daraus für Netzwerk, Rechenleistung und Speicher entstehen. Sie eignet sich besonders für die Abwägung zwischen Sicherheits- und Governance-Vorteilen einerseits sowie zusätzlicher Latenz und Systemkomplexität andererseits. In der Abhandlung kann sie für die Bewertung moderner BCFL-Architekturen und ihrer noch ungelösten Skalierungsprobleme verwendet werden.

Spezialisierte Arbeiten zu Quantum Federated Learning

  • Samuel Yen-Chi Chen und Shinjae Yoo: Federated Quantum Machine Learning, Entropy, Band 23, Ausgabe 4, Artikel 460, 2021.
    • Die Arbeit gehört zur frühen Primärliteratur des Quantum Federated Learning. Sie demonstriert das föderierte Training hybrider quantenklassischer Modelle und verbindet ein klassisches vortrainiertes Faltungsnetz mit einem Quantum Neural Network. Für die Abhandlung ist sie die wichtigste Quelle zur Erklärung, wie lokale Parameter eines Quantenmodells trainiert und anschließend klassisch aggregiert werden können. Sie sollte nicht als Nachweis eines allgemeinen Quantenvorteils, sondern als grundlegende Machbarkeitsstudie eingeordnet werden.
  • Mahdi Chehimi und Walid Saad: Quantum Federated Learning with Quantum Data, IEEE International Conference on Acoustics, Speech and Signal Processing, 2022.
    • Diese Primärarbeit erweitert Quantum Federated Learning auf quantenmechanische Trainingsdaten. Lokale Teilnehmer trainieren Parameter von Quantum Convolutional Neural Networks, während die Quantendaten dezentral verbleiben. Die Quelle ist für die Abhandlung besonders wichtig, weil sie den Unterschied zwischen klassischen Daten mit Quantenmodell und genuinen Quantendaten herausarbeitet. Sie liefert außerdem eine Grundlage für die Diskussion, weshalb Quantenzustände nicht wie gewöhnliche Datensätze beliebig kopiert und zentral gesammelt werden können.
  • Mahdi Chehimi, Samuel Yen-Chi Chen, Walid Saad, Don Towsley und Mérouane Debbah: Foundations of Quantum Federated Learning Over Classical and Quantum Networks, IEEE Network, 2024.
    • Die Arbeit entwickelt eine umfassende konzeptionelle Grundlage für QFL über klassische und quantenbasierte Kommunikationsnetze. Sie behandelt Systemkomponenten, Sicherheitsmodelle, Netzwerktopologien und offene Forschungsfragen. In einer BCFL-Abhandlung kann sie dazu dienen, die Blockchain-Schicht von der quantenmechanischen Lern- und Kommunikationsschicht abzugrenzen. Besonders relevant ist die Unterscheidung zwischen klassisch übertragenen Modellparametern und quantenbasierten Kommunikationsverfahren.
  • Zhi-Ping Liu, Xiao-Yu Cao, Hao-Wen Liu, Xiao-Ran Sun, Yu Bao, Jian-Yu Shen, Yu-Shuo Lu, Hua-Lei Yin und Zeng-Bing Chen: Experimentally Validated Quantum-Secure Federated Learning over a Multi-User Quantum Network, Research, Band 9, Artikel 1299, 2026.
    • Diese experimentelle Arbeit untersucht ein Quantum-Federated-Learning-Protokoll, bei dem lokale Modellupdates mit verteilten Quantenschlüsseln maskiert werden. Die Validierung erfolgt in einem Netzwerk mit mehreren Quantenclients und wird durch Simulationen größerer Teilnehmerzahlen ergänzt. Für die Abhandlung ist die Quelle besonders geeignet, um zwischen Quantum Machine Learning, quantengesicherter Aggregation und klassischer Blockchain-Koordination zu unterscheiden. Sie zeigt zugleich, dass quantensichere Kommunikation auch ohne eine quantenbasierte Blockchain realisiert werden kann.
  • Dinh C. Nguyen, Md Raihan Uddin, Shaba Shaon, Ratun Rahman, Octavia Dobre und Dusit Niyato: Quantum Federated Learning: A Comprehensive Survey, arXiv, 2025.
    • Diese aktuelle Übersichtsarbeit ordnet QFL nach Föderationsarchitektur, Netzwerktopologie, Kommunikation, Optimierung, Sicherheit und Anwendungsgebiet. Da es sich um eine Vorabveröffentlichung handelt, sollte sie vor allem als Recherchehilfe zur Erschließung neuerer Literatur und nicht als alleinige Grundlage zentraler Behauptungen verwendet werden. Für die Abhandlung ist sie nützlich, um aktuelle Forschungsrichtungen zu erfassen und ältere QFL-Arbeiten in einen breiteren Zusammenhang einzuordnen.

Bücher und Monographien

Die Monographien dieses Abschnitts dienen der theoretischen Absicherung der Abhandlung. Sie erklären die Grundlagen von Quanteninformation, Quantum Machine Learning, Blockchain-Technologie, Kryptografie und Differential Privacy. Da BCFL mehrere Fachgebiete verbindet, sollte keine einzelne Monographie als vollständige Darstellung des Gesamtthemas verstanden werden. Ihr Wert liegt in der präzisen Behandlung der jeweiligen Teildisziplin.

Standardwerke zur Quanteninformation

  • Michael A. Nielsen und Isaac L. Chuang: Quantum Computation and Quantum Information, 10th Anniversary Edition, Cambridge University Press, 2010.
    • Dieses Standardwerk vermittelt die theoretischen Grundlagen von Qubits, Quantenschaltungen, Messungen, Quantenalgorithmen, Quantenkommunikation, Fehlerkorrektur und Kryptografie. In der Abhandlung sollte es für physikalische und mathematische Grundbegriffe herangezogen werden. Besonders wichtig ist es für die korrekte Erklärung von Quantenzuständen, No-Cloning-Theorem, Shor-Algorithmus und Grover-Algorithmus sowie für die Abgrenzung zwischen Quantencomputing und quantensicherer Kommunikation.
  • John Watrous: The Theory of Quantum Information, Cambridge University Press, 2018.
    • Watrous bietet eine mathematisch präzise Darstellung von Quantenzuständen, Quantenkanälen, Messungen, Entropie und Informationsmaßen. Die Monographie eignet sich besonders für anspruchsvollere Passagen über Quantendaten und Quantenkommunikation. Sie kann außerdem verwendet werden, um weitreichende Sicherheits- oder Leistungsaussagen über QFL auf eine saubere informations-theoretische Grundlage zu stellen.

Standardwerke zu Quantum Machine Learning

  • Maria Schuld und Francesco Petruccione: Machine Learning with Quantum Computers, 2. Auflage, Springer, 2021.
    • Das Werk behandelt datengetriebene Quantenalgorithmen, Datenkodierung, parametrisierte Quantenschaltungen, Quanten-Kernel, Quantum Neural Networks und hybride Optimierung. Es ist die wichtigste Monographie für die methodische Einordnung quantenbasierter Lernmodelle innerhalb einer BCFL-Architektur. Die Quelle hilft insbesondere dabei, den quantenmechanischen Modellanteil von der klassischen Aggregations- und Blockchain-Infrastruktur zu trennen.

Hintergrundliteratur zu Blockchain, Datenschutz und Kryptografie

  • Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller und Steven Goldfeder: Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction, Princeton University Press, 2016.
    • Die Monographie erklärt kryptografische Hashfunktionen, digitale Signaturen, Konsens, verteilte Register und die Sicherheitsannahmen öffentlicher Blockchains. Obwohl der Schwerpunkt auf Bitcoin liegt, bietet sie eine belastbare Grundlage zur Erklärung der technischen Blockchain-Bausteine. Für BCFL sollte sie vor allem als Hintergrundliteratur genutzt werden, nicht als Beleg dafür, dass eine öffentliche Kryptowährungs-Blockchain für institutionelles Federated Learning geeignet wäre.
  • Cynthia Dwork und Aaron Roth: The Algorithmic Foundations of Differential Privacy, Foundations and Trends in Theoretical Computer Science, Band 9, Ausgaben 3–4, 2014.
    • Diese Monographie stellt die mathematischen Grundlagen von Differential Privacy und die Bedeutung des Datenschutzbudgets dar. Sie ist für die Abhandlung unverzichtbar, wenn Differential Privacy als ergänzender Schutzmechanismus von BCFL erläutert wird. Die Quelle verdeutlicht, dass Datenschutzgarantien aus einem definierten randomisierten Verfahren entstehen und nicht aus der bloßen Verwendung einer Blockchain.
  • Dylan Yaga, Peter Mell, Nik Roby und Karen Scarfone: Blockchain Technology Overview, NIST Internal Report 8202, National Institute of Standards and Technology, 2018.
    • Der technische Bericht bietet eine sachliche und anbieterunabhängige Einführung in Blockchain-Strukturen, Hashverkettung, digitale Signaturen, Konsensmodelle, Smart Contracts und Oracles. Für die Abhandlung ist er besonders geeignet, um Begriffe wie Manipulationserkennbarkeit und Manipulationsresistenz präziser zu verwenden als die häufig missverständliche Behauptung vollständiger Unveränderlichkeit. Er unterstützt außerdem die Entscheidung, wann eine Blockchain technisch gerechtfertigt ist.

Vorlesungsnotizen und Monographie-nahe Ressourcen

  • John Watrous: Understanding Quantum Information and Computation, Vorlesungsreihe und begleitende Manuskripte, 2025.
    • Die Ressource verbindet schriftliche Lektionen mit einer strukturierten Einführung in Quanteninformation, Quantenalgorithmen, Quantenkanäle und Fehlerkorrektur. Sie eignet sich als ergänzende Lernquelle zur Vertiefung einzelner Begriffe und zur Überprüfung einer verständlichen Darstellung. Für zentrale wissenschaftliche Aussagen sollten weiterhin die zugehörige Fachliteratur und veröffentlichte Monographien bevorzugt werden.

Online-Ressourcen und Datenbanken

Online-Ressourcen dienen vor allem der gezielten Literaturrecherche, der Überprüfung technischer Standards und der praktischen Erprobung von Federated-Learning-, Blockchain- und Quantum-Machine-Learning-Komponenten. Produktdokumentationen sollten nicht als Ersatz für begutachtete Primärliteratur verwendet werden. Sie sind jedoch unverzichtbar, wenn konkrete Softwarestände, Programmierschnittstellen, kryptografische Standards oder reproduzierbare Implementierungen beschrieben werden.

Fachjournale und Verlage

  • Institute of Electrical and Electronics Engineers: IEEE Xplore Digital Library, wissenschaftliche Literaturdatenbank, laufend aktualisiert.
    • IEEE Xplore ist eine zentrale Recherchequelle für Veröffentlichungen zu Federated Learning, Blockchain, Quantencomputing, Kommunikationsnetzen, Edge Computing und Cybersicherheit. Für die Abhandlung sollte die Plattform zur Suche nach begutachteten Journal- und Konferenzbeiträgen sowie zur Kontrolle von DOI, Erscheinungsjahr und Publikationsstatus genutzt werden.
  • Association for Computing Machinery: ACM Digital Library, wissenschaftliche Literaturdatenbank, laufend aktualisiert.
    • Die ACM Digital Library bietet hochwertige Literatur zu maschinellem Lernen, verteilten Systemen, Smart Contracts, Datenschutz und Softwaresicherheit. Besonders relevant sind ACM Computing Surveys und die Proceedings führender Sicherheitskonferenzen. Die Plattform sollte für bibliografische Prüfung und die Suche nach systematischen Übersichtsarbeiten eingesetzt werden.
  • Springer Nature: SpringerLink, wissenschaftliche Publikations- und Literaturplattform, laufend aktualisiert.
    • SpringerLink erschließt Fachzeitschriften, Konferenzbände und Monographien zu künstlicher Intelligenz, Blockchain, Kryptografie und Quanteninformation. Für die Abhandlung eignet sich die Plattform insbesondere zur Suche nach systematischen Reviews und zur Überprüfung veröffentlichter Journal-Versionen von zuvor auf arXiv erschienenen Arbeiten.
  • Proceedings of Machine Learning Research: PMLR, frei zugängliches Publikationsarchiv, laufend aktualisiert.
    • PMLR veröffentlicht begutachtete Beiträge bedeutender Konferenzen des maschinellen Lernens. Die Plattform ist besonders wichtig für grundlegende Arbeiten zu Federated Learning, verteilter Optimierung und Kommunikationsreduktion. Sie bietet häufig frei zugängliche Volltexte und verlässliche bibliografische Angaben.
  • Cornell University: arXiv, wissenschaftliches Preprint-Archiv, laufend aktualisiert.
    • arXiv ist für BCFL und QFL besonders wichtig, weil neue Forschung häufig vor der formalen Journal-Veröffentlichung verfügbar wird. Preprints müssen jedoch klar als nicht oder noch nicht begutachtete Fassungen gekennzeichnet werden. Vor einer Verwendung sollte geprüft werden, ob inzwischen eine Journal- oder Konferenzversion mit eigener DOI erschienen ist.

Kryptografische Standards und Post-Quanten-Sicherheit

  • National Institute of Standards and Technology: Post-Quantum Cryptography Project, Standardisierungs- und Informationsplattform, laufend aktualisiert.
    • Die NIST-Plattform dokumentiert die Auswahl, Standardisierung und Weiterentwicklung post-quanten-sicherer Kryptografie. Für BCFL ist sie die maßgebliche Recherchequelle zur Absicherung digitaler Identitäten, Modellupdate-Signaturen und Schlüsselaustauschverfahren gegen zukünftige Quantenangriffe. Sie sollte gegenüber Herstellerblogs oder spekulativen Darstellungen bevorzugt werden.
  • National Institute of Standards and Technology: FIPS 203 – Module-Lattice-Based Key-Encapsulation Mechanism Standard, 2024.
    • FIPS 203 standardisiert ML-KEM für die Einrichtung gemeinsamer geheimer Schlüssel über öffentliche Kommunikationskanäle. Die Quelle ist für die Abhandlung relevant, wenn eine krypto-agile oder post-quanten-sichere Kommunikation zwischen BCFL-Teilnehmern beschrieben wird. ML-KEM ist ein Schlüsselkapselungsverfahren und keine digitale Signatur.
  • National Institute of Standards and Technology: FIPS 204 – Module-Lattice-Based Digital Signature Standard, 2024.
    • FIPS 204 standardisiert ML-DSA als post-quanten-sicheres digitales Signaturverfahren. Für BCFL ist der Standard besonders wichtig, weil Teilnehmeridentitäten, Modellupdates, Smart-Contract-Transaktionen und Governance-Entscheidungen langfristig authentifizierbar bleiben müssen. Die Quelle kann für die Diskussion größerer Schlüssel und Signaturen sowie ihrer Auswirkungen auf Blockchain-Speicher und Transaktionsgröße verwendet werden.
  • National Institute of Standards and Technology: FIPS 205 – Stateless Hash-Based Digital Signature Standard, 2024.
    • FIPS 205 standardisiert SLH-DSA als zustandsloses hashbasiertes Signaturverfahren. Der Standard stellt eine kryptografisch anders begründete Alternative zu gitterbasierten Signaturen bereit. In der Abhandlung eignet er sich zur Erklärung von Krypto-Agilität und zur Begründung, weshalb langfristige BCFL-Systeme mehrere austauschbare Signaturfamilien unterstützen sollten.

Lern- und Forschungsplattformen

  • Hyperledger Foundation: Hyperledger Fabric Documentation, Dokumentation für permissioned Distributed-Ledger-Systeme, laufend aktualisiert.
    • Hyperledger Fabric ist für institutionelle BCFL-Prototypen relevant, weil es bekannte Teilnehmer, kontrollierte Mitgliedschaft, modulare Konsens- und Berechtigungsmodelle sowie private Datenstrukturen unterstützt. Die Dokumentation kann für die technische Beschreibung von Kanälen, Identitäten, Ledgern und Chaincode genutzt werden. Sie ist eine Implementierungsquelle und ersetzt keine unabhängige Bewertung der Sicherheit oder Eignung einer konkreten Architektur.
  • Flower Labs: Flower Framework Documentation, Entwicklungsplattform für Federated Learning, laufend aktualisiert.
    • Flower ermöglicht die Umsetzung und Simulation föderierter Lernsysteme mit unterschiedlichen Machine-Learning-Frameworks. Die Plattform eignet sich zur prototypischen Trennung von Client, Koordinator, Aggregationsstrategie und Nachrichtenübertragung. Für BCFL-Experimente kann sie als Lernschicht dienen, während die Blockchain- und Identitätsfunktionen separat integriert werden.
  • Google: TensorFlow Federated Documentation, Framework für Berechnungen auf dezentralen Daten, laufend aktualisiert.
    • TensorFlow Federated stellt Abstraktionen für föderiertes Training, Evaluation und verteilte Berechnungen bereit. Es eignet sich zur Untersuchung von Federated Averaging, nicht identisch verteilten Daten und Differential Privacy. In einer wissenschaftlichen Abhandlung kann die Plattform als Grundlage reproduzierbarer Simulationen und zur technischen Veranschaulichung des klassischen FL-Anteils verwendet werden.
  • Xanadu: PennyLane Documentation, Plattform für Quantum Machine Learning und hybride Quantenberechnungen, laufend aktualisiert.
    • PennyLane unterstützt parametrisierte Quantenschaltungen, automatische Differentiation, hybride Optimierung und die Anbindung verschiedener Simulatoren und Quantenhardware-Plattformen. Für die Abhandlung ist die Dokumentation hilfreich, um den Aufbau eines lokalen QFL-Clients oder einer hybriden Quantenschicht technisch nachzuvollziehen. Ergebnisse aus Demonstrationen sollten immer getrennt von Nachweisen eines praktischen Quantenvorteils bewertet werden.
  • IBM Quantum: Qiskit und IBM Quantum Documentation, Entwicklungs- und Forschungsplattform für Quantencomputing, laufend aktualisiert.
    • Die Plattform stellt Werkzeuge für Quantenschaltungen, Simulation, Transpilation, Messung und den Zugriff auf reale Quantenhardware bereit. Für QFL- und BCFL-Prototypen kann sie zur Ausführung lokaler Quantenmodelle und zur Erfassung hardwarebezogener Metadaten verwendet werden. Da Programmierschnittstellen und Hardwareangebote fortlaufend verändert werden, muss bei reproduzierbaren Experimenten immer der konkrete Software- und Backend-Stand dokumentiert werden.
National Quantum Initiative Act (NQIA)

National Quantum Initiative Act (NQIA)

...

Bosonische Qubits

Bosonische Qubits

...

Argonne National Laboratory (ANL)

Argonne National Laboratory (ANL)

...

Anti-Pion

Anti-Pion

...

Mediator-Qubits

Mediator-Qubits

...

Anti-Up-Squark

Anti-Up-Squark

...