Las aplicaciones entre cadenas se están convirtiendo en la base de la Web3 moderna, lo que permite que activos, usuarios y protocolos interactúen entre múltiples redes blockchain. Sin embargo, la interoperabilidad también introduce nuevos desafíos de seguridad. Diferentes cadenas mantienen conjuntos de validadores separados, mecanismos de consenso y supuestos de confianza, lo que dificulta verificar que una acción entre cadenas esté realmente autorizada.
Newton Protocol aborda este desafío con un marco de autorización entre cadenas descentralizado que preserva la seguridad y, al mismo tiempo, habilita una interoperabilidad fluida. En lugar de depender de puentes centralizados o intermediarios de confianza, Newton utiliza un modelo verificable criptográficamente basado en operadores de EigenLayer, firmas BLS y tablas de operadores sincronizadas.
En el corazón de la arquitectura de Newton se encuentra el modelo de Cadena de Origen y Cadena de Destino. La cadena de origen—como Ethereum Mainnet o Sepolia—actúa como el hogar de la red de operadores. Aquí, los operadores se registran, apuestan activos, publican sus claves públicas BLS y permanecen sujetos a responsabilidad a través del mecanismo de slashing de EigenLayer. Las cadenas de destino, incluidas redes como Base, Arbitrum, Optimism y Polygon, son donde las aplicaciones realmente ejecutan transacciones y hacen cumplir decisiones de política.
En lugar de requerir que cada cadena de destino se comunique constantemente con Ethereum, Newton sincroniza la información de los operadores mediante un protocolo descentralizado de Sincronización de Tabla de Operadores.
Siempre que el conjunto de operadores cambie debido a nuevas inscripciones, actualizaciones de stake, bajas (deregistrations) o eventos de slashing, los operadores de Newton producen conjuntamente una raíz de Merkle firmada con BLS que representa la tabla de operadores más reciente. Este snapshot criptográfico incluye identidades de operadores, claves públicas y ponderaciones de stake en una altura de bloque específica.
Cualquiera puede retransmitir sin permisos este snapshot firmado a las cadenas de destino. Dado que cada actualización incluye una firma BLS agregada válida, las cadenas de destino pueden verificar de forma independiente la autenticidad de la tabla de operadores sin confiar en el mensajero. Esto crea un mecanismo de sincronización altamente descentralizado a la vez que evita la comunicación continua con la cadena de origen.
Newton también separa la sincronización en dos flujos de trabajo independientes.
La ruta lenta actualiza la tabla de operadores solo cuando cambia la pertenencia de los operadores. Dado que estos eventos ocurren relativamente poco, la sincronización se mantiene eficiente.
La ruta rápida se centra en verificar certificados de transacción. Una vez que la tabla de operadores más reciente está disponible localmente, las cadenas de destino solo necesitan realizar una verificación BLS ligera cada vez que se completa una evaluación de política. Esto reduce drásticamente los costos de verificación mientras mantiene garantías sólidas de seguridad.
Para que la verificación sea aún más eficiente, cada cadena de destino mantiene un Calculador de Tabla de Operadores. En lugar de buscar a cada operador individualmente, el calculador calcula continuamente claves públicas agregadas para cada quórum. Cuando llega una nueva tabla de operadores, solo se procesan los cambios, permitiendo que la verificación siga siendo rápida incluso a medida que la red crece.
La verificación entre cadenas en sí sigue un modelo de seguridad consistente.
En Ethereum, Newton puede referenciar directamente el registro BLS de EigenLayer. En las cadenas de destino, Newton en su lugar verifica un certificado BN254, que empaqueta la firma BLS agregada junto con el snapshot de operadores usado durante la evaluación. Debido a que el certificado está ligado a una cadena específica, un número de bloque y un snapshot de tabla de operadores usando datos tipados EIP-712, los ataques de repetición entre cadenas quedan efectivamente prevenidos.
La seguridad sigue fundamentada en las garantías económicas de EigenLayer.
Los operadores que aprueban tablas de operadores fraudulentas enfrentan las mismas penalizaciones de slashing que los operadores que envían evaluaciones de políticas inválidas. Corromper exitosamente el proceso de sincronización requeriría comprometer a un quórum de operadores con stake, lo que hace que los ataques sean económicamente costosos y altamente impracticables.
La arquitectura también prioriza la vivacidad. Si condiciones temporales de red impiden que suficientes operadores firmen una nueva tabla de operadores, las cadenas de destino continúan operando usando el último snapshot verificado. Solo después de que expire un umbral de obsolescencia configurable se rechazarán nuevos certificados hasta que se sincronice una tabla de operadores actualizada. Este equilibrio mantiene las aplicaciones operativas mientras evita la dependencia a largo plazo de información de validadores desactualizada.
De cara al futuro, la arquitectura de Newton está diseñada para admitir verificación con Conocimiento Cero (ZK) de actualizaciones de la tabla de operadores. En lugar de requerir un quórum de firmas, implementaciones futuras podrían generar pruebas criptográficas concisas que demuestren que el registro de operadores hizo la transición correctamente de un estado a otro. Esto reduciría aún más las suposiciones de confianza y mejoraría la escalabilidad en un ecosistema multi-cadena en expansión.
En última instancia, el Protocolo Newton transforma la interoperabilidad entre cadenas de un proceso basado en confianza a uno verificable criptográficamente. Al combinar la sincronización descentralizada de operadores, firmas BLS agregadas, verificación eficiente de certificados y tecnología de conocimiento cero lista para el futuro, Newton crea una infraestructura en la que las aplicaciones pueden autorizar transacciones con confianza en múltiples blockchains sin sacrificar la descentralización ni la seguridad.