Introducción

Mirando hacia atrás, los rollups han surgido como la solución definitiva de escalabilidad para Ethereum y la tecnología descentralizada en general. Nueve meses después de la actualización de Dencun de Ethereum, que se centró en la escalabilidad de la disponibilidad de datos de rollup, el rendimiento de las transacciones ha superado…doscientas transacciones por segundolo que representa un aumento de cinco veces en lo que va del año. Los dos principales rollups, Arbitrum y OP Mainnet, han alcanzado la etapa 1 de descentralización:superando a varias redes alternativas prominentes de Capa 1en las métricas de descentralización, con rollups adicionales potencialmente apuntando a la descentralización de la etapa 2 en 2025. La tecnología de prueba de conocimiento cero ha progresado para permitirverificación de transacciones equivalentes a Ethereum a costos subcentavos, estableciendo un camino para la verificación eficiente de miles de transacciones estándar de usuarios en la contemporánea cadena de bloques Ethereum.

Sin embargo, este avance presenta nuevos desafíos. Múltiples equipos están desarrollando blockchains independientes sobre Ethereum, con una interoperabilidad limitada entre ellas. Esta limitación se debe principalmente a la finalización infrecuente de los rollups, lo que dificulta una comunicación significativa entre cadenas. Además, los rollups optimistas, que actualmente albergan la mayoría de la actividad del ecosistema y el Valor Total Bloqueado (TVL), enfrentan limitaciones técnicas inherentes que impiden la comunicación directa fuera de los puentes compartidos, creando una barrera significativa para la interoperabilidad entre redes importantes como Arbitrum y Base. La comunidad ha propuesto varias soluciones, que van desde el puenteo basado en la intención y los intercambios atómicos hasta la abstracción de cadena integral. A pesar de sus diferencias, estas soluciones comparten un requisito fundamental: una fuente confiable de verdad, un protocolo que permita la verificación segura del estado entre rollups de manera rápida y rentable.

Entre las soluciones destacadas, que normalmente se basan en oráculos optimistas (Across), consenso de operadores especializados (Stargate a través de LayerZero) o confianza en secuenciador centralizado (Polymer Hub), la capa de finalidad rápida (NFFL) de Nuffle Labs presenta un equilibrio convincente entre eficiencia, seguridad y alineación con Ethereum. Este documento examina el enfoque innovador de NFFL para habilitar la verificación de estado cruzado de rollup a través del mecanismo de reinversión de EigenLayer y NEAR DA, explora su diseño arquitectónico y hoja de ruta de desarrollo, y analiza las posibles aplicaciones y sus implicaciones para el ecosistema.

Tu Ethereum Edge

Obtenga investigaciones de primera mano entregadas por nuestro equipo de expertos.

Tu dirección de correo electrónico

Antecedentes

Para entender los desafíos que aborda NFFL, examinemos la arquitectura fundamental de rollups, sus objetivos y sus limitaciones inherentes.

Introducción a los Rollups

Un rollup es una cadena de bloquesque utiliza otra cadena de bloques independiente para el ordenamiento de transacciones, disponibilidad de datos y consenso, mientras ejecuta transacciones externamente de una manera verificable por la cadena principal. Si bien muchas definiciones se refieren a la cadena principal como Capa 1 (L1) y al rollup como Capa 2 (L2), algunos marcos no requieren que los L2 utilicen el L1 para la disponibilidad de datos. Para mayor claridad, este documento se centra específicamente en los rollups en lugar de la categoría L2 más amplia.

Un ejemplo de esta distinción: todos los rollups son L2s, pero no todos los L2s son necesariamente rollups. Fuente: blog.thirdweb.com

Por supuesto, en nuestro caso, el L1 principal es la cadena de bloques de Ethereum. Es responsable de compartir su consenso con los rollups (explicaremos esto más adelante). Analicemos cómo los rollups aprovechan Ethereum para sus funciones principales: ordenación de transacciones, disponibilidad de datos y consenso.

Ordenación de transacciones

Los rollups incorporan una entidad llamada secuenciador, responsable de gestionar la inclusión y el orden de las transacciones a través de la red L1. El secuenciador funciona de manera análoga a un productor de bloques en blockchains tradicionales. Específicamente, acepta transacciones entrantes de usuarios secuencialmente, las agrega en lotes (comparables a bloques L1) y publica periódicamente estos lotes en un contrato inteligente designado en la L1.

Un contrato inteligente en el L1 mantiene un registro autoritario de todas las transacciones publicadas y su ordenación. Los nodos de Rollup deben monitorear este contrato para recuperar nuevos bloques e información de transacciones. Una vez que un lote se incluye en un bloque L1 y ese bloque alcanza la finalidad a través del consenso L1, la inclusión y el ordenamiento de todas las transacciones dentro de ese lote están garantizados por las propiedades de seguridad de L1.

Hasta cierto punto, el secuenciador es un “iniciador” del rollup, ya que ayuda al rollup a aceptar realmente nuevas transacciones en la red, facilitando el avance del estado. Algunos rollups implementan secuenciación descentralizada: un conjunto rotativo de entidades especializadas que reducen el riesgo de inactividad de un secuenciador centralizado; y secuenciación basada, que no utiliza ningún secuenciador como fuente de confianza antes de publicar el lote en la L1. En cambio, la secuenciación basada permite que cualquiera sea un secuenciador, pero sus lotes solo son utilizados por los nodos cuando se publican en la L1. Esto prácticamente no supone riesgo de inactividad de secuenciación, a costa de una inclusión de transacciones más lenta (el escenario óptimo es de 12 segundos por bloque en L1).

Sin embargo, los secuenciadores no deciden sobre el nuevo estado de las cosas en el rollup, incluso después de la ejecución de sus propios lotes. Por lo tanto, los secuenciadores “inician” pero no necesariamente “ejecutan” el rollup, ya que sus acciones no pueden llevar directamente a la transición de estado malintencionada.

Un arrancador del motor. Aunque no hace funcionar el motor, sin él, el motor tampoco funcionaría. Piensa en el rollup como el motor y en el secuenciador como el arrancador.

Disponibilidad de datos

Sin embargo, la información sobre el ordenamiento de algunas transacciones no es suficiente para los nodos de rollup, ya que no poseen las propias transacciones. Para ejecutar estas transacciones y determinar su resultado en la cadena de bloques del rollup, los nodos deben tener acceso completo e irrestricto a todas las transacciones del lote.

En consecuencia, los secuenciadores de rollup deben publicar datos completos de transacciones en la L1 de manera que permita al contrato inteligente del rollup verificar disponibilidad de datosUna vez que los datos de transacción de un lote se incluyen y se finalizan en el L1, su disponibilidad está garantizada para todos los nodos participantes.

Antes de la actualización de Dencun, los rollups de Ethereum publicaban datos de transacciones en los datos de entrada (calldata) de las llamadas de secuenciación en L1. Por lo tanto, todas las transacciones debían haberse publicado en la cadena de bloques de L1 para siempre. Esto puede parecer razonable, ya que queremos que todos los nodos, incluidos los futuros, puedan reconstruir el estado del rollup. Sin embargo, esto es muy ineficiente, ya que Ethereum L1 no puede almacenar grandes cantidades de datos en su libro mayor, mientras que los rollups, los carriles de alta velocidad de Ethereum, son muy intensivos en datos. En su lugar, podemos hacer que el contrato inteligente del rollup verifique la validez de las transacciones secuenciadas, para que los nodos sigan instantáneamente el estado en el contrato, en lugar de reconstruirlo a partir de todas las transacciones desde el génesis.

Puente Consagrado (Consensus)

Para simplificar, hemos invertido la definición del rollup al revés. Por lo general, todas las explicaciones comienzan con un puente bidireccional entre el rollup y su L1. Es bastante común entre los rollups utilizar la moneda nativa de L1 como propia, para simplificar la estimación de las tarifas de gas en función de los gastos de los secuenciadores y proponentes. Además, muchos rollups desean obtener tokens populares en su ecosistema desde el primer día, para lo cual la mejor opción es transferirlos desde su L1.

