Nuffle: La capa de finalidad como servicio de Ethereum

En retrospectiva, los rollups han surgido como la solución de escalado definitiva para Ethereum y la tecnología descentralizada en su conjunto. Nueve meses después de la actualización Dencun de Ethereum, que apuntaba a la escalabilidad de la disponibilidad de datos de rollup, el rendimiento de las transacciones ha superado , lo que representa un aumento de cinco veces en lo que va de año. Los dos rollups líderes, Arbitrum y OP Mainnet, han logrado la descentralización de la etapa 1 en métricas de descentralización, con rollups adicionales que potencialmente apuntan a la descentralización de la etapa 2 en 2025. La tecnología de prueba de conocimiento cero ha progresado para permitir , estableciendo un camino para la verificación eficiente de miles de transacciones de usuarios estándar en la cadena de bloques Ethereum contemporánea. las doscientas transacciones por segundo , superando a varias redes alternativas prominentes de Capa 1 la verificación de transacciones equivalentes a Ethereum a costos inferiores al centavo Sin embargo, este avance presenta nuevos desafíos. Varios equipos están desarrollando cadenas de bloques independientes sobre Ethereum, con una interoperabilidad limitada entre ellas. Esta limitación se debe principalmente a la finalización poco frecuente de los rollups, lo que impide una comunicación significativa entre cadenas. Además, los rollups optimistas, que actualmente albergan la mayor parte 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, lo que crea una barrera significativa para la interoperabilidad entre las principales redes como Arbitrum y Base. La comunidad ha propuesto varias soluciones, que van desde puentes basados en intenciones e intercambios atómicos hasta una abstracción integral de la cadena. A pesar de sus diferencias, estas soluciones comparten un requisito fundamental: una fuente confiable de información, un protocolo que permita una verificación segura del estado entre paquetes que sea rápida y rentable. Entre las soluciones más destacadas, que suelen basarse en oráculos optimistas (Across), consenso de operadores especializados (Stargate a través de LayerZero) o confianza de secuenciador centralizado (Polymer Hub), de Nuffle Labs presenta un equilibrio convincente entre eficiencia, seguridad y alineación con Ethereum. Este artículo examina el enfoque innovador de NFFL para permitir la verificación del estado de cross-rollup a través del mecanismo de resttaking de EigenLayer y NEAR DA, explora su diseño arquitectónico y su hoja de ruta de desarrollo, y analiza las posibles aplicaciones y sus implicaciones para el ecosistema. Fast Finality Layer (NFFL) Un repaso sobre los rollups Para comprender los desafíos que aborda NFFL, examinemos la arquitectura fundamental de los rollups, sus objetivos y sus limitaciones inherentes: que utiliza otra cadena de bloques independiente para ordenar transacciones, hacer disponibles los datos y alcanzar consensos, al mismo tiempo que ejecuta transacciones de forma externa de una manera verificable por la cadena de bloques 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 las L2 utilicen la L1 para la disponibilidad de los datos. Para mayor claridad, este documento se centra específicamente en los rollups en lugar de en la categoría más amplia de L2. Un rollup es una cadena de bloques Por supuesto, en nuestro caso, la L1 principal es la cadena de bloques Ethereum. Es responsable de compartir su consenso con los rollups (lo explicaremos más adelante). Analicemos cómo los rollups aprovechan Ethereum para sus funciones principales: ordenamiento de transacciones, disponibilidad de datos y consenso. Orden de transacciones Los rollups incorporan una entidad llamada secuenciador, responsable de gestionar la inclusión y ordenación de transacciones a través de la red L1. El secuenciador funciona de manera análoga a un productor de bloques en las cadenas de bloques tradicionales. En concreto, acepta las transacciones entrantes de los usuarios de forma secuencial, las agrupa en lotes (comparables a los bloques L1) y publica periódicamente estos lotes en un contrato inteligente designado en la L1. Un contrato inteligente en la capa 1 mantiene un registro autorizado de todas las transacciones publicadas y su orden. Los nodos de acumulación deben monitorear este contrato para recuperar nuevos bloques e información de transacciones. Una vez que se incluye un lote en un bloque de la capa 1 y ese bloque logra su finalidad a través del consenso de la capa 1, la inclusión y el orden de todas las transacciones dentro de ese lote están garantizados por las propiedades de seguridad de la capa 1. Hasta cierto punto, el secuenciador es un "iniciador" del rollup: ayuda al rollup a aceptar nuevas transacciones en la red, lo que facilita el avance del estado. Algunos rollups implementan una secuenciación descentralizada (un conjunto rotativo de entidades especializadas que reduce el riesgo de tiempo de inactividad de un secuenciador que de otro modo estaría centralizado) y una secuenciación basada, que no utiliza ningún secuenciador como fuente de confianza antes de publicar el lote en la capa 1. (La secuenciación basada permite que cualquiera sea secuenciador, pero sus lotes solo son utilizados por los nodos cuando se publican en L1. Esto prácticamente no genera ningún riesgo de tiempo de inactividad de la secuenciación a costa de una inclusión de transacciones más lenta (el mejor escenario es los 12 segundos por bloque de L1).) Sin embargo, los secuenciadores no deciden el nuevo estado de las cosas en el paquete, incluso después de la ejecución de sus propios lotes. Por lo tanto, los secuenciadores “inician” pero no necesariamente “ejecutan” el paquete, ya que sus acciones no pueden conducir directamente a la transición de estado malicioso. Disponibilidad de datos Sin embargo, la información sobre el orden de algunas transacciones no es suficiente para los nodos del lote, ya que no poseen las transacciones en sí. Para ejecutar estas transacciones y determinar su resultado en la cadena de bloques del lote, los nodos deben tener acceso completo y sin restricciones a todas las transacciones del lote. En consecuencia, los secuenciadores de rollup deben publicar datos completos de transacciones en la L1 de una manera que permita que el contrato inteligente del rollup verifique . Una vez que los datos de transacciones de un lote se incluyen y finalizan en la L1, su disponibilidad está garantizada para todos los nodos participantes. la disponibilidad de los datos 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 la L1. Por lo tanto, todas las transacciones deben haberse publicado en la cadena de bloques de la 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 la L1 de Ethereum no puede almacenar grandes datos en su libro mayor, mientras que los rollups, los carriles de alta velocidad de Ethereum, son muy intensivos en datos. En cambio, podemos hacer que el contrato inteligente del rollup verifique la validez de las transacciones secuenciadas, de modo que los nodos sigan instantáneamente el estado en el contrato, en lugar de reconstruirlo a partir de todas las transacciones a partir de génesis. Manchas La actualización Dencun de Ethereum en marzo pasado introdujo los “ ”, celdas temporales de datos que se almacenan fuera de la cadena de bloques y se podan (eliminan por los validadores de la red) después de aproximadamente 18 días. Como los puentes de rollup permiten reconstruir el estado sin volver a ejecutar transacciones, esta propiedad se volvió muy útil para los rollups, que migraron de a blobs poco después de la actualización. Hablando de números, antes de Dencun, el total de TPS de los rollups era de alrededor de 50. Hoy, es más de 200, con límites teóricos de . blobs calldata 400 a 800 TPS según el rollup Además de las mejoras de capacidad, los blobs eliminaron el requisito de pagar los costos de gas EVM para el almacenamiento de datos de transacciones, estableciendo un canal separado con almacenamiento temporal especializado y tarifas independientes. Este cambio arquitectónico ha reducido drásticamente los costos de transacción en los rollups, con tarifas que se redujeron de 10 a 40 centavos por transacción a niveles inferiores al centavo en redes como Base. Puente consagrado (consenso) Para simplificar, hemos dado la vuelta a la definición del rollup: 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 . Además, muchos rollups quieren obtener tokens populares en su ecosistema desde el día 1, por lo que unirlos desde su L1 es la mejor opción. proponentes Implementar un desde L1 al rollup es bastante sencillo: los nodos del rollup ya escuchan todo lo que sucede en su contrato, por lo que podemos implementar una función de depósito L1 que todos los nodos interpretarán como un comando para emitir el token "envuelto" respectivo en el rollup mismo. contrato inteligente puente Sin embargo, los retiros sin confianza requieren que el contrato puente valide todas las transacciones de rollup y determine sus resultados legítimos. Esto permite que el puente procese solicitudes de retiro válidas al liberar fondos a los iniciadores autorizados en la L1. Este mecanismo de validación hace que el puente sea la fuente definitiva del estado canónico del rollup: los nodos se alinean con la transición de estado del puente independientemente de las bifurcaciones de cadena alternativas. A diferencia de las cadenas de bloques tradicionales, los rollup no implementan reglas de consenso independientes para la selección de la cadena. El contrato puente en la L1 es lo que define la cadena canónica. Liquidación de acumulación Si bien los secuenciadores gestionan el ordenamiento y la publicación de las transacciones, representan solo un componente de la arquitectura de los rollups. Los rollups también incorporan entidades llamadas "proponentes" responsables de convencer al puente L1 de los resultados de estados específicos resultantes de los lotes recién secuenciados. En esencia, mientras que los secuenciadores establecen la ocurrencia y el ordenamiento de las transacciones, los proponentes demuestran los resultados de estas transacciones de acuerdo con la lógica de procesamiento del rollup, como su máquina virtual. El rol del proponente varía significativamente según el enfoque de validación del estado del rollup. Existen dos metodologías fundamentalmente diferentes que definen dos categorías de rollups: y optimista de conocimiento cero (ZK). Rollups optimistas En los rollups optimistas, los proponentes envían actualizaciones de estado regularmente al puente L1, normalmente junto con las publicaciones de lotes del secuenciador o poco después de ellas. 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 lotes más recientes. Para evitar actualizaciones de estado no válidas, el puente implementa un período de impugnación (normalmente de 7 días) durante el cual los actores especializados denominados "retadores" pueden impugnar la propuesta mediante la presentación de una . Esta prueba demuestra que las transacciones se ejecutaron de forma incorrecta volviendo a ejecutar la transacción impugnada en la L1 y comparando los resultados. prueba de fraude Si un retador demuestra con éxito que un proponente presentó una transición de estado no válida, se revierte el resultado del estado y el retador recibe una recompensa (a menudo, mediante un bono que los proponentes deben depositar). Esto crea un juego económico en el que los proponentes tienen incentivos para presentar solo transiciones de estado válidas. Rollups de conocimiento cero En los rollups ZK, los proponentes generan pruebas matemáticas (denominadas "pruebas de validez" o, técnicamente, "pruebas ZK") que demuestran la corrección de cada transición de estado. Estas pruebas muestran que todas las transacciones de 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 mediante 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, firmeza 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 los rollups optimistas debido a su período de desafío, hasta varias horas para los rollups ZK debido a los costos generales de generación de pruebas y publicación por lotes. Si bien este modelo funciona bien para asegurar transacciones de alto valor que pueden tolerar demoras, crea una fricción significativa para el ecosistema DeFi más amplio. Piense en cómo esto afecta el uso en el mundo real: un usuario que quiere usar su garantía basada en Arbitrum para obtener un préstamo en Base primero debe hacer un puente entre sus activos y esperar hasta 7 días antes de poder usarlos. Un comerciante que detecte una oportunidad de arbitraje entre los pools de Uniswap en diferentes acumulaciones vería que la oportunidad desaparece mucho antes de poder aprovecharla. Una aplicación de juegos que quiera permitir que los jugadores intercambien artículos en diferentes implementaciones de acumulaciones se enfrentaría a una experiencia de usuario inaceptable con demoras tan prolongadas. La idea fundamental aquí es que los nodos de rollup pueden observar cambios de estado mucho más rápido, generalmente en cuestión de segundos luego de la confirmación del bloque L1. Si bien este estado no ha pasado por una liquidación completa en el puente canónico, se basa en datos de transacciones que ya se ordenaron y finalizaron en Ethereum. Muchos intercambios centralizados ya aprovechan esta propiedad, acreditando los depósitos de los usuarios de los rollups después de solo unas pocas confirmaciones de bloques ejecutando sus propios nodos y verificando la finalización de la transacción en L1. Esto crea una dicotomía interesante en el ecosistema de rollups. Si bien los rollups han logrado escalar con éxito el rendimiento de las transacciones de Ethereum, han introducido una grave fragmentación del estado y la liquidez. Cada rollup opera efectivamente como una cadena de bloques independiente que no puede verificar de manera eficiente el estado de otros rollups sin esperar la liquidación del puente, a pesar de que todos ellos derivan su seguridad de la misma cadena subyacente: Ethereum. ¿Cuáles son las soluciones existentes a la liquidez y la fragmentación del Estado? El ecosistema ha desarrollado diversos enfoques para superar estas limitaciones, desde puentes centralizados hasta redes especializadas fuera de la cadena. Estas soluciones suelen plantear diferentes compensaciones entre tres propiedades clave: : ¿Qué tan sólidas son las garantías de que la verificación estatal es correcta? Seguridad : qué tan rápido se puede verificar el estado en todas las cadenas Velocidad : qué tan costoso es mantener y usar la solución. Costo La mayoría de las soluciones existentes optimizan la velocidad y el costo a expensas de la seguridad, y a menudo dependen de operadores confiables, multifirmas o mecanismos optimistas con un respaldo económico mínimo. Esto ha llevado a varios ataques de alto perfil a puentes, en particular el ataque al puente Ronin de 625 millones de dólares, que pone de relieve los riesgos de sacrificar la seguridad por la conveniencia. El desafío fundamental es establecer una "fuente de verdad" segura sobre los estados de acumulación que pueda: Verifique los 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 Se integra perfectamente con las arquitecturas de rollup existentes Esta oportunidad de habilitar una verificación rápida y segura del estado entre acumulaciones ha generado una innovación significativa. Varios equipos están abordando el problema desde diferentes ángulos, buscando crear una infraestructura que pueda 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 novedosa combinación de resttaking de EigenLayer y NEAR DA, creando una capa de finalidad rápida que logra un equilibrio cuidadoso entre seguridad, velocidad y rentabilidad. Entendiendo la capa de finalidad rápida de Nuffle (NFFL) La capa de finalización rápida de Nuffle (NFFL) representa un enfoque novedoso para permitir interacciones seguras entre cadenas al proporcionar una verificación rápida del estado entre acumulaciones. En lugar de obligar a los desarrolladores a elegir entre seguridad y velocidad, NFFL aprovecha el ETH re-enlazado de EigenLayer para crear una capa de finalización rápida criptoeconómicamente segura que puede dar fe de los estados de las acumulaciones en cuestión de segundos. En esencia, NFFL funciona como un servicio validado activamente (AVS) que se ejecuta en EigenLayer. Una red descentralizada de operadores, cada uno de los cuales ejecuta nodos completos para los rollups participantes, verifica y da fe de las actualizaciones de estado. Estas certificaciones están respaldadas por el ETH re-stakeado de los operadores, lo que crea fuertes incentivos económicos para un comportamiento honesto. Al combinar esto con la capa de disponibilidad de datos de NEAR para un almacenamiento eficiente de datos de bloques, NFFL permite que las aplicaciones verifiquen de forma segura el estado entre cadenas en 2-3 segundos, órdenes de magnitud más rápido que la liquidación de puentes canónicos. 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 criptoeconómica de NFFL o esperar a que se liquide la L1 completa según sus necesidades específicas. Esta flexibilidad permite a NFFL mejorar la experiencia del usuario para muchas interacciones entre cadenas al tiempo que mantiene sólidas garantías de seguridad. El sistema introduce tres innovaciones clave: Una red de operadores descentralizados que logra un consenso sobre los estados de acumulación comparando las transiciones de estado ejecutadas localmente con los datos de bloques publicados en NEAR DA Un sistema de tareas basado en puntos de control que permite la agregación y verificación eficiente de las certificaciones de los operadores, manteniendo al mismo tiempo la responsabilidad a través de los mecanismos de reducción de EigenLayer. Un mecanismo de almacenamiento de datos que utiliza NEAR DA que permite una fácil recuperación de datos acumulados atestiguados en todos los acumulaciones Este diseño permite a NFFL lograr un equilibrio cuidadoso entre seguridad, velocidad y rentabilidad, tres propiedades que tradicionalmente han estado en conflicto en la infraestructura de cadenas cruzadas. Al proporcionar una verificación de estado rápida pero segura, NFFL abre nuevas posibilidades para aplicaciones de cadenas cruzadas que van desde protocolos de préstamos hasta agregadores de liquidez. En las siguientes secciones, exploraremos la arquitectura de NFFL en detalle y examinaremos 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, analizaremos posibles aplicaciones y veremos la hoja de ruta del protocolo para el desarrollo futuro. Una descripción general de los componentes principales de NFFL 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 entre transacciones. En lugar de crear otra red aislada que requiere sus propias suposiciones de seguridad, NFFL está construida como un Servicio Validado Activamente (AVS) en EigenLayer, lo que le permite aprovechar directamente el ecosistema de validadores existente de Ethereum. Esta elección arquitectónica es fundamental para comprender el modelo de seguridad de NFFL. Los mismos validadores que protegen el consenso de Ethereum pueden volver a poner en juego su ETH a través de EigenLayer para convertirse en operadores de NFFL. Al hacerlo, ponen en riesgo su ETH en juego para respaldar sus certificaciones sobre los estados de acumulación. Esto crea un poderoso puente de seguridad entre el consenso de Ethereum y la capa de finalidad rápida de NFFL. Cuando un paquete de datos publica nuevos datos de bloques en la capa 1, los retransmisores los reenvían a NEAR DA. Los operadores recuperan los datos de bloques a través de ambas fuentes y se aseguran de que sean equivalentes. Explicaremos más detalladamente por qué es necesario publicar datos de paquetes de datos en NEAR DA para 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 salida de estado, que es correcta. Esta salida de estado luego es firmada por todos los operadores. Cuando la mayoría de los operadores están de acuerdo con un estado específico, el sistema lo acepta y puede transmitirse a los contratos de registro en todos los rollups. La seguridad económica de dicho sistema tiene una propiedad muy interesante que se deriva de la mecánica de corte de EigenLayer: En EigenLayer, los servicios validados activamente pueden implementar un mecanismo de verificación que sea capaz de detectar certificaciones no válidas de los operadores y liquidar su depósito posteriormente. Como NFFL "liquida" de alguna manera el estado de acumulación fuera de la cadena antes de liquidarlo en el puente, es posible detectar objetivamente el fraude al esperar el retraso de la liquidación y notificar al contrato AVS sobre la inconsistencia de salida en la certificación y el puente. Esto desincentiva económicamente las certificaciones fraudulentas, ya que pueden ser detectadas y eliminadas por cualquier entidad que observe el estado de L1 y NFFL, incluso sin que ejecuten nodos de acumulación. En otras palabras, NFFL "asegura" las reclamaciones de la red: los operadores están poniendo en riesgo un capital significativo para respaldar sus reclamaciones sobre los estados de acumulación. Lo que hace que esto sea particularmente poderoso es la forma en que alinea los incentivos en todo el sistema. Los operadores ganan comisiones por participar honestamente mientras corren el riesgo de sufrir pérdidas significativas por deshonestidad. Cuanto más ETH se reinvierta en NFFL, más fuertes serán estos incentivos. Y debido a que esta seguridad se deriva de Ethereum a través de EigenLayer, se beneficia en parte del mismo modelo de seguridad económica sólida que asegura cientos de miles de millones en valor en Ethereum. Flujo de mensajes El sistema de mensajería de NFFL representa un enfoque innovador para gestionar la verificación de estado entre cadenas a gran escala. En lugar de registrar cada certificación de estado en la cadena, lo que 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 y, al mismo tiempo, mantiene sólidas garantías de seguridad en la cadena a pedido. 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 da fe de ese estado. Estos mensajes existen principalmente fuera de la cadena y circulan entre los operadores y el agregador sin incurrir en costos de gas dentro de 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 a 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, lo que crea un vínculo verificable entre el estado certificado y sus datos subyacentes. Los mensajes de actualización del conjunto de operadores rastrean los cambios en el conjunto de operadores de NFFL. Estos mensajes son cruciales para la seguridad del sistema, ya que permiten que los contratos de registro de acumulación mantengan un registro actualizado de operadores válidos, lo que garantiza que las certificaciones solo se acepten de participantes autorizados con 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 controlan el estado del sistema a intervalos regulares. En lugar de enviar cada mensaje a Ethereum, los operadores construyen periódicamente un disperso que contiene todos los mensajes de un período de tiempo específico. La raíz de este árbol se envía luego como una respuesta de tarea, lo que crea un compromiso eficiente en cadena para todas las certificaciones fuera de cadena. árbol Merkle Este sistema de puntos de control es particularmente inteligente porque permite la verificación selectiva de cualquier mensaje sin necesidad de que todos los mensajes estén almacenados en la cadena. A través de las pruebas de Merkle, cualquiera puede verificar que un mensaje específico se incluyó en un punto de control, lo que permite mecanismos de impugnación eficientes y, al mismo tiempo, mantiene bajos los costos de referencia. Se puede pensar en ello como la creación de una "cadena de bloques 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 desempeña un papel crucial en este sistema al recopilar 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 el ETH en stake) antes de exponerlas para que las usen las aplicaciones. Esto crea una interfaz limpia para los desarrolladores y, al mismo tiempo, mantiene las propiedades de seguridad descentralizadas del sistema. En la siguiente sección, explicaremos en detalle el servicio del agregador. Servicio de agregación El agregador actúa como la capa de coordinación de NFFL y gestiona de manera eficiente el flujo de mensajes entre operadores y aplicaciones. Si bien su concepto es sencillo, su diseño refleja una cuidadosa consideración de las necesidades prácticas de los desarrolladores y de los principios de descentralización. En esencia, 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 utilice NFFL tendría que recopilar y verificar de forma independiente las firmas de todos los operadores, un proceso ineficiente y costoso. En cambio, el agregador proporciona un único punto de recopilación de firmas de operadores, verificando el quórum y exponiendo las certificaciones verificadas a través de una API simple. El proceso de agregación de firmas funciona de la siguiente manera: Los operadores firman de forma independiente los mensajes que dan fe de las actualizaciones del 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 el peso de participación suficiente, la firma agregada queda 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 gestionar operaciones criptográficas complejas o rastrear las participaciones de los operadores, las aplicaciones pueden simplemente solicitar certificaciones para actualizaciones de estado específicas a través de una interfaz API limpia. El agregador maneja toda la complejidad de la recopilación de firmas, la verificación y la agregación de BLS en segundo plano. Agregación de firmas Exploremos más a fondo la agregación BLS que utiliza NFFL. Las firmas BLS tienen una propiedad matemática poderosa que permite combinar múltiples firmas en una sola. En lugar de verificar N firmas individuales de los operadores, lo que sería costoso en términos computacionales y requeriría un uso intensivo de gas, las aplicaciones pueden verificar una única firma agregada que demuestre un acuerdo colectivo. Las ganancias de eficiencia en este caso 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 el acuerdo de quórum. El tamaño y el costo de verificación de esta firma agregada se mantienen constantes independientemente de cuántos operadores participaron, una propiedad que hace que el sistema sea altamente escalable. Además, la firma agregada puede verificarse con las claves públicas combinadas de los operadores firmantes, ponderadas por las cantidades apostadas para garantizar que se tenga debidamente en cuenta la seguridad económica. El contrato de registro solo necesita realizar una operación de verificación de firma para confirmar que se ha atestiguado la actualización del estado con un peso de participación suficiente. Agregadores y puntos de control Es importante señalar que, si bien el agregador brinda comodidad, no compromete el modelo de seguridad de NFFL. Las firmas que recopila son verificables públicamente y su función es puramente organizativa, no autoritaria. Las aplicaciones siempre pueden verificar de forma independiente que las firmas agregadas representan el quórum legítimo de los operadores en 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 fundamental en el sistema de puntos de control. Al recopilar todos los mensajes a lo largo del tiempo, puede construir los árboles de Merkle dispersos que se utilizan en las tareas de los puntos de control. Esto crea un registro eficiente de todas las certificaciones que han pasado por el sistema, lo que permite una verificación posterior si es necesario para resolver problemas de seguridad o para fines de auditoría. Contratos de registro El contrato de Registro, implementado en cada rollup participante, sirve como puente crítico entre las certificaciones fuera de la cadena de NFFL y la verificación del estado dentro de la cadena. Estos contratos permiten que las aplicaciones verifiquen sin confianza el estado de otros rollups al validar las certificaciones criptoeconómicamente seguras de NFFL. Lo que hace que el Registro sea particularmente interesante es la forma en que mantiene las propiedades de seguridad de NFFL en diferentes cadenas. Cada contrato del Registro mantiene una copia local del conjunto de operadores de NFFL, y realiza un seguimiento de los cambios a través de las certificaciones de actualización del conjunto 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 las certificaciones de forma independiente. Cuando una aplicación necesita verificar el estado de otro paquete (por ejemplo, un protocolo de préstamos que verifica la garantía de Arbitrum de Optimism), envía la certificación correspondiente a su contrato de registro local. Esta certificación incluye la firma BLS agregada que analizamos anteriormente, junto con la raíz del estado específico que se está certificando y su referencia de transacción NEAR DA asociada. 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 única verificación de firma con las claves públicas ponderadas del conjunto de operadores actual. Si la firma es válida y representa un peso de participación suficiente, el Registro acepta el estado atestiguado como verificado. Esto crea un puente sin confianza entre los rollups que es seguro y rentable. El Registro crea un puente de confianza minimizada entre los rollups que es seguro y rentable. A través de la verificación de firmas agregadas con 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 ser considerada válida. Esto permite que las aplicaciones verifiquen de manera confiable los estados en diferentes rollups y, al mismo tiempo, hereden las garantías de seguridad económica de NFFL. El Registro también desempeña un papel crucial en el sistema de impugnación de NFFL. Si posteriormente se demuestra que una certificación es fraudulenta a través del sistema de impugnación, el Registro puede invalidarla, lo que evita que las solicitudes dependan de un estado incorrecto. Esto crea múltiples capas de seguridad: garantías criptoeconómicas inmediatas de ETH en stake combinadas con protección contra el fraude a largo plazo a través de impugnaciones. Clasificación de fallas y diseño de seguridad en NFFL El modelo de seguridad de NFFL se centra en detectar y penalizar dos tipos principales de mala conducta 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 incompatibles con las reglas del sistema. Existen dos tipos principales de fallas de seguridad que los operadores pueden cometer: La equivocidad se produce cuando un operador firma varios mensajes conflictivos para el mismo evento. Por ejemplo, firma certificaciones para diferentes raíces de estado en la misma altura de bloque o certifica varias marcas de tiempo diferentes para el mismo bloque. Este tipo de comportamiento socava la capacidad de la red para alcanzar un consenso sobre el estado canónico. La certificación no válida se produce cuando un operador firma una declaración demostrablemente incorrecta. Esto podría ser la certificación de una actualización del conjunto de operadores que no coincide con el delta del estado en cadena, o la firma de una raíz de estado que no corresponde a la ejecución correcta de las transacciones del bloque. Estas fallas se pueden verificar objetivamente a través de datos en cadena. Mientras que las fallas de seguridad atacan directamente la corrección, las fallas de actividad afectan la disponibilidad y la eficiencia de la red. Si los operadores se abstienen sistemáticamente de participar en la firma de mensajes, esto afecta tanto a la disponibilidad de la red como a los costos de verificación para los usuarios que necesitan más firmas para alcanzar el quórum. El protocolo rastrea la participación de los operadores a través de tareas de puntos de control para identificar y penalizar este tipo de comportamiento. El proceso de desafío varía según el tipo de falla y el mensaje que se cuestiona: En el caso de las tareas de punto de control, los retadores pueden demostrar errores 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 no válido o fuera de período, el desafío tiene éxito. Esto se verifica mediante pruebas de Merkle en el árbol de mensajes del punto de control. Se pueden impugnar mensajes individuales después de su período de control demostrando que el contenido del mensaje no es válido. Por ejemplo: Los mensajes de actualización del conjunto de operadores se pueden invalidar al mostrar que el ID de actualización solicitado o el delta del operador no coincide con el estado en cadena Los mensajes de actualización de la raíz del estado se pueden cuestionar 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 la cadena y, al mismo tiempo, preserve sólidas garantías de seguridad a través de mecanismos criptoeconómicos. Al hacer que el comportamiento inválido sea demostrablemente detectable y económicamente punible a través del recorte de EigenLayer, NFFL crea fuertes incentivos para una operación honesta y, al mismo tiempo, permite impugnaciones eficientes cuando ocurren violaciones. Aplicaciones del NFLL en el mundo real Al establecer una forma de lecturas de estados entre acumulaciones rápidas y económicas, 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 simple, descrito en la documentación oficial de Nuffle Labs: un protocolo que permite a los usuarios enviar mensajes de "hola" entre diferentes paquetes. Si bien es básico, demuestra la mecánica básica de cómo las aplicaciones pueden aprovechar NFFL para la comunicación entre cadenas. Consideremos un usuario que desea enviar un mensaje en la Red n.° 1 que será leído en la Red n.° 2. El proceso comienza cuando envía una transacción en la Red n.° 1 y registra su mensaje de "hola" en el estado de la red. En este punto, el mensaje solo existe en la Red n.° 1 y normalmente requeriría esperar la liquidación del puente canónico (posiblemente horas o días) antes de que otros rollups puedan verificarlo. Aquí es donde entra en juego NFFL. Cuando se produce el bloque que contiene este mensaje, el retransmisor de la red lo envía a NEAR DA. Los operadores de NFFL, que ejecutan nodos completos para ambas redes, verifican que los datos de este bloque coincidan con lo que su nodo de la red n.° 1 calculó localmente. Tras la verificación, firman los mensajes que dan fe del nuevo estado raíz. Estas certificaciones se realizan a través del servicio de agregación de NFFL, que recopila firmas hasta que se haya obtenido un peso suficiente de la participación para dar fe del estado. Una vez que se alcanza el quórum, la firma agregada se vuelve 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 n.° 2. El contrato del protocolo Hello en la red n.° 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 NFFL que prueba que este estado es válido Una referencia a la transacción NEAR DA que contiene los datos del bloque El protocolo envía estos datos al contrato de registro de la red n.° 2, que verifica la firma de la certificación con su registro de operadores NFFL. Si es válida, esto prueba que el mensaje existe en el estado verificado de la red n.° 1, lo que permite que el protocolo lo procese de manera segura. Lo que hace que esta criptomoneda sea poderosa es su combinación de velocidad y seguridad. Todo el flujo desde el envío de mensajes hasta la verificación entre cadenas se puede completar en segundos, en lugar de horas o días con los puentes canónicos. Sin embargo, la seguridad proviene de garantías criptoeconómicas respaldadas por ETH re-staked a través de EigenLayer, en lugar de o suposiciones optimistas. operadores confiables Si bien enviar mensajes de "hola" puede parecer trivial, este mismo patrón permite aplicaciones entre cadenas mucho más sofisticadas. La capacidad de verificar el estado de manera rápida y sin confianza entre los rollups crea elementos básicos para todo, desde DeFi entre cadenas hasta experiencias de usuario abstraídas de la cadena. Puente de tokens rápido y económico 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 transacciones. El panorama actual de los puentes obliga a hacer concesiones difíciles entre velocidad, costo y seguridad, pero NFFL puede reconfigurar esta dinámica y permitir una mejor experiencia de conexión para los usuarios. Los principales puentes de la actualidad ilustran claramente estas disyuntivas. Stargate, impulsado por LayerZero, logra costos relativamente bajos, pero tarda entre 10 y 30 minutos en completar las transferencias debido a que su red de operadores necesita lograr y transmitir el consenso entre múltiples cadenas. Across proporciona transferencias casi instantáneas, pero a costos entre 10 y 100 veces más altos, principalmente debido a los costosos resultados del oráculo UMA y los ciclos de reequilibrio lentos (de 6 horas) que afectan la eficiencia de la liquidez. NFFL introduce un nuevo paradigma en este caso. Al aprovechar el marco AVS de EigenLayer en lugar de mantener una red de operadores independiente, NFFL puede lograr un consenso sobre los estados de los rollups en cuestión de segundos. Este consenso se puede transmitir de manera eficiente a través de contratos de registro entre todos los rollups participantes, lo que permite diseños de puentes que combinan la eficiencia de costos de Stargate con una finalización aún más rápida que Across. Consideremos a 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 atestaciones, el contrato puente en Base puede verificar inmediatamente el bloqueo del token a través de su contrato de Registro y liberar fondos al usuario. Esta velocidad y eficiencia hacen que muchas optimizaciones de puentes existentes sean menos relevantes. Por ejemplo, suelen proponerse para evitar la finalidad lenta: los usuarios envían intenciones a tokens de puente, y estas intenciones son emparejadas y ejecutadas por actores especializados. Pero como NFFL proporciona consenso casi tan rápido como lo haría la comparación de intenciones, los puentes pueden utilizar en cambio diseños de fondos de liquidez más eficientes similares a Stargate, pero sin sus limitaciones de velocidad. los sistemas de puentes basados en intenciones Los beneficios en términos de costos son sustanciales. Los operadores de puentes no necesitan mantener una infraestructura de consenso separada ni pagar costosas salidas de oráculos. Los usuarios reciben tokens en la cadena de destino en segundos y pagan principalmente los costos básicos de gas de verificación. Los proveedores de liquidez pueden administrar las posiciones de manera más eficiente con ciclos de reequilibrio más rápidos. Como beneficio adicional, el sistema mantiene una fuerte seguridad a través de los mecanismos de corte de EigenLayer. Cualquier certificación fraudulenta daría como resultado que los operadores perdieran su ETH en stake, mientras que los puentes aún pueden verificar la liquidación final a través de puentes canónicos como una capa de seguridad adicional. Protocolo de préstamos multicadena Los préstamos entre cadenas representan quizás la aplicación inmediata más convincente de NFFL. actuales enfrentan limitaciones significativas debido a la fragmentación de la cadena. Tomemos como ejemplo Aave: a pesar de estar implementado en múltiples rollups, cada implementación opera de manera aislada (lo que crea varios problemas). Los protocolos de préstamos Los usuarios que desean utilizar garantías entre cadenas deben unir activos y esperar, lo que fragmenta la liquidez y reduce la eficiencia del capital. Además, algunas implementaciones en acumulaciones más pequeñas 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, independientemente del tamaño. En este caso, "Solo use Aave" podría formularse mejor como "Solo use Aave... pero solo en sus implementaciones más grandes". NFFL permite un enfoque fundamentalmente diferente. Considere un protocolo de préstamos que mantiene grupos en múltiples acumulaciones pero utiliza NFFL para compartir el estado de las garantías entre ellos. Un usuario podría depositar USDC como garantía en Base y luego pedir prestado inmediatamente USDT en Arbitrum contra esa misma garantía, aunque USDT no esté implementado en Base en absoluto. El contrato de Arbitrum del protocolo simplemente verifica la posición de las garantías de Base a través de las certificaciones de NFFL, sin necesidad de puentes. Esto crea nuevas y poderosas posibilidades para la eficiencia del capital. Los usuarios pueden acceder a las mejores tasas en cualquier acumulación compatible sin mover activos. Los proveedores de liquidez pueden implementar capital donde más se necesita sin mantener posiciones separadas por cadena. Y debido a que las posiciones se pueden monitorear casi en tiempo real a través de las certificaciones NFFL, los protocolos pueden ofrecer mejores tasas al mismo tiempo que mantienen la seguridad. Los beneficios van más allá de los préstamos básicos. Considere un protocolo de negociación apalancada que permita a los usuarios abrir posiciones en múltiples DEX. Un operador podría depositar una garantía en Arbitrum y luego usarla para abrir posiciones apalancadas en los DEX de Arbitrum y Base simultáneamente. El protocolo puede monitorear todas las posiciones a través de certificaciones NFFL, lo que permite liquidaciones rápidas si es necesario y brinda a los operadores 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 mecanismos de puente complejos o fuentes de precios centralizadas, los protocolos pueden verificar posiciones directamente 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 y al mismo tiempo mantener la seguridad. Y los usuarios obtienen una experiencia fluida al acceder a la liquidez en todo el ecosistema. DEX entre cadenas: impleméntelo una vez y úselo en todas partes El enfoque actual para escalar los exchanges descentralizados a través de los rollups a menudo conduce a ineficiencias absurdas. Cuando protocolos como Uniswap se implementan en un nuevo rollup, los usuarios inicialmente se enfrentan a pools sin liquidez y sin pares comerciales críticos. Consideremos la reciente implementación de Uniswap V3 en ZKsync: a pesar del entusiasmo significativo 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 liquidez insuficiente. Mientras tanto, las implementaciones 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 genera fricción en todo el ecosistema. Los proveedores de liquidez deben dividir su capital entre las distintas cadenas, lo que genera peores precios y un mayor deslizamiento en todas partes. Los usuarios necesitan conectar tokens y esperar cuando quieran acceder a una mejor liquidez en otra cadena. Los equipos de protocolo deben gestionar múltiples implementaciones, cada una de las cuales requiere un mantenimiento y una supervisión independientes. Lo has adivinado: NFFL permite una vez más un enfoque fundamentalmente diferente. Analicémoslo a través de dos patrones cada vez más potentes: Considere un nuevo DEX que se implementa exclusivamente en Arbitrum, elegido por su ecosistema DeFi establecido y sus costos de gas favorables. En lugar de lanzar instancias separadas en todas las cadenas, mantiene fondos de liquidez unificados en Arbitrum y, al mismo tiempo, permite el acceso comercial desde cualquier acumulación. Así es como un usuario de Base podría interactuar con él: Alice quiere intercambiar 10 000 USDC por ETH en Base La interfaz base de DEX consulta el estado del grupo de Arbitrum a través de certificaciones NFFL Alice ve que puede obtener mejores precios que los que ofrecen los grupos fragmentados de Base. Ella aprueba el intercambio en la Base La transacción se ejecuta en Arbitrum y el resultado se atestigua en Base. Los beneficios de esta liquidez unificada son sustanciales. Los proveedores de liquidez pueden concentrar su capital en un solo lugar, lo que genera mejores precios y menor deslizamiento. El equipo de protocolo solo necesita administrar una implementación, lo que simplifica el desarrollo y reduce los costos operativos. Y los usuarios obtienen acceso constante a una gran liquidez independientemente del paquete que estén utilizando. Un protocolo de este tipo podría utilizar el patrón de puenteo que hemos explorado anteriormente para gestionar sin problemas el flujo de intercambio. Con un tiempo de espera de tan solo unos segundos, el hecho real del puenteo puede abstraerse por completo. Esto nos acerca de manera emocionante a la tesis de la "abstracción de la cadena" que recientemente se ha vuelto bastante popular en la comunidad de criptomonedas: si para la dapp no importa en qué cadena estás, ¿por qué te importaría a ti en qué cadena estás tú y todas estas aplicaciones? Un usuario puede simplemente proceder al sitio web de la aplicación, conectar su billetera y realizar la acción deseada. Hecho. Pero NFFL permite un patrón aún más poderoso: encapsular los protocolos DeFi existentes para el acceso entre cadenas. En lugar de crear pools de liquidez que compitan entre sí, los desarrolladores pueden crear protocolos "auxiliares" que hagan que los enormes pools Uniswap de Arbitrum sean accesibles desde cualquier rollup. Por ejemplo, pensemos en Bob, que necesita intercambiar un par de tokens de cola larga en Base. Actualmente, sus opciones son limitadas: o bien pasar a otra cadena y esperar, o bien aceptar un deslizamiento extremo debido a la escasa liquidez de Base. Con un contenedor impulsado por NFFL alrededor de la implementación de Uniswap de Arbitrum, Bob podría: Consulta la liquidez disponible en todos los pools de Arbitrum Uniswap a través de las certificaciones NFFL Encuentre liquidez profunda para su par deseado en un grupo establecido de Arbitrum Ejecutar la operación desde Base a través del protocolo wrapper Reciba sus tokens en Base una vez que NFFL dé fe de la finalización del intercambio. Este patrón es transformador porque convierte las implementaciones exitosas existentes en una infraestructura universal. En lugar de esperar meses o años para que se genere liquidez a partir de nuevas implementaciones, los protocolos pueden aprovechar al instante los fondos 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 los simples swaps. Con la verificación de estado en tiempo real de NFFL, los protocolos podrían ofrecer funciones sofisticadas como órdenes límite entre cadenas. Un usuario podría colocar una orden límite en Base contra la liquidez de Arbitrum, con el protocolo contenedor monitoreando los movimientos de precios a través de las certificaciones de NFFL y ejecutándose cuando se cumplan las condiciones. Este modelo podría cambiar la forma en que pensamos sobre la implementación de protocolos en los rollups. En lugar de implementarlos automáticamente en todas partes o sumarse 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 del gas para sus operaciones específicas Pila tecnológica: máquina virtual, AA, tipo de secuenciación, DA, etc. Consideraciones regulatorias Luego, a través de NFFL, pueden seguir prestando servicio a los usuarios en todo el ecosistema de rollup y, al mismo tiempo, mantener operaciones más simples y eficientes. Las implicaciones para MEV también son interesantes. Con una liquidez unificada accesible a través de las cadenas, los buscadores de MEV necesitarían monitorear e interactuar con menos implementaciones. Esto podría conducir 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 dentro de la misma cadena, lo que permite a los protocolos optimizar su estrategia de implementación sin sacrificar la accesibilidad. En otras palabras, NFFL convierte a Ethereum en un ecosistema nuevamente. Hoja de ruta y desarrollo futuro de Nuffle Si bien NFFL ya permite nuevas y potentes aplicaciones entre cadenas, el protocolo continúa evolucionando. La hoja de ruta de desarrollo de NFFL se centra en tres áreas clave: Seguridad del protocolo Implementación de mecanismos integrales de desafío y reducción a través de EigenLayer Activación de la participación de operadores sin permiso con una gestión de participación sólida Mejora de la verificación del estado entre cadenas con primitivas criptográficas mejoradas (BLS→ECDSA) Escalabilidad de la red Optimización de esquemas de firma y propagación de estados Mejorar la eficiencia de los puntos de control y los costos de verificación Experiencia del desarrollador Creación de SDK y herramientas para una fácil integración Ampliación del soporte para diferentes tipos de acumulaciones y máquinas virtuales Creación de documentación y ejemplos para casos de uso comunes En las siguientes secciones, exploraremos en detalle algunas de las mejoras planificadas más significativas. De la Oficina de Estadísticas Laborales a la Oficina de Estadísticas Laborales de Canadá (ECDSA) Uno de los cambios más importantes planificados es la transición de las firmas BLS a las ECDSA. Actualmente, NFFL utiliza firmas BLS para permitir una agregación eficiente: las firmas de varios operadores se pueden combinar en una sola firma que demuestra el acuerdo de quórum. Si bien esto reduce los costos de verificación, crea desafíos para la gestión de conjuntos de operadores en todas las cadenas. El problema surge de cómo funciona la verificación de firmas BLS. Al verificar una firma BLS agregada, el verificador debe usar exactamente el mismo conjunto de claves públicas que la creó. Esto significa que cuando el conjunto de operadores cambia en Ethereum, todos los rollups deben actualizarse exactamente al mismo conjunto de operadores antes de que puedan verificar nuevas certificaciones. Incluso una pequeña discrepancia en los conjuntos de operadores entre cadenas puede impedir la verificación de firmas y requerir la sincronización de todos los mensajes de cambios en los conjuntos de operadores. Las firmas ECDSA, si bien requieren más espacio y cálculos para su verificación, ofrecen más flexibilidad. Las firmas de operadores individuales se pueden verificar de forma independiente, lo que permite transiciones más fluidas cuando cambia el conjunto de operadores. Los rollups pueden verificar las certificaciones siempre que 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 justificar el pequeño aumento en los costos de verificación. Conjuntos de operadores dinámicos Este cambio de firma se vincula directamente con otra mejora importante del protocolo: la implementación de conjuntos de operadores dinámicos. El sistema actual utiliza un conjunto de operadores estáticos y autorizados. Si bien esto simplificó el desarrollo inicial, limita la descentralización y la escalabilidad del protocolo. Un sistema de operadores dinámico permitiría a los nuevos operadores unirse a la red sin necesidad de permiso mediante el staking a través de EigenLayer. Esto presenta varios desafíos técnicos que deben abordarse con cuidado: En primer lugar, el protocolo debe gestionar las colas de entrada y salida de los operadores. Cuando los operadores quieren unirse o abandonar la red, estos cambios deben coordinarse entre todas las cadenas participantes. El sistema de colas garantiza transiciones fluidas sin interrumpir la capacidad de la red para verificar las certificaciones. En segundo lugar, el protocolo necesita mecanismos para hacer un seguimiento del rendimiento de los operadores y del peso de sus participaciones. A medida que los operadores se incorporan y se van, el sistema debe mantener registros precisos de las participaciones de cada operador y de 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 listas blancas. Por último, el protocolo debe gestionar de manera eficiente las actualizaciones de los conjuntos de operadores en las distintas cadenas. Cuando el conjunto de operadores cambia en Ethereum, estas actualizaciones deben propagarse a todos los conjuntos participantes a través de sus contratos de registro. La transición planificada a ECDSA ayudará en este sentido al hacer que estas actualizaciones sean más flexibles. Quitarse las ruedas de entrenamiento Otro ámbito crítico de desarrollo es la activación de mecanismos de impugnación y reducción de la competencia sin necesidad de permiso. Estos mecanismos son esenciales para imponer un comportamiento honesto y proporcionar las garantías de seguridad económica en las que se basa la NFFL. El sistema de impugnación 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, cualquiera puede impugnar estos puntos de control si cree que contienen certificaciones no válidas. Una impugnación exitosa puede surgir de varios tipos de fallas: En primer lugar, las fallas de seguridad que afectan directamente la integridad de la red. Entre ellas se incluyen las equivocaciones, en las que un operador firma varios mensajes conflictivos para el mismo caso, como la certificación de diferentes raíces de estado para el mismo bloque. También se incluyen las certificaciones no válidas, en las que un operador aprueba transiciones de estado o actualizaciones de conjuntos de operadores que pueden demostrarse incorrectas. En segundo lugar, las fallas de actividad que afectan la disponibilidad de la red. Si los operadores se abstienen sistemáticamente 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 este tipo de comportamiento y tener en cuenta el tiempo de inactividad legítimo. El protocolo implementará un sistema de impugnación basado en garantías. Los impugnadores deben bloquear las garantías cuando presentan una impugnación, que perderán si la impugnación resulta inválida. Sin embargo, si logran demostrar con éxito que el operador cometió un error, recibirán una recompensa de la participación del operador reducida. Esto crea incentivos económicos para monitorear el comportamiento del operador y evitar impugnaciones frívolas. En el caso de las actualizaciones de la raíz del estado, el proceso de impugnación es particularmente interesante. Una vez que un operador da fe del estado de un rollup, se puede impugnar demostrando que los datos del bloque correspondiente no se publicaron correctamente en NEAR DA o que el estado atestiguado no coincide con el estado canónico después de la liquidación. Esto requiere que los impugnadores proporcionen pruebas a través del Rainbow Bridge para la verificación de NEAR DA, lo que crea múltiples capas de seguridad. El mecanismo de reducción 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 pérdidas potenciales superen significativamente cualquier ganancia derivada de un comportamiento malicioso. Parte de esta reducción se otorga a los retadores exitosos, mientras que el resto puede distribuirse entre operadores honestos o usarse para el desarrollo de protocolos. Estos mecanismos crean un marco de seguridad integral. Los operadores enfrentan importantes sanciones financieras por mala conducta, los retadores tienen incentivos para monitorear la red y las aplicaciones pueden confiar en garantías criptoeconómicas respaldadas por ETH re-staked. Los períodos de desafío son mucho más cortos que las pruebas de fraude de los optimistas rollup, al mismo tiempo que brindan una seguridad sólida a través de la mecánica de corte de EigenLayer. El futuro de la finalidad rápida en Ethereum Si bien NFFL ofrece una solución inmediata para la verificación del estado de los rollups cruzados, vale la pena examinar cómo encaja el protocolo en la hoja de ruta de escalamiento más amplia de Ethereum. La pregunta clave que muchos se hacen es: "¿NFFL seguirá siendo relevante a medida que avance la tecnología de rollup?" La respuesta se hace evidente cuando examinamos las limitaciones fundamentales de la liquidación en diferentes diseños de rollups. Los rollups optimistas, a pesar de su popularidad y madurez, no pueden liquidarse fundamentalmente más rápido que su ventana a prueba de fraude, que normalmente es de 7 días. Si bien soluciones como la 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 esos dos. Los rollups de ZK enfrentan limitaciones diferentes pero igualmente importantes. Aunque la tecnología de prueba de ZK mejora drásticamente, existen límites prácticos para la velocidad de liquidación. Incluso si llegamos a un punto en el que se puedan generar pruebas para cada bloque L1, Ethereum aún debe tener capacidad para verificar múltiples pruebas de ZK por bloque en diferentes rollups. Cuando esto sea posible, la liquidación seguirá estando limitada por el tiempo del bloque L1, al menos 12 segundos según los parámetros actuales. NFFL ofrece un enfoque diferente al utilizar las certificaciones firmadas del secuenciador a partir de los paquetes. En lugar de esperar a que se publiquen los lotes en L1, los operadores de NFFL pueden verificar y certificar los cambios de estado tan pronto como los produce el secuenciador. Esto permite la verificación del estado entre cadenas en segundos, manteniendo al mismo tiempo una sólida seguridad criptoeconómica a través de EigenLayer. Es importante destacar que NFFL no debe considerarse como una competencia o una amenaza para el modelo de seguridad 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 y, al mismo tiempo, seguir dependiendo de la liquidación canónica a través de L1 cuando sea necesario. Esto crea un conjunto de herramientas más completo para que los desarrolladores creen aplicaciones entre cadenas con modelos de seguridad adecuados a sus necesidades específicas. Conclusión NFFL representa un enfoque novedoso para resolver uno de los desafíos más urgentes en el ecosistema modular de Ethereum: permitir una verificación de estado de acumulación cruzada segura y eficiente. Al aprovechar el ETH reestablecido de EigenLayer para la seguridad económica y NEAR DA para el almacenamiento eficiente de datos, NFFL crea una capa de finalidad rápida que puede verificar los estados de acumulación en segundos en lugar de horas o días. Las decisiones de diseño bien pensadas del protocolo reflejan una comprensión profunda de los desafíos en la infraestructura entre cadenas. 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 una finalización más rápida. El sistema de tareas basado en puntos de control permite una operación eficiente fuera de la cadena mientras mantiene fuertes garantías de seguridad dentro de la cadena. Y la arquitectura del contrato de registro permite que los rollups verifiquen los estados sin necesidad de confiar en ellos mientras heredan la seguridad económica de NFFL. Quizás lo más importante es que NFFL permite una nueva generación de aplicaciones entre cadenas que antes eran poco prácticas. Desde protocolos de préstamos unificados que comparten garantías entre acumulaciones hasta contenedores DEX que hacen que la liquidez establecida sea universalmente accesible, la verificación rápida del estado de NFFL crea los elementos básicos 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. La hoja de ruta del protocolo demuestra el compromiso con la mejora continua. Las actualizaciones planificadas, como la transición a las 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 integrales de desafío y reducción de errores 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 acumulación de Ethereum continúa evolucionando, la necesidad de una verificación segura del estado entre cadenas no hará más que crecer. El enfoque de NFFL de ampliar la seguridad de Ethereum mediante el resttaking, al tiempo que optimiza la velocidad y la rentabilidad, lo posiciona bien para satisfacer esta necesidad. Al permitir nuevas formas de interacción entre cadenas y al mismo tiempo mantener sólidas garantías de seguridad, NFFL contribuye a hacer realidad la visión modular de Ethereum. Nota del autor: una versión de este artículo fue publicada originalmente . aquí