Ein Post getaggt mit "dezentrales Computing"

Einführung​

Dezentrale KI-Inferenz-/Trainingsmärkte zielen darauf ab, globale Rechenressourcen und Community-Modelle auf vertrauenslose Weise zu nutzen. Projekte wie Bittensor, Gensyn und Cuckoo Network (Cuckoo AI) veranschaulichen, wie Blockchain-Technologie offene KI-Marktplätze antreiben kann. Jede Plattform tokenisiert wichtige KI-Assets – Rechenleistung, Machine-Learning-Modelle und manchmal auch Daten – in On-Chain-Wirtschaftseinheiten. Im Folgenden gehen wir auf die technischen Architekturen dieser Netzwerke ein, wie sie Ressourcen tokenisieren, ihre Governance- und Anreizstrukturen, Methoden zur Verfolgung des Modelleigentums, Umsatzbeteiligungsmechanismen und die Angriffsflächen (z. B. Sybil-Angriffe, Kollusion, Trittbrettfahren, Vergiftung), die dabei entstehen. Eine vergleichende Tabelle am Ende fasst alle wichtigen Dimensionen von Bittensor, Gensyn und Cuckoo AI zusammen.

Technische Architekturen​

Bittensor: Dezentrales „Neuronales Internet“ auf Subnetzen​

Bittensor basiert auf einer benutzerdefinierten Layer-1-Blockchain (der Subtensor-Kette, basierend auf Substrate), die ein Netzwerk von KI-Modellknoten über viele spezialisierte Subnetze koordiniert. Jedes Subnetz ist ein unabhängiges Mini-Netzwerk, das sich auf eine bestimmte KI-Aufgabe konzentriert (zum Beispiel ein Subnetz für Sprachgenerierung, ein anderes für Bildgenerierung usw.). Die Teilnehmer in Bittensor übernehmen unterschiedliche Rollen:

• Miner – Sie betreiben Machine-Learning-Modelle auf ihrer Hardware und liefern Inferenzantworten (oder führen sogar Trainings durch) für die Aufgabe des Subnetzes. Im Wesentlichen ist ein Miner ein Knoten, der ein KI-Modell hostet, das Anfragen beantwortet.
• Validatoren – Sie fragen die Modelle der Miner mit Prompts ab und bewerten die Qualität der Antworten, um eine Meinung darüber zu bilden, welche Miner wertvolle Ergebnisse liefern. Validatoren bewerten effektiv die Leistung der Miner.
• Subnetz-Besitzer – Sie erstellen und definieren Subnetze und legen die Regeln fest, welche Aufgaben erledigt werden und wie die Validierung in diesem Subnetz durchgeführt wird. Ein Subnetz-Besitzer könnte zum Beispiel festlegen, dass ein Subnetz für einen bestimmten Datensatz oder eine bestimmte Modalität bestimmt ist und das Validierungsverfahren definieren.
• Delegatoren – Token-Inhaber, die keine Knoten betreiben, können ihre Bittensor-Tokens (TAO) an Miner oder Validatoren delegieren (staken), um die besten Performer zu unterstützen und einen Anteil an den Belohnungen zu verdienen (ähnlich dem Staking in Proof-of-Stake-Netzwerken).

Der Konsensmechanismus von Bittensor ist neuartig: Anstelle der traditionellen Blockvalidierung verwendet Bittensor den Yuma-Konsens, eine Form des „Proof-of-Intelligence“. Im Yuma-Konsens werden die Bewertungen der Miner durch Validatoren On-Chain aggregiert, um die Belohnungsverteilung zu bestimmen. Alle 12 Sekunden prägt das Netzwerk neue TAO-Tokens und verteilt sie gemäß dem Konsens der Validatoren darüber, welche Miner nützliche Arbeit geleistet haben. Die Bewertungen der Validatoren werden in einem stake-gewichteten Median-Schema kombiniert: Ausreißermeinungen werden beschnitten und die ehrliche Mehrheitsmeinung setzt sich durch. Das bedeutet, wenn die meisten Validatoren zustimmen, dass ein Miner qualitativ hochwertig war, erhält dieser Miner eine hohe Belohnung; weicht ein Validator stark von anderen ab (möglicherweise aufgrund von Kollusion oder Fehler), wird dieser Validator bestraft, indem er weniger verdient. Auf diese Weise koordiniert die Blockchain von Bittensor eine Miner-Validator-Feedbackschleife: Miner konkurrieren darum, die besten KI-Outputs zu produzieren, und Validatoren kuratieren und bewerten diese Outputs, wobei beide Seiten Tokens proportional zum von ihnen hinzugefügten Wert verdienen. Diese Architektur wird oft als „dezentrales neuronales Netzwerk“ oder „globales Gehirn“ beschrieben, in dem Modelle voneinander lernen und sich kollektiv entwickeln. Bemerkenswert ist, dass Bittensor kürzlich seine Kette aktualisiert hat, um EVM-Kompatibilität (für Smart Contracts) zu unterstützen, und dTAO eingeführt hat, ein System von Subnetz-spezifischen Tokens und Staking (später erklärt), um die Kontrolle über die Ressourcenzuweisung weiter zu dezentralisieren.

Gensyn: Vertrauensloses verteiltes Rechenprotokoll​

Gensyn nähert sich dezentraler KI aus dem Blickwinkel eines verteilten Rechenprotokolls für Machine Learning. Seine Architektur verbindet Entwickler (Submitter), die KI-Aufgaben haben (wie das Trainieren eines Modells oder das Ausführen eines Inferenz-Jobs), mit Rechenanbietern (Solver) weltweit, die über freie GPU-/TPU-Ressourcen verfügen. Ursprünglich plante Gensyn eine Substrate L1-Kette, schwenkte aber auf den Bau auf Ethereum als Rollup um, um stärkere Sicherheit und Liquidität zu gewährleisten. Das Gensyn-Netzwerk ist somit ein Ethereum Layer-2 (ein Ethereum-Rollup), das Job-Anzeigen und Zahlungen koordiniert, während die Berechnung Off-Chain auf der Hardware der Anbieter stattfindet.

Eine Kerninnovation des Gensyn-Designs ist sein Verifizierungssystem für Off-Chain-Arbeit. Gensyn verwendet eine Kombination aus optimistischer Verifizierung (Fraud Proofs) und kryptografischen Techniken, um sicherzustellen, dass das Ergebnis korrekt ist, wenn ein Solver behauptet, eine Trainings-/Inferenzaufgabe ausgeführt zu haben. In der Praxis umfasst das Protokoll mehrere Teilnehmerrollen:

• Submitter – die Partei, die einen Job anfordert (zum Beispiel jemand, der ein Modell trainieren lassen muss). Sie zahlen die Netzwerkgebühr und stellen das Modell/die Daten oder die Spezifikation der Aufgabe bereit.
• Solver – ein Knoten, der für die ML-Aufgabe auf seiner Hardware bietet und diese ausführt. Er trainiert das Modell oder führt die Inferenz wie angefordert aus und übermittelt dann die Ergebnisse und einen Berechnungsnachweis.
• Verifier/Challenger – Knoten, die die Arbeit des Solvers prüfen oder stichprobenartig überprüfen können. Gensyn implementiert ein Truebit-ähnliches Schema, bei dem das Ergebnis eines Solvers standardmäßig akzeptiert wird, ein Verifier es jedoch innerhalb eines Zeitfensters anfechten kann, wenn er eine falsche Berechnung vermutet. Bei einer Anfechtung wird eine interaktive „binäre Suche“ durch die Berechnungsschritte (ein Fraud-Proof-Protokoll) verwendet, um jede Diskrepanz zu lokalisieren. Dies ermöglicht es der Kette, Streitigkeiten zu lösen, indem nur ein minimaler kritischer Teil der Berechnung On-Chain durchgeführt wird, anstatt die gesamte teure Aufgabe zu wiederholen.

Entscheidend ist, dass Gensyn so konzipiert ist, dass die massive Redundanz naiver Ansätze vermieden wird. Anstatt dass viele Knoten alle denselben ML-Job wiederholen (was Kosteneinsparungen zunichte machen würde), verwendet Gensyns „Proof-of-Learning“-Ansatz Trainingsmetadaten, um zu überprüfen, ob Lernfortschritte erzielt wurden. Zum Beispiel könnte ein Solver kryptografische Hashes oder Checkpoints von Zwischenmodellgewichten und einen prägnanten Nachweis liefern, dass diese gemäß den Trainingsaktualisierungen fortgeschritten sind. Dieser probabilistische Proof-of-Learning kann viel kostengünstiger überprüft werden als das erneute Ausführen des gesamten Trainings, was eine vertrauenslose Verifizierung ohne vollständige Replikation ermöglicht. Nur wenn ein Verifier eine Anomalie feststellt, würde als letztes Mittel eine aufwändigere On-Chain-Berechnung ausgelöst. Dieser Ansatz reduziert den Overhead im Vergleich zur Brute-Force-Verifizierung drastisch, wodurch dezentrales ML-Training praktikabler wird. Gensyns Architektur betont daher stark das kryptoökonomische Spieldesign: Solver hinterlegen einen Stake oder eine Anleihe, und wenn sie betrügen (falsche Ergebnisse einreichen), verlieren sie diesen Stake an ehrliche Verifier, die sie erwischen. Durch die Kombination von Blockchain-Koordination (für Zahlungen und Streitbeilegung) mit Off-Chain-Compute und cleverer Verifizierung schafft Gensyn einen Marktplatz für ML-Compute, der ungenutzte GPUs überall nutzen kann, während die Vertrauenslosigkeit erhalten bleibt. Das Ergebnis ist ein Hyperscale-„Compute-Protokoll“, bei dem jeder Entwickler bei Bedarf auf erschwingliche, global verteilte Trainingsleistung zugreifen kann.

Cuckoo AI: Full-Stack dezentrale KI-Serviceplattform​

Cuckoo Network (oder Cuckoo AI) verfolgt einen stärker vertikal integrierten Ansatz und zielt darauf ab, End-to-End dezentrale KI-Dienste anstatt nur rohe Rechenleistung bereitzustellen. Cuckoo baute seine eigene Blockchain (ursprünglich eine Layer-1 namens Cuckoo Chain auf Arbitrum Orbit, einem Ethereum-kompatiblen Rollup-Framework), um alles zu orchestrieren: Sie gleicht nicht nur Jobs mit GPUs ab, sondern hostet auch KI-Anwendungen und wickelt Zahlungen in einem System ab. Das Design ist Full-Stack: Es kombiniert eine Blockchain für Transaktionen und Governance, eine dezentrale GPU-/CPU-Ressourcenschicht und benutzerorientierte KI-Anwendungen und APIs darüber. Mit anderen Worten, Cuckoo integriert alle drei Schichten – Blockchain, Compute und KI-Anwendung – innerhalb einer einzigen Plattform.

Die Teilnehmer in Cuckoo lassen sich in vier Gruppen einteilen:

• KI-App-Entwickler (Koordinatoren) – Dies sind Entwickler, die KI-Modelle oder -Dienste auf Cuckoo bereitstellen. Zum Beispiel könnte ein Entwickler einen Stable Diffusion Bildgenerator oder einen LLM-Chatbot als Dienst hosten. Sie betreiben Koordinator-Knoten, die für die Verwaltung ihres Dienstes verantwortlich sind: Benutzeranfragen annehmen, diese in Aufgaben aufteilen und diese Aufgaben den Minern zuweisen. Koordinatoren staken den nativen Token ($CAI), um dem Netzwerk beizutreten und das Recht zu erhalten, Miner zu nutzen. Sie fungieren im Wesentlichen als Layer-2-Orchestratoren, die zwischen Benutzern und den GPU-Anbietern vermitteln.
• GPU-/CPU-Miner (Aufgabenknoten) – Dies sind die Ressourcenanbieter. Miner betreiben den Cuckoo-Aufgabenclient und stellen ihre Hardware zur Verfügung, um Inferenzaufgaben für die KI-Apps auszuführen. Zum Beispiel könnte einem Miner von einem Koordinator eine Bildgenerierungsanfrage (mit einem bestimmten Modell und Prompt) zugewiesen werden, und er verwendet seine GPU, um das Ergebnis zu berechnen. Miner müssen ebenfalls $CAI staken, um Engagement und gutes Verhalten zu gewährleisten. Sie verdienen Token-Belohnungen für jede korrekt abgeschlossene Aufgabe.
• Endbenutzer – die Konsumenten der KI-Anwendungen. Sie interagieren über Cuckoos Webportal oder APIs (zum Beispiel Kunst generieren über CooVerse oder mit KI-Persönlichkeiten chatten). Benutzer können entweder mit Krypto für jede Nutzung bezahlen oder möglicherweise ihre eigene Rechenleistung (oder ihren Stake) beisteuern, um die Nutzungskosten auszugleichen. Ein wichtiger Aspekt ist die Zensurresistenz: Wenn ein Koordinator (Dienstanbieter) blockiert wird oder ausfällt, können Benutzer zu einem anderen wechseln, der dieselbe Anwendung bereitstellt, da mehrere Koordinatoren ähnliche Modelle im dezentralen Netzwerk hosten könnten.
• Staker (Delegatoren) – Community-Mitglieder, die keine KI-Dienste oder Mining-Hardware betreiben, können dennoch teilnehmen, indem sie $CAI auf diejenigen staken, die dies tun. Indem sie mit ihrem Stake auf vertrauenswürdige Koordinatoren oder Miner stimmen, helfen sie, Reputation zu signalisieren und verdienen im Gegenzug einen Anteil an den Netzwerkbelohnungen. Dieses Design baut eine Web3-Reputationsschicht auf: Gute Akteure ziehen mehr Stake an (und damit Vertrauen und Belohnungen), während schlechte Akteure Stake und Reputation verlieren. Sogar Endbenutzer können in einigen Fällen staken, wodurch sie mit dem Erfolg des Netzwerks in Einklang gebracht werden.