Implementar un contrato inteligente de puente desde L1 hasta el rollup es bastante sencillo: los nodos de rollup ya escuchan todo lo que sucede en su contrato, por lo que podemos implementar una función de depósito de L1 que todos los nodos interpretarán como un comando para emitir el respectivo token “envuelto” en el propio rollup.

Sin embargo, los retiros sin confianza requieren que el contrato puente valide todas las transacciones rollup y determine sus resultados legítimos. Esto permite que el puente procese solicitudes de retiro válidas liberando fondos a iniciadores autorizados en el L1. Este mecanismo de validación convierte al puente en la fuente definitiva del estado canónico del rollup, y los nodos se alinean con la transición de estado del puente independientemente de las bifurcaciones de la cadena alternativa. A diferencia de las blockchains tradicionales, los rollups no implementan reglas de consenso independientes para la selección de la cadena. El contrato puente en el L1 es lo que define la cadena canónica.

Blobs

La actualización Dencun de Ethereum de marzo pasado había introducido “blobs” - celdas temporales de datos que se almacenan fuera de la cadena de bloques y se eliminan (borradas por los validadores de la red) después de ~18 días. A medida que los puentes rollup hacen posible reconstruir el estado sin volver a ejecutar transacciones, esta propiedad se volvió muy útil para los rollups, que migraron de calldata a blobs poco después de la actualización. Hablando de números, antes de Dencun, la TPS total de los rollups era de alrededor de 50. Hoy, es más de 200, con límites teóricos en400-800 TPS dependiendo de rollup.

Fuente: L2BEAT

Además de las mejoras de capacidad, los blobs eliminaron la necesidad de pagar los costos de gas de EVM para el almacenamiento de datos de transacción, estableciendo un canal separado con almacenamiento temporal especializado y precios de tarifas independientes. Este cambio arquitectónico ha reducido drásticamente los costos de transacción en rollups, con tarifas que pasan de 10-40 centavos por transacción a niveles inferiores a un centavo en redes como Base.

Origen: growthepie.xyz

Liquidación Rollup

Si bien los secuenciadores se encargan de la ordenación y publicación de las transacciones, solo representan un componente de la arquitectura de rollup. Los rollups también incorporan entidades llamadas ‘proposers’ responsables de convencer al puente L1 de las salidas de estado específicas resultantes de lotes recién secuenciados. En esencia, mientras que los secuenciadores establecen la ocurrencia y el orden de las transacciones, los proposers demuestran los resultados de estas transacciones de acuerdo con la lógica de procesamiento del rollup, como su máquina virtual.

El papel del proponente varía significativamente según el enfoque de validación de estado del rollup. Existen dos metodologías fundamentalmente diferentes que definen dos categorías de rollups: Optimistas y de Conocimiento Cero (ZK).

Optimistic Rollups

En rollups optimistas, los proponentes envían regularmente actualizaciones de estado al puente L1, típicamente junto o poco después de las publicaciones de lotes del secuenciador. Estas actualizaciones de estado incluyen la nueva raíz de estado (un compromiso criptográfico con todo el nuevo estado del rollup) después de ejecutar todas las transacciones en los últimos lotes.

Para evitar actualizaciones de estado inválidas, el puente implementa un período de desafío (normalmente de 7 días) durante el cual actores especializados llamados “desafiantes” pueden impugnar la propuesta mediante la presentación de una prueba de fraude. Esta prueba demuestra que las transacciones se ejecutaron incorrectamente mediante la reejecución de la transacción impugnada en L1 y comparando los resultados.

Si un retador demuestra con éxito que un proponente presentó una transición de estado inválida, la salida de estado se revierte y el retador es recompensado (a menudo de un bono que los proponentes deben publicar). Esto crea un juego económico en el que se incentiva a los proponentes a presentar solo transiciones de estado válidas.

Zero-Knowledge Rollups

En los rollups de ZK, los proponentes generan pruebas matemáticas (llamadas “pruebas de validez” o, más técnicamente correctas, “pruebas de ZK”) que demuestran la corrección de cada transición de estado. Estas pruebas muestran que todas las transacciones en un lote se ejecutaron de acuerdo con las reglas del rollup sin revelar los detalles específicos de su ejecución.

El puente L1 puede verificar rápidamente estas pruebas utilizando operaciones criptográficas eficientes, por aproximadamente el costo de un intercambio de tokens. Una vez que se verifica una prueba, el puente acepta la actualización de estado como resuelta. Esto significa que los proponentes deben realizar un trabajo computacional significativo antes de enviar actualizaciones de estado, pero esas actualizaciones se resuelven mucho más rápido en comparación con los rollups optimistas.

Liquidación, Finalidad e Interoperabilidad

El tiempo de liquidación a través de puentes canónicos varía significativamente entre los tipos de rollup, desde 7 días para rollups optimistas debido a su período de desafío, hasta varias horas para rollups ZK debido a la generación de pruebas y los costos de publicación por lotes. Si bien este modelo funciona bien para asegurar transacciones de alto valor que pueden tolerar retrasos, crea fricciones significativas para el ecosistema DeFi en general.

Considera cómo esto afecta el uso en el mundo real: un usuario que quiera usar su garantía basada en Arbitrum para obtener un préstamo en Base primero debe transferir sus activos y esperar hasta 7 días antes de poder usarlos. Un trader que identifica una oportunidad de arbitraje entre los pools de Uniswap en diferentes rollups vería desaparecer la oportunidad mucho antes de poder ejecutarla. Una aplicación de juegos que quiera permitir a los jugadores intercambiar objetos entre diferentes implementaciones de rollup tendría una experiencia de usuario inaceptable con tales retrasos tan largos.

La idea crucial aquí es que los nodos de rollup pueden observar los cambios de estado mucho más rápido, generalmente en cuestión de segundos después de la confirmación del bloque L1. Si bien este estado no ha pasado por un proceso de liquidación completo en el puente canónico, se basa en datos de transacciones que ya han sido ordenados y finalizados en Ethereum. Muchos intercambios centralizados ya aprovechan esta propiedad, acreditando los depósitos de los usuarios desde los rollups después de solo unas pocas confirmaciones de bloque mediante la ejecución de sus propios nodos y verificando la finalidad de las transacciones en L1.

Esto crea una interesante dicotomía en el ecosistema de rollups. Si bien los rollups han escalado con éxito la capacidad de transacción de Ethereum, han introducido una grave fragmentación del estado y la liquidez. Cada rollup opera efectivamente como una blockchain independiente que no puede verificar eficientemente el estado de otros rollups sin esperar el establecimiento del puente, a pesar de que todos derivan su seguridad de la misma cadena subyacente: Ethereum.

Soluciones existentes

El ecosistema ha desarrollado varios enfoques para superar estas limitaciones, desde puentes centralizados hasta redes especializadas fuera de la cadena. Estas soluciones suelen hacer diferentes compensaciones entre tres propiedades clave:

• Seguridad - ¿Cuán fuertes son las garantías de que la verificación del estado es correcta
• Velocidad: qué tan rápido se puede verificar el estado en todas las cadenas
• Costo: qué tan caro es mantener y usar la solución

La mayoría de las soluciones existentes optimizan la velocidad y el costo a expensas de la seguridad, a menudo confiando en operadores de confianza, multisigs o mecanismos optimistas con un respaldo económico mínimo. Esto ha llevado a varios hacks de puentes de gran repercusión, especialmente la explotación del puente Ronin de $625 millones, destacando los riesgos de sacrificar la seguridad por conveniencia.

El desafío fundamental es establecer una ‘fuente de verdad’ segura sobre los estados de rollup que pueden:

