Introdução

Em retrospecto, os rollups surgiram como a solução definitiva de escalabilidade para Ethereum e tecnologia descentralizada como um todo. Nove meses após a atualização Dencun do Ethereum, que visava à escalabilidade da disponibilidade de dados de rollup, a taxa de transações ultrapassouduzentas transações por segundo—representando um aumento de cinco vezes desde o início do ano. As duas principais rollups, Arbitrum e OP Mainnet, alcançaram a descentralização da etapa 1—ultrapassando várias redes alternativas proeminentes da Camada 1nas métricas de descentralização—com rollups adicionais potencialmente visando a descentralização do estágio 2 em 2025. A tecnologia de prova de conhecimento zero progrediu para permitirverificação de transações equivalentes ao Ethereum a custos inferiores a um centavo, estabelecendo um caminho para a verificação eficiente de milhares de transações padrão de usuários na contemporânea blockchain Ethereum.

No entanto, esse avanço apresenta novos desafios. Múltiplas equipes estão desenvolvendo blockchains independentes sobre o Ethereum, com interoperabilidade limitada entre elas. Essa limitação decorre principalmente da finalização infrequente dos rollups, o que dificulta uma comunicação significativa entre blockchains. Além disso, os rollups otimistas, que atualmente hospedam a maioria das atividades ecossistêmicas e Valor Total Bloqueado (TVL), enfrentam restrições técnicas inerentes que impedem a comunicação direta fora das pontes compartilhadas, criando uma barreira significativa para a interoperabilidade entre redes importantes como Arbitrum e Base. A comunidade propôs várias soluções, que vão desde pontes baseadas em intenção e trocas atômicas até abstração completa de blockchains. Apesar de suas diferenças, essas soluções compartilham um requisito fundamental: uma fonte confiável de verdade - um protocolo que permite verificação de estado segura entre rollups, que seja rápida e econômica.

Entre as soluções proeminentes, que geralmente dependem de oráculos otimistas (Across), consenso de operador especializado (Stargate via LayerZero) ou confiança sequenciadora centralizada (Polymer Hub), a Camada de Finalidade Rápida da Nuffle Labs (NFFL) apresenta um equilíbrio convincente entre eficiência, segurança e alinhamento com o Ethereum. Este artigo examina a abordagem inovadora da NFFL para permitir a verificação de estado entre rollups por meio do mecanismo de restaking da EigenLayer e da NEAR DA, explora seu design arquitetônico e roteiro de desenvolvimento e analisa aplicações potenciais e suas implicações para o ecossistema.

Sua Ethereum Edge

Receba pesquisas em primeira mão entregues pela nossa equipe de especialistas.

Seu endereço de e-mail

Antecedentes

Para entender os desafios abordados pela NFFL, vamos examinar a arquitetura fundamental dos rollups, seus objetivos e suas limitações inerentes.

Rollups 101

Um rollup é um blockchainque utiliza outra blockchain independente para ordenação de transações, disponibilidade de dados e consenso, enquanto executa transações externamente de maneira verificável pela blockchain principal. Embora muitas definições se refiram à cadeia principal como Camada 1 (L1) e o rollup como Camada 2 (L2), alguns frameworks não exigem que os L2s usem o L1 para disponibilidade de dados. Para maior clareza, este artigo foca especificamente em rollups ao invés da categoria mais ampla L2.

Um exemplo dessa distinção - todos os rollups são L2s, mas nem todos os L2s são necessariamente rollups. Origem:blog.thirdweb.com

Claro, no nosso caso, o L1 pai é o blockchain Ethereum. Ele é responsável por compartilhar seu consenso com os rollups (vamos elaborar mais sobre isso depois). Vamos analisar como os rollups alavancam o Ethereum para suas funções principais: ordenação de transações, disponibilidade de dados e consenso.

Ordenação de Transações

Rollups incorporam uma entidade chamada sequenciador, responsável por gerenciar a inclusão e a ordem das transações por meio da rede L1. O sequenciador funciona de forma análoga a um produtor de blocos em blockchains tradicionais. Especificamente, ele aceita transações recebidas de usuários sequencialmente, as agrupa em lotes (comparáveis a blocos L1) e publica periodicamente esses lotes em um contrato inteligente designado na L1.

Um contrato inteligente na L1 mantém um registro autoritário de todas as transações publicadas e sua ordem. Os nós Rollup devem monitorar este contrato para obter novos blocos e informações de transação. Uma vez que um lote é incluído em um bloco L1 e esse bloco alcança a finalidade por meio do consenso L1, a inclusão e a ordem de todas as transações dentro desse lote são garantidas pelas propriedades de segurança da L1.

Em certa medida, o sequenciador é um “iniciador” do rollup - ele ajuda o rollup a realmente aceitar novas transações na rede, facilitando o avanço do estado. Alguns rollups implementam sequenciamento descentralizado - conjunto rotativo de entidades especializadas que reduzem o risco de tempo de inatividade de um sequenciador centralizado - e sequenciamento baseado, que não usa nenhum sequenciador como fonte de confiança antes de publicar o lote para o L1. Em vez disso, o sequenciamento baseado permite que qualquer pessoa seja um sequenciador, mas seus lotes só são usados pelos nós quando publicados para o L1. Isso praticamente elimina o risco de tempo de inatividade do sequenciamento, ao custo de uma inclusão de transações mais lenta (o cenário ideal é de 12 segundos por bloco do L1).

No entanto, os sequenciadores não decidem sobre o novo estado das coisas no rollup, mesmo após a execução de seus próprios lotes. Portanto, os sequenciadores “começam”, mas não necessariamente “executam” o rollup, pois suas ações não podem levar diretamente à transição de estado maliciosa.

Um motor de arranque. Mesmo que não ligue o motor, sem ele o motor também não funcionaria. Pense no rollup como o motor e no sequenciador como o motor de arranque.

Disponibilidade de Dados

No entanto, as informações sobre o pedido de algumas transações não são suficientes para os nós do rollup, pois eles não possuem as transações em si. Para executar essas transações e determinar seu resultado no blockchain do rollup, os nós devem ter acesso total e irrestrito a todas as transações no lote.

Consequentemente, os sequenciadores rollup devem publicar dados abrangentes de transação para o L1 de maneira que permita que o contrato inteligente do rollup verifiquedisponibilidade de dados. Uma vez que os dados da transação para um lote são incluídos e finalizados na L1, sua disponibilidade é garantida para todos os nós participantes.

Antes da atualização do Dencun, os rollups do Ethereum estavam postando os dados da transação nos dados de entrada (calldata) das chamadas de sequenciamento no L1. Portanto, todas as transações devem ter sido postadas para sempre no blockchain do L1. Isso pode parecer razoável, pois queremos que todos os nós, incluindo os futuros, sejam capazes de reconstruir o estado do rollup. No entanto, isso é muito ineficiente, já que o Ethereum L1 não pode armazenar grandes dados em seu livro-razão, enquanto os rollups, as vias de alta velocidade do Ethereum, são muito intensivos em dados. Em vez disso, podemos fazer com que o contrato inteligente do rollup verifique a validade das transações sequenciadas, para que os nós sigam instantaneamente o estado no contrato, em vez de reconstruí-lo a partir de todas as transações a partir do início.

Enshrined Bridge (Consensus)

Para simplificar, apenas invertemos a definição do rollup de cabeça para baixo - geralmente, todas as explicações começam com uma ponte bidirecional entre o rollup e seu L1. É bastante comum entre os rollups usar a moeda nativa do L1 como sua própria, para simplificar a estimativa das taxas de gás com base nos gastos dos sequenciadores e proponentes. Além disso, muitos rollups desejam obter tokens populares em seu ecossistema a partir do dia 1, para o qual a ponte do L1 é a melhor escolha.