Die Cuckoo-Kette (die sich derzeit im Übergang von einer eigenständigen Kette zu einem Shared-Security-Rollup befindet) verfolgt all diese Interaktionen. Wenn ein Benutzer einen KI-Dienst aufruft, erstellt der Koordinator-Knoten On-Chain-Aufgabenzuweisungen für Miner. Die Miner führen die Aufgaben Off-Chain aus und senden die Ergebnisse an den Koordinator zurück, der sie validiert (z. B. überprüft, ob das Ausgabebild oder der Text kein Kauderwelsch ist) und das Endergebnis an den Benutzer liefert. Die Blockchain wickelt die Zahlungsabwicklung ab: Für jede Aufgabe zahlt der Smart Contract des Koordinators den Miner in $CAI (oft werden Mikrozahlungen zu täglichen Auszahlungen aggregiert). Cuckoo betont Vertrauenslosigkeit und Transparenz – alle Teilnehmer staken Tokens und alle Aufgabenzuweisungen und -abschlüsse werden aufgezeichnet, sodass Betrug durch die Androhung des Verlusts des Stakes und durch die öffentliche Sichtbarkeit der Leistung entmutigt wird. Das modulare Design des Netzwerks bedeutet, dass neue KI-Modelle oder Anwendungsfälle einfach hinzugefügt werden können: Obwohl es mit der Text-zu-Bild-Generierung als Proof of Concept begann, ist seine Architektur allgemein genug, um andere KI-Workloads (z. B. Sprachmodell-Inferenz, Audiotranskription usw.) zu unterstützen.

Ein bemerkenswerter Aspekt der Cuckoo-Architektur ist, dass sie ursprünglich eine eigene Layer-1-Blockchain startete, um den Durchsatz für KI-Transaktionen zu maximieren (während der Tests erreichte sie Spitzenwerte von 300.000 täglichen Transaktionen). Dies ermöglichte benutzerdefinierte Optimierungen für die KI-Aufgabenplanung. Das Team stellte jedoch fest, dass die Wartung einer eigenständigen L1 kostspielig und komplex war, und beschloss Mitte 2025, die benutzerdefinierte Kette einzustellen und zu einem Rollup-/AVS-Modell (Active Validated Service) auf Ethereum zu migrieren. Dies bedeutet, dass Cuckoo die Sicherheit von Ethereum oder einem L2 wie Arbitrum erben wird, anstatt einen eigenen Konsens zu betreiben, aber seinen dezentralen KI-Marktplatz auf dieser gemeinsamen Sicherheitsschicht weiter betreiben wird. Die Änderung soll die wirtschaftliche Sicherheit verbessern (durch Nutzung der Robustheit von Ethereum) und dem Cuckoo-Team ermöglichen, sich auf das Produkt statt auf die Wartung der Low-Level-Kette zu konzentrieren. Zusammenfassend schafft Cuckoos Architektur eine dezentrale KI-Bereitstellungsplattform, auf der jeder Hardware anschließen oder einen KI-Modell-Dienst bereitstellen kann und Benutzer weltweit auf KI-Apps mit geringeren Kosten und weniger Abhängigkeit von der Big-Tech-Infrastruktur zugreifen können.

Mechanismen zur Asset-Tokenisierung​

Ein gemeinsames Thema dieser Netzwerke ist die Umwandlung von Rechenleistung, Modellen und Daten in On-Chain-Assets oder Wirtschaftseinheiten, die gehandelt oder monetarisiert werden können. Jedes Projekt konzentriert sich jedoch auf unterschiedliche Weisen der Tokenisierung dieser Ressourcen:

• Rechenleistung: Alle drei Plattformen wandeln Rechenarbeit in Belohnungs-Tokens um. In Bittensor wird nützliche Berechnung (Inferenz oder Training durch einen Miner) über Validatoren-Scores quantifiziert und mit TAO-Tokens pro Block belohnt. Im Wesentlichen „misst“ Bittensor die beigesteuerte Intelligenz und prägt TAO als Ware, die diesen Beitrag repräsentiert. Gensyn behandelt Rechenleistung explizit als Ware – sein Protokoll schafft einen Marktplatz, auf dem GPU-Zeit das Produkt ist und der Preis durch Angebot und Nachfrage in Token-Begriffen festgelegt wird. Entwickler kaufen Rechenleistung mit dem Token, und Anbieter verdienen Tokens, indem sie ihre Hardware-Zyklen verkaufen. Das Gensyn-Team bemerkt, dass jede digitale Ressource (Rechenleistung, Daten, Algorithmen) in einem ähnlichen vertrauenslosen Markt dargestellt und gehandelt werden kann. Cuckoo tokenisiert Rechenleistung über einen ERC-20-Token $CAI, der als Zahlung für abgeschlossene Aufgaben ausgegeben wird. GPU-Anbieter „minen“ im Wesentlichen CAI, indem sie KI-Inferenzarbeit leisten. Cuckoos System erstellt On-Chain-Aufzeichnungen von Aufgaben, sodass man jede abgeschlossene GPU-Aufgabe als eine atomare Arbeitseinheit betrachten kann, die in Tokens bezahlt wird. Die Prämisse bei allen dreien ist, dass ansonsten ungenutzte oder unzugängliche Rechenleistung zu einem tokenisierten, liquiden Asset wird – entweder durch Token-Emissionen auf Protokollebene (wie bei Bittensor und frühem Cuckoo) oder durch einen offenen Markt von Kauf-/Verkaufsaufträgen für Rechenjobs (wie bei Gensyn).

• KI-Modelle: Die Darstellung von KI-Modellen als On-Chain-Assets (z. B. NFTs oder Tokens) steckt noch in den Kinderschuhen. Bittensor tokenisiert die Modelle selbst nicht – die Modelle bleiben Off-Chain im Besitz der Miner. Stattdessen bewertet Bittensor Modelle indirekt, indem es diejenigen belohnt, die gut funktionieren. Im Grunde wird die „Intelligenz“ eines Modells in TAO-Einnahmen umgewandelt, aber es gibt kein NFT, das die Modellgewichte repräsentiert oder anderen die Nutzung des Modells erlaubt. Gensyns Fokus liegt auf Rechen-Transaktionen, nicht explizit auf der Erstellung von Tokens für Modelle. Ein Modell in Gensyn wird typischerweise von einem Entwickler Off-Chain bereitgestellt (vielleicht Open-Source oder proprietär), von Solvern trainiert und zurückgegeben – es gibt keinen eingebauten Mechanismus, um einen Token zu erstellen, der das Modell oder sein IP besitzt. (Allerdings könnte der Gensyn-Marktplatz potenziell den Handel mit Modellartefakten oder Checkpoints erleichtern, wenn die Parteien dies wünschen, aber das Protokoll selbst betrachtet Modelle als Inhalt der Berechnung und nicht als tokenisiertes Asset.) Cuckoo liegt irgendwo dazwischen: Es spricht von „KI-Agenten“ und in das Netzwerk integrierten Modellen, aber derzeit gibt es keinen nicht-fungiblen Token, der jedes Modell repräsentiert. Stattdessen wird ein Modell von einem App-Entwickler bereitgestellt und dann über das Netzwerk bedient. Die Nutzungsrechte an diesem Modell sind implizit tokenisiert, da das Modell $CAI verdienen kann, wenn es verwendet wird (über den Koordinator, der es bereitstellt). Alle drei Plattformen erkennen das Konzept der Modell-Tokenisierung an – zum Beispiel, Gemeinschaften über Tokens Eigentum an Modellen zu geben – aber praktische Implementierungen sind begrenzt. Als Branche wird die Tokenisierung von KI-Modellen (z. B. als NFTs mit Eigentumsrechten und Gewinnbeteiligung) noch erforscht. Bittensors Ansatz, bei dem Modelle Werte miteinander austauschen, ist eine Form eines „Modell-Marktplatzes“ ohne expliziten Token pro Modell. Das Cuckoo-Team merkt an, dass dezentrales Modelleigentum vielversprechend ist, um Barrieren im Vergleich zu zentralisierter KI abzubauen, aber es erfordert effektive Methoden zur Überprüfung von Modellausgaben und -nutzung On-Chain. Zusammenfassend lässt sich sagen, dass Rechenleistung sofort tokenisiert wird (es ist unkompliziert, Tokens für geleistete Arbeit zu bezahlen), während Modelle indirekt oder aspirativ tokenisiert werden (für ihre Outputs belohnt, möglicherweise durch Stake oder Reputation repräsentiert, aber auf diesen Plattformen noch nicht als übertragbare NFTs behandelt werden).

• Daten: Die Daten-Tokenisierung bleibt am schwierigsten. Keines der Projekte Bittensor, Gensyn oder Cuckoo hat vollständig verallgemeinerte On-Chain-Datenmarktplätze integriert (wo Datensätze mit durchsetzbaren Nutzungsrechten gehandelt werden). Bittensor-Knoten könnten auf verschiedenen Datensätzen trainieren, aber diese Datensätze sind nicht Teil des On-Chain-Systems. Gensyn könnte einem Entwickler erlauben, einen Datensatz für das Training bereitzustellen, aber das Protokoll tokenisiert diese Daten nicht – sie werden einfach Off-Chain für den Solver bereitgestellt. Cuckoo tokenisiert ebenfalls keine Benutzerdaten; es verarbeitet Daten (wie Benutzer-Prompts oder Outputs) hauptsächlich transient für Inferenzaufgaben. Der Cuckoo-Blog stellt explizit fest, dass „dezentrale Daten trotz ihrer kritischen Bedeutung schwer zu tokenisieren bleiben“. Daten sind sensibel (Datenschutz- und Eigentumsfragen) und mit der aktuellen Blockchain-Technologie schwer zu handhaben. Während Rechenleistung und Modelle zunehmend zu Commodities werden, bleiben Daten weitgehend Off-Chain, außer in Sonderfällen (einige Projekte außerhalb dieser drei experimentieren mit Daten-Unions und Token-Belohnungen für Datenbeiträge, aber das liegt außerhalb unseres aktuellen Umfangs). Zusammenfassend lässt sich sagen, dass Rechenleistung in diesen Netzwerken jetzt eine On-Chain-Ware ist, Modelle durch Tokens bewertet, aber noch nicht individuell als Assets tokenisiert werden, und die Daten-Tokenisierung immer noch ein offenes Problem ist (abgesehen von der Anerkennung ihrer Bedeutung).

Governance und Anreize​

Ein robustes Governance- und Anreizdesign ist entscheidend, damit diese dezentralen KI-Netzwerke autonom und fair funktionieren können. Hier untersuchen wir, wie sich jede Plattform selbst regiert (wer Entscheidungen trifft, wie Upgrades oder Parameteränderungen erfolgen) und wie sie die Anreize der Teilnehmer durch Token-Ökonomie aufeinander abstimmt.

• Bittensor Governance: In seinen frühen Phasen wurden Bittensors Entwicklung und Subnetzparameter weitgehend vom Kernteam und einer Gruppe von 64 „Root“-Validatoren im Haupt-Subnetz kontrolliert. Dies war ein Punkt der Zentralisierung – einige mächtige Validatoren hatten einen überproportionalen Einfluss auf die Belohnungszuweisungen, was zu dem führte, was einige als „oligarchisches Wahlsystem“ bezeichneten. Um dies zu beheben, führte Bittensor 2025 die dTAO (dezentrale TAO)-Governance ein. Das dTAO-System verlagerte die Ressourcenzuweisung auf eine marktorientierte und gemeinschaftlich kontrollierte Basis. Konkret können TAO-Inhaber ihre Tokens in Subnetz-spezifische Liquiditätspools staken (im Wesentlichen „stimmen“ sie darüber ab, welche Subnetze mehr Netzwerkemissionen erhalten sollen) und erhalten Alpha-Tokens, die das Eigentum an diesen Subnetz-Pools repräsentieren. Subnetze, die mehr Stake anziehen, werden einen höheren Alpha-Token-Preis haben und einen größeren Anteil an der täglichen TAO-Emission erhalten, während unpopuläre oder leistungsschwache Subnetze Kapital (und damit Emissionen) abfließen sehen werden. Dies schafft eine Rückkopplungsschleife: Wenn ein Subnetz wertvolle KI-Dienste produziert, staken mehr Leute TAO darauf (auf der Suche nach Belohnungen), was diesem Subnetz mehr TAO gibt, um seine Teilnehmer zu belohnen, was das Wachstum fördert. Wenn ein Subnetz stagniert, ziehen Staker zu lukrativeren Subnetzen ab. Im Effekt regieren TAO-Inhaber kollektiv den Fokus des Netzwerks, indem sie finanziell signalisieren, welche KI-Domänen mehr Ressourcen verdienen. Dies ist eine Form der On-Chain-Governance nach Token-Gewichtung, ausgerichtet auf wirtschaftliche Ergebnisse. Abgesehen von der Ressourcenzuweisung erfolgen größere Protokoll-Upgrades oder Parameteränderungen wahrscheinlich immer noch über Governance-Vorschläge, über die TAO-Inhaber abstimmen (Bittensor verfügt über einen Mechanismus für On-Chain-Vorschläge und Referenden, die von der Bittensor Foundation und einem gewählten Rat verwaltet werden, ähnlich der Governance von Polkadot). Im Laufe der Zeit ist zu erwarten, dass Bittensors Governance zunehmend dezentralisiert wird, wobei die Stiftung zurücktritt, während die Community (über TAO-Stake) Dinge wie Inflationsrate, Genehmigung neuer Subnetze usw. steuert. Der Übergang zu dTAO ist ein großer Schritt in diese Richtung, der zentralisierte Entscheidungsträger durch einen anreizorientierten Markt von Token-Stakeholdern ersetzt.

