Fui en busca de la palabra "confianza" en los materiales propios de Newton, casi por costumbre, y la encontré usada constantemente para describir lo que el protocolo elimina. Automatización sin confianza. Verificación sin confianza. Una brecha de confianza que Newton cierra.

Luego miré qué es exactamente lo que está ejecutándose por debajo de las atestaciones.

Newton verifica el comportamiento del agente combinando pruebas de conocimiento cero con la ejecución dentro de Entornos de Ejecución de Confianza, enclaves de hardware como los que ofrece Phala. El agente se ejecuta dentro del enclave; el enclave produce una atestación de que el código se ejecutó según lo especificado, y una prueba de conocimiento cero de esa atestación se comprueba en la cadena (onchain) antes de que se permita que la acción continúe.

Ese diseño es realmente ingenioso. Además, no equivale a la ausencia de confianza. Es una redistribución de la confianza.

La garantía de seguridad de un TEE se apoya, en última instancia, en que el fabricante del hardware haya construido el enclave correctamente y no haya insertado una puerta trasera, en que el firmware no haya sido modificado y en que el servicio de atestación en sí sea honesto con lo que observó. Los ataques por canal lateral contra los TEE no son hipotéticos; se ha demostrado que afectan a arquitecturas de enclaves antes, y la respuesta del sector ha consistido, en general, en aplicar parches en lugar de ofrecer una prueba limpia de que la clase de vulnerabilidad está cerrada para siempre. Nada de esto convierte a los TEE en una mala elección. Solo significa que "verificable" y "sin confianza" no son aquí exactamente sinónimos, aunque esas dos palabras se usen casi indistintamente en el material explicativo de Newton.

Lo que hace que valga la pena sentarse a considerarlo, en lugar de tratarlo como una advertencia genérica sobre criptoinfraestructura, es en qué lugar Newton coloca el enclave en la pila.

No se trata de un TEE que ejecuta cómputo periférico fuera de la cadena que luego se verifica doblemente mediante algún otro mecanismo. Es lo que ejecutan los agentes dentro antes de que sus acciones toquen los fondos del usuario bajo una concesión de zkPermissions. Si la atestación del enclave es incorrecta debido a hardware comprometido, una filtración por canal lateral o una compilación mal configurada, la prueba de conocimiento cero demuestra fielmente que se produjo una atestación falsa. La capa de ZKP solo es tan honesta como lo es la capa de TEE sobre la que está haciendo afirmaciones. No vuelve a derivar de forma independiente que el cómputo subyacente fuera correcto; prueba que el enclave dijo que lo era.

Creo que por eso el lenguaje del propio roadmap de Newton es más cuidadoso que su copia de marketing. El informe de transparencia marca "maduración de la atestación basada en TEE" como una dependencia externa que la Fundación no controla por completo, colocada junto con el rendimiento de zk VM y el soporte del proveedor de hardware como variables abiertas en lugar de problemas resueltos. Esa es una postura significativamente diferente a "automatización sin confianza", y apostaría a que es la más precisa.

También hay un ángulo práctico en esto, no solo uno epistemológico.

Actualmente, Newton depende de un número reducido de proveedores de TEE y de zk-VM para que esta arquitectura funcione en absoluto. Si el modelo de seguridad se concentra alrededor de un puñado de proveedores de hardware y de sistemas de prueba, entonces las garantías de Newton heredan el riesgo de concentración que esos proveedores conllevan: bloqueo del proveedor, una única clase de vulnerabilidad que afecta a muchos enclaves a la vez, o que un proveedor no priorice la generación de chips de la que depende la pila de Newton. Un conjunto de validadores puede ser descentralizado mientras que la suposición de confianza en el hardware subyacente se mantenga relativamente estrecha. Esas son dimensiones separadas de la descentralización, y no veo que se analicen por separado con mucha frecuencia.

Nada de esto significa que la arquitectura sea incorrecta. TEE más ZKPs es, quizá, la forma más creíble de lograr hoy ejecución verificable de agentes de IA en cadena, mejor que el ZKML puro, que todavía es demasiado lento y costoso para automatización financiera en tiempo real, y mejor que diseños que usan solo TEE, que no ofrecen ninguna verificación independiente. Newton eligió el enfoque híbrido porque, actualmente, el híbrido es el mejor compromiso disponible. Esa es una decisión de ingeniería defendible.

Pero un compromiso sigue siendo un compromiso, y creo que los usuarios que conceden zkPermissions a un agente merecen saber qué suposición de confianza están aceptando realmente: la integridad del fabricante de hardware más la honestidad del servicio de atestación, envueltas en un sistema de pruebas que verifica que la atestación se informó de manera fiel, no que el cómputo subyacente se reprodujera de forma independiente.

¿La brecha entre "verificable" y "sin confianza" es un simple error de redondeo que se cierra a medida que maduran los servicios TEE y las herramientas de zk-VM, tal como sugiere el roadmap de Newton? ¿O es una característica estructural permanente de cualquier sistema basado en TEE, una en la que la idea de "automatización verificable" seguirá subestimando durante tanto tiempo como el marketing supere al hardware?
#NEWT
#Newt $NEWT @NewtonProtocol