Anoche me quedé despierto revisando@NewtonProtocol la documentación técnica, y esa línea, aparentemente casual, de “Non-EVM support is on the roadmap” disparó al instante mi nivel de alerta.
现阶段的$NEWT es que corre en el AVS de EigenLayer. Las policy enforcement que utiliza para la verificación, en esencia, se dedican a tratar el estado de cadenas compatibles con Ethereum. Aunque el whitepaper enumera con gran elocuencia los logros de Ethereum, Arbitrum e incluso Base, en cuanto te atreves a preguntar por Solana o Sui, esas cadenas no EVM, la respuesta se transforma de inmediato en ese inexistente mapa de ruta. Me quedé mirando la pantalla y calculé durante un buen rato: si un motor de infraestructura que todo el día presume ser “chain-agnostic” en realidad solo puede leer el bytecode de Solidity en sus nodos de verificación, entonces ¿cómo se supone que va a hacer cumplir esas políticas de seguridad en cadenas heterogéneas?
Pongamos el Solana más típico como ejemplo para razonar este dilema técnico. Supongamos que hoy quiero, en Solana, configurar con Newton-guarded wallet una estrategia de seguridad que limite el desvío de activos de gran cuantía por día. Esta regla debe obtener el sello de confirmación de los nodos de la red AVS de Newton. Pero el problema mortal está en que las estructuras de datos y el modelo de cuentas de Solana son completamente dos universos paralelos al de EVM. Los nodos EVM ya están acostumbrados a analizar formatos de prueba de Merkle Patricia Trie, pero Solana utiliza precisamente otra variante de árbol Merkle; los formatos de prueba criptográfica de la base no pueden interoperar directamente. Hablé de esto con un amigo que desarrolla arquitectura multi-cadena, y sin rodeos me dijo: si quieres romper de verdad las fronteras entre cadenas para implementar verificación de estado, o inviertes una fortuna para construir por tu cuenta un cliente ligero que mantenga el estado multi-cadena, o solo te queda una salida: ceder y aceptar un puente entre cadenas externo. $BTC
Siguiendo esta inferencia, estas dos rutas tienen costos demasiado abrumadores. Escribir tú mismo el trabajo de ingeniería de un cliente ligero multi-cadena es prácticamente como volver a “inventar la rueda”, y al usar puentes entre cadenas es como exponer directamente la seguridad de tu capa de verificación, construida con tanto esfuerzo, a una crisis de confianza de terceros puentes. Muchos equipos de infraestructura que presumen de cobertura total multi-cadena, en el día a día solo repiten en voz alta el “roadmap”, pero en privado quizá ni siquiera hayan probado un borrador técnico básico. Esto no es en absoluto que yo quiera desanimarte a propósito con gafas de color; es que en la documentación oficial actual ni siquiera puedes encontrar un cronograma, y menos aún pruebas de código sustanciales.
Otro quiebre técnico más sutil está en la compatibilidad entre cadenas de las claves de session key. Siguiendo la documentación, descubrí que la session key, que Newton considera un modelo de seguridad central, en realidad es un tema delicado. En el ecosistema EVM, aprovechando la “ventaja” de ERC-4337 account abstraction, emitir una clave temporal con permisos limitados para que el agent ejecute operaciones automatizadas hace que todo el ciclo lógico encaje de forma bastante fluida. Pero si trasladas esta mecánica a Solana de manera forzada, te darás cuenta de que ni siquiera existe la distinción a nivel de base entre cuentas EOA y cuentas de contrato. Esa diferencia de filosofía subyacente de cuentas implica que, si metes de manera rígida en Solana toda esta arquitectura de gestión de claves basada en ERC-4337, prácticamente habría que rehacer por completo el flujo de firmas y de autenticación; suena muy bien la estandarización entre cadenas, pero el código no miente. $ETH
Esto ni siquiera es lo que más me pone ansioso. Ejecutar la validación de attestation BLS de Newton en una cadena EVM tiene un costo que es prácticamente insignificante, porque tienen contratos precompilados dedicados a atender esa curva BLS12-381. Pero si lo piensas con cuidado, el soporte de esas precompilaciones para cadenas heterogéneas es completamente distinto. La misma verificación de firma criptográfica, si la ejecutas a la fuerza sin optimizaciones específicas, hará que el consumo de recursos computacionales se dispare de forma exponencial. Creo haber calculado en un borrador que esa brecha de potencia de cómputo subyacente probablemente haga que ejecutar una policy enforcement en una cadena que no sea EVM cueste al menos diez veces más que en el ecosistema de Ethereum. Un supuesto “estándar unificado de seguridad”, si al final permite que una parte de usuarios juegue casi gratis pero obliga a otra parte a pagar tarifas de verificación astronómicas, entonces el significado de ese estándar a través de cadenas deja de existir.
En realidad entiendo muy bien por qué la parte del proyecto tiene que elegir así. Primero se enfocan en el ecosistema EVM para que su red de verificación y su motor de políticas se conviertan en estándar; al fin y al cabo, allí se concentra la gran mayoría de fondos activos, y en términos de ingeniería es una jugada que parece buena. Pero el riesgo letal de esta estrategia está en el desalineamiento serio entre el relato y los fundamentos. El entusiasmo actual se basa en la gran expectativa de que podrá unificar todas las cadenas públicas. Muchos minoristas están comprando esa idea amplia. Si en algún punto futuro todos descubren que el soporte a cadenas que no sean EVM está lejos de llegar, entonces esas frases de marketing sobre “chain-agnostic” se convertirán instantáneamente en una broma. Para ese momento, la lógica de valuación que han inflado, probablemente se enfrenta a un peligro de colapso de la noche a la mañana.
Ahora mismo no me atrevo a entrar con todo solo por unas cuantas consignas bonitas. Las condiciones que me impuse para añadir exposición están muy claras: no me importa cómo “venden” el futuro con planes de desarrollo; me fijo solo en dos datos duros. Primero: si realmente puede presentar un borrador técnico concreto y una línea de tiempo para verificar cadenas que no sean EVM. Segundo: cuándo en la testnet podrá ejecutarse de verdad un ejemplo de interceptación de políticas en Solana. Ayer pasé un eterno un par de horas rastreando datos en un explorador de blockchain; al final no encontré ningún registro sustancial de operaciones que pudiera demostrar el soporte para cadenas heterogéneas, así que simplemente terminé cerrando la página. Comprar transacciones a veces funciona así: frente a una caja negra tecnológica donde el ciclo lógico no puede cerrarse, contenerse y no comprar sin pensar también es una forma de autoprotección. Claro que esto podría ser solo una concesión del equipo para salir rápido; seguiré vigilando sus envíos de código posteriores para ver cómo, al final, van a cerrar el “gran espectáculo” entre cadenas.