• Bittensor-Anreize: Bittensors Anreizstruktur ist eng mit seinem Konsens verknüpft. Bei jedem Block (12 Sekunden) wird genau 1 TAO neu geprägt und basierend auf der Leistung unter den Mitwirkenden jedes Subnetzes aufgeteilt. Die Standardaufteilung für die Blockbelohnung jedes Subnetzes beträgt 41 % für Miner, 41 % für Validatoren und 18 % für den Subnetz-Besitzer. Dies stellt sicher, dass alle Rollen belohnt werden: Miner verdienen für Inferenzarbeit, Validatoren für ihre Bewertungsbemühungen und Subnetz-Besitzer (die möglicherweise die Daten/Aufgabe für dieses Subnetz gebootstrappt haben) erhalten einen Restbetrag für die Bereitstellung des „Marktplatzes“ oder des Aufgabendesigns. Diese Prozentsätze sind im Protokoll festgelegt und zielen darauf ab, die Anreize aller auf eine qualitativ hochwertige KI-Ausgabe auszurichten. Der Yuma-Konsensmechanismus verfeinert die Anreize weiter, indem er Belohnungen nach Qualitätsbewertungen gewichtet – ein Miner, der bessere Antworten liefert (gemäß Validatoren-Konsens), erhält einen höheren Anteil dieser 41 %, und ein Validator, der dem ehrlichen Konsens genau folgt, erhält mehr vom Validatorenanteil. Schlechte Performer werden wirtschaftlich aussortiert. Zusätzlich erhalten Delegatoren (Staker), die einen Miner oder Validator unterstützen, typischerweise einen Anteil an den Einnahmen dieses Knotens (Knoten legen oft eine Provision fest und geben den Rest an ihre Delegatoren weiter, ähnlich dem Staking in PoS-Netzwerken). Dies ermöglicht passiven TAO-Inhabern, die besten Mitwirkenden zu unterstützen und Erträge zu erzielen, was die Meritokratie weiter stärkt. Bittensors Token (TAO) ist somit ein Utility-Token: Er ist für die Registrierung neuer Miner erforderlich (Miner müssen einen kleinen Betrag an TAO ausgeben, um beizutreten, was Sybil-Spam bekämpft) und kann gestaked werden, um den Einfluss zu erhöhen oder über Delegation zu verdienen. Er ist auch als Zahlungstoken vorgesehen, wenn externe Benutzer Dienste aus Bittensors Netzwerk nutzen möchten (zum Beispiel TAO zahlen, um ein Sprachmodell auf Bittensor abzufragen), obwohl der interne Belohnungsmechanismus bisher die primäre „Ökonomie“ war. Die allgemeine Anreizphilosophie besteht darin, „wertvolle Intelligenz“ zu belohnen – d. h. Modelle, die gute KI-Ergebnisse liefern – und einen Wettbewerb zu schaffen, der die Qualität der Modelle im Netzwerk kontinuierlich verbessert.

• Gensyn Governance: Gensyns Governance-Modell ist so strukturiert, dass es sich mit der Reifung des Netzwerks von der Kontrolle durch das Kernteam zur Kontrolle durch die Community entwickelt. Zunächst wird Gensyn eine Gensyn Foundation und einen gewählten Rat haben, die Protokoll-Upgrades und Treasury-Entscheidungen überwachen. Dieser Rat wird voraussichtlich zunächst aus Kernteammitgliedern und frühen Community-Führern bestehen. Gensyn plant ein Token Generation Event (TGE) für seinen nativen Token (oft als GENS bezeichnet), wonach die Governance-Macht zunehmend über On-Chain-Abstimmungen in den Händen der Token-Inhaber liegen würde. Die Rolle der Stiftung ist es, die Interessen des Protokolls zu vertreten und einen reibungslosen Übergang zur vollständigen Dezentralisierung zu gewährleisten. In der Praxis wird Gensyn wahrscheinlich On-Chain-Vorschlagsmechanismen haben, bei denen über Änderungen von Parametern (z. B. Verifizierungsspieldauer, Gebührensätze) oder Upgrades von der Community abgestimmt wird. Da Gensyn als Ethereum-Rollup implementiert wird, könnte die Governance auch an die Sicherheit von Ethereum gebunden sein (zum Beispiel die Verwendung von Upgrade-Schlüsseln für den Rollup-Vertrag, die schließlich an eine DAO von Token-Inhabern übergehen). Der Abschnitt Dezentralisierung und Governance des Gensyn-Litepapers betont, dass das Protokoll letztendlich global im Besitz sein muss, im Einklang mit dem Ethos, dass das „Netzwerk für maschinelle Intelligenz“ seinen Benutzern und Mitwirkenden gehören sollte. Zusammenfassend beginnt Gensyns Governance semi-zentralisiert, ist aber so konzipiert, dass sie zu einer DAO wird, in der GENS-Token-Inhaber (potenziell nach Stake oder Beteiligung gewichtet) kollektiv Entscheidungen treffen.

• Gensyn-Anreize: Die wirtschaftlichen Anreize in Gensyn sind unkomplizierte Marktdynamiken, ergänzt durch kryptoökonomische Sicherheit. Entwickler (Clients) bezahlen ML-Aufgaben mit dem Gensyn-Token, und Solver verdienen Tokens, indem sie diese Aufgaben korrekt erledigen. Der Preis für Rechenzyklen wird durch einen offenen Markt bestimmt – vermutlich können Entwickler Aufgaben mit einer Belohnung ausschreiben, und Solver können bieten oder sie einfach annehmen, wenn der Preis ihren Erwartungen entspricht. Dies stellt sicher, dass, solange ein Angebot an ungenutzten GPUs vorhanden ist, der Wettbewerb die Kosten auf einen fairen Satz senkt (Gensyns Team prognostiziert eine Kostenreduzierung von bis zu 80 % im Vergleich zu Cloud-Preisen, da das Netzwerk die günstigste verfügbare Hardware weltweit findet). Auf der anderen Seite haben Solver den Anreiz, Tokens für Arbeit zu verdienen; ihre Hardware, die sonst ungenutzt bleiben könnte, generiert nun Einnahmen. Um die Qualität zu gewährleisten, verlangt Gensyn von Solvern, dass sie Sicherheiten staken, wenn sie einen Job annehmen – wenn sie betrügen oder ein falsches Ergebnis produzieren und erwischt werden, verlieren sie diesen Stake (er kann „geslasht“ und dem ehrlichen Verifier zugesprochen werden). Verifier werden durch die Chance motiviert, eine „Jackpot“-Belohnung zu verdienen, wenn sie einen betrügerischen Solver erwischen, ähnlich dem Truebit-Design, das Verifier, die erfolgreich falsche Berechnungen identifizieren, periodisch belohnt. Dies hält Solver ehrlich und motiviert einige Knoten, als Wächter zu fungieren. In einem optimalen Szenario (kein Betrug) verdienen Solver einfach die Aufgaben-Gebühr, und die Rolle des Verifiers ist größtenteils untätig (oder einer der teilnehmenden Solver könnte auch als Verifier für andere fungieren). Gensyns Token dient somit sowohl als Gas-Währung für den Kauf von Rechenleistung als auch als Stake-Sicherheit, die das Protokoll sichert. Das Litepaper erwähnt ein Testnetz mit nicht-permanenten Tokens und dass frühe Testnetz-Teilnehmer beim TGE mit echten Tokens belohnt werden. Dies deutet darauf hin, dass Gensyn einen Teil des Token-Angebots für das Bootstrapping bereitgestellt hat – zur Belohnung von Early Adopters, Test-Solvern und Community-Mitgliedern. Langfristig sollten Gebühren aus echten Jobs das Netzwerk aufrechterhalten. Es kann auch eine kleine Protokollgebühr (ein Prozentsatz jeder Aufgaben-Zahlung) geben, die in eine Treasury fließt oder verbrannt wird; dieses Detail ist noch nicht bestätigt, aber viele Marktplatzprotokolle enthalten eine Gebühr zur Finanzierung der Entwicklung oder des Token-Kaufs und -Verbrennens. Zusammenfassend richten sich Gensyns Anreize an der ehrlichen Erledigung von ML-Jobs aus: Arbeit leisten, bezahlt werden; versuchen zu betrügen, Stake verlieren; andere überprüfen, verdienen, wenn man Betrüger erwischt. Dies schafft ein sich selbst regulierendes Wirtschaftssystem, das darauf abzielt, zuverlässige verteilte Berechnungen zu erreichen.

• Cuckoo Governance: Cuckoo Network hat die Governance von Anfang an in sein Ökosystem integriert, obwohl es sich noch in einer Entwicklungsphase befindet. Der $CAI-Token ist neben seinen Utility-Rollen explizit ein Governance-Token. Cuckoos Philosophie ist, dass GPU-Knotenbetreiber, App-Entwickler und sogar Endbenutzer ein Mitspracherecht bei der Entwicklung des Netzwerks haben sollten – was seine gemeinschaftsgetriebene Vision widerspiegelt. In der Praxis würden wichtige Entscheidungen (wie Protokoll-Upgrades oder wirtschaftliche Änderungen) durch Token-gewichtete Abstimmungen entschieden, vermutlich über einen DAO-Mechanismus. Zum Beispiel könnte Cuckoo On-Chain-Abstimmungen über die Änderung der Belohnungsverteilung oder die Einführung einer neuen Funktion abhalten, und $CAI-Inhaber (einschließlich Miner, Entwickler und Benutzer) würden abstimmen. Bereits jetzt wird On-Chain-Abstimmung als Reputationssystem verwendet: Cuckoo verlangt von jeder Rolle, Tokens zu staken, und dann können Community-Mitglieder (vielleicht durch Delegation von Stake oder über Governance-Module) darüber abstimmen, welche Koordinatoren oder Miner vertrauenswürdig sind. Dies beeinflusst Reputationswerte und könnte die Aufgabenplanung beeinflussen (z. B. könnte ein Koordinator mit mehr Stimmen mehr Benutzer anziehen, oder ein Miner mit mehr Stimmen könnte mehr Aufgaben zugewiesen bekommen). Es ist eine Mischung aus Governance und Anreiz – die Verwendung von Governance-Tokens zur Etablierung von Vertrauen. Die Cuckoo Foundation oder das Kernteam hat die Richtung des Projekts bisher geleitet (zum Beispiel die jüngste Entscheidung, die L1-Kette einzustellen), aber ihr Blog deutet auf ein Engagement hin, sich in Richtung dezentraler Eigentümerschaft zu bewegen. Sie stellten fest, dass der Betrieb einer eigenen Kette hohe Gemeinkosten verursachte und dass der Wechsel zu einem Rollup eine offenere Entwicklung und Integration mit bestehenden Ökosystemen ermöglichen wird. Es ist wahrscheinlich, dass Cuckoo, sobald es auf einer gemeinsamen Schicht (wie Ethereum) ist, eine traditionellere DAO für Upgrades implementieren wird, wobei die Community mit CAI abstimmt.