• Verificar cambios de estado en segundos o minutos en lugar de horas o días
• Proporcionar fuertes garantías de seguridad criptoeconómica
• Operar de manera rentable tanto para los proveedores de infraestructura como para los usuarios
• Integrarse perfectamente con las arquitecturas de rollup existentes

Esta oportunidad de habilitar una verificación de estado rápida y segura entre rollups ha generado una importante innovación. Diversos equipos están abordando el problema desde diferentes ángulos, buscando crear infraestructuras que puedan impulsar la próxima generación de aplicaciones entre cadenas sin comprometer la seguridad.

En las siguientes secciones, exploraremos cómo NFFL aborda este desafío a través de su combinación novedosa de restake de EigenLayer y NEAR DA, creando una capa de finalidad rápida que logra un equilibrio cuidadoso entre seguridad, velocidad y rentabilidad.

NFFL Deep Dive

Tesis central

La Capa de Finalidad Rápida Nuffle (NFFL) representa un enfoque novedoso para habilitar interacciones seguras entre cadenas mediante la verificación rápida del estado entre rollups. En lugar de obligar a los desarrolladores a elegir entre seguridad y velocidad, NFFL aprovecha el ETH restaked de EigenLayer para crear una capa de finalidad rápida segura desde el punto de vista criptoeconómico que puede atestiguar los estados de rollup en cuestión de segundos.

En su núcleo, NFFL funciona como un Servicio de Validación Activa (AVS) que se ejecuta en EigenLayer. Una red descentralizada de operadores, cada uno ejecutando nodos completos para participar en rollups, verifica y certifica las actualizaciones de estado. Estas certificaciones están respaldadas por el ETH reestacado de los operadores, creando fuertes incentivos económicos para un comportamiento honesto. Al combinar esto con la capa de disponibilidad de datos de NEAR para el almacenamiento eficiente de datos de bloques, NFFL permite que las aplicaciones verifiquen de manera segura el estado de cadena cruzada en 2-3 segundos, órdenes de magnitud más rápido que el asentamiento de puente canónico.

Arquitectura de diseño simplificado de NFFL

Lo que hace que NFFL sea particularmente atractivo es su enfoque de diseño pragmático. En lugar de intentar reemplazar o competir con el modelo de seguridad de Ethereum, proporciona una capa complementaria optimizada para casos de uso que requieren una finalización más rápida. Las aplicaciones pueden elegir si confiar en la seguridad cripto-económica de NFFL o esperar el asentamiento completo de L1 según sus necesidades específicas. Esta flexibilidad permite a NFFL mejorar la experiencia del usuario para muchas interacciones entre cadenas mientras mantiene fuertes garantías de seguridad.

El sistema introduce tres innovaciones clave:

1. Una red de operadores descentralizada que logra consenso en los estados de rollup mediante la comparación de las transiciones de estado ejecutadas localmente con los datos de bloque publicados en NEAR DA
2. Un sistema de tareas basado en checkpoints que permite la agregación eficiente y verificación de las certificaciones del operador mientras mantiene la responsabilidad a través de los mecanismos de penalización de EigenLayer.
3. Un mecanismo de almacenamiento de datos utilizando NEAR DA que permite una fácil recuperación de datos de rollup atestados en todos los rollups

Este diseño permite que NFFL encuentre un equilibrio cuidadoso entre seguridad, velocidad y rentabilidad, tres propiedades que tradicionalmente han estado en desacuerdo en la infraestructura de cadena cruzada. Al proporcionar una verificación de estado rápida pero segura, NFFL abre nuevas posibilidades para aplicaciones de cadena cruzada que van desde protocolos de préstamos hasta agregadores de liquidez.

En las siguientes secciones, exploraremos detalladamente la arquitectura de NFFL, examinando cómo sus diversos componentes trabajan juntos para permitir esta nueva primitiva para la interacción entre cadenas. También analizaremos su modelo de seguridad, discutiremos posibles aplicaciones y veremos el plan de ruta del protocolo para el desarrollo futuro.

Componentes principales

Conjunto de operadores

En el corazón de NFFL se encuentra su red de operadores, un sistema descentralizado que extiende la seguridad de Ethereum para permitir una verificación rápida de cross-rollup. En lugar de crear otra red aislada que requiera sus propias suposiciones de seguridad, NFFL se construye como un Servicio Validado Activamente (AVS) en EigenLayer, lo que le permite conectarse directamente al ecosistema validador existente de Ethereum.

Esta elección arquitectónica es fundamental para entender el modelo de seguridad de NFFL. Los mismos validadores que aseguran el consenso de Ethereum pueden volver a apostar su ETH a través de EigenLayer para convertirse en operadores de NFFL. Al hacerlo, ponen en riesgo su ETH apostado para respaldar sus certificaciones sobre los estados de rollup. Esto crea un poderoso puente de seguridad entre el consenso de Ethereum y la capa de finalización rápida de NFFL.

Cuando un rollup publica nuevos datos de bloque en el L1, los relayers lo reenvían a NEAR DA. Los operadores recuperan los datos de bloque a través de ambas fuentes y se aseguran de que sean equivalentes. Explicaremos más adelante por qué es necesario publicar datos de rollup en NEAR DA para hacer que las aplicaciones que utilizan NFFL sean más convenientes para los usuarios y desarrolladores.

Después de recuperar nuevos lotes de rollup, los operadores los ejecutan en sus nodos de rollup. Dado que todos ejecutan el mismo software de nodo, siempre aparecerán con la misma y correcta salida de estado. Este resultado de estado luego es firmado por todos los operadores. Cuando la mayoría de los operadores está de acuerdo en un estado específico, es aceptado por el sistema y puede ser transmitido a los contratos de registro en todos los rollups.

La seguridad económica de dicho sistema tiene una propiedad muy interesante que proviene de la mecánica de penalización de EigenLayer:

En EigenLayer, los Servicios Validados Activamente pueden implementar un mecanismo de verificación que sea capaz de detectar las declaraciones inválidas de los operadores y recortar (liquidar) su depósito posteriormente. Como NFFL “preliminarmente liquida” el estado del rollup fuera de la cadena antes de que se liquide en el puente, es posible detectar objetivamente el fraude esperando el retraso de la liquidación y notificando al contrato AVS sobre la inconsistencia de la salida en la declaración y el puente. Esto desincentiva económicamente las declaraciones fraudulentas, ya que pueden ser detectadas y recortadas por cualquier entidad que observa el estado de L1 y NFFL, incluso sin que ejecuten nodos de rollup. En otras palabras, NFFL “asegura” las afirmaciones de la red: los operadores ponen un capital significativo en riesgo para respaldar sus afirmaciones sobre los estados de rollup.

Lo que hace esto particularmente poderoso es cómo alinea los incentivos en todo el sistema. Los operadores ganan tarifas por participación honesta, mientras arriesgan pérdidas significativas por deshonestidad. Cuanto más ETH se reinvierte en NFFL, más fuertes se vuelven estos incentivos. Y debido a que esta seguridad se deriva de Ethereum a través de EigenLayer, en parte se beneficia del mismo sólido modelo de seguridad económica que asegura cientos de miles de millones en valor en Ethereum mismo.

Flujo de mensajería

El sistema de mensajería de NFFL representa un enfoque innovador para manejar la verificación de estado entre cadenas a gran escala. En lugar de registrar cada certificación de estado en la cadena, lo cual sería prohibitivamente costoso, NFFL introduce un sistema de dos capas de Mensajes y Tareas que permite una operación eficiente fuera de la cadena mientras mantiene garantías sólidas de seguridad en la cadena según sea necesario.

Los mensajes son la unidad básica de comunicación en NFFL. Cuando los operadores verifican un nuevo estado, crean y firman un mensaje que atestigua ese estado. Estos mensajes existen principalmente fuera de la cadena, circulando entre los operadores y el agregador sin incurrir en costos de gas en la cadena. Hay dos tipos distintos de mensajes que fluyen a través del sistema:

