Análisis: los permisos para la minería de Bitcoin con IA dependen de los controles del sitio y de las versiones del software

Paolo Ardoino quiere que la IA opere minas de Bitcoin, pero el agente de referencia MDK v0.11 de Tether exige aprobación humana antes de invocar su herramienta de acciones sobre los equipos. Cada sitio minero debe determinar quién puede autorizar esas acciones. Tether anunció el 24 de octubre compromisos de 15 participantes del sector para desarrollar y mantener integraciones con el Mining Development Kit. MDK es un marco de código abierto que conecta equipos de minería, pools y aplicaciones.

Los participantes son BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital, Luxor Technology, ACME Swisstech, Elektron Energy, EMCD, F2Pool, Heatbit, OCEAN, Proto, SpiderPool y Stratum V2. En virtud del acuerdo, los participantes desarrollarán y mantendrán Workers, software que convierte las interfaces existentes de hardware, pools o sistemas en la interfaz compartida de MDK. Cada empresa decide qué funciones pone a disposición. Las aplicaciones pueden usar la interfaz compartida en lugar de necesitar una integración individual para cada fabricante. Tether afirma que el agente de minería QVAC ya usa MDK como demostración inicial. El anuncio de Tether no reveló la capacidad de las flotas participantes, su proporción del hashrate de Bitcoin ni los ahorros medidos.

La herramienta de acción de referencia v0.11 se dirige a un único dispositivo identificado por su nombre y permite reiniciarlo o cambiar su modo de energía. El controlador verifica que el dispositivo sea compatible antes de emitir un comando para cambiar el modo de energía a bajo, normal, alto o suspensión. Estas capacidades de referencia no limitan las funciones que los desarrolladores podrían ofrecer mediante otras aplicaciones o Workers de MDK. La herramienta de referencia está clasificada como una operación de escritura, y el ciclo de ejecución se detiene y genera un evento de aprobación pendiente antes de llamar a herramientas que requieren aprobación; el rechazo bloquea la invocación. El complemento de agente Gateway establece un período de aprobación predeterminado de dos minutos, tras el cual se rechaza una solicitud que no haya recibido respuesta.

El complemento v0.11 asocia las sesiones y las aprobaciones con la identidad de origen, y utiliza un operador local compartido cuando no se proporciona una identidad de usuario. La configuración con operador compartido no permite distinguir a cada persona durante la pausa para solicitar aprobación. Una mina que despliegue esta versión debe proporcionar verificaciones de identidad y establecer permisos separados para consultar la información de los equipos y aprobar cambios en el modo de energía. El agente de referencia admite modelos QVAC locales y endpoints alojados; las configuraciones alojadas envían las instrucciones y los resultados de las herramientas al host del endpoint. La ejecución local del agente y la ubicación del modelo se configuran de forma independiente.

El documento de seguridad de v0.11 señala que las llamadas directas a command.request no reciben del Kernel ninguna comprobación de permisos. En cambio, la ruta action.push depende de los permisos que proporcione un cliente backend admitido, por lo que el punto de entrada Gateway debe obtenerlos de un usuario verificado. El Kernel coordina las solicitudes de las aplicaciones a los Workers. Una clave de acceso backend admite un proceso, pero no establece la identidad de la persona que solicita un cambio en los equipos.

La implementación de Worker de v0.11 envía comandos de red sin validar la clave del solicitante. El documento de seguridad correspondiente a esa versión advierte que un par con acceso de red a un Worker y conocimiento de su clave pública puede enviarle comandos directamente. La configuración de red y la instalación determinan esa exposición, pero no permiten afirmar que una mina concreta exponga sus Workers. La aprobación mediante el chat de referencia protege la interacción de ese agente, mientras que las restricciones integrales sobre los equipos también requieren controles para otras rutas de comandos.

Las referencias de GitHub consultadas el 24 de octubre vinculan v0.11.0 con el commit fae8fbce052a y main con el commit 35c144f240f0. Los Workers de esta última versión requieren claves de clientes admitidos, salvo que se active explícitamente la opción allowAll. El registro de cambios identificado como v0.12 describe roles de lectura, escritura y administración en Kernel, herramientas de escritura MCP optativas y verificación declarada del estado de los dispositivos. La guía de seguridad publicada que se consultó el 24 de octubre todavía describe Workers sin listas de permitidos para clientes, por lo que es necesario que la documentación se ajuste al código desplegado. El ejemplo de v0.11 no establece qué versiones de software están instaladas en QVAC o en las minas participantes.

El documento de gobernanza de MDK concede la autoridad final sobre el proyecto al equipo central. El documento otorga al responsable de mantenimiento principal la autoridad técnica final sobre las fusiones de código, la arquitectura y la planificación de versiones. También asigna al Community Manager la autoridad final sobre la dirección estratégica y la hoja de ruta. Los compromisos de integración no otorgan automáticamente a los participantes el control de las versiones de MDK, del mismo modo que la autoridad para aprobar fusiones de código en el proyecto no concede permiso para controlar equipos dentro de una mina. La política de seguridad de v0.11 ofrece correcciones de buena fe para el commit más reciente de main y advierte que los commits antiguos o las versiones etiquetadas podrían no recibir correcciones. La selección de una versión establece la base de código de un sitio, la configuración determina su implementación y las actualizaciones posteriores requieren una revisión aparte. La autorización para enviar un comando que cambie el modo de energía no equivale a confirmar que el dispositivo haya adoptado realmente el modo solicitado.