• Cuckoo-Anreize: Das Anreizdesign für Cuckoo hat zwei Phasen: die anfängliche Bootstrapping-Phase mit festen Token-Zuweisungen und einen zukünftigen Zustand mit nutzungsbasierter Umsatzbeteiligung. Beim Start führte Cuckoo eine „Fair Launch“-Verteilung von 1 Milliarde CAI-Tokens durch. 51 % des Angebots wurden für die Community reserviert, aufgeteilt als:

  • Mining-Belohnungen: 30 % des Gesamtangebots reserviert, um GPU-Miner für die Ausführung von KI-Aufgaben zu bezahlen.
  • Staking-Belohnungen: 11 % des Angebots für diejenigen, die staken und zur Sicherung des Netzwerks beitragen.
  • Airdrops: 5 % an frühe Benutzer und Community-Mitglieder als Anreiz zur Adoption.
  • (Weitere 5 % waren für Entwicklerzuschüsse zur Förderung des Aufbaus auf Cuckoo.)

  Diese große Zuweisung bedeutet, dass im frühen Netzwerk Miner und Staker aus einem Emissionspool belohnt wurden, selbst wenn die tatsächliche Benutzernachfrage gering war. Tatsächlich bot Cuckoos Anfangsphase hohe APY-Renditen für Staking und Mining, was erfolgreich Teilnehmer anzog, aber auch „Yield Farmer“, die nur wegen der Tokens da waren. Das Team stellte fest, dass viele Benutzer das Netzwerk verließen, sobald die Belohnungsraten sanken, was darauf hindeutet, dass diese Anreize nicht an die tatsächliche Nutzung gebunden waren. Aus diesen Erfahrungen lernend, wechselt Cuckoo zu einem Modell, bei dem Belohnungen direkt mit der tatsächlichen KI-Arbeitslast korrelieren. Zukünftig (und teilweise bereits jetzt), wenn ein Endbenutzer für eine KI-Inferenz bezahlt, wird diese Zahlung (in CAI oder möglicherweise einem anderen akzeptierten Token, der in CAI umgewandelt wird) unter den Mitwirkenden aufgeteilt:

  • GPU-Miner erhalten den Großteil des Anteils für die von ihnen bereitgestellte Rechenleistung.
  • Koordinator (App-Entwickler) erhält einen Anteil als Dienstanbieter, der das Modell bereitgestellt und die Anfrage bearbeitet hat.
  • Staker, die an diese Miner oder Koordinatoren delegiert haben, könnten einen kleinen Anteil oder eine inflationäre Belohnung erhalten, um die Unterstützung zuverlässiger Knoten weiterhin zu fördern.
  • Netzwerk/Treasury könnte eine Gebühr für die laufende Entwicklung einbehalten oder zukünftige Anreize finanzieren (oder die Gebühr könnte null/nominal sein, um die Benutzerfreundlichkeit zu maximieren).

  Im Wesentlichen bewegt sich Cuckoo auf ein Umsatzbeteiligungsmodell zu: Wenn eine KI-App auf Cuckoo Einnahmen generiert, werden diese Einnahmen fair an alle Mitwirkenden dieses Dienstes verteilt. Dies stimmt die Anreize so ab, dass die Teilnehmer von der tatsächlichen Nutzung profitieren und nicht nur von der Inflation. Bereits jetzt verlangte das Netzwerk von allen Parteien, CAI zu staken – das bedeutet, dass Miner und Koordinatoren nicht nur eine pauschale Belohnung verdienen, sondern möglicherweise auch stake-basierte Belohnungen (zum Beispiel könnte ein Koordinator höhere Belohnungen verdienen, wenn viele Benutzer auf ihn staken oder wenn er selbst mehr stakt, ähnlich wie Proof-of-Stake-Validatoren verdienen). Was die Benutzeranreize betrifft, führte Cuckoo auch Dinge wie ein Airdrop-Portal und Faucets ein (die einige Benutzer ausnutzten), um die anfängliche Aktivität anzukurbeln. Zukünftig könnten Benutzer über Token-Rabatte für die Nutzung der Dienste oder über Governance-Belohnungen für die Teilnahme an der Kuration (z. B. kleine Tokens für die Bewertung von Outputs oder die Bereitstellung von Daten) incentiviert werden. Das Fazit ist, dass Cuckoos Token ($CAI) vielseitig einsetzbar ist: Es ist der Gas-/Gebühren-Token auf der Kette (alle Transaktionen und Zahlungen verwenden ihn), er wird für Staking und Abstimmungen verwendet und ist die Einheit der Belohnung für geleistete Arbeit. Cuckoo erwähnt explizit, dass es Token-Belohnungen an Service-Level-KPIs (Key Performance Indicators) binden möchte – zum Beispiel Verfügbarkeit, Abfragedurchsatz, Benutzerzufriedenheit – um rein spekulative Anreize zu vermeiden. Dies spiegelt eine Reifung der Token-Ökonomie von einfachem Liquiditäts-Mining zu einem nachhaltigeren, nutzungsgetriebenen Modell wider.

Modelleigentum und IP-Zuordnung​

Der Umgang mit geistigem Eigentum (IP) und Eigentumsrechten an KI-Modellen ist ein komplexer Aspekt dezentraler KI-Netzwerke. Jede Plattform hat eine etwas andere Haltung eingenommen, und im Allgemeinen ist dies ein sich entwickelnder Bereich ohne vollständige Lösung bisher:

• Bittensor: Modelle in Bittensor werden von den Miner-Knoten bereitgestellt, und diese Miner behalten die volle Kontrolle über ihre Modellgewichte (die niemals On-Chain veröffentlicht werden). Bittensor verfolgt nicht explizit, wer ein Modell „besitzt“, außer der Tatsache, dass es unter einer bestimmten Wallet-Adresse läuft. Wenn ein Miner geht, geht sein Modell mit ihm. Daher erfolgt die IP-Zuordnung in Bittensor Off-Chain: Wenn ein Miner ein proprietäres Modell verwendet, gibt es nichts On-Chain, das dies durchsetzt oder gar weiß. Bittensors Philosophie fördert offene Beiträge (viele Miner könnten Open-Source-Modelle wie GPT-J oder andere verwenden) und das Netzwerk belohnt die Leistung dieser Modelle. Man könnte sagen, Bittensor erstellt einen Reputations-Score für Modelle (über die Validatoren-Rankings), und das ist eine Form der Anerkennung des Modellwerts, aber die Rechte am Modell selbst werden nicht tokenisiert oder verteilt. Bemerkenswert ist, dass Subnetz-Besitzer in Bittensor als Eigentümer eines Teils des IP angesehen werden könnten: Sie definieren eine Aufgabe (die einen Datensatz oder eine Methode umfassen könnte). Der Subnetz-Besitzer prägt ein NFT (genannt Subnetz-UID) bei der Erstellung eines Subnetzes, und dieses NFT berechtigt ihn zu 18 % der Belohnungen in diesem Subnetz. Dies tokenisiert effektiv die Schaffung eines Modell-Marktplatzes (das Subnetz), wenn auch nicht die Modellinstanzen. Wenn man die Definition des Subnetzes (sagen wir eine Spracherkennungsaufgabe mit einem bestimmten Datensatz) als IP betrachtet, wird dies zumindest aufgezeichnet und belohnt. Aber individuelle Modellgewichte, die Miner trainieren – davon gibt es keine On-Chain-Eigentumsaufzeichnung. Die Zuordnung erfolgt in Form von Belohnungen, die an die Adresse des Miners gezahlt werden. Bittensor implementiert derzeit kein System, bei dem zum Beispiel mehrere Personen gemeinsam ein Modell besitzen und eine automatische Umsatzbeteiligung erhalten könnten – die Person, die das Modell betreibt (Miner), erhält die Belohnung, und es liegt an ihr Off-Chain, alle IP-Lizenzen des von ihr verwendeten Modells einzuhalten.

• Gensyn: In Gensyn ist das Modelleigentum unkompliziert, da der Submitter (derjenige, der ein Modell trainieren lassen möchte) die Modellarchitektur und Daten bereitstellt, und nach dem Training das resultierende Modellartefakt erhält. Die Solver, die die Arbeit ausführen, haben keine Rechte am Modell; sie sind wie Auftragnehmer, die für Dienstleistungen bezahlt werden. Gensyns Protokoll geht also vom traditionellen IP-Modell aus: Wenn Sie rechtliche Rechte an dem von Ihnen eingereichten Modell und den Daten hatten, haben Sie diese auch nach dem Training noch – das Rechennetzwerk beansprucht kein Eigentum. Gensyn erwähnt, dass der Marktplatz auch Algorithmen und Daten wie jede andere Ressource handeln könnte. Dies deutet auf ein Szenario hin, in dem jemand ein Modell oder einen Algorithmus zur Nutzung im Netzwerk anbieten könnte, möglicherweise gegen eine Gebühr, wodurch der Zugang zu diesem Modell tokenisiert würde. Zum Beispiel könnte ein Modellersteller sein vorab trainiertes Modell auf Gensyn platzieren und anderen erlauben, es über das Netzwerk gegen eine Gebühr feinabzustimmen (dies würde das Modell-IP effektiv monetarisieren). Während das Protokoll keine Lizenzbedingungen durchsetzt, könnte man Zahlungsanforderungen kodieren: Ein Smart Contract könnte eine Gebühr verlangen, um die Modellgewichte für einen Solver freizuschalten. Dies sind jedoch spekulative Anwendungsfälle – Gensyns primäres Design dreht sich um die Ermöglichung von Trainingsjobs. Was die Zuordnung betrifft, so würde, wenn mehrere Parteien zu einem Modell beitragen (sagen wir, einer stellt Daten bereit, ein anderer Rechenleistung), dies wahrscheinlich durch den Vertrag oder die Vereinbarung geregelt, die sie vor der Nutzung von Gensyn getroffen haben (z. B. könnte ein Smart Contract die Zahlung zwischen Datenanbieter und Rechenanbieter aufteilen). Gensyn selbst verfolgt On-Chain nicht, „dieses Modell wurde von X, Y, Z erstellt“, außer der Aufzeichnung, welche Adressen für den Job bezahlt wurden. Zusammenfassend lässt sich sagen, dass Modell-IP in Gensyn beim Submitter verbleibt, und jede Zuordnung oder Lizenzierung muss über die rechtlichen Vereinbarungen außerhalb des Protokolls oder über darauf aufbauende benutzerdefinierte Smart Contracts gehandhabt werden.

• Cuckoo: Im Cuckoo-Ökosystem sind Modellersteller (KI-App-Entwickler) erstklassige Teilnehmer – sie stellen den KI-Dienst bereit. Wenn ein App-Entwickler ein Sprachmodell feinabstimmt oder ein benutzerdefiniertes Modell entwickelt und es auf Cuckoo hostet, ist dieses Modell im Wesentlichen sein Eigentum, und er fungiert als Dienstbesitzer. Cuckoo beansprucht kein Eigentum; stattdessen bietet es die Infrastruktur, damit sie die Nutzung monetarisieren können. Wenn zum Beispiel ein Entwickler einen Chatbot-KI bereitstellt, können Benutzer damit interagieren, und der Entwickler (plus Miner) verdienen CAI aus jeder Interaktion. Die Plattform ordnet somit Nutzungseinnahmen dem Modellersteller zu, veröffentlicht aber nicht explizit die Modellgewichte oder wandelt sie in ein NFT um. Tatsächlich muss der Koordinator-Knoten, um das Modell auf den GPUs der Miner auszuführen, das Modell (oder die Laufzeitumgebung) in irgendeiner Form an den Miner senden. Dies wirft IP-Fragen auf: Könnte ein böswilliger Miner die Modellgewichte kopieren und verteilen? In einem dezentralen Netzwerk besteht dieses Risiko, wenn proprietäre Modelle verwendet werden. Cuckoos aktueller Fokus lag auf ziemlich offenen Modellen (Stable Diffusion, LLaMA-abgeleitete Modelle usw.) und dem Aufbau einer Community, sodass wir noch keine Durchsetzung von IP-Rechten über Smart Contracts gesehen haben. Die Plattform könnte potenziell Tools wie verschlüsselte Modellausführung oder sichere Enklaven in Zukunft zum IP-Schutz integrieren, aber in der Dokumentation wird nichts Spezifisches erwähnt. Was es tut, ist die Verfolgung, wer den Modell-Dienst für jede Aufgabe bereitgestellt hat – da der Koordinator eine On-Chain-Identität ist, wird jede Nutzung seines Modells ihm zugerechnet, und er erhält automatisch seinen Anteil an den Belohnungen. Wenn man ein Modell an jemand anderen weitergeben oder verkaufen würde, würde man effektiv die Kontrolle über den Koordinator-Knoten übertragen (vielleicht sogar nur den privaten Schlüssel oder das NFT geben, wenn die Koordinator-Rolle tokenisiert wäre). Derzeit ist die Gemeinschaftseigentümerschaft von Modellen (über Token-Anteile) nicht implementiert, aber Cuckoos Vision deutet auf dezentrale, gemeinschaftsgetriebene KI hin, sodass sie möglicherweise erforschen werden, wie Menschen gemeinsam ein KI-Modell finanzieren oder regieren können. Die Tokenisierung von Modellen über das individuelle Eigentum hinaus ist in diesen Netzwerken immer noch ein offenes Feld – es wird als Ziel anerkannt (um Gemeinschaften KI-Modelle statt Unternehmen zu ermöglichen), aber praktisch erfordert es Lösungen für die oben genannten IP- und Verifizierungsherausforderungen.

Zusammenfassend lässt sich sagen, dass das Modelleigentum in Bittensor, Gensyn und Cuckoo Off-Chain auf traditionelle Weise gehandhabt wird: Die Person oder Entität, die das Modell betreibt oder einreicht, ist effektiv der Eigentümer. Die Netzwerke bieten eine Zuordnung in Form von wirtschaftlichen Belohnungen (Bezahlung des Modell-Beitragenden für sein IP oder seine Bemühungen). Keines der drei hat bisher eine integrierte Lizenz- oder Lizenzgebühren-Durchsetzung für die Modellnutzung auf Smart-Contract-Ebene. Die Zuordnung erfolgt durch Reputation und Belohnung: z. B. erhalten Bittensors beste Modelle hohe Reputationswerte (die öffentlich aufgezeichnet werden) und mehr TAO, was eine implizite Anerkennung ihrer Ersteller ist. Im Laufe der Zeit könnten wir Funktionen wie NFT-gebundene Modellgewichte oder dezentrale Lizenzen sehen, um IP besser zu verfolgen, aber derzeit lag die Priorität darauf, die Netzwerke funktionsfähig zu machen und Beiträge zu incentivieren. Alle sind sich einig, dass die Überprüfung der Modellherkunft und -ausgaben der Schlüssel zur Ermöglichung echter Modell-Asset-Märkte ist, und die Forschung in dieser Richtung ist im Gange.

