Dilema de la “transferencia de confianza” en la IA verificable
Al leer documentación técnica, vi una frase: cada vez que el razonamiento obtiene una “prueba verificable”, el punto final de la confianza no es las matemáticas, sino la firma de AWS.
Esa frase me hizo detenerme. Cuando se registra un nodo TEE en la cadena, la lógica de verificación es “comprobar si la prueba está firmada por la raíz CA de AWS Nitro”. Dicho en sencillo: esto no es “sin necesidad de confiar”, sino trasladar la confianza del proyecto a AWS.
Lo que aún más pone los pelos de punta es el historial de seguridad del propio TEE. Intel SGX, que salió al mercado en 2015 y fue descontinuado por Intel en 2022, tuvo tantas vulnerabilidades en esos 7 años que lo llegaron a llamar “un colador”. L1TF/Foreshadow pudieron leer directamente los datos en la zona aislada de SGX mediante canales laterales; Plundervolt, manipulando el voltaje, podía destruir la integridad de esa zona aislada.
La capa de verificación de OPG no es más sólida que la de los predecesores. Pero lo que más inquieta a quien lo sostiene no son solo las vulnerabilidades del hardware en sí, sino un problema lógico aún más fundamental: el TEE puede demostrar que “el código se ejecuta en el enclave y no ha sido alterado”, pero no puede demostrar que “ese código no tiene errores”. Si el software con el que corre el nodo de inferencia contiene fallos lógicos, el TEE igualmente lo firmará y lo subirá a la cadena.
La “prueba verificable” que obtienes verifica únicamente que “el código no ha sido tocado”, no que “el código esté bien”. En cuanto se compromete el TEE, la privacidad y la integridad de toda la capa de verificación se desvanecen al instante.
No confías en las matemáticas, sino en un chip que podría fallar en cualquier momento.
#OPG $OPG @OpenGradient $BTC
Al leer documentación técnica, vi una frase: cada vez que el razonamiento obtiene una “prueba verificable”, el punto final de la confianza no es las matemáticas, sino la firma de AWS.
Esa frase me hizo detenerme. Cuando se registra un nodo TEE en la cadena, la lógica de verificación es “comprobar si la prueba está firmada por la raíz CA de AWS Nitro”. Dicho en sencillo: esto no es “sin necesidad de confiar”, sino trasladar la confianza del proyecto a AWS.
Lo que aún más pone los pelos de punta es el historial de seguridad del propio TEE. Intel SGX, que salió al mercado en 2015 y fue descontinuado por Intel en 2022, tuvo tantas vulnerabilidades en esos 7 años que lo llegaron a llamar “un colador”. L1TF/Foreshadow pudieron leer directamente los datos en la zona aislada de SGX mediante canales laterales; Plundervolt, manipulando el voltaje, podía destruir la integridad de esa zona aislada.
La capa de verificación de OPG no es más sólida que la de los predecesores. Pero lo que más inquieta a quien lo sostiene no son solo las vulnerabilidades del hardware en sí, sino un problema lógico aún más fundamental: el TEE puede demostrar que “el código se ejecuta en el enclave y no ha sido alterado”, pero no puede demostrar que “ese código no tiene errores”. Si el software con el que corre el nodo de inferencia contiene fallos lógicos, el TEE igualmente lo firmará y lo subirá a la cadena.
La “prueba verificable” que obtienes verifica únicamente que “el código no ha sido tocado”, no que “el código esté bien”. En cuanto se compromete el TEE, la privacidad y la integridad de toda la capa de verificación se desvanecen al instante.
No confías en las matemáticas, sino en un chip que podría fallar en cualquier momento.
#OPG $OPG @OpenGradient $BTC