¿Alguien ha visto en los últimos días los mini-artículos sobre Newton Protocol? Su principal propuesta estrella que no paran de mencionar últimamente es esa supuesta “capa de automatización verificable y descentralizada”. ¿No suena súper duro, súper Web3?
Tengo un hábito: cuando veo palabras tan sofisticadas, me encanta ir al fondo de la arquitectura tecnológica. Seguí su rastro a través de la documentación de desarrollo y me quedé directamente con la boca abierta. Hay un bucle lógico fundamental que no encaja: Newton repite todos los días que es descentralizado, pero la capa TEE (entorno de ejecución confiable) de bajo nivel está toda ejecutándose en AWS (Amazon Web Services). Es decir, crees que confías en la blockchain, pero al final terminas entregando todas las claves de seguridad a Amazon.
Hoy lo diremos con palabras claras, sin filtros de ninguna industria: hablemos de cuántos “trucos” oculta eso del supuesto “automatizado descentralizado”.
1. Lo que llaman “verificable”, en el último paso, resulta que hay que mirar la cara de Amazon
Primero, todos deben entender la lógica de TEE. El código sí es inalterable, y los archivos de prueba generados también se pueden enviar a la cadena para verificarlos; sobre el papel no hay nada malo. Pero el problema es que el entorno TEE que usa Newton se ejecuta dentro de AWS Nitro Enclaves de Amazon, ¡y finalmente la prueba de cantidad remota es emitida por AWS!
¿Qué significa eso?
AWS da el “ok” y entonces tu verificación se considera válida.
Si AWS no da el visto bueno, o por algún motivo le exigen no darlo, tus operaciones automatizadas se convierten directamente en un chiste.
¿No es esto, precisamente, una “transferencia de confianza”? Solo estás trasladando la confianza en el equipo del proyecto a un gigante tradicional de Internet, el más grande del mundo: Amazon. Si esto también se llama descentralización, entonces mejor que nadie juegue con cadenas: desarrollen directamente con servidores de Web2.
2. Si ocurre una fuerza mayor, Newton ni siquiera tiene un Plan B.
Lo que también preocupa es que, al revisar a fondo la documentación técnica oficial, no encontré por ningún lado ninguna descripción sobre “plan de hardware de respaldo” ni mecanismos de desastres multi-nube.
Esto no es que yo esté preocupado sin fundamento. La gente que trabaja con tecnología sabe que, en una arquitectura con una dependencia tan alta de un solo proveedor, el riesgo no lo puede resolver el código: lo determina el interés comercial subyacente o la geopolítica externa.
Supongamos un escenario extremo: /> Un día, por cumplimiento de políticas o algún caso de fuerza mayor, el gobierno de EE. UU. exige a AWS que coopere con una revisión. Con solo levantar la mano, AWS puede detener la emisión de firmas de pruebas TEE que se ejecutan en Nitro Enclaves; entonces, la capacidad de verificación de toda la red Newton quedaría paralizada instantáneamente.
Ante un evento “cisne negro” tan destructivo, por lo visto la parte del proyecto no tiene ningún plan de contingencia en este momento.
Alguien podría salir a refutar: “Al menos aislar con hardware TEE es mejor que depender completamente del proyecto para hacer operaciones en una caja negra”?
No se puede decir así. Cuando transfieres el punto de anclaje de la confianza desde el equipo del proyecto a Amazon, en realidad cambiaste un monstruo enorme que entiendes menos y que no puedes controlar. Las estrategias internas de operación de AWS, los estándares de cumplimiento e incluso el historial de caídas, para un usuario común están completamente fuera de su alcance. En la historia de Internet, ¿cuántas veces ha tenido AWS caídas masivas? ¿Alguna vez no se acostaron junto con cientos o miles de servicios de Internet que dependen de ella? Si AWS falla, no se podrá generar la prueba de TEE; y la estrategia automatizada del usuario se bloqueará directamente a mitad de camino, quedando en una situación sin salida.
3. La cadena de confianza se estira demasiado: en medio todo se convierte en “muñecas rusas” de hardware de empresas estadounidenses
¿Crees que solo debes confiar en Amazon y ya? Desarmemos cuidadosamente la cadena de confianza de este TEE; descubrirás que las “muñecas rusas” dentro son de un nivel que da miedo.
La seguridad central del hardware TEE, en última instancia, depende de las claves raíz que los fabricantes de chips inyectan en el momento de fábrica. En el mercado actual, el hardware más común es Intel y AMD. Por tanto, si queremos completar una supuesta “operación automatizada verificable”, la ruta real de confianza sería esta:
Paso 1: Tus instrucciones de trading automatizado se entregan al protocolo Newton.
Paso 2: Newton envía la estrategia al servidor cloud de AWS para que se ejecute.
Paso 3: La ejecución TEE de AWS depende de las claves de hardware de Intel o AMD para cifrado y aislamiento.
Paso 4: Una vez finalizada la ejecución, el sistema de cumplimiento de AWS emite la prueba de medición remota.
Paso 5: Envía la prueba de vuelta a la cadena de Newton y completa la verificación final de on-chain.
Contemos: ¡hay nada menos que cinco capas de cadena de confianza! Aquí solo la última capa —es decir, el paso de verificar en la cadena— es pública y transparente en la blockchain. Las primeras cuatro capas (nodos de Newton, plataforma cloud de AWS, chips Intel y chips AMD) son entidades 100% centralizadas. Después de dar tantas vueltas, solo pasamos de “confiar en el equipo de Newton” a “confiar también en Amazon + Intel + AMD”. ¿Esto es realmente una mejora en la experiencia para una comunidad cripto que busca descentralización?
4. Lo de “pasará a futuro”, en realidad se parece más a un pastel prometido a lo lejos, sin fin
En realidad, hace mucho que en la comunidad algunos veteranos ya detectaron este problema y se lo plantearon a la parte del proyecto con una duda: “Si Newton se promociona como una capa de automatización descentralizada, ¿por qué no se encarga él mismo de montar un clúster físico de hardware TEE distribuido y, en cambio, depende de AWS por comodidad?”
En aquel momento, la respuesta oficial, a grandes rasgos, fue: “Para la eficiencia del desarrollo y la ejecución en las etapas iniciales, elegimos primero una solución de un proveedor cloud maduro. En el futuro iremos pasando gradualmente a una red completamente descentralizada de hardware físico.”
Esto es lo interesante. “¿Futuro” de verdad significa qué tan lejos? ¿Tres meses, un año, o esperar a que el proyecto no se pueda sostener y ya ni se vea? En su hoja de ruta oficial (Roadmap), Newton no escribe ni un solo hito de tiempos concretos para ese crucial “periodo de transición de descentralización del hardware”. Es decir, antes de eso, cada una de las “estrategias verificables” que se ejecutan en la red y se presentan como si fueran lo máximo, mantiene firmemente la puerta final de verificación bajo el control de los grandes centralizados.
Resumamos
Una red que se autodenomina de manera insistente “descentralizada”, pero cuyo módulo más esencial de verificación automatizada corre en el servidor cloud centralizado más grande del mundo… eso en sí mismo es una enorme ironía.
TEE es, ciertamente, una buena tecnología y es muy útil para la computación de privacidad. Pero todos deben tener la cabeza fría: la tecnología TEE en sí no resuelve el problema de “desconfianza” (trustlessness) de Web3; solo transfiere nuestra confianza en “las personas” hacia “los gigantes del hardware” y “los proveedores de servicios cloud”. Si juegas en el ecosistema cripto por el control absoluto y la resistencia a la censura, entonces la arquitectura tecnológica actual de Newton con una dependencia grave de AWS es para ti una vulnerabilidad que no puedes ignorar.
(Este artículo es una tarea de plataforma y no constituye ningún consejo de inversión.)