Umsatzbeteiligungsstrukturen​

Alle drei Plattformen müssen entscheiden, wie der wirtschaftliche Kuchen aufgeteilt wird, wenn mehrere Parteien zusammenarbeiten, um eine wertvolle KI-Ausgabe zu produzieren. Wer wird bezahlt und wie viel, wenn ein KI-Dienst genutzt wird oder wenn Tokens emittiert werden? Jede hat ein eigenes Umsatzbeteiligungsmodell:

• Bittensor: Wie unter Anreize erwähnt, ist Bittensors Umsatzverteilung auf Blockebene protokoll-definiert: 41 % an Miner, 41 % an Validatoren, 18 % an den Subnetz-Besitzer für jede TAO-Ausgabe eines Blocks. Dies ist effektiv eine eingebaute Umsatzaufteilung für den in jedem Subnetz generierten Wert. Der Anteil des Subnetz-Besitzers (18 %) fungiert als Lizenzgebühr für das „Modell-/Aufgabendesign“ oder für das Bootstrapping des Ökosystems dieses Subnetzes. Miner und Validatoren erhalten gleiche Anteile, um sicherzustellen, dass Miner ohne Validierung nicht belohnt werden (und umgekehrt) – sie sind symbiotisch und jeder erhält einen gleichen Anteil an den geprägten Belohnungen. Wenn wir einen externen Benutzer betrachten, der TAO zahlt, um ein Modell abzufragen, sieht das Bittensor-Whitepaper vor, dass diese Zahlung ebenfalls ähnlich zwischen dem Miner, der antwortet, und den Validatoren, die bei der Überprüfung der Antwort geholfen haben, aufgeteilt wird (die genaue Aufteilung könnte durch das Protokoll oder Marktkräfte bestimmt werden). Zusätzlich sind Delegatoren, die auf Miner/Validatoren staken, effektiv Partner – typischerweise teilt ein Miner/Validator einen Prozentsatz seiner verdienten TAO mit seinen Delegatoren (dies ist konfigurierbar, aber oft der Großteil an Delegatoren). Wenn also ein Miner 1 TAO aus einem Block verdient hat, könnte dieser beispielsweise basierend auf dem Stake 80/20 zwischen seinen Delegatoren und sich selbst aufgeteilt werden. Das bedeutet, dass auch Nicht-Betreiber einen Anteil am Umsatz des Netzwerks proportional zu ihrer Unterstützung erhalten. Mit der Einführung von dTAO wurde eine weitere Ebene der Aufteilung hinzugefügt: Diejenigen, die in den Pool eines Subnetzes staken, erhalten Alpha-Tokens, die sie zu einem Teil der Emissionen dieses Subnetzes berechtigen (wie Yield Farming). Im Effekt kann jeder einen Anteil am Erfolg eines bestimmten Subnetzes nehmen und einen Bruchteil der Miner-/Validatoren-Belohnungen durch das Halten von Alpha-Tokens erhalten (Alpha-Tokens steigen im Wert, wenn das Subnetz mehr Nutzung und Emissionen anzieht). Zusammenfassend lässt sich sagen, dass Bittensors Umsatzbeteiligung für die Hauptrollen durch Code festgelegt ist und durch soziale/Staking-Vereinbarungen weiter aufgeteilt wird. Es ist eine relativ transparente, regelbasierte Aufteilung – bei jedem Block wissen die Teilnehmer genau, wie der 1 TAO zugewiesen wird, und kennen somit ihre „Einnahmen“ pro Beitrag. Diese Klarheit ist ein Grund, warum Bittensor manchmal als Bitcoin für KI bezeichnet wird – eine deterministische Geldausgabe, bei der die Belohnung der Teilnehmer mathematisch festgelegt ist.

• Gensyn: Die Umsatzbeteiligung in Gensyn ist dynamischer und marktorientierter, da Aufgaben individuell bepreist werden. Wenn ein Submitter einen Job erstellt, fügt er eine Belohnung (sagen wir X Tokens) hinzu, die er zu zahlen bereit ist. Ein Solver, der den Job abschließt, erhält dieses X (abzüglich etwaiger Netzwerkgebühren). Wenn ein Verifier beteiligt ist, gibt es typischerweise eine Regel wie: Wenn kein Betrug entdeckt wird, behält der Solver die volle Zahlung; wenn Betrug entdeckt wird, wird der Solver „geslasht“ – er verliert einen Teil oder seinen gesamten Stake – und dieser „geslashte“ Betrag wird dem Verifier als Belohnung gegeben. Verifier verdienen also nicht an jeder Aufgabe, sondern nur, wenn sie ein schlechtes Ergebnis erwischen (plus möglicherweise eine kleine Grundgebühr für die Teilnahme, je nach Implementierung). Es gibt hier kein eingebautes Konzept der Bezahlung eines Modelleigentümers, da davon ausgegangen wird, dass der Submitter entweder der Modelleigentümer ist oder die Rechte zur Nutzung des Modells besitzt. Man könnte sich ein Szenario vorstellen, in dem ein Submitter das vortrainierte Modell eines anderen feinabstimmt und ein Teil der Zahlung an den ursprünglichen Modellersteller geht – dies müsste jedoch außerhalb des Protokolls gehandhabt werden (z. B. durch eine Vereinbarung oder einen separaten Smart Contract, der die Token-Zahlung entsprechend aufteilt). Gensyns protokollseitige Aufteilung ist im Wesentlichen Client -> Solver (-> Verifier). Das Token-Modell beinhaltet wahrscheinlich eine Zuweisung für die Protokoll-Treasury oder -Stiftung; zum Beispiel könnte ein kleiner Prozentsatz der Zahlung jeder Aufgabe an eine Treasury gehen, die zur Finanzierung von Entwicklung oder Versicherungs-Pools verwendet werden könnte (dies ist in den verfügbaren Dokumenten nicht explizit angegeben, aber viele Protokolle tun dies). Auch könnte Gensyn anfangs Solver über Inflation subventionieren: Testnet-Benutzern werden Belohnungen beim TGE versprochen, was effektiv eine Umsatzbeteiligung aus der anfänglichen Token-Verteilung ist (frühe Solver und Unterstützer erhalten einen Teil der Tokens, um beim Bootstrapping zu helfen, ähnlich einem Airdrop oder einer Mining-Belohnung). Im Laufe der Zeit, wenn echte Jobs dominieren, würden inflationäre Belohnungen abnehmen, und das Einkommen der Solver würde hauptsächlich aus Benutzerzahlungen stammen. Gensyns Ansatz lässt sich als Gebühren-für-Service-Umsatzmodell zusammenfassen: Das Netzwerk ermöglicht eine direkte Zahlung von denen, die Arbeit erledigt haben möchten, an diejenigen, die die Arbeit erledigen, wobei Verifier und möglicherweise Token-Staker nur dann Anteile erhalten, wenn sie eine Rolle bei der Sicherung dieses Dienstes spielen.

• Cuckoo: Cuckoos Umsatzbeteiligung hat sich weiterentwickelt. Anfangs, da es nicht viele zahlende Endbenutzer gab, war die Umsatzbeteiligung im Wesentlichen Inflationsbeteiligung: Die 30 % Mining- und 11 % Staking-Zuweisungen aus dem Token-Angebot bedeuteten, dass Miner und Staker die vom Fair-Launch-Pool des Netzwerks ausgegebenen Tokens teilten. In der Praxis führte Cuckoo Dinge wie tägliche CAI-Auszahlungen an Miner proportional zu den abgeschlossenen Aufgaben durch. Diese Auszahlungen stammten größtenteils aus der Mining-Belohnungszuweisung (die Teil des fest reservierten Angebots ist). Dies ähnelt der Art und Weise, wie viele Layer-1-Blockchains Blockbelohnungen an Miner/Validatoren verteilen – es war nicht an die tatsächliche Nutzung durch externe Benutzer gebunden, sondern sollte eher die Teilnahme und das Wachstum fördern. Wie jedoch in ihrem Blog vom Juli 2025 hervorgehoben, führte dies zu einer Nutzung, die eher durch Token-Farming als durch echte Nachfrage motiviert war. Die nächste Phase für Cuckoo ist ein echtes Umsatzbeteiligungsmodell basierend auf Servicegebühren. In diesem Modell, wenn ein Endbenutzer beispielsweise den Bildgenerierungsdienst nutzt und 1 $ (in Krypto-Begriffen) bezahlt, würde dieser Token-Wert von 1 $ vielleicht aufgeteilt wie folgt: 0,70 an den Miner, der die GPU-Arbeit geleistet hat, 0,20 an den App-Entwickler (Koordinator), der das Modell und die Schnittstelle bereitgestellt hat, und 0,10 an Staker oder die Netzwerk-Treasury. (Hinweis: Die genauen Verhältnisse sind hypothetisch; Cuckoo hat sie noch nicht öffentlich spezifiziert, aber dies veranschaulicht das Konzept.) Auf diese Weise erhalten alle Mitwirkenden an der Bereitstellung des Dienstes einen Anteil am Umsatz. Dies ist analog zu, zum Beispiel, einer Fahrgemeinschafts-Wirtschaft, aber für KI: Das Fahrzeug (GPU-Miner) erhält den Großteil, der Fahrer oder die Plattform (Koordinator, der den Modell-Dienst erstellt hat) erhält einen Anteil, und vielleicht erhalten die Governance/Staker der Plattform eine kleine Gebühr. Cuckoos Erwähnung von „Umsatzbeteiligungsmodellen und Token-Belohnungen, die direkt an Nutzungsmetriken gebunden sind“ deutet darauf hin, dass wenn ein bestimmter Dienst oder Knoten ein hohes Volumen verarbeitet, seine Betreiber und Unterstützer mehr verdienen werden. Sie entfernen sich von pauschalen Renditen für das bloße Sperren von Tokens (was bei ihrem anfänglichen Staking-APY der Fall war). Konkret: Wenn Sie auf einen Koordinator staken, der letztendlich eine sehr beliebte KI-App antreibt, könnten Sie einen Teil der Gebühren dieser App verdienen – ein echtes Staking-als-Investition-in-Utility-Szenario, anstatt nur für die Inflation zu staken. Dies stimmt die Anreize aller darauf ab, echte Benutzer anzuziehen, die für KI-Dienste bezahlen, was wiederum Wert an die Token-Inhaber zurückführt. Es ist erwähnenswert, dass Cuckoos Kette auch Gebühren für Transaktionen (Gas) hatte, sodass Miner, die Blöcke produzierten (anfangs trugen GPU-Miner auch zur Blockproduktion auf der Cuckoo-Kette bei), auch Gasgebühren erhielten. Mit der Abschaltung der Kette und der Migration zu einem Rollup werden die Gasgebühren wahrscheinlich minimal sein (oder auf Ethereum liegen), sodass die Haupteinnahmen die KI-Servicegebühren selbst werden. Zusammenfassend wechselt Cuckoo von einem subventionsgetriebenen Modell (Netzwerk zahlt Teilnehmer aus seinem Token-Pool) zu einem nachfragegetriebenen Modell (Teilnehmer verdienen an tatsächlichen Benutzerzahlungen). Der Token wird weiterhin eine Rolle beim Staking und der Governance spielen, aber die täglichen Einnahmen von Minern und App-Entwicklern sollten zunehmend von Benutzern stammen, die KI-Dienste kaufen. Dieses Modell ist langfristig nachhaltiger und spiegelt die Umsatzbeteiligung von Web2-SaaS wider, jedoch über Smart Contracts und Tokens für Transparenz implementiert.

Angriffsflächen und Schwachstellen​

Die Dezentralisierung von KI bringt mehrere Anreiz- und Sicherheitsherausforderungen mit sich. Wir analysieren nun die wichtigsten Angriffsvektoren – Sybil-Angriffe, Kollusion, Trittbrettfahren und Daten-/Modellvergiftung – und wie jede Plattform diese mindert oder ihnen gegenüber anfällig bleibt:

• Sybil-Angriffe (gefälschte Identitäten): In einem offenen Netzwerk könnte ein Angreifer viele Identitäten (Knoten) erstellen, um unverhältnismäßige Belohnungen oder Einfluss zu erlangen.

  • Bittensor: Sybil-Resistenz wird hauptsächlich durch die Eintrittskosten gewährleistet. Um einen neuen Miner oder Validator auf Bittensor zu registrieren, muss man TAO ausgeben oder staken – dies könnte eine Burn- oder Bonding-Anforderung sein. Das bedeutet, dass die Erstellung von N gefälschten Knoten N-mal die Kosten verursacht, was große Sybil-Schwärme teuer macht. Zusätzlich bindet Bittensors Konsens den Einfluss an Stake und Leistung; ein Sybil ohne Stake oder mit schlechter Leistung verdient wenig. Ein Angreifer müsste stark investieren und seine Sybil-Knoten tatsächlich nützliche Arbeit leisten lassen, um eine signifikante Belohnung zu erhalten (was keine typische Sybil-Strategie ist). Wenn ein Angreifer jedoch viel Kapital besitzt, könnte er eine Mehrheit der TAO erwerben und viele Validatoren oder Miner registrieren – effektiv ein Sybil durch Reichtum. Dies überschneidet sich mit dem 51%-Angriffsszenario: Wenn eine einzelne Entität >50 % der gestakten TAO in einem Subnetz kontrolliert, kann sie den Konsens stark beeinflussen. Bittensors Einführung von dTAO hilft hier ein wenig: Es verteilt den Einfluss auf mehrere Subnetze und erfordert die Unterstützung der Community beim Staking, damit Subnetze gedeihen können, was es für eine Entität schwieriger macht, alles zu kontrollieren. Dennoch bleiben Sybil-Angriffe durch einen gut finanzierten Gegner ein Problem – die Arxiv-Analyse weist explizit darauf hin, dass der Stake derzeit ziemlich konzentriert ist, sodass die Barriere für einen Mehrheitsangriff nicht so hoch ist wie gewünscht. Um dies zu mindern, wurden Vorschläge wie Stake-Obergrenzen pro Wallet (z. B. Begrenzung des effektiven Stakes auf das 88. Perzentil, um die Dominanz einer Wallet zu verhindern) gemacht. Zusammenfassend verlässt sich Bittensor auf Stake-gewichtete Identität (man kann Identitäten nicht billig ohne proportionalen Stake erzeugen), um Sybils zu handhaben; es ist einigermaßen effektiv, außer bei einem sehr ressourcenstarken Angreifer.
  • Gensyn: Sybil-Angriffe in Gensyn würden sich darin äußern, dass ein Angreifer viele Solver- oder Verifier-Knoten hochfährt, um das System zu manipulieren. Gensyns Verteidigung ist rein wirtschaftlich und kryptografisch – Identitäten an sich spielen keine Rolle, aber das Erledigen von Arbeit oder das Hinterlegen von Sicherheiten schon. Wenn ein Angreifer 100 gefälschte Solver-Knoten erstellt, diese aber keine Jobs oder keinen Stake haben, erreichen sie nichts. Um Aufgaben zu gewinnen, müsste ein Sybil-Knoten wettbewerbsfähig bieten und die Hardware haben, um die Arbeit zu erledigen. Wenn sie ohne Kapazität unterbieten, werden sie scheitern und Stake verlieren. Ähnlich könnte ein Angreifer viele Verifier-Identitäten erstellen, in der Hoffnung, zur Verifizierung ausgewählt zu werden (wenn das Protokoll Verifier zufällig auswählt). Aber wenn es zu viele gibt, könnte das Netzwerk oder der Job-Poster die Anzahl der aktiven Verifier begrenzen. Außerdem müssen Verifier möglicherweise die Berechnung durchführen, um sie zu überprüfen, was kostspielig ist; viele gefälschte Verifier helfen nicht, es sei denn, man kann tatsächlich Ergebnisse verifizieren. Ein relevanterer Sybil-Aspekt in Gensyn ist, wenn ein Angreifer versucht, das Netzwerk mit gefälschten Jobs oder Antworten zu füllen, um die Zeit anderer zu verschwenden. Dies wird durch die Anforderung einer Einzahlung von Submittern gemildert (ein böswilliger Submitter, der gefälschte Jobs postet, verliert seine Zahlung oder Einzahlung). Insgesamt bedeutet Gensyns Verwendung von erforderlichen Stakes/Bonds und zufälliger Auswahl zur Verifizierung, dass ein Angreifer wenig gewinnt, indem er mehrere Identitäten hat, es sei denn, er bringt auch proportionale Ressourcen mit. Es wird zu einem kostspieligeren Angriff statt zu einem billigen. Das optimistische Sicherheitsmodell geht davon aus, dass mindestens ein ehrlicher Verifier vorhanden ist – Sybils müssten alle Verifier überwältigen und sein, um konsequent zu betrügen, was wiederum auf den Besitz einer Mehrheit des Stakes oder der Rechenleistung zurückführt. Gensyns Sybil-Resistenz ist daher vergleichbar mit der eines optimistischen Rollups: Solange es einen ehrlichen Akteur gibt, können Sybils keinen systemischen Schaden leicht verursachen.
  • Cuckoo: Die Prävention von Sybil-Angriffen in Cuckoo basiert auf Staking und Community-Überprüfung. Jede Rolle in Cuckoo (Miner, Koordinator, in einigen Fällen sogar Benutzer) erfordert das Staking von $CAI. Dies erhöht sofort die Kosten für Sybil-Identitäten – ein Angreifer, der 100 Dummy-Miner erstellt, müsste für jeden Stake erwerben und sperren. Darüber hinaus hat Cuckoos Design ein menschliches/gemeinschaftliches Element: Neue Knoten müssen Reputation durch On-Chain-Abstimmung verdienen. Eine Sybil-Armee von neuen Knoten ohne Reputation wird wahrscheinlich nicht viele Aufgaben zugewiesen bekommen oder von Benutzern vertraut werden. Koordinatoren müssen insbesondere Benutzer anziehen; ein gefälschter Koordinator ohne Erfolgsbilanz würde keine Nutzung erhalten. Für Miner können Koordinatoren ihre Leistungsstatistiken (erfolgreiche Aufgaben usw.) auf Cuckoo Scan sehen und werden zuverlässige Miner bevorzugen. Cuckoo hatte auch eine relativ kleine Anzahl von Minern (zu einem Zeitpunkt in der Beta 40 GPUs), sodass jeder ungewöhnliche Zustrom vieler Knoten auffallen würde. Der potenzielle Schwachpunkt ist, wenn der Angreifer auch das Reputationssystem ausnutzt – z. B. staken sie viel CAI auf ihre Sybil-Knoten, um sie seriös aussehen zu lassen, oder erstellen gefälschte „Benutzer“-Konten, um sich selbst hochzustimmen. Dies ist theoretisch möglich, aber da alles Token-kuratiert ist, kostet es Tokens, dies zu tun (man würde im Wesentlichen mit dem eigenen Stake auf die eigenen Knoten stimmen). Das Cuckoo-Team kann auch die Staking- und Belohnungsparameter anpassen, wenn Sybil-Verhalten beobachtet wird (insbesondere jetzt, da es zu einem stärker zentralisierten Rollup-Dienst wird; sie können schlechte Akteure pausieren oder „slashen“). Alles in allem werden Sybils durch die Anforderung von „Skin in the Game“ (Stake) und die Notwendigkeit der Community-Zustimmung in Schach gehalten. Niemand kann einfach mit Hunderten von gefälschten GPUs hereinspazieren und Belohnungen ernten, ohne eine erhebliche Investition zu tätigen, die ehrliche Teilnehmer besser für echte Hardware und Stake ausgeben könnten.

• Kollusion: Hier betrachten wir mehrere Teilnehmer, die kolludieren, um das System zu manipulieren – zum Beispiel Validatoren und Miner, die in Bittensor kolludieren, oder Solver und Verifier, die in Gensyn kolludieren usw.

  • Bittensor: Kollusion wurde als echtes Problem identifiziert. Im ursprünglichen Design konnte eine Handvoll Validatoren kolludieren, um bestimmte Miner oder sich selbst immer hochzustufen, wodurch die Belohnungsverteilung unfair verzerrt wurde (dies wurde als Machtkonzentration im Root-Subnetz beobachtet). Der Yuma-Konsens bietet eine gewisse Verteidigung: Indem er einen Median der Validatoren-Scores nimmt und diejenigen bestraft, die abweichen, verhindert er, dass eine kleine kolludierende Gruppe ein Ziel dramatisch aufwertet, es sei denn, sie bilden die Mehrheit. Mit anderen Worten, wenn 3 von 10 Validatoren kolludieren, um einem Miner einen super hohen Score zu geben, die anderen 7 dies aber nicht tun, werden die Ausreißer-Scores der Kolludierenden beschnitten und die Belohnung des Miners basiert auf dem Median-Score (so scheitert die Kollusion daran, signifikant zu helfen). Wenn die Kolludierenden jedoch >50 % der Validatoren (oder >50 % des Stakes unter den Validatoren) bilden, sind sie effektiv der Konsens – sie können sich auf falsche hohe Scores einigen, und der Median wird ihre Ansicht widerspiegeln. Dies ist das klassische 51%-Angriffsszenario. Leider ergab die Arxiv-Studie, dass in einigen Bittensor-Subnetzen eine Koalition von nur 1–2 % der Teilnehmer (nach Anzahl) eine Mehrheit des Stakes kontrollierte, aufgrund einer starken Token-Konzentration. Dies bedeutet, dass Kollusion durch einige wenige Großinhaber eine glaubwürdige Bedrohung darstellte. Die Minderung, die Bittensor über dTAO verfolgt, ist die Demokratisierung des Einflusses: Indem jeder TAO-Inhaber Stake an Subnetze lenken kann, wird die Macht geschlossener Validatoren-Gruppen verwässert. Auch Vorschläge wie konkaves Staking (abnehmende Erträge für übermäßigen Stake) und Stake-Obergrenzen zielen darauf ab, die Fähigkeit einer kolludierenden Entität zu brechen, zu viel Stimmrecht zu sammeln. Bittensors Sicherheitsannahme ähnelt nun Proof-of-Stake: keine einzelne Entität (oder Kartell) kontrolliert >50 % des aktiven Stakes. Solange dies gilt, ist Kollusion begrenzt, da ehrliche Validatoren schlechte Bewertungen überschreiben werden und kolludierende Subnetz-Besitzer ihre eigenen Belohnungen nicht willkürlich erhöhen können. Schließlich, bei Kollusion zwischen Subnetz-Besitzern und Validatoren (z. B. ein Subnetz-Besitzer besticht Validatoren, um die Miner seines Subnetzes hoch zu bewerten), entfernt dTAO die direkte Validatoren-Kontrolle und ersetzt sie durch Token-Inhaber-Entscheidungen. Es ist schwieriger, mit „dem Markt“ zu kolludieren, es sei denn, man kauft das Token-Angebot auf – in diesem Fall ist es keine Kollusion, sondern eine Übernahme. Bittensors Haupttechnik gegen Kollusion ist also algorithmischer Konsens (Median-Clipping) und breite Token-Verteilung.

  • Gensyn: Kollusion in Gensyn würde wahrscheinlich einen Solver und einen Verifier (oder mehrere Verifier) umfassen, die kolludieren, um das System zu betrügen. Zum Beispiel könnte ein Solver ein gefälschtes Ergebnis produzieren, und ein kolludierender Verifier könnte es absichtlich nicht anfechten (oder sogar bestätigen, dass es korrekt ist, wenn das Protokoll Verifier auffordert, dies zu unterschreiben). Um dies zu mindern, erfordert Gensyns Sicherheitsmodell mindestens einen ehrlichen Verifier. Wenn alle Verifier mit dem Solver kolludieren, bleibt ein schlechtes Ergebnis unangefochten. Gensyn begegnet dem, indem es viele unabhängige Verifier fördert (jeder kann verifizieren) und durch die Spieltheorie, dass ein Verifier eine große Belohnung verdienen könnte, indem er die Kollusion bricht und anfechtet (weil er den Stake des Solvers erhalten würde). Im Wesentlichen hat jedes Mitglied, selbst wenn eine Gruppe sich zur Kollusion bereit erklärt, einen Anreiz, abtrünnig zu werden und die Belohnung für sich selbst zu beanspruchen – dies ist ein klassisches Gefangenendilemma. Die Hoffnung ist, dass dies Kollusionsgruppen klein oder ineffektiv hält. Eine weitere potenzielle Kollusion besteht zwischen mehreren Solvern, um Preise in die Höhe zu treiben oder Aufgaben zu monopolisieren. Da Entwickler jedoch wählen können, wo sie Aufgaben posten (und Aufgaben keine identischen Einheiten sind, die leicht monopolisiert werden können), wäre eine Solver-Kollusion bei der Preisgestaltung global schwer zu koordinieren – jeder nicht-kolludierende Solver könnte unterbieten, um die Arbeit zu gewinnen. Die Dynamik des offenen Marktes wirkt der Preiskollusion entgegen, vorausgesetzt, es gibt zumindest einige wettbewerbsfähige Teilnehmer. Ein weiterer Aspekt: Verifier-Kollusion, um Solver zu schädigen – z. B. Verifier, die ehrliche Solver fälschlicherweise beschuldigen, um deren Stake zu stehlen. Gensyns Fraud Proof ist binär und On-Chain; eine falsche Anschuldigung würde fehlschlagen, wenn die On-Chain-Neuberechnung keinen Fehler findet, und presumably würde der böswillige Verifier dann etwas verlieren (vielleicht eine Einzahlung oder Reputation). Eine Kollusion von Verifiern, die versuchen, Solver zu sabotieren, würde also durch den Verifizierungsprozess des Protokolls aufgedeckt. Zusammenfassend ist Gensyns Architektur robust, solange mindestens eine Partei in jedem kolludierenden Set einen Anreiz hat, ehrlich zu sein – eine Eigenschaft der optimistischen Verifizierung, ähnlich der Anforderung eines ehrlichen Miners in Bitcoin, um schließlich einen Betrug aufzudecken. Kollusion ist theoretisch möglich, wenn ein Angreifer alle Verifier und Solver in einer Aufgabe kontrollieren könnte (wie eine Mehrheit des Netzwerks), aber dann könnten sie einfach betrügen, ohne Kollusion an sich zu benötigen. Die kryptoökonomischen Anreize sind so angeordnet, dass die Aufrechterhaltung von Kollusion irrational ist.

  • Cuckoo: Kollusion in Cuckoo könnte auf verschiedene Weisen geschehen:

    1. Ein Koordinator kolludiert mit Minern – zum Beispiel könnte ein Koordinator Aufgaben immer einer Gruppe befreundeter Miner zuweisen und Belohnungen aufteilen, während er andere ehrliche Miner ignoriert. Da Koordinatoren bei der Aufgabenplanung Ermessensspielraum haben, kann dies geschehen. Wenn die befreundeten Miner jedoch unterdurchschnittlich sind, könnten die Endbenutzer einen langsamen oder schlechten Dienst bemerken und abwandern, sodass der Koordinator von reinem Favoritismus, der die Qualität beeinträchtigt, abgeschreckt wird. Wenn die Kollusion darauf abzielt, Belohnungen zu manipulieren (z. B. das Einreichen gefälschter Aufgaben, um Minern Tokens zu geben), würde dies On-Chain entdeckt werden (viele Aufgaben mit vielleicht identischen Eingaben oder ohne tatsächlichen Benutzer) und kann bestraft werden. Cuckoos On-Chain-Transparenz bedeutet, dass ungewöhnliche Muster von der Community oder dem Kernteam gemeldet werden könnten. Da alle Teilnehmer staken, riskiert ein kolludierender Koordinator-Miner-Ring den Verlust seines Stakes, wenn er beim Missbrauch des Systems erwischt wird (z. B. wenn die Governance beschließt, sie wegen Betrugs zu „slashen“).
    2. Miner kolludieren untereinander – sie könnten Informationen teilen oder ein Kartell bilden, um sich beispielsweise gegenseitig bei der Reputation zu wählen oder alle weigern, einem bestimmten Koordinator zu dienen, um höhere Gebühren zu erzielen. Diese Szenarien sind weniger wahrscheinlich: Die Reputationsabstimmung erfolgt durch Staker (einschließlich Benutzer), nicht durch die Miner selbst, die sich gegenseitig wählen. Und die Verweigerung des Dienstes würde Koordinatoren nur dazu bringen, andere Miner zu finden oder Alarm zu schlagen. Angesichts des derzeit relativ kleinen Umfangs wäre jede Kollusion schwer zu verbergen.
    3. Kollusion zur Manipulation der Governance – große CAI-Inhaber könnten kolludieren, um Vorschläge zu ihren Gunsten durchzusetzen (wie die Festlegung einer exorbitanten Gebühr oder die Umleitung der Treasury). Dies ist ein Risiko in jeder Token-Governance. Die beste Minderung ist eine breite Verteilung des Tokens (Cuckoos Fair Launch gab 51 % an die Community) und eine aktive Community-Aufsicht. Da Cuckoo auch von L1 abgewichen ist, könnte die sofortige On-Chain-Governance begrenzt sein, bis sie sich auf einer neuen Kette niedergelassen haben; das Team behält wahrscheinlich in der Zwischenzeit eine Multisig-Kontrolle, was ironischerweise Kollusion durch böswillige Außenseiter auf Kosten einer vorübergehenden Zentralisierung verhindert.

  Insgesamt stützt sich Cuckoo auf Transparenz und Staking, um Kollusion zu handhaben. Es gibt ein Element des Vertrauens in Koordinatoren, sich korrekt zu verhalten, da sie in einem wettbewerbsintensiven Umfeld Benutzer anziehen wollen. Wenn Kollusion zu schlechterem Service oder offensichtlicher Belohnungsmanipulation führt, können Stakeholder schlechte Akteure abwählen oder das Staking auf sie einstellen, und das Netzwerk kann sie „slashen“ oder blockieren. Die ziemlich offene Natur (jeder kann Koordinator oder Miner werden, wenn er stakt) bedeutet, dass Kollusion eine große koordinierte Anstrengung erfordern würde, die offensichtlich wäre. Es ist nicht so mathematisch verhindert wie in Bittensor oder Gensyn, aber die Kombination aus wirtschaftlichem Stake und Community-Governance bietet eine Kontrolle.