• Los mensajes de actualización de la raíz del estado contienen la certificación de un operador sobre el estado de un rollup en una altura de bloque específica. Cada mensaje incluye no solo la raíz del estado en sí, sino también una referencia a la transacción NEAR DA que contiene los datos del bloque, creando un vínculo verificable entre el estado atestiguado y sus datos subyacentes.
• La actualización del conjunto de operadores rastrea los cambios en el conjunto de operadores de NFFL. Estos mensajes son cruciales para la seguridad del sistema, ya que permiten a los contratos de registro rollup mantener un registro actualizado de operadores válidos, asegurando que las acreditaciones solo sean aceptadas de participantes autorizados con una participación en riesgo.

Si bien los Mensajes permiten una verificación eficiente del estado, por sí solos no son suficientes para garantizar la seguridad económica del sistema. Aquí es donde entran en juego las Tareas. Las Tareas son unidades de trabajo en cadena que verifican el estado del sistema en intervalos regulares. En lugar de enviar cada Mensaje a Ethereum, los operadores construyen periódicamente un Árbol Merkle Disperso que contiene todos los Mensajes de un período de tiempo específico. La raíz de este árbol se envía como respuesta de una Tarea, creando un compromiso eficiente en cadena para todas las certificaciones fuera de cadena.

Este sistema de punto de control es particularmente inteligente porque permite la verificación selectiva de cualquier Mensaje sin requerir que todos los Mensajes se almacenen en la cadena. A través de pruebas de Merkle, cualquier persona puede verificar que un Mensaje específico se incluyó en un punto de control, lo que permite mecanismos de desafío eficientes y costos básicos bajos. Puedes pensar en ello como la creación de una ‘blockchain de certificaciones’, donde los puntos de control sirven como encabezados de bloque que se comprometen con todos los Mensajes dentro de un período de tiempo.

El agregador juega un papel crucial en este sistema al recolectar firmas de operadores y ponerlas a disposición a través de una API. Cuando los operadores firman mensajes, los envían al agregador que verifica que las firmas hayan alcanzado el quórum (ponderado por ETH apostado) antes de exponerlos para su uso por parte de las aplicaciones. Esto crea una interfaz limpia para los desarrolladores al tiempo que mantiene las propiedades de seguridad descentralizadas del sistema. Ampliaremos sobre el servicio del agregador en la siguiente sección.

Servicio de agregación

El agregador actúa como la capa de coordinación de NFFL, gestionando eficientemente el flujo de mensajes entre operadores y aplicaciones. Aunque conceptualmente sencillo, su diseño refleja una cuidadosa consideración tanto de las necesidades prácticas de los desarrolladores como de los principios de descentralización.

En su núcleo, el agregador resuelve el problema de la ‘tragedia de los comunes’ en la agregación de firmas. Sin un servicio dedicado, cada aplicación que use NFFL tendría que recopilar y verificar de forma independiente las firmas de todos los operadores, lo cual es un proceso ineficiente y costoso. En cambio, el agregador proporciona un único punto de recopilación de firmas de operadores, verifica el quórum y expone las certificaciones verificadas a través de una API sencilla.

El proceso de agregación de firmas funciona de la siguiente manera:

• Los operadores firman de forma independiente mensajes que atestiguan actualizaciones de estado
• Estas firmas se envían al agregador para su recopilación
• El agregador verifica la validez de la firma y realiza un seguimiento del quórum
• Una vez que se alcanza suficiente peso de participación, la firma agregada se vuelve disponible
• Las aplicaciones pueden obtener estas certificaciones a través de la API del agregador

Este diseño reduce significativamente la complejidad para los desarrolladores que integran NFFL. En lugar de manejar operaciones criptográficas complejas o rastrear apuestas de operadores, las aplicaciones pueden simplemente solicitar certificaciones para actualizaciones de estado específicas a través de una interfaz API clara. El agregador maneja toda la complejidad de la recopilación de firmas, verificación y agregación BLS detrás de escena.

Agregación de firmas

Vamos a explorar más a fondo la agregación BLS utilizada por NFFL. Las firmas BLS tienen una potente propiedad matemática que permite combinar múltiples firmas en una sola. En lugar de verificar N firmas individuales de los operadores, lo cual sería computacionalmente costoso e intensivo en gas, las aplicaciones pueden verificar una sola firma agregada que demuestra un acuerdo colectivo.

Las ganancias de eficiencia aquí son sustanciales. Cuando los operadores de NFFL firman un Mensaje, generan firmas BLS estándar utilizando sus claves privadas. El agregador puede luego combinar estas firmas individuales en una firma compacta que demuestra acuerdo de quórum. El tamaño y el costo de verificación de esta firma agregada permanecen constantes independientemente de cuántos operadores participaron, una propiedad que hace que el sistema sea altamente escalable.

Además, la firma agregada se puede verificar con las claves públicas combinadas de los operadores de firma, ponderadas por las cantidades apostadas para asegurar que la seguridad económica se tenga en cuenta adecuadamente. El contrato de registro solo necesita realizar una operación de verificación de firma para confirmar que el peso suficiente de la apuesta ha atestiguado la actualización del estado.

Aggregator y Checkpoints

Es importante tener en cuenta que, si bien el agregador proporciona comodidad, no compromete el modelo de seguridad de NFFL. Las firmas que recopila son públicamente verificables y su papel es puramente organizativo en lugar de autoritario. Las aplicaciones siempre pueden verificar de forma independiente que las firmas agregadas representen un jurado legítimo de operadores con participación. El agregador no puede falsificar firmas ni ocultar certificaciones válidas, simplemente las hace más accesibles.

El agregador también desempeña un papel vital en el sistema de punto de control. Al recopilar todos los mensajes con el tiempo, puede construir los árboles de Merkle dispersos utilizados en las tareas de punto de control. Esto crea un registro eficiente de todas las certificaciones que han pasado a través del sistema, lo que permite su verificación posterior si es necesario para desafíos de seguridad o fines de auditoría.

Contratos de registro

El contrato de Registro, implementado en cada rollup participante, sirve como el puente crítico entre las certificaciones externas de NFFL y la verificación del estado en cadena. Estos contratos permiten a las aplicaciones verificar sin confianza el estado de otros rollups mediante la validación de las certificaciones de NFFL aseguradas criptoeconómicamente.

Lo que hace que el Registro sea particularmente interesante es cómo mantiene las propiedades de seguridad de NFFL en diferentes cadenas. Cada contrato de Registro mantiene una copia local del conjunto de operadores de NFFL, realizando un seguimiento de los cambios a través de atestaciones de actualización de conjuntos de operadores. Esto significa que, si bien el conjunto de operadores se administra a través de EigenLayer en Ethereum, su estado se refleja de manera confiable en todos los rollups participantes, lo que les permite verificar de forma independiente las certificaciones.

Cuando una aplicación necesita verificar el estado de otro rollup, por ejemplo, un protocolo de préstamos que verifica el colateral en Arbitrum desde Optimism, envía la certificación relevante a su contrato de Registro local. Esta certificación incluye la firma BLS agregada que discutimos anteriormente, junto con la raíz de estado específica que se está certificando y su referencia de transacción asociada de NEAR DA.

El proceso de verificación en el Registro es notablemente eficiente gracias a la agregación de firmas BLS. El contrato solo necesita realizar una verificación de firma única contra las claves públicas ponderadas del conjunto de operadores actual. Si la firma es válida y representa un peso suficiente de participación, el Registro acepta el estado atestiguado como verificado. Esto crea un puente sin confianza entre rollups que es seguro y rentable.

El Registro crea un puente de confianza minimizada entre rollups que es seguro y rentable. A través de la verificación de firmas agregadas contra las claves públicas ponderadas del conjunto de operadores, puede confirmar que una actualización de estado ha recibido suficiente peso de certificación para considerarse válida. Esto permite que las aplicaciones verifiquen de manera confiable los estados en diferentes rollups, al tiempo que heredan las garantías de seguridad económica de NFFL.