Implementar um contrato inteligente de ponte do L1 para a rollup é bastante direto - os nós da rollup já ouvem todas as coisas acontecendo em seu contrato, assim podemos implementar uma função de depósito do L1 que todos os nós interpretarão como um comando para emitir o respectivo token “wrapped” na própria rollup.

No entanto, as retiradas sem confiança exigem que o contrato de ponte valide todas as transações do rollup e determine seus resultados legítimos. Isso permite que a ponte processe solicitações de retirada válidas liberando fundos para iniciadores autorizados no L1. Esse mecanismo de validação torna a ponte a fonte definitiva do estado canônico do rollup - os nós se alinham com a transição de estado da ponte, independentemente de bifurcações de cadeia alternativas. Ao contrário das blockchains tradicionais, os rollups não implementam regras de consenso independentes para seleção de cadeia. O contrato de ponte no L1 é o que define a cadeia canônica.

Blobs

A atualização Dencun do Ethereum em março passado introduziu ‘blobs’ - células temporárias de dados armazenadas fora da blockchain e podadas (excluídas pelos validadores da rede) após ~ 18 dias. À medida que as pontes rollup tornam possível reconstruir o estado sem reexecutar transações, essa propriedade se tornou muito útil para rollups, que migraram de calldata para blobs logo após a atualização. Falando em números, antes de Dencun, o TPS total dos rollups era de cerca de 50. Hoje, está acima de 200, com limites teóricos em400-800 TPS dependendo do rollup.

Fonte: L2BEAT

Além das melhorias de capacidade, os blobs eliminaram a necessidade de pagar custos de gás EVM para armazenamento de dados de transação, estabelecendo um canal separado com armazenamento temporário especializado e precificação de taxas independentes. Essa mudança arquitetônica reduziu drasticamente os custos de transação em rollups, com as taxas caindo de 10-40 centavos por transação para níveis subcentrais em redes como Base.

Origem: growthepie.xyz

Compensação em Rollup

Enquanto os sequenciadores gerenciam a ordem e a publicação das transações, eles representam apenas um componente da arquitetura de rollup. Os rollups também incorporam entidades chamadas “propositores” responsáveis por convencer a ponte L1 de saídas de estado específicas resultantes de lotes recém-sequenciados. Em essência, enquanto os sequenciadores estabelecem a ocorrência e a ordem das transações, os propositores demonstram os resultados dessas transações de acordo com a lógica de processamento do rollup, como sua máquina virtual.

O papel do proponente varia significativamente com base na abordagem de validação de estado do rollup. Existem duas metodologias fundamentalmente diferentes, definindo duas categorias de rollups: Otimista e Zero-Knowledge (ZK).

Rollups otimistas

Em rollups otimistas, os proponentes enviam regularmente atualizações de estado para a ponte L1, normalmente ao lado ou logo após as publicações em lote do sequenciador. Essas atualizações de estado incluem a nova raiz de estado (um compromisso criptográfico com todo o novo estado do rollup) após a execução de todas as transações nos lotes mais recentes.

Para evitar atualizações inválidas de estado, a ponte implementa um período de desafio (geralmente 7 dias) durante o qual atores especializados chamados “desafiadores” podem contestar a proposta enviando uma prova de fraude. Essa prova demonstra que as transações foram executadas incorretamente, reexecutando a transação contestada no L1 e comparando os resultados.

Se um desafiante conseguir provar com sucesso que um proponente enviou uma transição de estado inválida, a saída do estado é revertida e o desafiante é recompensado (geralmente de uma fiança que os proponentes devem apresentar). Isso cria um jogo econômico onde os proponentes são incentivados a enviar apenas transições de estado válidas.

Rollups de conhecimento zero

Em rollups ZK, os proponentes geram provas matemáticas (chamadas de “provas de validade” ou, mais tecnicamente correto, “provas ZK”) que demonstram a correção de cada transição de estado. Essas provas mostram que todas as transações em lote foram executadas de acordo com as regras do rollup sem revelar os detalhes específicos de sua execução.

A ponte L1 pode verificar rapidamente essas provas usando operações criptográficas eficientes, com o custo aproximado de uma troca de tokens. Uma vez que uma prova é verificada, a ponte aceita a atualização do estado como liquidada. Isso significa que os proponentes devem realizar um trabalho computacional significativo antes de enviar atualizações de estado, mas essas atualizações são liquidadas muito mais rapidamente em comparação com os rollups otimistas.

Assentamento, Finalidade e Interoperabilidade

O tempo de liquidação através das pontes canônicas varia significativamente entre os tipos de rollup—de 7 dias para rollups otimistas devido ao seu período de desafio, a várias horas para rollups ZK devido ao custo de geração de prova e custos de publicação em lote. Embora esse modelo funcione bem para garantir transações de alto valor que podem tolerar atrasos, ele cria uma fricção significativa para o ecossistema DeFi mais amplo.

Considere como isso afeta o uso no mundo real: um usuário que deseja usar seu colateral baseado em Arbitrum para conseguir um empréstimo no Base deve primeiro transferir seus ativos e esperar até 7 dias antes que eles possam ser usados. Um trader que identifica uma oportunidade de arbitragem entre pools Uniswap em diferentes rollups veria a oportunidade desaparecer muito antes que ele pudesse executá-la. Um aplicativo de jogos que deseja permitir que os jogadores negociem itens em diferentes implantações de rollup enfrentaria uma experiência do usuário inaceitável com esses atrasos longos.

A visão crucial aqui é que os nós de rollup podem realmente observar as mudanças de estado muito mais rápido - normalmente dentro de segundos da confirmação do bloco L1. Embora esse estado não tenha passado por um ajuste completo na ponte canônica, ele é baseado em dados de transação que já foram ordenados e finalizados no Ethereum. Muitas exchanges centralizadas já aproveitam essa propriedade, creditando os depósitos de usuários dos rollups após apenas algumas confirmações de bloco, executando seus próprios nós e verificando a finalidade da transação no L1.

Isso cria uma interessante dicotomia no ecossistema de rollup. Embora os rollups tenham aumentado com sucesso o throughput de transações do Ethereum, eles introduziram uma severa fragmentação de estado e liquidez. Cada rollup opera efetivamente como uma blockchain independente que não pode verificar eficientemente o estado de outros rollups sem esperar pelo ajuste da ponte, apesar de todos eles derivarem sua segurança da mesma cadeia subjacente - Ethereum.

Soluções Existente

O ecossistema desenvolveu várias abordagens para superar essas limitações, desde pontes centralizadas até redes off-chain especializadas. Essas soluções geralmente fazem diferentes compensações entre três propriedades-chave:

• Segurança - Quão fortes são as garantias de que a verificação de estado está correta
• Velocidade - Quão rapidamente o estado pode ser verificado em várias cadeias
• Custo - Quão caro é manter e usar a solução

A maioria das soluções existentes otimiza a velocidade e o custo às custas da segurança - muitas vezes dependendo de operadores confiáveis, multisigs ou mecanismos otimistas com suporte econômico mínimo. Isso levou a vários hacks de pontes de alto perfil, destacando os riscos de sacrificar a segurança pela conveniência, mais notavelmente a exploração da ponte Ronin de $625 milhões.

O desafio fundamental é estabelecer uma “fonte segura de verdade” sobre os estados de rollup que podem:

• Verifique as alterações de estado em segundos ou minutos, em vez de horas ou dias
• Fornecer garantias fortes de segurança criptoeconômica
• Operar de forma rentável tanto para fornecedores de infraestrutura quanto para usuários
• Integre-se perfeitamente às arquiteturas de rollup existentes

