Analyse: KI-Bitcoin-Mining hängt von Standortkontrollen und Softwareversionen ab

Paolo Ardoino möchte, dass KI Bitcoin-Minen betreibt. Tethers Referenz-Agent MDK v0.11 verlangt jedoch eine menschliche Freigabe, bevor er sein Tool für Geräteaktionen aufruft. Jede Mining-Anlage muss festlegen, wer diese Aktionen genehmigen darf. Tether gab am 24. Oktober Zusagen von 15 Branchenakteuren bekannt, Integrationen mit dem Mining Development Kit zu entwickeln und zu warten. MDK ist ein Open-Source-Framework, das Mining-Geräte, Pools und Anwendungen miteinander verbindet.

Zu den Beteiligten zählen BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital, Luxor Technology, ACME Swisstech, Elektron Energy, EMCD, F2Pool, Heatbit, OCEAN, Proto, SpiderPool und Stratum V2. Im Rahmen der Vereinbarung werden die Beteiligten Workers entwickeln und warten – Software, die bestehende Schnittstellen von Hardware, Pools oder Systemen in die gemeinsame MDK-Schnittstelle überführt. Jedes Unternehmen entscheidet, welche Funktionen es verfügbar macht. Anwendungen können die gemeinsame Schnittstelle nutzen, statt für jeden Hersteller eine eigene Integration zu benötigen. Tether zufolge nutzt der QVAC-Mining-Agent MDK bereits als frühe Demonstration. In Tethers Mitteilung wurden weder die Kapazität der teilnehmenden Flotten noch ihr Anteil an der Bitcoin-Hashrate oder gemessene Einsparungen genannt.

Das Referenz-Tool für Aktionen in v0.11 zielt auf ein einzelnes, namentlich angegebenes Gerät und unterstützt einen Neustart oder eine Änderung des Energiemodus. Der Handler prüft, ob das Gerät unterstützt wird, bevor er einen Befehl zur Änderung des Energiemodus für „low“, „normal“, „high“ oder „sleep“ ausführt. Diese Referenzfunktionen beschränken nicht die Funktionen, die Entwickler über andere MDK-Anwendungen oder Workers bereitstellen könnten. Das Referenz-Tool ist als Schreiboperation eingestuft. Die Ausführungsschleife hält bei einem Ereignis für eine ausstehende Freigabe an, bevor sie Tools aufruft, für die eine Freigabe erforderlich ist; bei Ablehnung wird der Aufruf blockiert. Das Gateway-Agent-Plugin legt standardmäßig eine Freigabefrist von 2 Minuten fest. Wird eine Anfrage bis dahin nicht beantwortet, wird sie abgelehnt.

Das Plugin in v0.11 ordnet Sitzungen und Freigaben der ursprünglichen Identität zu und verwendet einen gemeinsam genutzten lokalen Operator, wenn keine Benutzeridentität angegeben ist. Die Konfiguration mit einem gemeinsam genutzten Operator kann einzelne Personen während der Freigabe nicht unterscheiden. Eine Mine, die diese Version einsetzt, muss Identitätsprüfungen bereitstellen und separate Berechtigungen für das Anzeigen von Geräteinformationen und das Genehmigen von Änderungen des Energiemodus festlegen. Die Agentenreferenz unterstützt lokale QVAC-Modelle und gehostete Endpunkte. Bei gehosteten Konfigurationen werden Prompts und Tool-Ergebnisse an den Host des Endpunkts gesendet. Die lokale Ausführung des Agenten und der Standort des Modells werden unabhängig voneinander konfiguriert.

Das Sicherheitskonzept von v0.11 besagt, dass direkte Aufrufe von command.request vom Kernel keiner Berechtigungsprüfung unterzogen werden. Die Route action.push stützt sich dagegen auf Berechtigungen, die ein zugelassener Backend-Aufrufer bereitstellt. Daher muss der Gateway-Einstiegspunkt diese Berechtigungen von einem verifizierten Nutzer beziehen. Der Kernel koordiniert Anfragen von Anwendungen an Workers. Ein Backend-Zugriffsschlüssel lässt einen Prozess zu, weist aber nicht die Identität der Person nach, die eine Geräteänderung beantragt.

Die Worker-Implementierung in v0.11 leitet Netzwerkbefehle weiter, ohne den Schlüssel des Aufrufers zu überprüfen. Das mit dem Versions-Tag versehene Sicherheitskonzept warnt, dass ein Peer mit Netzwerkzugriff auf einen Worker und Kenntnis seines öffentlichen Schlüssels direkt Befehle übermitteln kann. Die Netzwerkkonfiguration und die Installation bestimmen, ob diese Angriffsfläche besteht; daraus folgt nicht, dass Workers in einer bestimmten Mine exponiert sind. Die Freigabe über den Referenz-Chat schützt diese Agenteninteraktion. Um Geräte umfassend einzuschränken, müssen jedoch auch andere Befehlswege kontrolliert werden.

GitHub-Verweise, die am 24. Oktober geprüft wurden, ordnen v0.11.0 dem Commit fae8fbce052a und „main“ dem Commit 35c144f240f0 zu. Workers in letzterem Snapshot verlangen zugelassene Aufruferschlüssel, außer wenn die explizite Einstellung allowAll aktiviert ist. Das mit v0.12 gekennzeichnete Changelog beschreibt Lese-, Schreib- und Administrationsrollen für den Kernel, optional aktivierbare MCP-Schreibtools und eine deklarierte Überprüfung des Gerätestatus. Der am 24. Oktober abgerufene veröffentlichte Sicherheitsleitfaden beschreibt weiterhin Workers ohne Zulassungsliste für Aufrufer. Daher müssen Dokumentation und eingesetzter Code aufeinander abgestimmt sein. Das v0.11-Beispiel belegt nicht, welche Softwareversionen bei QVAC oder den teilnehmenden Minen installiert sind.

Das Governance-Dokument von MDK überträgt dem Kernteam die endgültige Projektverantwortung. Dem Dokument zufolge hat der Lead Maintainer die endgültige technische Entscheidungsbefugnis bei Zusammenführungen, Architektur und Release-Planung. Die endgültige Entscheidungsbefugnis für die strategische Ausrichtung und die Roadmap weist das Dokument dem Community Manager zu. Integrationszusagen verleihen den Beteiligten nicht automatisch Kontrolle über MDK-Releases – ebenso wenig wie die Befugnis, Änderungen in das Upstream-Projekt zu übernehmen, eine Berechtigung zum Steuern von Geräten in einer Mine verleiht. Die Sicherheitsrichtlinie von v0.11 sieht Fehlerbehebungen nach bestem Bemühen für den neuesten Commit im main-Branch vor und warnt, dass ältere Commits oder mit einem Versions-Tag versehene Releases möglicherweise keine Fehlerbehebungen erhalten. Die Versionswahl legt die Codebasis eines Standorts fest; die Konfiguration bestimmt die Umsetzung, und spätere Updates müssen gesondert geprüft werden. Die Freigabe zum Senden eines Befehls zur Änderung des Energiemodus ist nicht gleichbedeutend mit der Bestätigung, dass das Gerät den angeforderten Modus tatsächlich aktiviert hat.