El Registro también desempeña un papel crucial en el sistema de desafío de NFFL. Si más tarde se demuestra que una certificación es fraudulenta a través del sistema de desafío, el Registro puede invalidarla, protegiendo a las aplicaciones de depender de un estado incorrecto. Esto crea múltiples capas de seguridad: garantías criptoeconómicas inmediatas de ETH apostado combinadas con protección contra fraudes a largo plazo a través de desafíos.

Clasificación de Fallas y Diseño de Seguridad

El modelo de seguridad de NFFL se centra en detectar y penalizar dos tipos principales de comportamientos incorrectos del operador: Fallas de Seguridad y Fallas de Vitalidad.

Las fallas de seguridad son violaciones que afectan la integridad de la red al producir estados incorrectos o resultados inconsistentes con las reglas del sistema. Hay dos tipos clave de fallas de seguridad que los operadores pueden cometer:

• La equivocación ocurre cuando un operador firma múltiples mensajes conflictivos para el mismo evento. Por ejemplo, firmar certificaciones para diferentes raíces de estado en la misma altura de bloque, o atestiguar múltiples marcas de tiempo diferentes para el mismo bloque. Tal comportamiento socava la capacidad de la red para alcanzar consenso sobre el estado canónico.
• La Attestation no válida ocurre cuando un operador firma una declaración comprobablemente incorrecta. Esto puede ser atestando una actualización del conjunto de operadores que no coincide con el delta de estado en cadena, o firmando una raíz de estado que no corresponde a la ejecución correcta de las transacciones del bloque. Estas fallas se pueden verificar de manera objetiva a través de datos en cadena.

Si los operadores consistentemente se abstienen de participar en la firma de mensajes, esto afecta tanto la disponibilidad de la red como aumenta los costos de verificación para los usuarios que necesitan más firmas para alcanzar el quórum. El protocolo realiza un seguimiento de la participación de los operadores a través de tareas de comprobación para identificar y penalizar dicho comportamiento.

El proceso de desafío varía según el tipo de falla y el mensaje que se está desafiando:

Para las tareas de punto de control, los retadores pueden probar fallas de inclusión o exclusión de mensajes. Si se omitió un mensaje con certificaciones válidas del período de tiempo del punto de control, o se incluyó un mensaje inválido/fuera de período, el desafío tiene éxito. Esto se verifica a través de pruebas de Merkle contra el árbol de mensajes del punto de control.

Los mensajes individuales pueden ser desafiados después de su período de control al demostrar que el contenido del mensaje era inválido. Por ejemplo:

• Los mensajes de actualización del conjunto de operadores pueden ser invalidados mostrando el ID de actualización reclamado o el delta del operador no coincide con el estado en la cadena
• Los mensajes de actualización de la raíz del estado pueden ser impugnados demostrando que la raíz del estado reclamada es inconsistente con la ejecución correcta de la transacción.

Este sistema de verificación de múltiples capas permite que el protocolo mantenga una operación rápida a través de mensajes fuera de cadena mientras preserva garantías de seguridad sólidas a través de mecanismos cripto-económicos. Al hacer que el comportamiento inválido sea detectable y económicamente punible a través de la reducción de EigenLayer, NFFL crea fuertes incentivos para una operación honesta al tiempo que permite desafíos eficientes cuando se producen violaciones.

Ejemplos de flujo del mundo real

Al establecer una forma de lecturas rápidas y baratas de estados cross-rollup, NFFL abre una amplia gama de aplicaciones que no eran factibles con la pila tecnológica actual del ecosistema. Exploremos algunas de las ideas, desde algo teórico y simple hasta aplicaciones más complejas y específicas, útiles en las áreas más populares del ecosistema Ethereum actual.

Hola Protocolo

Comencemos con un ejemplo sencillo, descrito en la documentación oficial de Nuffle Labs, un protocolo que permite a los usuarios enviar mensajes de «hola» entre diferentes rollups. Aunque básico, esto demuestra los mecanismos principales de cómo las aplicaciones pueden aprovechar NFFL para la comunicación entre cadenas.

Considere un usuario que desea enviar un mensaje en la Red #1 que será leído en la Red #2. El proceso comienza cuando envían una transacción en la Red #1 registrando su mensaje “¡hola!” en el estado de la red. En este punto, el mensaje existe solo en la Red #1 y normalmente requeriría esperar el acuerdo de puente canónico (potencialmente horas o días) antes de que pudiera ser verificado por otros rollups.

Aquí es donde entra NFFL. Cuando se produce el bloque que contiene este mensaje, se publica en NEAR DA por el relé de la red. Los operadores de NFFL, que ejecutan nodos completos para ambas redes, verifican que estos datos del bloque coincidan con lo que su nodo de la red #1 calculó localmente. Una vez verificado, firman mensajes que atestiguan la nueva raíz de estado.

Estas acreditaciones fluyen a través del servicio agregador de NFFL, que recopila firmas hasta que se haya atestado el peso suficiente. Una vez que se alcanza el quorum, la firma agregada está disponible a través de la API de NFFL, generalmente en cuestión de segundos desde la producción del bloque original.

Ahora viene la parte interesante: consumir el mensaje en la Red #2. El contrato del Protocolo Hello en la Red #2 puede aceptar una transacción que contenga:

• La prueba de almacenamiento que muestra que el mensaje existe en el estado de la Red #1
• La certificación de la NFFL que demuestra que este estado es válido
• Una referencia a la transacción de NEAR DA que contiene los datos del bloque

El protocolo enruta estos datos al contrato de Registro de la Red #2, que verifica la firma de la certificación con su registro de operadores NFFL. Si es válido, esto demuestra que el mensaje existe en el estado verificado de la Red #1, lo que permite que el protocolo lo procese de forma segura.

Lo que hace esto poderoso es su combinación de velocidad y seguridad. Todo el flujo desde la presentación del mensaje hasta la verificación entre cadenas puede completarse en segundos, en lugar de horas o días con puentes canónicos. Sin embargo, la seguridad proviene de garantías criptoeconómicas respaldadas por ETH restakeado a través de EigenLayer, en lugar deoperadores confiableso suposiciones optimistas.

Si bien el envío de mensajes de “hola” puede parecer trivial, este mismo patrón permite aplicaciones de cadena cruzada mucho más sofisticadas. La capacidad de verificar el estado de forma rápida y fiable en los paquetes acumulativos crea bloques de construcción para todo, desde DeFi entre cadenas hasta experiencias de usuario abstraídas en cadena.

Rápido y económico puente de tokens

Basándonos en estos fundamentos, exploremos una aplicación más práctica: un puente de tokens que aprovecha NFFL para transferencias rápidas entre rollups. El panorama actual de puentes obliga a hacer difíciles compensaciones entre velocidad, coste y seguridad. Veamos cómo NFFL puede cambiar estas dinámicas.

Los principales puentes de hoy ilustran claramente estos compromisos. Stargate, impulsado por LayerZero, logra costos relativamente bajos pero tarda de 10 a 30 minutos en completar las transferencias debido a que su red de operadores necesita lograr y transmitir consenso en múltiples cadenas. Across proporciona transferencias casi instantáneas pero a costos 10-100 veces más altos, principalmente debido a las salidas de oráculo UMA costosas y a los ciclos de reequilibrio lentos (de 6 horas) que afectan la eficiencia de liquidez.

NFFL introduce un nuevo paradigma aquí. Al aprovechar el marco de trabajo AVS de EigenLayer en lugar de mantener una red de operadores separada, NFFL puede lograr un consenso sobre los estados de rollup en cuestión de segundos. Este consenso puede transmitirse eficientemente a través de contratos de registro en todos los rollups participantes, lo que permite diseños de puente que combinan la eficiencia de costos de Stargate con una finalidad aún más rápida que Across.