Essa oportunidade de permitir uma verificação de estado rápida e segura entre rollups tem despertado uma inovação significativa. Diversas equipes estão abordando o problema de diferentes ângulos, buscando criar uma infraestrutura que possa impulsionar a próxima geração de aplicações entre cadeias sem comprometer a segurança.

Nas seções seguintes, exploraremos como a NFFL aborda esse desafio por meio de sua combinação inovadora de restaking da EigenLayer e NEAR DA, criando uma camada de finalidade rápida que equilibra cuidadosamente segurança, velocidade e eficácia de custo.

Mergulho Profundo da NFFL

Tese principal

A Camada de Finalidade Rápida Nuffle (NFFL) representa uma abordagem inovadora para possibilitar interações seguras entre cadeias, fornecendo verificação rápida de estados entre rollups. Em vez de forçar os desenvolvedores a escolher entre segurança e velocidade, o NFFL aproveita o ETH restakeado da EigenLayer para criar uma camada de finalidade rápida criptoeconomicamente segura que pode atestar estados de rollup em questão de segundos.

Em sua essência, NFFL opera como um Serviço Ativamente Validado (AVS) executado na EigenLayer. Uma rede descentralizada de operadores, cada um executando nós completos para rollups participantes, verifica e atesta atualizações de estado. Essas declarações são respaldadas pelo ETH reinvestido pelos operadores, criando fortes incentivos econômicos para comportamento honesto. Ao combinar isso com a camada de Disponibilidade de Dados da NEAR para armazenamento eficiente de dados de bloco, o NFFL permite que aplicativos verifiquem com segurança o estado cross-chain em 2-3 segundos - ordens de grandeza mais rápido do que a liquidação de bridge canônica.

Arquitetura de design simplificado do NFFL

O que torna o NFFL particularmente cativante é a sua abordagem de design pragmática. Em vez de tentar substituir ou competir com o modelo de segurança do Ethereum, ele fornece uma camada complementar otimizada para casos de uso que exigem uma finalização mais rápida. As aplicações podem escolher se querem confiar na segurança cripto-econômica do NFFL ou aguardar a liquidação completa do L1 com base em suas necessidades específicas. Essa flexibilidade permite que o NFFL melhore a experiência do usuário para muitas interações entre cadeias enquanto mantém garantias de segurança sólidas.

O sistema introduz três inovações-chave:

1. Uma rede de operadores descentralizada que alcança consenso nos estados de rollup comparando transições de estado executadas localmente em relação aos dados de bloco postados no NEAR DA
2. Um sistema de tarefas baseado em checkpoints que permite a agregação e verificação eficiente de atestações de operadores, mantendo a responsabilidade por meio dos mecanismos de penalização do EigenLayer.
3. Um mecanismo de armazenamento de dados usando NEAR DA que permite a fácil recuperação de dados de rollup atestados em todos os rollups

Essa concepção permite à NFFL encontrar um equilíbrio cuidadoso entre segurança, velocidade e custo-efetividade - três propriedades que tradicionalmente estiveram em conflito na infraestrutura cross-chain. Ao fornecer verificação de estado rápida e segura, a NFFL abre novas possibilidades para aplicações cross-chain que vão desde protocolos de empréstimo até agregadores de liquidez.

Nas próximas seções, exploraremos a arquitetura do NFFL em detalhes, examinando como seus vários componentes trabalham juntos para possibilitar essa nova primitiva de interação entre cadeias. Também analisaremos seu modelo de segurança, discutiremos possíveis aplicações e examinaremos o roteiro do protocolo para desenvolvimentos futuros.

Componentes Principais

Conjunto de operadores

No coração do NFFL está sua rede de operadores - um sistema descentralizado que estende a segurança do Ethereum para permitir uma verificação rápida entre rollups. Em vez de criar mais uma rede isolada que exige suas próprias suposições de segurança, o NFFL é construído como um Serviço Ativamente Validado (AVS) na EigenLayer, permitindo que ele se conecte diretamente ao ecossistema existente de validadores do Ethereum.

Essa escolha arquitetônica é fundamental para entender o modelo de segurança da NFFL. Os mesmos validadores que garantem o consenso do Ethereum podem reestacar seu ETH através da EigenLayer para se tornarem operadores da NFFL. Ao fazer isso, eles colocam seu ETH em jogo para respaldar suas atestações sobre os estados de rollup. Isso cria uma ponte de segurança poderosa entre o consenso do Ethereum e a camada de finalidade rápida da NFFL.

Quando um rollup publica novos dados de bloco no L1, os relayers os encaminham para o NEAR DA. Os operadores recuperam os dados do bloco por meio de ambas as fontes e garantem que sejam equivalentes. Explicaremos mais adiante por que a publicação de dados de rollup no NEAR DA é necessária para tornar as aplicações que utilizam NFFL mais convenientes para usuários e desenvolvedores.

Após recuperar novos lotes de rollup, os operadores os executam em seus nós de rollup. Dado que todos executam o mesmo software de nó, eles sempre aparecerão com a mesma saída de estado correta. Esta saída de estado é então assinada por todos os operadores. Quando a maioria dos operadores concorda com um estado específico, ele é aceito pelo sistema e pode ser transmitido para contratos de registro em todos os rollups.

A segurança econômica desse sistema possui uma propriedade muito interessante que deriva da mecânica de penalização do EigenLayer:

No EigenLayer, os Serviços Ativamente Validados podem implementar um mecanismo de verificação capaz de detectar atestados inválidos dos operadores e cortar (liquidar) seu depósito posteriormente. Como o NFFL “resolve preliminarmente” o estado de rollup off-chain antes de ser instalado na ponte, é possível detectar objetivamente a fraude aguardando o atraso na liquidação e notificando o contrato AVS sobre a inconsistência de saída no atestado e na ponte. Isso desincentiva economicamente os atestados fraudulentos, pois eles podem ser detectados e cortados por qualquer entidade que observe o estado de L1 e NFFL, mesmo sem que eles executem nós de rollup. Em outras palavras, a NFFL “assegura” as reivindicações da rede – as operadoras estão colocando capital significativo em risco para apoiar suas reivindicações sobre estados de rollup.

O que torna isso particularmente poderoso é como alinha os incentivos em todo o sistema. Os operadores ganham taxas por participação honesta enquanto arriscam perdas significativas por desonestidade. Quanto mais ETH é reinvestido na NFFL, mais fortes se tornam esses incentivos. E porque essa segurança é derivada do Ethereum através do EigenLayer, ela se beneficia parcialmente do mesmo modelo robusto de segurança econômica que protege centenas de bilhões em valor no próprio Ethereum.

Fluxo de mensagens

O sistema de mensagens da NFFL representa uma abordagem inovadora para lidar com a verificação de estado intercadeias em escala. Em vez de registrar todas as declarações de estado on-chain, o que seria proibitivamente caro, a NFFL introduz um sistema de duas camadas de Mensagens e Tarefas que permite uma operação off-chain eficiente ao mesmo tempo em que mantém garantias de segurança on-chain fortes sob demanda.

As mensagens são a unidade básica de comunicação na NFFL. Quando os operadores verificam um novo estado, eles criam e assinam uma Mensagem atestando esse estado. Essas Mensagens existem principalmente off-chain, circulando entre os operadores e o agregador sem incorrer em custos de gás on-chain. Existem dois tipos distintos de Mensagens que fluem pelo sistema:

• As mensagens de atualização do estado raiz contêm a atestação de um operador sobre o estado de um rollup em uma altura de bloco específica. Cada mensagem inclui não apenas o próprio estado raiz, mas também uma referência à transação NEAR DA que contém os dados do bloco, criando um link verificável entre o estado atestado e seus dados subjacentes.
• Atualização do conjunto de operadores As mensagens de atualização do conjunto de operadores acompanham as alterações no conjunto de operadores da NFFL. Essas mensagens são cruciais para a segurança do sistema, pois permitem que os contratos de registro rollup mantenham um registro atualizado de operadores válidos, garantindo que as atestações sejam aceitas apenas de participantes autorizados com participação em risco.

Embora as Mensagens permitam uma verificação eficiente do estado, elas por si só não são suficientes para garantir a segurança econômica do sistema. É aqui que entram as Tarefas. As Tarefas são unidades de trabalho on-chain que fazem checkpoint do estado do sistema em intervalos regulares. Em vez de enviar cada Mensagem para o Ethereum, os operadores periodicamente constroem uma Árvore Merkle Esparsa contendo todas as Mensagens de um período de tempo específico. A raiz dessa árvore é então enviada como uma resposta de Tarefa, criando um compromisso eficiente on-chain para todas as atestações off-chain.

Este sistema de ponto de verificação é particularmente inteligente porque permite a verificação seletiva de qualquer Mensagem sem exigir que todas as Mensagens sejam armazenadas na cadeia. Através de provas de Merkle, qualquer pessoa pode verificar que uma Mensagem específica foi incluída em um ponto de verificação, possibilitando mecanismos de desafio eficientes, mantendo os custos básicos baixos. Você pode pensar nisso como a criação de um “blockchain de atestações” onde os pontos de verificação servem como cabeçalhos de bloco que se comprometem com todas as Mensagens dentro de um período de tempo.

O agregador desempenha um papel crucial neste sistema, coletando assinaturas de operadores e disponibilizando-as por meio de uma API. Quando os operadores assinam Mensagens, eles as enviam para o agregador que verifica se as assinaturas atingiram o quórum (ponderado por ETH apostado) antes de expô-las para uso por aplicativos. Isso cria uma interface limpa para os desenvolvedores, mantendo as propriedades de segurança descentralizadas do sistema. Vamos elaborar sobre o serviço de agregador na próxima seção.

Serviço de Agregador

O agregador atua como a camada de coordenação do NFFL, gerenciando eficientemente o fluxo de mensagens entre operadores e aplicativos. Embora conceitualmente simples, seu design reflete uma cuidadosa consideração tanto das necessidades práticas dos desenvolvedores quanto dos princípios de descentralização.

Em sua essência, o agregador resolve o problema da ‘tragédia dos comuns’ na agregação de assinaturas. Sem um serviço dedicado, cada aplicativo que usa NFFL precisaria coletar e verificar independentemente as assinaturas de todos os operadores - um processo ineficiente e caro. Em vez disso, o agregador fornece um único ponto de coleta para as assinaturas dos operadores, verificando o quórum e expondo as atestações verificadas por meio de uma API simples.

O processo de agregação de assinaturas funciona da seguinte maneira:

• Operadores assinam independentemente mensagens atestando as atualizações de estado
• Essas assinaturas são enviadas ao agregador para coleta
• O agregador verifica a validade da assinatura e rastreia o quórum
• Uma vez alcançado peso de participação suficiente, a assinatura agregada fica disponível
• Os aplicativos podem buscar essas atestações por meio da API do agregador

Este design reduz significativamente a complexidade para os desenvolvedores que integram NFFL. Em vez de gerenciar operações criptográficas complexas ou rastrear apostas de operadores, os aplicativos podem simplesmente solicitar comprovações para atualizações específicas de estado por meio de uma interface de API limpa. O agregador lida com toda a complexidade da coleta de assinaturas, verificação e agregação BLS nos bastidores.

Assinatura Agregada

Vamos explorar a agregação BLS usada pelo NFFL. As assinaturas BLS têm uma propriedade matemática poderosa que permite que várias assinaturas sejam combinadas em uma única assinatura. Em vez de verificar N assinaturas individuais de operadores, o que seria computacionalmente caro e intensivo em gás, as aplicações podem verificar uma única assinatura agregada que comprova acordo coletivo.

Os ganhos de eficiência aqui são substanciais. Quando os operadores da NFFL assinam uma Mensagem, eles geram assinaturas BLS padrão usando suas chaves privadas. O agregador pode então combinar essas assinaturas individuais em uma assinatura compacta que prova o acordo do quórum. O tamanho e o custo de verificação dessa assinatura agregada permanecem constantes, independentemente do número de operadores participantes - uma propriedade que torna o sistema altamente escalável.

Além disso, a assinatura agregada pode ser verificada em relação às chaves públicas combinadas dos operadores de assinatura, ponderadas pelos valores apostados para garantir que a segurança econômica seja devidamente considerada. O contrato de registro só precisa executar uma operação de verificação de assinatura para confirmar que peso de aposta suficiente atestou a atualização de estado.

Agregador e Pontos de Verificação

É importante observar que, embora o agregador forneça conveniência, ele não compromete o modelo de segurança do NFFL. As assinaturas que ele coleta são publicamente verificáveis e seu papel é puramente organizacional, não autoritário. As aplicações sempre podem verificar independentemente que as assinaturas agregadas representam um quórum legítimo dos operadores apostados. O agregador não pode forjar assinaturas nem ocultar atestações válidas, apenas as torna mais acessíveis.

O agregador também desempenha um papel vital no sistema de checkpoints. Ao coletar todas as mensagens ao longo do tempo, ele pode construir as Árvores Merkle Esparsas usadas nas tarefas de checkpoint. Isso cria um registro eficiente de todas as atestações que passaram pelo sistema, possibilitando verificação posterior, se necessário, para desafios de segurança ou fins de auditoria.

Contratos de Registro

O contrato de Registro, implantado em cada rollup participante, serve como a ponte crítica entre as declarações fora da cadeia da NFFL e a verificação do estado na cadeia. Esses contratos permitem que aplicativos verifiquem, sem confiança, o estado de outros rollups validando as declarações criptoeconomicamente seguras da NFFL.

O que torna o Registro particularmente interessante é como ele mantém as propriedades de segurança da NFFL em diferentes cadeias. Cada contrato de Registro mantém uma cópia local do conjunto de operadores da NFFL, rastreando as mudanças por meio de atestados de atualização do conjunto de operadores. Isso significa que, embora o conjunto de operadores seja gerenciado por meio do EigenLayer no Ethereum, seu estado é espelhado de forma confiável em todos os rollups participantes, permitindo que eles verifiquem independentemente os atestados.

Quando um aplicativo precisa verificar o estado de outro rollup - por exemplo, um protocolo de empréstimo verificando o colateral no Arbitrum a partir do Optimism - ele envia a respectiva comprovação para o seu contrato de Registro local. Esta comprovação inclui a assinatura BLS agregada que discutimos anteriormente, juntamente com a raiz de estado específica que está sendo atestada e sua referência de transação NEAR DA associada.

O processo de verificação no Registro é incrivelmente eficiente graças à agregação de assinatura BLS. O contrato só precisa executar uma única verificação de assinatura em relação às chaves públicas ponderadas do conjunto atual de operadores. Se a assinatura for válida e representar peso de participação suficiente, o Registro aceita o estado atestado como verificado. Isso cria uma ponte confiável entre rollups que é segura e econômica.

O Registro cria uma ponte de confiança minimizada entre rollups que é segura e econômica. Por meio da verificação de assinaturas agregadas em relação às chaves públicas ponderadas do conjunto de operadores, ele pode confirmar que uma atualização do estado recebeu peso de atestação suficiente para ser considerada válida. Isso permite que aplicativos verifiquem de forma confiável os estados em diferentes rollups enquanto herdam as garantias de segurança econômica do NFFL.

