Paolo Ardoino vuole che l'IA gestisca le miniere di Bitcoin. Chi ottiene il permesso di agire?

Il tentativo di Paolo Ardoino di portare l'IA nel mining di Bitcoin ha al suo centro una decisione umana: chi può autorizzare una macchina a cambiare ciò che sta facendo? L'agente di riferimento MDK v0.11 di Tether interrompe il suo strumento di azione per l'approvazione umana, mentre il sito deve stabilire chi ha diritto a concederla.

Questa distinzione è importante poiché Tether ha annunciato impegni da parte di 15 partecipanti del settore il 24 ottobre per costruire e mantenere integrazioni con il suo Mining Development Kit, un framework open-source che collega attrezzature di mining, pool e applicazioni. Un'interfaccia comune può fornire al software un modo coerente per raggiungere diversi sistemi. Il permesso di agire dipende ancora dall'installazione.

L'esempio v0.11 non stabilisce quale codice QVAC o miniere partecipanti siano state installate. Il codice più recente del ramo principale aggiunge restrizioni ai chiamanti assenti da quel tag. Il controllo del sito dipende quindi sia da chi può emettere comandi sia da quale software upstream la miniera adotta.

Dalle integrazioni ai comandi delle attrezzature

L'elenco di Tether include BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital e Luxor Technology. Nomina anche ACME Swisstech, Elektron Energy, EMCD, F2Pool, Heatbit, OCEAN, Proto, SpiderPool e Stratum V2.

Sotto l'accordo annunciato, i partecipanti costruiranno e manterranno Workers: software che traduce l'hardware esistente di un'azienda, pool o interfaccia di sistema nel linguaggio comune dell'MDK. Ogni azienda sceglie le funzioni che espone. Un'applicazione può quindi utilizzare quell'interfaccia piuttosto che richiedere un'integrazione separata per ogni produttore.

Tether afferma che il suo agente di mining QVAC opera già su MDK come dimostrazione iniziale. L'annuncio non fornisce capacità della flotta partecipante, quota di hash rate di Bitcoin o risparmi misurati.

Lo strumento di azione del sito di riferimento v0.11 accetta un dispositivo nominato e offre due operazioni: riavviarlo o cambiare la sua modalità di alimentazione. Le opzioni di modalità di alimentazione sono bassa, normale, alta e sonno, con il gestore che verifica quali modalità quel dispositivo supporta prima di inviare il comando.

Queste sono le capacità dell'esempio, piuttosto che un tetto su ogni applicazione o Worker che qualcuno potrebbe costruire con MDK.

Lo strumento di riferimento è esplicitamente contrassegnato come scrittura. Quando il ciclo di esecuzione dell'agente incontra uno strumento classificato come richiedente approvazione, emette un evento di approvazione in sospeso e si interrompe prima di invocarlo. Il rifiuto impedisce la chiamata. Il plugin dell'agente Gateway documenta una finestra di approvazione predefinita di due minuti, con una richiesta non risposta che si risolve in un rifiuto.

Il plugin v0.11 lega sessioni e approvazioni all'identità che le ha create. Quando non viene fornita alcuna identità utente, le richieste utilizzano un operatore locale condiviso. In quella configurazione, una pausa di approvazione non distingue un umano da un altro.

Una miniera che assembla questa versione deve quindi collegare i propri controlli di identità alla superficie di approvazione. La persona autorizzata a visualizzare i dati delle attrezzature e la persona autorizzata ad approvare un cambiamento della modalità di alimentazione necessitano di permessi stabiliti dal sito.

La stessa scelta di distribuzione si applica ai dati. L'agente di riferimento supporta modelli QVAC locali e endpoint ospitati; con un fornitore ospitato, i prompt e i risultati degli strumenti lasciano il sito per l'host di quell'endpoint. Eseguire un agente localmente e scegliere dove eseguire il suo modello sono decisioni di configurazione separate.

Il percorso del comando cambia il controllo dei permessi

Il blueprint di sicurezza v0.11 contrassegnato distingue i comandi diretti dalle azioni soggette ad approvazione. Le chiamate dirette command.request non hanno alcun controllo dei permessi lato Kernel. Il percorso separato action.push utilizza i permessi forniti da un chiamante backend ammesso, quindi il Gateway, il punto di ingresso dell'applicazione, deve derivarli da un utente verificato.

Qui, il Kernel coordina le richieste tra le applicazioni e i Workers. Una chiave che consente a un processo backend di contattarlo stabilisce l'ammissione di quel processo. Non identifica l'umano che richiede una modifica.

L'implementazione del Worker v0.11 aggiunge un altro confine da considerare: la sua interfaccia di comando di rete invia richieste senza controllare la chiave del chiamante. Il blueprint contrassegnato avverte che un peer in grado di raggiungere un Worker e indirizzare la sua chiave pubblica può inviare comandi direttamente. Tale esposizione dipende dalla rete e dall'installazione; non stabilisce che una particolare miniera esponga i suoi Workers.

Di conseguenza, un'approvazione nella chat di riferimento copre quell'interazione dell'agente. Limitare ogni percorso verso l'attrezzatura richiede controlli anche sugli altri punti di accesso.

Il nuovo codice del repository cambia questo quadro. I riferimenti di GitHub controllati il 24 ottobre mappano v0.11.0 al commit fae8fbce052a e main a 35c144f240f0. Nello snapshot fissato successivo, i Workers richiedono chiavi di chiamante ammesse a meno che non sia abilitata un'impostazione esplicita allowAll.

Il changelog etichettato v0.12 descrive anche i ruoli del Kernel per lettura, scrittura e amministrazione, strumenti di scrittura MCP su opt-in e verifica dichiarata dello stato del dispositivo.

Nel frattempo, la guida alla sicurezza pubblicata recuperata il 24 ottobre descrive ancora i Workers senza liste di autorizzazione per i chiamanti. Un operatore deve abbinare la guida al codice distribuito prima di trattare entrambi come la descrizione delle protezioni di un sito.

L'autorità di rilascio rimane con il progetto

La scelta di software di una miniera la collega anche alla governance del rilascio di MDK. Il documento di governance del progetto conferisce al team centrale l'autorità finale sul progetto, al Lead Maintainer l'autorità tecnica finale su fusioni, architettura e pianificazione dei rilasci, e al Community Manager l'autorità finale sulla direzione strategica e sulla roadmap.

Un impegno di integrazione non conferisce di per sé a un partecipante l'autorità sui rilasci di MDK. Allo stesso modo, l'autorità di unire codice upstream non stabilisce il permesso di emettere comandi all'interno di una miniera.

Ciò rende la revisione degli aggiornamenti una responsabilità operativa. La politica di sicurezza v0.11 afferma che le correzioni sono gestite su base di miglior sforzo per l'ultimo commit principale e che i commit più vecchi o i rilasci contrassegnati potrebbero non riceverli. Scegliere una versione fissa la base del codice del sito, mentre la configurazione determina come quel codice viene utilizzato. Le modifiche successive necessitano della propria revisione.

La distinzione nel nuovo changelog tra accettazione dei comandi e conferma dello stato del dispositivo risultante illustra ciò che è in gioco. Il permesso di inviare un'istruzione di modalità di potenza e la prova che la macchina ha raggiunto la modalità richiesta rispondono a domande operative diverse.

L'autonomia di una miniera dipende da chi può approvare le scritture, quali programmi backend possono raggiungere l'attrezzatura e chi adotta gli aggiornamenti software.