Considere un usuario que mueve ETH de Arbitrum a Base. Cuando los tokens están bloqueados en el contrato puente en Arbitrum, los operadores de NFFL verifican y atestiguan rápidamente este cambio de estado a través de sus nodos completos. Una vez que el agregador recopila suficientes certificaciones, el contrato puente en Base puede verificar inmediatamente el bloqueo de tokens a través de su contrato de registro y liberar fondos para el usuario.

Esta velocidad y eficiencia hacen que muchas optimizaciones de puentes existentes sean menos relevantes. Por ejemplo, a menudo se proponen sistemas de puentes basados en la intención para solucionar la lentitud de la finalización: los usuarios envían intenciones para puentear tokens y estas intenciones son coincidentes y ejecutadas por actores especializados. Pero con NFFL proporcionando consenso casi tan rápido como tomaría coincidir intenciones, los puentes pueden utilizar diseños de piscinas de liquidez más eficientes similares a Stargate, pero sin sus limitaciones de velocidad.

Los beneficios económicos aquí son sustanciales. Los operadores de puente no necesitan mantener una infraestructura de consenso separada ni pagar por resultados de oráculos costosos. Los usuarios reciben tokens en la cadena de destino en segundos, mientras pagan principalmente los costos básicos de gas de verificación. Los proveedores de liquidez pueden gestionar posiciones de manera más eficiente con ciclos de reequilibrio más rápidos.

Como beneficio adicional, el sistema mantiene una seguridad sólida a través de los mecanismos de penalización de EigenLayer. Cualquier atestación fraudulenta resultaría en que los operadores pierdan su ETH en juego, mientras que los puentes aún pueden verificar el acuerdo final a través de puentes canónicos como una capa adicional de seguridad.

Protocolo de Préstamos Multi-Cadena

Los préstamos entre cadenas representan quizás la aplicación inmediata más convincente de NFFL. Los protocolos de préstamo actuales se enfrentan a importantes limitaciones debido a la fragmentación de la cadena. Por ejemplo, Aave: a pesar de implementarse en varios paquetes acumulativos, cada implementación funciona de forma aislada. Los usuarios que deseen utilizar garantías a través de las cadenas deben unir los activos y esperar, lo que fragmenta la liquidez y reduce la eficiencia del capital. Además, algunas implementaciones en rollups más pequeños ni siquiera tienen suficiente liquidez para ningún préstamo significativo, lo que cuestiona la posición de marketing de Aave de préstamos simples para todos en cualquier tamaño. “Solo usa Aave”. pero solo en sus despliegues más grandes.

NFFL permite un enfoque fundamentalmente diferente. Considere un protocolo de préstamos que mantiene pools en múltiples rollups pero utiliza NFFL para compartir el estado del colateral entre ellos. Un usuario podría depositar USDC como colateral en Base, luego pedir prestado USDT en Arbitrum contra ese mismo colateral, aunque USDT no esté desplegado en Base en absoluto. El contrato de Arbitrum del protocolo simplemente verifica la posición del colateral de Base a través de las acreditaciones de NFFL, sin necesidad de puentes.

Esto crea nuevas posibilidades poderosas para la eficiencia del capital. Los usuarios pueden acceder a las mejores tarifas en cualquier rollup admitido sin mover activos. Los proveedores de liquidez pueden desplegar capital donde más se necesita sin mantener posiciones separadas por cadena. Y debido a que las posiciones se pueden supervisar casi en tiempo real a través de las atestaciones de NFFL, los protocolos pueden ofrecer mejores tarifas mientras mantienen la seguridad.

Los beneficios van más allá del préstamo básico. Considere un protocolo de negociación apalancada que permite a los usuarios abrir posiciones en múltiples DEX. Un trader podría depositar garantías en Arbitrum y luego usarlas para abrir posiciones apalancadas tanto en las DEX de Arbitrum como en las de Base simultáneamente. El protocolo puede monitorear todas las posiciones a través de las atestaciones NFFL, lo que permite liquidaciones rápidas si es necesario mientras brinda a los traders acceso a los mejores precios en todo el ecosistema.

Este modelo es mucho más simple y eficiente que los enfoques existentes. En lugar de complejos mecanismos de puente o fuentes de precios centralizadas, los protocolos pueden verificar directamente las posiciones a través de contratos de registro. La rápida finalidad de NFFL significa que pueden operar con márgenes de seguridad más bajos mientras mantienen la seguridad. Y los usuarios obtienen una experiencia fluida al acceder a la liquidez en todo el ecosistema.

Cross-DEX: Implementar una vez, usar en todas partes

El enfoque actual para escalar los intercambios descentralizados en rollups a menudo conduce a ineficiencias absurdas. Cuando protocolos como Uniswap se implementan en un nuevo rollup, los usuarios se enfrentan inicialmente a pools sin liquidez y sin pares de negociación críticos. Consideremos el reciente despliegue de Uniswap V3 en ZKsync, a pesar de la emoción significativa y el flujo de fondos de un reciente airdrop de ZK, muchos pools permanecieron inutilizables durante días después del lanzamiento debido a la falta de liquidez suficiente. Mientras tanto, los despliegues del mismo protocolo en Arbitrum, Base y otras cadenas establecidas mantienen una liquidez profunda, tarifas bajas y precios eficientes para miles de pares.

Esta fragmentación crea fricción en todo el ecosistema. Los proveedores de liquidez deben dividir su capital entre las cadenas, lo que lleva a precios más bajos y mayor deslizamiento en todas partes. Los usuarios necesitan transferir tokens y esperar siempre que quieran acceder a una mayor liquidez en otra cadena. Los equipos de protocolo deben gestionar múltiples implementaciones, cada una requiriendo mantenimiento y monitoreo por separado.

Has acertado: NFFL permite un enfoque fundamentalmente diferente una vez más. Explorémoslo a través de dos patrones cada vez más poderosos:

Considere un nuevo DEX que se implemente exclusivamente en Arbitrum, elegido por su ecosistema DeFi establecido y costos de gas favorables. En lugar de lanzar instancias separadas en todas las cadenas, mantiene pools de liquidez unificados en Arbitrum al tiempo que permite el acceso a las operaciones desde cualquier rollup. Así es como un usuario de Base puede interactuar con él:

1. Alice quiere intercambiar 10,000 USDC por ETH en Base
2. La interfaz base del DEX consulta el estado del grupo de Arbitrum a través de las attestations NFFL
3. Alice ve que puede obtener mejores precios que las piscinas fragmentadas de Base ofrecen
4. Ella aprueba el intercambio en Base
5. La transacción se ejecuta en Arbitrum, con el resultado atestiguado de vuelta a Base

Los beneficios de esta liquidez unificada son sustanciales. Los proveedores de liquidez pueden concentrar su capital en un solo lugar, lo que conduce a una mejor fijación de precios y menor deslizamiento. El equipo del protocolo solo necesita gestionar una implementación, simplificando el desarrollo y reduciendo los costos operativos. Y los usuarios obtienen acceso constante a una liquidez profunda independientemente del rollup que estén utilizando.

Un protocolo de este tipo podría utilizar el patrón de puente que hemos explorado anteriormente para gestionar de manera transparente el flujo de intercambio. En un tiempo de espera de solo unos segundos, el hecho real de la conexión puede ser completamente abstracto. Esto nos acerca emocionantemente a la tesis de la ‘abstracción de cadena’ que recientemente se ha vuelto muy popular en la comunidad cripto: si no importa para la dapp en qué cadena estás, ¿por qué te importaría en qué cadena estás tú y todas estas aplicaciones? Un usuario simplemente puede proceder al sitio web de la aplicación, conectar su billetera y realizar una acción deseada. ¡Listo!

Pero NFFL permite un patrón aún más poderoso: envolver los protocolos DeFi existentes para acceso entre cadenas. En lugar de construir piscinas de liquidez en competencia, los desarrolladores pueden crear protocolos ‘helper’ que hacen que las enormes piscinas Uniswap de Arbitrum sean accesibles desde cualquier rollup.