O Registro também desempenha um papel crucial no sistema de desafio da NFFL. Se uma atestação for posteriormente comprovada como fraudulenta através do sistema de desafio, o Registro pode invalidá-la, protegendo as aplicações de dependerem de um estado incorreto. Isso cria múltiplas camadas de segurança - garantias criptoecônomicas imediatas de ETH apostado combinadas com proteção contra fraudes a longo prazo através de desafios.

Classificação de Falhas e Projeto de Segurança

O modelo de segurança da NFFL centra-se na detecção e penalização de dois tipos principais de comportamento inadequado do operador: Falhas de segurança e Falhas de vivacidade.

Falhas de segurança são violações que afetam a integridade da rede ao produzir estados incorretos ou resultados inconsistentes com as regras do sistema. Existem dois tipos principais de falhas de segurança que os operadores podem cometer:

• Equivocação ocorre quando um operador assina múltiplas mensagens conflitantes para o mesmo evento. Por exemplo, assinar declarações para diferentes raízes de estado na mesma altura de bloco, ou atestar múltiplos carimbos de tempo diferentes para o mesmo bloco. Tal comportamento mina a capacidade da rede de alcançar consenso sobre o estado canônico.
• A Attestation Inválida ocorre quando um operador assina uma declaração provavelmente incorreta. Isso pode ser atestar uma atualização do conjunto de operadores que não corresponde à diferença de estado em cadeia, ou assinar uma raiz de estado que não corresponde à execução correta das transações do bloco. Essas falhas podem ser verificadas objetivamente por meio de dados em cadeia.

Enquanto falhas de segurança atacam diretamente a correção, falhas de Liveness afetam a disponibilidade e eficiência da rede. Se os operadores consistentemente se abstiverem de participar na assinatura de mensagens, isso afeta tanto a disponibilidade da rede quanto aumenta os custos de verificação para os usuários que precisam de mais assinaturas para alcançar o quórum. O protocolo rastreia a participação do operador por meio de tarefas de checkpoint para identificar e penalizar tal comportamento.

O processo de desafio varia com base no tipo de falha e mensagem sendo desafiada:

Para tarefas de ponto de verificação, os desafiantes podem comprovar falhas de inclusão ou exclusão de mensagens. Se uma mensagem com atestações válidas do período de tempo do ponto de verificação foi omitida, ou uma mensagem inválida/fora do período foi incluída, o desafio tem sucesso. Isso é verificado através de provas de Merkle contra a árvore de mensagens do ponto de verificação.

Mensagens individuais podem ser contestadas após o período de verificação, provando que o conteúdo da mensagem era inválido. Por exemplo:

• Mensagens de atualização do conjunto de operadores podem ser invalidadas mostrando o ID de atualização reivindicado ou o delta do operador não corresponde ao estado on-chain
• Mensagens de atualização da raiz do estado podem ser contestadas demonstrando que a raiz do estado alegada é inconsistente com a execução correta da transação

Esse sistema de verificação em várias camadas permite que o protocolo mantenha uma operação rápida por meio de mensagens fora da cadeia, ao mesmo tempo em que preserva garantias de segurança sólidas por meio de mecanismos criptoeconômicos. Ao tornar comportamentos inválidos comprovadamente detectáveis e economicamente puníveis através do slashing do EigenLayer, o NFFL cria fortes incentivos para uma operação honesta, permitindo desafios eficientes quando ocorrem violações.

Exemplos de Fluxo do Mundo Real

Ao estabelecer uma forma de leitura rápida e barata de estados cruzados entre rollups, o NFFL abre uma ampla gama de aplicações que não eram viáveis com a pilha tecnológica atual do ecossistema. Vamos explorar algumas ideias, desde algo teórico e simples até aplicações mais complexas e específicas, úteis nas áreas mais populares do ecossistema Ethereum atual.

Olá Protocolo

Vamos começar com um exemplo simples, descrito na documentação oficial da Nuffle Labs - um protocolo que permite aos usuários enviar mensagens de “olá” entre diferentes rollups. Embora básico, isso demonstra a mecânica principal de como as aplicações podem aproveitar a NFFL para comunicação entre cadeias.

Considere um usuário que deseja enviar uma mensagem na Rede #1 que será lida na Rede #2. O processo começa quando eles enviam uma transação na Rede #1 gravando sua mensagem “Olá!” no estado da rede. Neste ponto, a mensagem existe apenas na Rede #1 e normalmente exigiria aguardar a liquidação da ponte canônica (potencialmente horas ou dias) antes que pudesse ser verificada por outros pacotes cumulativos.

É aqui que a NFFL entra em ação. Quando o bloco contendo esta mensagem é produzido, ele é enviado para a NEAR DA pelo relé da rede. Os operadores da NFFL, que executam nós completos para ambas as redes, verificam se os dados do bloco correspondem ao que seu nó da Rede #1 calculou localmente. Após a verificação, eles assinam mensagens atestando a nova raiz do estado.

Essas declarações fluem pelo serviço agregador da NFFL, que coleta assinaturas até que um peso de participação suficiente tenha atestado o estado. Quando o quórum é atingido, a assinatura agregada fica disponível através da API da NFFL, normalmente em questão de segundos da produção do bloco original.

Agora vem a parte interessante - consumindo a mensagem na rede #2. O contrato do Protocolo Hello na rede #2 pode aceitar uma transação contendo:

• A prova de armazenamento mostrando que a mensagem existe no estado da Rede #1
• A comprovação da NFFL atestando que este estado é válido
• Uma referência à transação NEAR DA contendo os dados do bloco

O protocolo encaminha esses dados para o contrato de Registro da Rede #2, que verifica a assinatura da atestação em relação ao seu registro de operadores NFFL. Se válido, isso prova que a mensagem existe no estado verificado da Rede #1, permitindo que o protocolo a processe com segurança.

O que torna isso poderoso é sua combinação de velocidade e segurança. Todo o fluxo, desde o envio de mensagens até a verificação entre cadeias, pode ser concluído em segundos, em vez de horas ou dias com pontes canônicas. No entanto, a segurança vem de garantias criptoeconômicas apoiadas por ETH por meio da EigenLayer, em vez de operadores confiáveisou suposições otimistas.

Embora o envio de mensagens de “olá” possa parecer trivial, esse mesmo padrão permite aplicações muito mais sofisticadas entre cadeias. A capacidade de verificar rapidamente e de forma confiável o estado entre rollups cria blocos de construção para tudo, desde DeFi entre cadeias até experiências de usuário abstraídas de cadeias.

Transferência rápida & barata de tokens

Com base nesses fundamentos, vamos explorar uma aplicação mais prática - uma ponte de tokens alavancando NFFL para transferências rápidas entre rollups cruzados. O cenário atual das pontes impõe compensações difíceis entre velocidade, custo e segurança. Vamos examinar como o NFFL pode remodelar essas dinâmicas.

As principais pontes de hoje ilustram claramente essas compensações. Stargate, alimentado pela LayerZero, alcança custos relativamente baixos, mas leva de 10 a 30 minutos para concluir as transferências devido à necessidade de a rede do operador atingir e transmitir consenso em várias cadeias. Across fornece transferências quase instantâneas, mas com custos 10-100x mais altos, principalmente devido aos caros outputs do oráculo UMA e ciclos de rebalanceamento lentos (6 horas) que afetam a eficiência da liquidez.

NFFL introduz um novo paradigma aqui. Ao aproveitar o framework AVS da EigenLayer em vez de manter uma rede de operadores separada, o NFFL pode alcançar consenso sobre os estados de rollup em segundos. Esse consenso pode ser eficientemente transmitido por meio de contratos de registro em todos os rollups participantes, permitindo projetos de ponte que combinam a eficiência de custo do Stargate com uma finalidade ainda mais rápida do que o Across.