• Trittbrettfahren (Free-Rider-Probleme): Dies bezieht sich auf Teilnehmer, die versuchen, Belohnungen zu ernten, ohne einen gleichwertigen Beitrag zu leisten – z. B. ein Validator, der nicht tatsächlich evaluiert, aber trotzdem verdient, oder ein Miner, der die Antworten anderer kopiert, anstatt zu rechnen, oder Benutzer, die Belohnungen farmen, ohne nützliche Eingaben zu liefern.

  • Bittensor: Ein bekanntes Trittbrettfahrerproblem in Bittensor ist das „Gewichtskopieren“ durch faule Validatoren. Ein Validator könnte einfach die Mehrheitsmeinung (oder die Bewertungen eines anderen Validators) kopieren, anstatt Miner unabhängig zu bewerten. Dadurch vermeiden sie die Kosten für die Ausführung von KI-Abfragen, erhalten aber dennoch Belohnungen, wenn ihre eingereichten Bewertungen konsenskonform aussehen. Bittensor bekämpft dies, indem es die Konsensausrichtung und den informatorischen Beitrag jedes Validators misst. Wenn ein Validator immer nur andere kopiert, mag er gut ausgerichtet sein (so dass er nicht stark bestraft wird), aber er fügt keinen einzigartigen Wert hinzu. Die Protokollentwickler haben diskutiert, Validatoren, die genaue, aber nicht rein redundante Bewertungen liefern, höhere Belohnungen zu geben. Techniken wie die Rauschinfusion (absichtliches Geben von leicht unterschiedlichen Abfragen an Validatoren) könnten sie zwingen, tatsächlich zu arbeiten, anstatt zu kopieren – obwohl unklar ist, ob dies implementiert ist. Der Arxiv schlägt leistungsgewichtete Emissions- und zusammengesetzte Bewertungsmethoden vor, um den Aufwand des Validators besser mit der Belohnung zu verknüpfen. Was Miner betrifft, so wäre ein mögliches Trittbrettfahrer-Verhalten, wenn ein Miner andere Miner abfragt und die Antwort weiterleitet (eine Form von Plagiat). Bittensors Design (mit dezentralen Abfragen) könnte es einem Miner-Modell ermöglichen, andere über seinen eigenen Dendriten aufzurufen. Wenn ein Miner nur die Antwort eines anderen weiterleitet, könnte ein guter Validator dies erkennen, da die Antwort möglicherweise nicht konsistent mit den vom Miner beanspruchten Modellfähigkeiten übereinstimmt. Es ist algorithmisch schwierig zu erkennen, aber ein Miner, der niemals originelle Ergebnisse berechnet, sollte schließlich bei einigen Abfragen schlecht abschneiden und an Reputation verlieren. Ein weiteres Trittbrettfahrer-Szenario waren Delegatoren, die Belohnungen verdienten, ohne KI-Arbeit zu leisten. Das ist beabsichtigt (um Token-Inhaber einzubeziehen), also kein Angriff – aber es bedeutet, dass einige Token-Emissionen an Personen gehen, die nur gestakt haben. Bittensor rechtfertigt dies als Ausrichtung der Anreize, nicht als verschwendete Belohnungen. Kurz gesagt, Bittensor erkennt das Trittbrettfahrerproblem der Validatoren an und stimmt die Anreize ab (z. B. durch die Vergabe von Validatoren-Vertrauens-Scores, die diejenigen fördern, die nicht abweichen oder kopieren). Ihre Lösung besteht im Wesentlichen darin, Aufwand und Korrektheit expliziter zu belohnen, so dass Nichtstun oder blindes Kopieren im Laufe der Zeit weniger TAO einbringt.
  • Gensyn: In Gensyn hätten Trittbrettfahrer es schwer, zu verdienen, da man entweder Rechenleistung bereitstellen oder jemanden beim Betrug erwischen muss, um Tokens zu erhalten. Ein Solver kann Arbeit nicht „fälschen“ – er muss entweder einen gültigen Nachweis einreichen oder das Risiko des „Slashing“ eingehen. Es gibt keinen Mechanismus, um bezahlt zu werden, ohne die Aufgabe zu erledigen. Ein Verifier könnte theoretisch untätig bleiben und hoffen, dass andere Betrug aufdecken – aber dann verdient er nichts (weil nur derjenige, der den Fraud Proof vorlegt, die Belohnung erhält). Wenn zu viele Verifier versuchen, Trittbrett zu fahren (Aufgaben nicht tatsächlich neu berechnen), könnte ein betrügerischer Solver durchrutschen, weil niemand prüft. Gensyns Anreizdesign begegnet dem durch die Jackpot-Belohnung: Es braucht nur einen aktiven Verifier, um einen Betrug zu erwischen und eine große Auszahlung zu erhalten, daher ist es rational, dass mindestens einer immer die Arbeit erledigt. Andere, die keine Arbeit leisten, schaden dem Netzwerk nicht, außer dass sie nutzlos sind; sie erhalten auch keine Belohnung. Das System filtert Trittbrettfahrer also natürlich heraus: Nur diejenigen Verifier, die tatsächlich verifizieren, werden langfristig Gewinn machen (andere verschwenden Ressourcen für Knoten umsonst oder ergattern sehr selten zufällig eine Belohnung). Das Protokoll könnte auch zufällig auswählen, welcher Verifier die Möglichkeit erhält, eine Anfechtung vorzunehmen, um alle Verifier davon abzuhalten, anzunehmen, „jemand anderes wird es tun“. Da Aufgaben einzeln bezahlt werden, gibt es kein Analogon zu „Staking-Belohnungen ohne Arbeit“, abgesehen von Testnet-Anreizen, die temporär sind. Ein Bereich, den man beobachten sollte, ist die Multi-Task-Optimierung: Ein Solver könnte versuchen, Arbeit zwischen Aufgaben wiederzuverwenden oder sie heimlich an jemanden billigeren auszulagern (z. B. eine zentralisierte Cloud nutzen) – aber das ist kein wirklich schädliches Trittbrettfahren; wenn sie korrekte Ergebnisse pünktlich liefern, spielt es keine Rolle, wie sie es getan haben. Das ist eher Arbitrage als ein Angriff. Zusammenfassend lässt Gensyns Mechanismusdesign wenig Raum für Trittbrettfahrer, um zu gewinnen, da jeder verteilte Token einer erledigten Aufgabe oder einem bestraften Betrug entspricht.
  • Cuckoo: Cuckoos Anfangsphase schuf unbeabsichtigt ein Trittbrettfahrerproblem: Der Airdrop und das High-Yield-Staking zogen Benutzer an, die nur da waren, um Tokens zu farmen. Diese Benutzer würden Tokens durch Faucets zirkulieren lassen oder die Airdrop-Aufgaben manipulieren (zum Beispiel kontinuierlich kostenlose Test-Prompts verwenden oder viele Konten erstellen, um Belohnungen zu beanspruchen), ohne zum langfristigen Netzwerkwert beizutragen. Cuckoo erkannte dies als Problem – im Wesentlichen nutzten die Leute das Netzwerk nicht für KI-Outputs, sondern für spekulative Belohnungsgewinne. Die Entscheidung, die L1-Kette zu beenden und sich neu zu konzentrieren, diente teilweise dazu, diese Fehlausrichtungen der Anreize zu beseitigen. Indem zukünftige Token-Belohnungen an die tatsächliche Nutzung gebunden werden (d. h., man verdient, weil der Dienst tatsächlich von zahlenden Kunden genutzt wird), nimmt die Attraktivität des Trittbrettfahrens ab. Es gibt auch ein minerseitiges Trittbrettfahrer-Szenario: Ein Miner könnte beitreten, Aufgaben zugewiesen bekommen und diese irgendwie nicht ausführen, aber trotzdem Belohnungen beanspruchen. Der Koordinator überprüft jedoch die Ergebnisse – wenn ein Miner keine oder schlechte Outputs zurückgibt, wird der Koordinator dies nicht als abgeschlossene Aufgabe zählen, sodass der Miner nicht bezahlt würde. Miner könnten auch versuchen, einfache Aufgaben auszuwählen und schwierige fallen zu lassen (zum Beispiel, wenn einige Prompts langsamer sind, könnte ein Miner die Verbindung trennen, um sie zu vermeiden). Dies könnte ein Problem sein, aber Koordinatoren können die Zuverlässigkeit eines Miners beachten. Wenn ein Miner häufig ausfällt, kann der Koordinator aufhören, ihm Aufgaben zuzuweisen, oder seinen Stake „slashen“ (falls ein solcher Mechanismus existiert oder ihn einfach nicht belohnen). Benutzer-Trittbrettfahren – da viele KI-Dienste kostenlose Testphasen haben, könnte ein Benutzer Anfragen spammen, um Outputs ohne Bezahlung zu erhalten (wenn es ein subventioniertes Modell gibt). Das ist weniger ein Protokoll- als ein Dienstleistungsproblem; jeder Koordinator kann entscheiden, wie er mit kostenloser Nutzung umgeht (z. B. eine kleine Zahlung oder Drosselung verlangen). Da Cuckoo anfangs Werbegeschenke (wie kostenlose KI-Bildgenerierungen, um Benutzer anzuziehen) verteilte, nutzten einige dies aus, aber das war Teil des erwarteten Wachstumsmarketings. Wenn diese Aktionen enden, müssen Benutzer bezahlen, sodass es kein kostenloses Mittagessen mehr zu nutzen gibt. Insgesamt zielt Cuckoos neue Strategie, die Token-Verteilung an den tatsächlichen Nutzen zu koppeln, explizit darauf ab, das Trittbrettfahrerproblem des „Mining von Tokens für sinnlose Schleifen“ zu eliminieren.