Despliegues de Uniswap con el mayor TVL. Base y Arbitrum encabezan la lista, con Optimism teniendo un TVL 6 veces menor que cualquiera de los dos, y otros rollups clasificados como ‘Otros’. Fuente: DefiLlama

Por ejemplo, consideremos a Bob, quien necesita intercambiar un par de tokens de cola larga en Base. Actualmente, sus opciones son limitadas: o bien conectarse a otra cadena y esperar, o aceptar un deslizamiento extremo debido a la poca liquidez de Base. Con una interfaz NFFL en torno a la implementación de Uniswap de Arbitrum, Bob podría:

1. Consulte la liquidez disponible en todas las piscinas de Arbitrum Uniswap a través de las attestaciones NFFL
2. Encontrar liquidez profunda para su par deseado en un pool establecido de Arbitrum
3. Ejecutar la operación desde Base a través del protocolo de envoltura
4. Reciba sus tokens en Base una vez que NFFL certifique la finalización del intercambio

Este patrón es transformador porque convierte las implementaciones correctas existentes en una infraestructura universal. En lugar de esperar meses o años para que la liquidez se acumule en los nuevos rollups, los protocolos pueden aprovechar instantáneamente los grupos establecidos. Esto es mucho más eficiente en términos de capital y crea una mejor experiencia de usuario.

Las posibilidades se extienden mucho más allá de simples intercambios. Con la verificación en tiempo real del estado de NFFL, los protocolos podrían ofrecer funciones sofisticadas como órdenes límite entre cadenas. Un usuario podría realizar una orden límite en Base contra la liquidez de Arbitrum, con el protocolo envolvente monitoreando los movimientos de precios a través de las confirmaciones de NFFL y ejecutando cuando se cumplan las condiciones.

Este modelo podría remodelar la forma en que pensamos sobre la implementación de protocolos en rollups. En lugar de implementar automáticamente en todas partes o unirse a los efectos de red de una cadena específica, los protocolos podrían elegir estratégicamente su cadena principal en función de factores como:

• Costos de gas para sus operaciones específicas
• Pila tecnológica - máquina virtual, AA, tipo de secuenciación, DA, etc.
• Consideraciones regulatorias

A través de NFFL, aún pueden servir a los usuarios en todo el ecosistema de rollup mientras mantienen operaciones más simples y eficientes.

Las implicaciones para el MEV también son interesantes. Con liquidez unificada accesible en todas las cadenas, los buscadores de MEV necesitarían monitorear e interactuar con menos implementaciones. Esto podría llevar a un descubrimiento de precios más eficiente y una mejor ejecución para los usuarios en todos los rollups.

Como ya habrás notado, este patrón de implementación de una sola cadena con acceso a múltiples cadenas a través de NFFL podría extenderse mucho más allá de los DEX. Cualquier protocolo que se beneficie de la profundidad de liquidez o de los efectos de red podría adoptar este modelo: protocolos de préstamos, plataformas de opciones, mercados de NFT y más. La idea clave es que NFFL hace que el acceso entre cadenas sea casi tan fluido como la interacción entre cadenas, lo que permite a los protocolos optimizar su estrategia de implementación sin sacrificar la accesibilidad. En otras palabras, NFFL hace que Ethereum vuelva a ser un ecosistema.

Hoja de ruta y desarrollo futuro

Si bien NFFL ya permite nuevas y poderosas aplicaciones de intercambio cruzado, el protocolo sigue evolucionando. La hoja de ruta de desarrollo de NFFL se centra en tres áreas clave:

Seguridad del protocolo

• Implementando mecanismos completos de desafío y penalización a través de EigenLayer
• Activación de la participación de operadores sin permisos con una sólida gestión de participaciones
• Mejorando la verificación de estado entre cadenas con primitivas criptográficas mejoradas (BLS→ECDSA)

Escalabilidad de la red

• Optimizando esquemas de firma y propagación de estado
• Mejorar la eficiencia de los puntos de control y los costos de verificación

Experiencia de Desarrollador

• Construyendo SDK y herramientas para una integración fácil
• Ampliación de la compatibilidad con diferentes tipos de paquetes acumulativos y máquinas virtuales
• Creando documentación y ejemplos para casos de uso comunes

En las siguientes secciones, exploraremos algunos de los mejoras planificadas más significativas en detalle.

BLS a ECDSA

Uno de los cambios planificados más importantes es la transición de firmas BLS a firmas ECDSA. Actualmente, NFFL utiliza firmas BLS para permitir la agregación eficiente: múltiples firmas de operadores pueden combinarse en una sola firma que demuestra el acuerdo del quórum. Si bien esto reduce los costos de verificación, crea desafíos para la gestión del conjunto de operadores en diferentes cadenas.

El problema surge de cómo funciona la verificación de firma BLS. Al verificar una firma BLS agregada, el verificador debe utilizar exactamente el mismo conjunto de claves públicas que la crearon. Esto significa que cuando cambia el conjunto de operadores en Ethereum, todos los rollups deben actualizarse al mismo conjunto de operadores antes de poder verificar nuevas attestations. Incluso una pequeña diferencia en los conjuntos de operadores entre las cadenas puede evitar la verificación de firmas y requerir la sincronización de todos los mensajes de cambios en el conjunto de operadores.

Las firmas ECDSA, aunque requieren más espacio y cálculos para verificar, ofrecen más flexibilidad. Las firmas de operador individuales pueden verificarse de forma independiente, lo que permite transiciones más suaves cuando cambia el conjunto de operadores. Los rollups pueden verificar las certificaciones siempre y cuando reconozcan a los operadores firmantes, incluso si su visión del conjunto completo de operadores difiere temporalmente de la de Ethereum. Esta mayor flexibilidad puede valer la ligera aumento en los costos de verificación.

Conjuntos de Operadores Dinámicos

Este cambio de firma se relaciona directamente con otra mejora importante del protocolo: la implementación de conjuntos de operadores dinámicos. El sistema actual utiliza un conjunto estático de operadores incluidos en la lista blanca. Si bien esto simplificó el desarrollo inicial, limita la descentralización y escalabilidad del protocolo.

Un sistema de operadores dinámicos permitiría a los nuevos operadores unirse a la red sin permiso mediante el staking a través de EigenLayer. Esto plantea varios desafíos técnicos que deben abordarse cuidadosamente:

Primero, el protocolo debe gestionar las colas de entrada y salida de los operadores. Cuando los operadores desean unirse o abandonar la red, estos cambios deben ser coordinados en todas las cadenas participantes. El sistema de colas garantiza transiciones suaves sin interrumpir la capacidad de la red para verificar las certificaciones.

En segundo lugar, el protocolo necesita mecanismos para hacer un seguimiento del rendimiento del operador y el peso de la participación. A medida que los operadores se unen y abandonan, el sistema debe mantener registros precisos de la participación de cada operador y sus derechos para participar en el consenso. Esto se vuelve más complejo con un conjunto dinámico en comparación con el enfoque actual de lista blanca.

Por último, el protocolo debe manejar las actualizaciones de conjuntos de operadores en todas las cadenas de manera eficiente. Cuando el operador establece cambios en Ethereum, estas actualizaciones deben propagarse a todos los rollups participantes a través de sus contratos de registro. La transición planificada de ECDSA ayudará en este sentido al flexibilizar estas actualizaciones.

Fuera de las ruedas de entrenamiento

Otra área crítica de desarrollo es la activación de los mecanismos de desafío y reducción sin permiso. Estos mecanismos son esenciales para hacer cumplir el comportamiento honesto y proporcionar las garantías de seguridad económica en las que NFFL se basa.

El sistema de desafío se centra en el mecanismo de tareas de puntos de control. Cuando los operadores envían puntos de control que contienen Mensajes merkleizados de un período de tiempo, cualquier persona puede desafiar estos puntos de control si cree que contienen atestaciones inválidas. Un desafío exitoso puede surgir de varios tipos de fallas:

• En primer lugar, fallas de seguridad que afectan directamente la integridad de la red. Estas incluyen la equivocación, donde un operador firma Mensajes múltiples y conflictivos para el mismo caso, como atestiguar raíces de estado diferentes para el mismo bloque. También incluyen atestaciones inválidas, donde un operador firma transiciones de estado incorrectas de forma comprobable o actualizaciones del conjunto de operadores.
• En segundo lugar, los fallos de vivacidad que afectan a la disponibilidad de la red. Si los operadores se abstienen constantemente de participar en la firma de mensajes, esto afecta la capacidad de la red para verificar los estados de manera eficiente. El mecanismo de desafío debe equilibrar la penalización de dicho comportamiento teniendo en cuenta el tiempo de inactividad legítimo.

El protocolo implementará un sistema de impugnación basado en garantías. Los impugnadores deben bloquear la garantía al presentar una impugnación, que perderán si la impugnación resulta inválida. Sin embargo, si prueban con éxito una falla del operador, reciben una recompensa de la apuesta del operador recortado. Esto crea incentivos económicos para monitorear el comportamiento de los operadores al tiempo que evita desafíos frívolos.

Para las actualizaciones de raíz del estado, el proceso de desafío es particularmente interesante. Después de que un operador certifica el estado de un rollup, esto puede ser desafiado demostrando que los datos de bloque relevantes no se publicaron correctamente en NEAR DA, o que el estado certificado no coincide con el estado canónico después del acuerdo. Esto requiere que los desafiantes proporcionen pruebas a través del Puente del Arco Iris para la verificación de NEAR DA, creando múltiples capas de seguridad.

El mecanismo de reducción en sí se implementará a través de los contratos de middleware de EigenLayer. Cuando los desafíos tienen éxito, los operadores pierden una parte de su ETH en juego. Los parámetros de reducción están diseñados para que las posibles pérdidas superen significativamente cualquier ganancia por comportamiento malicioso. Una parte de esta participación reducida se otorga a los desafiadores exitosos, mientras que el resto puede distribuirse a operadores honestos o utilizarse para el desarrollo del protocolo.

Estos mecanismos crean un marco de seguridad integral. Los operadores enfrentan sanciones financieras significativas por mal comportamiento, los desafiantes tienen incentivos para monitorear la red y las aplicaciones pueden confiar en garantías criptoeconómicas respaldadas por ETH reinvertido. Los períodos de desafío son mucho más cortos que las pruebas de fraude de optimistic rollup, al tiempo que brindan una seguridad sólida a través de los mecanismos de penalización de EigenLayer.

Future of Fast Finality

Si bien NFFL proporciona una solución inmediata para la verificación de estado cruzado de rollup, vale la pena examinar cómo encaja el protocolo en la hoja de ruta de escalabilidad más amplia de Ethereum. La pregunta clave que muchos se hacen es: “¿Seguirá siendo relevante NFFL a medida que avance la tecnología de rollup?”

La respuesta se vuelve clara cuando examinamos las limitaciones fundamentales de liquidación en diferentes diseños de rollup. Los rollups optimistas, a pesar de su popularidad y madurez, no pueden liquidar fundamentalmente más rápido que su ventana de prueba de fraude, que suele ser de 7 días. Si bien soluciones como Superchain de Optimism y Arbitrum Orbit permiten una comunicación más rápida entre rollups que comparten un puente, no ayudan con la interoperabilidad fuera de sus ecosistemas específicos, por ejemplo, entre estos dos.

ZK rollups enfrentan limitaciones diferentes pero igualmente importantes. Incluso a medida que la tecnología de prueba ZK mejora drásticamente, existen límites prácticos para la velocidad de liquidación. Incluso si alcanzamos un punto en el que las pruebas se puedan generar para cada bloque L1, Ethereum aún debe tener la capacidad de verificar múltiples pruebas ZK por bloque en diferentes rollups. Cuando esto sea posible, la liquidación seguirá estando limitada por el tiempo de bloque L1, al menos 12 segundos según los parámetros actuales.

NFFL ofrece un enfoque diferente al utilizar afirmaciones de secuenciador firmadas de rollups. En lugar de esperar a que se publiquen lotes en L1, los operadores de NFFL pueden verificar y atestiguar los cambios de estado tan pronto como sean producidos por el secuenciador. Esto permite la verificación del estado entre cadenas en cuestión de segundos, manteniendo al mismo tiempo una sólida seguridad criptoeconómica a través de EigenLayer.

Es importante destacar que NFFL no debe ser visto como competencia o amenaza para el modelo de seguridad de rollup de Ethereum. Más bien, proporciona una herramienta complementaria que permite nuevas posibilidades dentro del ecosistema modular de Ethereum. Las aplicaciones pueden usar NFFL para una verificación rápida del estado, al mismo tiempo que dependen de un acuerdo canónico a través de L1 cuando sea necesario. Esto crea un conjunto de herramientas más completo para que los desarrolladores construyan aplicaciones entre cadenas con modelos de seguridad apropiados para sus necesidades específicas.

Conclusión

NFFL representa un enfoque novedoso para resolver uno de los desafíos más apremiantes en el ecosistema modular de Ethereum: permitir una verificación de estado cruzada segura y eficiente. Al aprovechar el ETH restaurado de EigenLayer para la seguridad económica y NEAR DA para un almacenamiento de datos eficiente, NFFL crea una capa de finalidad rápida que puede verificar los estados de acumulación en cuestión de segundos en lugar de horas o días.

Las cuidadosas decisiones de diseño del protocolo reflejan una profunda comprensión de los desafíos en la infraestructura intercadena. En lugar de intentar reemplazar el modelo de seguridad de los rollups, NFFL proporciona una capa complementaria optimizada para casos de uso específicos que requieren mayor finalidad. El sistema de tareas basado en checkpoints permite una operación eficiente fuera de la cadena mientras mantiene garantías de seguridad fuertes en la cadena. Y la arquitectura del contrato de registro permite a los rollups verificar estados de manera confiable mientras heredan la seguridad económica de NFFL.

Quizás lo más importante es que NFFL permite una nueva generación de aplicaciones de cadena cruzada que antes eran poco prácticas. Desde protocolos de préstamos unificados que comparten garantías a través de rollups hasta envoltorios DEX que hacen que la liquidez establecida sea universalmente accesible, la rápida verificación de estado de NFFL crea bloques de construcción para una verdadera abstracción de la cadena. Esto tiene profundas implicaciones para la eficiencia del capital y la experiencia del usuario en todo el ecosistema.

El roadmap del protocolo demuestra compromiso con la mejora continua. Las actualizaciones planificadas, como la transición a firmas ECDSA y la implementación de conjuntos de operadores dinámicos, mejorarán la descentralización y la escalabilidad. La activación de mecanismos completos de desafío y penalización fortalecerá las garantías de seguridad. Y la integración con soluciones DA adicionales más allá de NEAR hará que NFFL sea aún más universal.

A medida que el ecosistema de rollup de Ethereum continúa evolucionando, la necesidad de verificación segura del estado interconectado solo aumentará. El enfoque de NFFL de extender la seguridad de Ethereum a través de la redistribución mientras se optimiza la velocidad y la rentabilidad lo posiciona bien para satisfacer esta necesidad. Al permitir nuevas formas de interacción interconectada al tiempo que se mantienen garantías de seguridad sólidas, NFFL contribuye a hacer realidad la visión modular de Ethereum.

Descargo de responsabilidad:

1. Este artículo ha sido reimpreso de [[](https://research.2077.xyz/nuffle-ethereums-finality-as-a-service-layer#introduction)[2077 Investigación](https://research.2077.xyz/)\]. Todos los derechos de autor pertenecen al autor original [Alex Hook]. Si hay objeciones a esta reimpresión, póngase en contacto con el Gate Learnequipo, y lo manejarán rápidamente.
2. Renuncia de Responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Aprende de gate. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.