Considere um usuário movendo ETH de Arbitrum para Base. Quando os tokens são bloqueados no contrato de ponte em Arbitrum, os operadores NFFL verificam e atestam rapidamente essa mudança de estado por meio de seus nós completos. Assim que o agregador coleta suficientes atestações, o contrato de ponte em Base pode imediatamente verificar o bloqueio do token por meio de seu contrato de Registro e liberar fundos para o usuário.

Essa velocidade e eficiência tornam muitas otimizações de ponte existentes menos relevantes. Por exemplo, os sistemas de ponte baseados em intenções geralmente são propostos para contornar a finalização lenta - os usuários enviam intenções para pontuar tokens, e essas intenções são correspondidas e executadas por atores especializados. Mas com o NFFL fornecendo consenso quase tão rápido quanto a correspondência de intenções levaria, as pontes podem, em vez disso, usar designs de pool de liquidez mais eficientes semelhantes ao Stargate, mas sem suas limitações de velocidade.

Os benefícios de custo aqui são substanciais. Os operadores de ponte não precisam manter uma infraestrutura de consenso separada nem pagar por saídas de oráculos caras. Os usuários recebem tokens na cadeia de destino em segundos, enquanto pagam principalmente pelos custos básicos de gás de verificação. Os provedores de liquidez podem gerenciar posições de forma mais eficiente com ciclos de reequilíbrio mais rápidos.

Como benefício adicional, o sistema mantém forte segurança através dos mecanismos de slashing da EigenLayer. Quaisquer atestações fraudulentas resultariam na perda dos ETH apostados pelos operadores, enquanto as pontes ainda podem verificar o acordo final através de pontes canônicas como uma camada adicional de segurança.

Protocolo de Empréstimo Multi-Chain

O empréstimo entre cadeias representa talvez a aplicação imediata mais convincente do NFFL. Os protocolos de empréstimo atuais enfrentam limitações significativas devido à fragmentação da cadeia. Pegue o Aave—apesar de ser implantado em vários pacotes cumulativos, cada implantação opera isoladamente. Os usuários que desejam usar garantias entre cadeias devem fazer a ponte entre ativos e esperar, fragmentando a liquidez e reduzindo a eficiência do capital. Além disso, algumas implantações em pacotes menores nem sequer têm liquidez suficiente para qualquer empréstimo significativo, questionando a posição de marketing da Ave de empréstimos simples para todos em qualquer tamanho. “Basta usar Aave.” … mas apenas em suas maiores implantações.

NFFL permite uma abordagem fundamentalmente diferente. Considere um protocolo de empréstimo que mantém pools em várias rollups, mas usa NFFL para compartilhar o estado do colateral entre eles. Um usuário pode depositar USDC como colateral na Base e imediatamente pegar emprestado USDT no Arbitrum usando o mesmo colateral, mesmo que o USDT não esteja implantado na Base. O contrato Arbitrum do protocolo simplesmente verifica a posição do colateral da Base por meio de atestações NFFL, sem necessidade de ponte.

Isso cria novas possibilidades poderosas para eficiência de capital. Os usuários podem acessar as melhores taxas em qualquer rollup suportado sem mover ativos. Os provedores de liquidez podem implantar capital onde é mais necessário sem manter posições separadas por cadeia. E porque as posições podem ser monitoradas quase em tempo real através de atestações NFFL, os protocolos podem oferecer melhores taxas mantendo a segurança.

Os benefícios vão além do empréstimo básico. Considere um protocolo de negociação alavancada que permite aos usuários abrir posições em várias DEXs. Um trader pode depositar garantias no Arbitrum e usá-las para abrir posições alavancadas simultaneamente nas DEXs do Arbitrum e do Base. O protocolo pode monitorar todas as posições por meio de atestações NFFL, permitindo liquidações rápidas, se necessário, enquanto dá aos traders acesso aos melhores preços em todo o ecossistema.

Este modelo é dramaticamente mais simples e eficiente do que as abordagens existentes. Em vez de mecanismos de ponte complexos ou feeds de preço centralizados, os protocolos podem verificar diretamente as posições por meio de contratos de registro. A finalidade rápida do NFFL significa que eles podem operar com margens de segurança mais baixas enquanto mantêm a segurança. E os usuários obtêm uma experiência perfeita ao acessar a liquidez em todo o ecossistema.

Cross-DEX: Implante uma vez, Use em qualquer lugar

A abordagem atual para escalar exchanges descentralizadas em rollups muitas vezes leva a ineficiências absurdas. Quando protocolos como o Uniswap são implantados em um novo rollup, os usuários inicialmente se deparam com pools sem liquidez e pares de negociação críticos ausentes. Considere a recente implantação do Uniswap V3 no ZKsync - apesar da empolgação significativa e do fluxo de fundos de um recente airdrop do ZK, muitas pools permaneceram inutilizáveis por dias após o lançamento devido à falta de liquidez. Enquanto isso, as implantações do mesmo protocolo no Arbitrum, Base e outras chains estabelecidas mantêm alta liquidez, baixas taxas e precificação eficiente para milhares de pares.

Essa fragmentação gera atrito em todo o ecossistema. Os provedores de liquidez precisam dividir seu capital entre as redes, resultando em pior precificação e maior derrapagem em todos os lugares. Os usuários precisam fazer a ponte de tokens e esperar sempre que desejam acessar uma liquidez melhor em outra rede. As equipes de protocolo devem gerenciar múltiplas implantações, cada uma exigindo manutenção e monitoramento separados.

Você acertou: NFFL permite uma abordagem fundamentalmente diferente mais uma vez. Vamos explorar isso através de dois padrões cada vez mais poderosos:

Considere um novo DEX implantado exclusivamente no Arbitrum, escolhido por seu ecossistema DeFi estabelecido e custos de gás favoráveis. Em vez de lançar instâncias separadas em várias redes, ele mantém pools de liquidez unificadas no Arbitrum, permitindo o acesso à negociação a partir de qualquer rollup. Veja como um usuário no Base pode interagir com ele:

1. Alice quer trocar 10.000 USDC por ETH na Base
2. A interface base do DEX consulta o estado da piscina do Arbitrum por meio de testemunhos NFFL
3. Alice vê que pode obter preços melhores do que as pools fragmentadas da Base oferecem
4. Ela aprova a negociação na Base
5. A transação é executada no Arbitrum, com o resultado atestado de volta para a Base

Os benefícios desta liquidez unificada são substanciais. Os provedores de liquidez podem concentrar seu capital em um só lugar, resultando em uma melhor precificação e menor derrapagem. A equipe do protocolo só precisa gerenciar um único deployment, simplificando o desenvolvimento e reduzindo custos operacionais. E os usuários obtêm acesso consistente a uma liquidez profunda, independentemente de qual rollup eles estão usando.

Um protocolo como esse poderia utilizar o padrão de ponte que exploramos anteriormente para gerenciar perfeitamente o fluxo de troca. Em um tempo de espera de apenas alguns segundos, o fato real de fazer a ponte pode ser totalmente abstraído. Isso nos aproxima empolgantemente da tese de ‘abstração de cadeia’ que recentemente se tornou muito popular na comunidade de criptografia: se não importa para o dapp em qual cadeia você está, por que você se importaria em qual cadeia você e todos esses aplicativos estão? Um usuário pode simplesmente acessar o site do aplicativo, conectar sua carteira e realizar uma ação desejada. Pronto.

Mas o NFFL possibilita um padrão ainda mais poderoso - envolvendo protocolos DeFi existentes para acesso entre cadeias. Em vez de construir pools de liquidez concorrentes, os desenvolvedores podem criar protocolos auxiliares que tornam as enormes pools Uniswap do Arbitrum acessíveis a partir de qualquer rollup.