• Daten- oder Modellvergiftung: Dies bezieht sich auf das böswillige Einführen schlechter Daten oder Verhaltensweisen, sodass die KI-Modelle sich verschlechtern oder Outputs manipuliert werden, sowie auf Probleme mit schädlichen oder voreingenommenen Inhalten, die beigesteuert werden.

  • Bittensor: Datenvergiftung in Bittensor würde bedeuten, dass ein Miner absichtlich falsche oder schädliche Antworten gibt oder Validatoren gute Antworten absichtlich falsch bewerten. Wenn ein Miner konsistent Müll oder bösartigen Inhalt ausgibt, werden Validatoren niedrige Bewertungen vergeben, und dieser Miner wird wenig verdienen und schließlich ausscheiden – der wirtschaftliche Anreiz ist, Qualität zu liefern, sodass das „Vergiften“ anderer dem Angreifer keinen Nutzen bringt (es sei denn, sein Ziel ist reine Sabotage auf eigene Kosten). Könnte ein bösartiger Miner andere vergiften? In Bittensor trainieren Miner sich nicht direkt gegenseitig (zumindest nicht von Natur aus – es gibt kein globales Modell, das aktualisiert wird und vergiftet werden könnte). Das Modell jedes Miners ist separat. Sie lernen in dem Sinne, dass ein Miner interessante Beispiele von anderen nehmen könnte, um sich selbst feinabzustimmen, aber das ist völlig optional und jedem selbst überlassen. Wenn ein böswilliger Akteur unsinnige Antworten spammen würde, würden ehrliche Validatoren dies herausfiltern (sie würden es niedrig bewerten), sodass es den Trainingsprozess eines ehrlichen Miners nicht wesentlich beeinflussen würde (außerdem würde ein Miner wahrscheinlich das Wissen von hoch bewerteten Peers nutzen, nicht von niedrig bewerteten). Klassische Datenvergiftung (Einspeisung schlechter Trainingsdaten zur Korruption eines Modells) ist in Bittensors aktueller Konfiguration minimal. Das relevantere Risiko ist die Manipulation von Modellantworten: z. B. ein Miner, der subtil voreingenommene oder gefährliche Inhalte ausgibt, die für Validatoren nicht offensichtlich sind. Da Validatoren jedoch auch von Menschen entworfen oder zumindest algorithmische Agenten sind, wird offensichtliche Toxizität oder Fehler wahrscheinlich erkannt (einige Subnetze könnten sogar KI-Validatoren haben, die auf unsichere Inhalte prüfen). Ein Worst-Case-Szenario wäre, wenn ein Angreifer irgendwie eine Mehrheit der Validatoren und Miner dazu bringen könnte, eine bestimmte falsche Ausgabe als „korrekt“ durchzusetzen – sie könnten dann den Konsens des Netzwerks über Antworten verzerren (wie alle kolludierenden Validatoren eine bösartige Antwort hochstufen). Aber damit ein externer Benutzer dadurch geschädigt wird, müsste er das Netzwerk tatsächlich abfragen und der Ausgabe vertrauen. Bittensor befindet sich noch in einer Phase, in der es Fähigkeiten aufbaut, und wird von Endbenutzern nicht weit verbreitet für kritische Abfragen verwendet. Bis dahin hofft man, dass es Inhaltsfilterung und eine Vielfalt von Validatoren haben wird, um solche Risiken zu mindern. Auf der Validatorenseite könnte ein bösartiger Validator vergiftete Bewertungen einspeisen – z. B. einen bestimmten ehrlichen Miner konsequent herabstufen, um den Wettbewerb zu eliminieren. Mit genügend Stake könnten sie erfolgreich sein, diesen Miner zu verdrängen (wenn die Belohnungen des Miners so stark sinken, dass er geht). Dies ist ein Angriff auf den Anreizmechanismus. Auch hier gilt: Wenn sie nicht die Mehrheit sind, wird das Median-Clipping einen Ausreißer-Validator vereiteln. Wenn sie die Mehrheit sind, verschmilzt es mit dem Kollusions-/51%-Szenario – jede Mehrheit kann Regeln umschreiben. Die Lösung kehrt zur Dezentralisierung zurück: verhindern, dass eine einzelne Entität dominiert. Zusammenfassend bestraft Bittensors Design vergiftete Daten-/Modellbeiträge über sein Bewertungssystem – schlechte Beiträge erhalten geringes Gewicht und somit geringe Belohnung. Es gibt kein permanentes Modell-Repository zum Vergiften; alles ist dynamisch und wird kontinuierlich bewertet. Dies bietet Resilienz: Das Netzwerk kann schlechte Akteure allmählich „vergessen“ oder ignorieren, da ihre Beiträge von Validatoren herausgefiltert werden.
  • Gensyn: Wenn ein Solver ein zu trainierendes Modell vergiften wollte (z. B. eine Hintertür oder eine Verzerrung während des Trainings einführen), könnte er versuchen, dies heimlich zu tun. Das Gensyn-Protokoll würde überprüfen, ob das Training gemäß dem angegebenen Algorithmus (stochastische Gradientenabstiegs-Schritte usw.) verlief, würde aber nicht unbedingt erkennen, ob der Solver einen subtilen Hintertür-Trigger eingeführt hat, der in normalen Validierungsmetriken nicht auftaucht. Dies ist ein heimtückischeres Problem – es ist kein Fehler der Berechnung, sondern eine Manipulation innerhalb der zulässigen Freiheitsgrade des Trainings (wie das Anpassen von Gewichten an eine Triggerphrase). Die Erkennung dessen ist ein aktives Forschungsproblem in der ML-Sicherheit. Gensyn hat keinen speziellen Mechanismus zur Modellvergiftung, abgesehen davon, dass der Submitter das endgültige Modell auf einem Testset seiner Wahl bewerten könnte. Ein versierter Submitter sollte das zurückgegebene Modell immer testen; wenn er feststellt, dass es bei einigen Eingaben fehlschlägt oder ein seltsames Verhalten aufweist, kann er das Ergebnis anfechten oder die Zahlung verweigern. Vielleicht könnte das Protokoll einem Submitter erlauben, bestimmte Akzeptanzkriterien festzulegen (wie „Modell muss mindestens X Genauigkeit auf diesem geheimen Testset erreichen“), und wenn das Ergebnis des Solvers fehlschlägt, wird der Solver nicht vollständig bezahlt. Dies würde eine Vergiftung abschrecken, da der Angreifer die Bewertungskriterien nicht erfüllen würde. Wenn das Gift jedoch die Genauigkeit bei normalen Tests nicht beeinträchtigt, könnte es durchrutschen. Verifier in Gensyn überprüfen nur die Berechnungsintegrität, nicht die Modellqualität, sodass sie absichtliches Overfitting oder Trojaner nicht erkennen würden, solange die Trainingsprotokolle gültig aussehen. Dies bleibt also ein Vertrauensproblem auf Aufgabenebene: Der Submitter muss entweder darauf vertrauen, dass der Solver das Modell nicht vergiften wird, oder Methoden wie das Ensembling mehrerer Trainingsergebnisse von verschiedenen Solvern verwenden, um den Einfluss eines einzelnen Solvers zu verwässern. Ein weiterer Aspekt ist die Datenvergiftung: Wenn der Submitter Trainingsdaten bereitstellt, könnte ein böswilliger Solver diese Daten ignorieren und auf etwas anderem trainieren oder Mülldaten hinzufügen. Dies würde jedoch wahrscheinlich die Genauigkeit verringern, was der Submitter an der Leistung des Ausgabemodells bemerken würde. Der Solver würde dann keine volle Zahlung erhalten (da er vermutlich ein Leistungsziel erreichen möchte). Eine Vergiftung, die die Leistung beeinträchtigt, ist also für die Belohnung des Solvers selbstzerstörerisch. Nur ein Gift, das leistungsneutral, aber bösartig ist (eine Hintertür), ist eine echte Gefahr, und das liegt außerhalb des Bereichs der typischen Blockchain-Verifizierung – es ist eine Herausforderung der Machine-Learning-Sicherheit. Gensyns beste Minderung ist wahrscheinlich sozial: bekannte, seriöse Modelle verwenden, mehrere Trainingsläufe durchführen, Open-Source-Tools verwenden. Bei Inferenzaufgaben (wenn Gensyn auch für Inferenzjobs verwendet wird) könnte ein kolludierender Solver falsche Outputs zurückgeben, die eine bestimmte Antwort verzerren. Aber Verifier würden falsche Outputs erkennen, wenn sie dasselbe Modell ausführen, sodass dies weniger eine Vergiftung als vielmehr Betrug ist, den die Fraud Proofs adressieren. Zusammenfassend lässt sich sagen, dass Gensyn den Prozess, nicht die Absicht, sichert. Es stellt sicher, dass das Training/die Inferenz korrekt durchgeführt wurde, aber nicht, dass das Ergebnis gut oder frei von versteckten Gemeinheiten ist. Das bleibt ein offenes Problem, und Gensyns Whitepaper löst dies wahrscheinlich noch nicht vollständig (nur wenige tun dies).
  • Cuckoo: Da Cuckoo derzeit auf Inferenz (Bereitstellung bestehender Modelle) fokussiert ist, ist das Risiko von Daten-/Modellvergiftung relativ begrenzt auf Output-Manipulation oder Inhaltsvergiftung. Ein böswilliger Miner könnte versuchen, das Modell, das er ausführen soll, zu manipulieren – z. B. wenn er einen Stable Diffusion Checkpoint erhält, könnte er ihn durch ein anderes Modell ersetzen, das vielleicht ein subtiles Wasserzeichen oder eine Werbung in jedes Bild einfügt. Der Koordinator (der der Modelleigentümer ist) sendet Aufgaben jedoch typischerweise mit einer Erwartung an das Ausgabeformat; wenn ein Miner konsistent nicht-spezifikationsgerechte Outputs zurückgibt, wird der Koordinator diesen Miner kennzeichnen und sperren. Außerdem können Miner ein Modell nicht einfach ändern, ohne dessen Outputs merklich zu beeinflussen. Ein weiteres Szenario ist, wenn Cuckoo von der Community trainierte Modelle einführt: Dann könnten Miner oder Datenanbieter versuchen, die Trainingsdaten zu vergiften (zum Beispiel viele falsche Labels oder voreingenommenen Text einzugeben). Cuckoo müsste eine Validierung von Crowd-sourced-Daten oder eine Gewichtung der Mitwirkenden implementieren. Dies ist noch keine Funktion, aber das Interesse des Teams an personalisierter KI (wie ihre Erwähnung von KI-Life-Coaches oder Lern-Apps) bedeutet, dass sie möglicherweise irgendwann benutzerbereitgestellte Trainingsdaten verarbeiten werden, was sorgfältige Überprüfungen erfordert. Was die Inhaltssicherheit betrifft, so könnte man sich, da Cuckoo-Miner Inferenz durchführen, Sorgen machen, dass sie schädliche Inhalte ausgeben, selbst wenn das Modell dies normalerweise nicht tun würde. Miner haben jedoch keinen Anreiz, Outputs willkürlich zu ändern – sie werden für korrekte Berechnung bezahlt, nicht für Kreativität. Wenn überhaupt, könnte ein böswilliger Miner die vollständige Berechnung überspringen, um Zeit zu sparen (z. B. ein unscharfes Bild oder eine generische Antwort zurückgeben). Der Koordinator oder Benutzer würde dies sehen und diesen Miner herabstufen (und wahrscheinlich nicht für diese Aufgabe bezahlen). Datenschutz ist ein weiterer Aspekt: Ein böswilliger Miner könnte Benutzerdaten leaken oder protokollieren (z. B. wenn ein Benutzer sensible Texte oder Bilder eingibt). Dies ist keine Vergiftung, sondern ein Angriff auf die Vertraulichkeit. Cuckoos Datenschutzhaltung ist, dass es datenschutzfreundliche Methoden erforscht (die Erwähnung eines datenschutzfreundlichen VPN im Ökosystem deutet auf einen zukünftigen Fokus hin). Sie könnten Techniken wie sichere Enklaven oder geteilte Inferenz integrieren, um Daten vor Minern privat zu halten. Noch nicht implementiert, aber eine bekannte Überlegung. Schließlich betont Cuckoos Blog die effektive Überprüfung von Modellausgaben und die Sicherstellung eines sicheren dezentralen Modellbetriebs als Schlüssel zur Realisierung der Modell-Tokenisierung. Dies deutet darauf hin, dass sie sich bewusst sind, dass man, um KI wirklich zu dezentralisieren, sich gegen Dinge wie vergiftete Outputs oder fehlerhafte Modelle schützen muss. Möglicherweise beabsichtigen sie, eine Kombination aus kryptoökonomischen Anreizen (Stake-Slashing für schlechte Akteure) und Benutzerbewertungssystemen (Benutzer können schlechte Outputs kennzeichnen, und diese Miner verlieren Reputation) zu verwenden. Das Reputationssystem kann hier helfen: Wenn ein Miner auch nur ein offensichtlich bösartiges oder falsches Ergebnis zurückgibt, können Benutzer/Koordinatoren ihn herabstufen, was seine zukünftige Verdienstfähigkeit stark beeinträchtigt. In dem Wissen darum sind Miner motiviert, konsistent