Implantações Uniswap com maior TVL. Base e Arbitrum lideram o gráfico, com Optimism tendo TVL 6x menor do que qualquer um, e outros rollups caindo em “Outros”. Fonte: DefiLlama

Por exemplo, considere Bob, que precisa trocar um par de tokens de longa cauda na Base. Atualmente, suas opções são limitadas - ou fazer uma ponte para outra cadeia e esperar, ou aceitar uma grande diferença de preço devido à baixa liquidez da Base. Com um invólucro alimentado por NFFL em torno da implementação do Uniswap da Arbitrum, Bob poderia:

1. Consulte a liquidez disponível em todas as pools Uniswap Arbitrum via atestados NFFL
2. Encontre liquidez profunda para seu par desejado em uma pool Arbitrum estabelecida
3. Execute a transação da Base por meio do protocolo wrapper
4. Receba seus tokens na Base assim que a NFFL atestar a conclusão da troca

Este padrão é transformador porque transforma implantações bem-sucedidas existentes em infraestrutura universal. Em vez de esperar meses ou anos para a liquidez se acumular em novos rollups, os protocolos podem instantaneamente aproveitar pools estabelecidos. Isso é dramaticamente mais eficiente em capital e cria uma experiência de usuário melhor.

As possibilidades vão muito além de simples trocas. Com a verificação de estado em tempo real da NFFL, os protocolos poderiam oferecer recursos sofisticados como ordens limitadas entre cadeias. Um usuário poderia colocar uma ordem limitada em Base contra a liquidez do Arbitrum, com o protocolo wrapper monitorando os movimentos de preço através das atestações da NFFL e executando quando as condições são atendidas.

Este modelo poderia remodelar a forma como pensamos sobre a implantação de protocolos em rollups. Em vez de implantar automaticamente em todos os lugares ou se juntar aos efeitos de rede de uma cadeia específica, os protocolos poderiam escolher estrategicamente sua cadeia primária com base em fatores como:

• Custos de gás para suas operações específicas
• Pilha tecnológica - máquina virtual, AA, tipo de sequenciamento, DA, etc.
• Considerações Regulatórias

Então, através da NFFL, eles ainda podem atender aos usuários em todo o ecossistema rollup, mantendo operações mais simples e eficientes.

As implicações para MEV também são interessantes. Com a liquidez unificada acessível em todas as cadeias, os buscadores de MEV precisariam monitorar e interagir com menos implantações. Isso poderia levar a uma descoberta de preços mais eficiente e melhor execução para os usuários em todos os rollups.

Como você pode ter percebido, esse padrão de implementação de cadeia única com acesso multichain através do NFFL poderia se estender além dos DEXs. Qualquer protocolo que se beneficie da profundidade de liquidez ou dos efeitos de rede poderia adotar esse modelo - protocolos de empréstimo, plataformas de opções, mercados de NFT e muito mais. A ideia-chave é que o NFFL torna o acesso entre cadeias quase tão fluido quanto a interação dentro da mesma cadeia, permitindo que os protocolos otimizem sua estratégia de implementação sem sacrificar a acessibilidade. Em outras palavras, o NFFL torna o Ethereum um ecossistema novamente.

Cronograma e Desenvolvimento Futuro

Embora o NFFL já permita novas aplicações poderosas entre cadeias, o protocolo continua a evoluir. O roteiro de desenvolvimento do NFFL se concentra em três áreas-chave:

Segurança de Protocolo

• Implementando mecanismos abrangentes de desafio e corte por meio do EigenLayer
• Ativando a participação do operador sem permissão com gerenciamento robusto de stake
• Aprimorando a verificação de estado entre cadeias cruzadas com primitivas criptográficas melhoradas (BLS→ECDSA)

Escalabilidade da rede

• Otimizando esquemas de assinatura e propagação de estados
• Melhorando a eficiência do ponto de verificação e os custos de verificação

Experiência do Desenvolvedor

• Construindo SDK e ferramentas para integração fácil
• Expansão do suporte para diferentes tipos de rollup e VMs
• Criando documentação e exemplos para casos de uso comuns

Nas seções seguintes, exploraremos alguns dos planos de melhoria mais significativos em detalhes.

BLS para ECDSA

Uma das mudanças planejadas mais significativas é a transição de assinaturas BLS para ECDSA. Atualmente, NFFL utiliza assinaturas BLS para permitir a agregação eficiente - várias assinaturas de operador podem ser combinadas em uma única assinatura que comprove acordo de quórum. Embora isso reduza os custos de verificação, cria desafios para o gerenciamento do conjunto de operadores em diferentes redes.

O problema decorre de como funciona a verificação de assinatura BLS. Ao verificar uma assinatura BLS agregada, o verificador deve usar exatamente o mesmo conjunto de chaves públicas que a criaram. Isso significa que quando o conjunto de operadores muda no Ethereum, todos os rollups devem atualizar para o exato mesmo conjunto de operadores antes que possam verificar novas confirmações. Mesmo uma pequena discrepância nos conjuntos de operadores entre as cadeias pode impedir a verificação da assinatura e exigir a sincronização de todas as mensagens de alterações no conjunto de operadores.

As assinaturas ECDSA, embora exijam mais espaço e cálculo para verificação, oferecem mais flexibilidade. As assinaturas individuais do operador podem ser verificadas independentemente, permitindo transições mais suaves quando o conjunto de operadores muda. Os rollups podem verificar as declarações desde que reconheçam os operadores de assinatura, mesmo que sua visão do conjunto completo de operadores temporariamente difere da do Ethereum. Essa maior flexibilidade pode valer o pequeno aumento nos custos de verificação.

Conjuntos de Operadores Dinâmicos

Essa mudança de assinatura está diretamente ligada a outra grande melhoria de protocolo—implementando conjuntos dinâmicos de operadores. O sistema atual usa um conjunto estático e autorizado de operadores. Embora isso tenha simplificado o desenvolvimento inicial, limita a descentralização e escalabilidade do protocolo.

Um sistema de operadores dinâmicos permitiria que novos operadores entrassem na rede sem permissão, apostando através do EigenLayer. Isso introduz vários desafios técnicos que precisam ser cuidadosamente abordados:

Primeiro, o protocolo deve gerenciar as filas de entrada e saída de operadores. Quando os operadores desejam entrar ou sair da rede, essas alterações precisam ser coordenadas em todas as cadeias participantes. O sistema de filas garante transições suaves sem interromper a capacidade da rede de verificar atestações.

Em segundo lugar, o protocolo precisa de mecanismos para rastrear o desempenho do operador e o peso da participação. À medida que os operadores entram e saem, o sistema deve manter registros precisos da participação de cada operador e de seus direitos de participar do consenso. Isso se torna mais complexo com um conjunto dinâmico em comparação com a abordagem atual de lista branca.

Finalmente, o protocolo deve lidar de forma eficiente com as atualizações do conjunto de operadores entre as cadeias. Quando o conjunto de operadores muda no Ethereum, essas atualizações precisam ser propagadas para todas as rollups participantes por meio de seus contratos de registro. A transição planejada do ECDSA ajudará aqui, tornando essas atualizações mais flexíveis.

Fora das Rodinhas de Treinamento

Outra área crítica de desenvolvimento é a ativação de mecanismos de desafio e punição sem permissão. Esses mecanismos são essenciais para garantir um comportamento honesto e fornecer as garantias de segurança econômica nas quais o NFFL se baseia.

O sistema de desafio gira em torno do mecanismo de tarefa de checkpoint. Quando os operadores enviam checkpoints contendo Mensagens merkleizadas de um período de tempo, qualquer pessoa pode desafiar esses checkpoints se acreditar que eles contêm atestações inválidas. Um desafio bem-sucedido pode surgir de vários tipos de falhas:

• Primeiro, falhas de segurança que afetam diretamente a integridade da rede. Isso inclui equívoco - quando um operador assina várias Mensagens conflitantes para o mesmo caso, como atestar raízes de estado diferentes para o mesmo bloco. Eles também incluem atestados inválidos, onde um operador aprova transições de estado comprovadamente incorretas ou atualizações do conjunto do operador.
• Segundo, falhas de vivacidade que impactam a disponibilidade da rede. Se os operadores consistentemente se abstêm de participar na assinatura de mensagens, isso afeta a capacidade da rede de verificar estados de forma eficiente. O mecanismo de desafio deve equilibrar a penalização desse comportamento enquanto considera o tempo de inatividade legítimo.

O protocolo implementará um sistema de desafio baseado em garantia. Os desafiadores devem bloquear a garantia ao enviar um desafio, que eles perdem se o desafio se provar inválido. No entanto, se eles conseguirem provar com sucesso um erro do operador, eles recebem uma recompensa da participação do operador cortado. Isso cria incentivos econômicos para monitorar o comportamento do operador enquanto evita desafios frívolos.

Para atualizações de raiz de estado, o processo de desafio é particularmente interessante. Depois que um operador atesta o estado de um rollup, isso pode ser contestado provando que os dados do bloco relevante não foram postados corretamente para NEAR DA ou que o estado atestado não corresponde ao estado canônico após a liquidação. Isso requer que os desafiadores forneçam provas por meio da Rainbow Bridge para verificação do NEAR DA, criando várias camadas de segurança.

O próprio mecanismo de punição será implementado por meio dos contratos intermediários da EigenLayer. Quando os desafios têm sucesso, os operadores perdem uma parte de seus ETHs apostados. Os parâmetros de punição são projetados de forma que as perdas potenciais excedam significativamente quaisquer ganhos provenientes de comportamento malicioso. Alguma parte dessa aposta punida é concedida aos desafiadores bem-sucedidos, enquanto o restante pode ser distribuído para operadores honestos ou usado para o desenvolvimento do protocolo.

Esses mecanismos criam um quadro de segurança abrangente. Os operadores enfrentam penalidades financeiras significativas por comportamento incorreto, os desafiadores são incentivados a monitorar a rede e as aplicações podem contar com garantias criptoeconômicas respaldadas pelo ETH recolocado. Os períodos de desafio são muito mais curtos do que as provas de fraude do otimismo rollup, ao mesmo tempo em que oferecem segurança sólida por meio dos mecanismos de corte do EigenLayer.

Futuro da Finalidade Rápida

Embora a NFFL forneça uma solução imediata para a verificação de estado entre rollups, vale a pena examinar como o protocolo se encaixa no roadmap de escalabilidade mais amplo do Ethereum. A pergunta-chave que muitos fazem é: “A NFFL ainda será relevante à medida que a tecnologia rollup avança?”

A resposta fica clara quando examinamos as limitações fundamentais de liquidação em diferentes designs de rollup. Rollups otimistas, apesar de sua popularidade e maturidade, não podem liquidar fundamentalmente mais rápido do que sua janela de prova de fraude—tipicamente 7 dias. Enquanto soluções como Superchain da Optimism e Arbitrum Orbit permitem uma comunicação mais rápida entre rollups que compartilham uma ponte, elas não ajudam com a interoperabilidade fora de seus ecossistemas específicos—por exemplo, entre esses dois.

As rollups de ZK enfrentam restrições diferentes, mas igualmente importantes. Mesmo com a melhoria significativa da tecnologia de prova de ZK, existem limites práticos para a velocidade de liquidação. Mesmo que cheguemos a um ponto em que as provas possam ser geradas para cada bloco L1, o Ethereum ainda deve ter capacidade para verificar várias provas de ZK por bloco em diferentes rollups. Quando isso se tornar possível, a liquidação ainda estará limitada pelo tempo de bloco L1 - pelo menos 12 segundos sob os parâmetros atuais.

O NFFL oferece uma abordagem diferente, utilizando atestações assinadas do sequencer dos rollups. Em vez de esperar que lotes sejam publicados no L1, os operadores do NFFL podem verificar e atestar as alterações de estado assim que forem produzidas pelo sequencer. Isso permite a verificação de estado entre cadeias em segundos, mantendo uma segurança criptoeconômica sólida através da EigenLayer.

Importante, NFFL não deve ser visto como competindo com ou ameaçando o modelo de segurança rollup do Ethereum. Em vez disso, fornece uma ferramenta complementar que possibilita novas possibilidades dentro do ecossistema modular do Ethereum. Aplicativos podem utilizar o NFFL para verificação rápida de estado, enquanto ainda dependem de acordos canônicos através do L1 quando necessário. Isso cria um conjunto de ferramentas mais rico para os desenvolvedores construírem aplicativos cross-chain com modelos de segurança apropriados às suas necessidades específicas.

Conclusão

NFFL representa uma abordagem inovadora para resolver um dos desafios mais urgentes no ecossistema modular da Ethereum - permitindo a verificação segura e eficiente do estado cruzado entre rollups. Ao alavancar o ETH restaked da EigenLayer para segurança econômica e o NEAR DA para armazenamento eficiente de dados, o NFFL cria uma camada de finalidade rápida que pode verificar estados de rollup em segundos, em vez de horas ou dias.

As escolhas de design cuidadosas do protocolo refletem uma compreensão profunda dos desafios na infraestrutura entre cadeias. Em vez de tentar substituir o modelo de segurança das rollups, o NFFL fornece uma camada complementar otimizada para casos de uso específicos que exigem maior finalidade. O sistema de tarefas baseado em checkpoints permite uma operação eficiente fora da cadeia, mantendo garantias de segurança fortes na cadeia. E a arquitetura do contrato do registro permite que as rollups verifiquem estados de forma segura, herdando a segurança econômica do NFFL.

Talvez o mais importante, NFFL permite uma nova geração de aplicações cross-chain que antes eram impraticáveis. Desde protocolos de empréstimo unificados que compartilham garantia entre rollups até envoltórios DEX que tornam a liquidez estabelecida universalmente acessível, a verificação rápida de estado do NFFL cria blocos de construção para uma verdadeira abstração de cadeia. Isso tem implicações profundas para a eficiência de capital e a experiência do usuário em todo o ecossistema.

O roteiro do protocolo demonstra comprometimento com a melhoria contínua. Atualizações planejadas, como a transição para assinaturas ECDSA e a implementação de conjuntos de operadores dinâmicos, aumentarão a descentralização e escalabilidade. A ativação de mecanismos abrangentes de desafio e corte fortalecerá as garantias de segurança. E a integração com soluções adicionais de DA além do NEAR tornará o NFFL ainda mais universal.

À medida que o ecossistema de rollup do Ethereum continua a evoluir, a necessidade de verificação segura do estado entre cadeias só aumentará. A abordagem da NFFL de estender a segurança do Ethereum por meio de retomada enquanto otimiza a velocidade e a relação custo-benefício a posiciona bem para atender a essa necessidade. Ao permitir novas formas de interação entre cadeias, mantendo fortes garantias de segurança, o NFFL contribui para tornar a visão modular do Ethereum uma realidade.

Isenção de responsabilidade:

1. Este artigo é reproduzido de [[](https://research.2077.xyz/nuffle-ethereums-finality-as-a-service-layer#introduction)[2077 Pesquisa](https://research.2077.xyz/)\]. Todos os direitos autorais pertencem ao autor original [Alex Hook]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprendaequipe, e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo menção em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.