Introdução

Em retrospectiva, os rollups surgiram como a solução definitiva de escalabilidade para Ethereum e tecnologia descentralizada como um todo. Nove meses após o upgrade Dencun do Ethereum, que visava a escalabilidade da disponibilidade de dados do rollup, a taxa de transações ultrapassou duzentas transações por segundo—representando um aumento cinco vezes maior no ano. Os dois principais rollups, Arbitrum e OP Mainnet, alcançaram a descentralização da fase 1—ultrapassando várias redes alternativas proeminentes de Camada 1nas métricas de descentralização, com rollups adicionais possivelmente visando a descentralização da fase 2 em 2025. A tecnologia de prova de conhecimento zero avançou 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, este avanço apresenta novos desafios. Múltiplas equipas estão a desenvolver blockchains independentes sobre o Ethereum, com interoperabilidade limitada entre elas. Esta limitação resulta principalmente da finalização pouco frequente dos rollups, o que impede uma comunicação significativa entre cadeias. Além disso, os rollups otimistas, que atualmente hospedam a maioria da atividade do ecossistema e do Valor Total Bloqueado (TVL), enfrentam restrições técnicas inerentes que impedem a comunicação direta fora das pontes partilhadas, criando uma barreira significativa para a interoperabilidade entre grandes redes como Arbitrum e Base. A comunidade propôs várias soluções, desde pontes baseadas em intenções e trocas atômicas até abstração abrangente de cadeias. Apesar das diferenças, estas soluções partilham um requisito fundamental: uma fonte confiável de verdade - um protocolo que permite a verificação segura do estado entre rollups que seja tanto rápida como rentável.

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

A sua Ethereum Edge

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

O seu endereço de email

Antecedentes

Para entender os desafios que a NFFL enfrenta, 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 forma verificável pela blockchain principal. Embora muitas definições se refiram à blockchain 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 em vez 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. Fonte:blog.thirdweb.com

Claro, no nosso caso, o pai L1 é a cadeia de blocos Ethereum. É responsável por partilhar o seu consenso com os rollups (iremos elaborar sobre isto mais tarde). Vamos analisar como os rollups tiram partido do Ethereum para as suas funções principais: ordenação de transações, disponibilidade de dados e consenso.

Ordenação de Transações

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

Um contrato inteligente na L1 mantém um registro autoritativo de todas as transações publicadas e sua ordem. Os nós de Rollup devem monitorar este contrato para recuperar 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 através do consenso L1, a inclusão e ordenação de todas as transações dentro desse lote são garantidas pelas propriedades de segurança do L1.

Até certo ponto, o sequenciador é um “iniciador” do rollup - ele ajuda o rollup a aceitar efetivamente novas transações na rede, facilitando o avanço do estado. Alguns rollups implementam sequenciamento descentralizado - um 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 no 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 no L1. Isso praticamente não abre risco de tempo de inatividade de sequenciamento, ao custo de uma inclusão de transação mais lenta (cenário ideal é 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 “iniciam”, 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 arranque.

Disponibilidade de dados

No entanto, a informação sobre a ordem de algumas transações não é suficiente para os nós da rollup, pois eles não possuem as próprias transações. Para executar essas transações e determinar seu resultado na blockchain da rollup, os nós devem ter acesso completo e irrestrito a todas as transações no lote.

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

Antes da atualização Dencun, as rollups do Ethereum estavam a publicar dados de transação nos dados de entrada (calldata) das chamadas de sequenciamento na L1. Portanto, todas as transações devem ter sido publicadas para sempre no blockchain do L1. Isto poderá parecer razoável, uma vez que queremos que todos os nós, incluindo os futuros, sejam capazes de reconstruir o estado da rollup. No entanto, isto é muito ineficiente, já que a L1 do Ethereum não consegue armazenar grandes dados no seu livro-razão, enquanto as rollups, as vias de alta velocidade do Ethereum, são muito intensivas em dados. Em vez disso, podemos fazer com que o contrato inteligente da rollup verifique a validade das transações sequenciadas, para que os nós sigam instantaneamente o estado no contrato, em vez de o reconstruir a partir de todas as transações a partir do genesis.

Ponte Entronizada (Consenso)

Por simplicidade, apenas viramos a definição do rollup ao contrário - 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 própria, para simplificar a estimativa de taxas de gás com base nos gastos de sequenciadores e proponentes. Além disso, muitos rollups desejam obter tokens populares em seu ecossistema a partir do dia 1, para o que trazê-los do seu L1 é a melhor escolha.

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

No entanto, as retiradas sem confiança requerem que o contrato de ponte valide todas as transações de 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 garfos alternativos na cadeia. 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 os “blobs” - células temporárias de dados que são armazenadas fora da blockchain e podadas (excluídas pelos validadores da rede) após ~18 dias. À medida que as bridges de rollup tornam possível reconstruir o estado sem reexecutar transações, essa propriedade tornou-se muito útil para os rollups, que migraram de calldata para blobs logo após a atualização. Falando em números, antes do Dencun, o TPS total dos rollups era cerca de 50. Hoje, está acima de 200, com limites teóricos em 400-800 TPS dependendo do rollup.

Origem: L2BEAT

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

Origem: growthepie.xyz

Acordo de Liquidação

Enquanto os sequenciadores gerenciam a ordem e publicação das transações, eles representam apenas um componente da arquitetura rollup. Os rollups também incorporam entidades chamadas ‘proposers’ responsáveis por convencer a ponte L1 das saídas de estado específicas resultantes dos lotes recém-sequenciados. Em essência, enquanto os sequenciadores estabelecem a ocorrência e a ordem das transações, os proposers 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: Otimistas e Zero-Knowledge (ZK).

Rollups Otimistas

Nos rollups otimistas, os proponentes enviam regularmente atualizações de estado para a ponte L1, geralmente ao lado ou pouco depois das publicações em lote do sequenciador. Estas atualizações de estado incluem a nova raiz de estado (um compromisso criptográfico com o novo estado completo do rollup) após executar todas as transações nos últimos lotes.

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

Se um desafiador provar com sucesso que um proponente submeteu uma transição de estado inválida, a saída do estado é revertida e o desafiador é recompensado (geralmente de uma garantia que os proponentes devem postar). Isso cria um jogo econômico em que os proponentes são incentivados a submeter apenas transições de estado válidas.

Rollups de Conhecimento Zero

Nos rollups ZK, os proponentes geram provas matemáticas (chamadas ‘provas de validade’ ou, mais tecnicamente, ‘provas ZK’) que demonstram a correção de cada transição de estado. Essas provas mostram que todas as transações em um 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, pelo custo de uma troca de tokens. Uma vez que uma prova é verificada, a ponte aceita a atualização de estado como resolvida. Isso significa que os proponentes devem realizar um trabalho computacional significativo antes de enviar atualizações de estado, mas essas atualizações são resolvidas muito mais rapidamente em comparação com rollups otimistas.

Resolução, Finalidade e Interoperabilidade

O tempo de liquidação através de 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 publicação em lote. Embora esse modelo funcione bem para garantir transações de alto valor que podem tolerar atrasos, ele cria 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 obter um empréstimo na Base deve primeiro transferir seus ativos e esperar até 7 dias antes que eles possam ser usados. Um trader que identifique uma oportunidade de arbitragem entre pools da Uniswap em rollups diferentes veria a oportunidade desaparecer muito antes que pudessem aproveitá-la. Uma aplicação de jogos que queira permitir que os jogadores negociem itens em diferentes implantações de rollup enfrentaria uma UX inaceitável com atrasos tão longos.

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

Isto cria uma dicotomia interessante no ecossistema rollup. Enquanto os rollups escalaram com sucesso a capacidade de transação do Ethereum, introduziram uma fragmentação severa do estado e da liquidez. Cada rollup opera efetivamente como uma blockchain independente que não consegue verificar eficientemente o estado de outros rollups sem aguardar o estabelecimento da ponte, apesar de todos derivarem a 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 especializadas fora da cadeia. Essas soluções normalmente fazem diferentes compensações entre três propriedades-chave:

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

A maioria das soluções existentes otimiza a velocidade e o custo em detrimento 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 ataques de ponte de alto perfil, mais notavelmente a exploração de ponte Ronin de $625 milhões, destacando os riscos de sacrificar a segurança pela conveniência.

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

• Verificar alterações de estado em segundos ou minutos em vez de horas ou dias
• Fornecer garantias fortes de segurança cripto-econômica
• Operar de forma rentável tanto para os fornecedores de infraestrutura como para os utilizadores
• Integrar-se perfeitamente com arquiteturas de rollup existentes

Esta oportunidade de permitir a verificação de estado rápida e segura entre rollups tem suscitado uma significativa inovação. Várias equipas estão a abordar o problema de diferentes perspetivas, procurando criar infraestruturas que possam impulsionar a próxima geração de aplicações entre cadeias sem comprometer a segurança.

Nas seções a seguir, exploraremos como a NFFL aborda esse desafio por meio de sua nova combinação de retomada da EigenLayer e NEAR DA, criando uma camada de finalidade rápida que atinge um equilíbrio cuidadoso entre segurança, velocidade e custo-benefício.

NFFL Deep Dive

Tese Principal

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

No seu cerne, o NFFL opera como um Serviço Validado Ativamente (AVS) executado na EigenLayer. Uma rede descentralizada de operadores, cada um executando nós completos para rollups participantes, verifica e atesta as atualizações de estado. Essas atestações são respaldadas pelo ETH reservado novamente 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 de forma segura o estado intercadeias em 2-3 segundos - ordens de magnitude mais rápido do que a liquidação de ponte canônica.

Arquitetura de design simplificado da 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 requerem maior finalização. As aplicações podem escolher se devem confiar na segurança criptoeconômica do NFFL ou aguardar a liquidação completa da 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, mantendo 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 as transições de estado executadas localmente com os dados de bloco publicados no NEAR DA
2. Um sistema de tarefas baseado em checkpoints que permite a agregação eficiente e verificação das declarações dos operadores, mantendo a responsabilidade através dos mecanismos de punição da EigenLayer
3. Um mecanismo de armazenamento de dados usando NEAR DA que permite a fácil recuperação de dados rollup atestados em todos os rollups

Este design permite à NFFL encontrar um equilíbrio cuidadoso entre segurança, velocidade e rentabilidade - três propriedades que tradicionalmente estavam em conflito na infraestrutura de interligação de blockchains. Ao fornecer uma verificação de estado rápida e segura, a NFFL abre novas possibilidades para aplicações interligadas entre blockchains, desde protocolos de empréstimos até agregadores de liquidez.

Nas seções seguintes, exploraremos em detalhe a arquitetura da NFFL, examinando como seus vários componentes trabalham juntos para permitir essa nova primitiva de interação entre cadeias. Também analisaremos seu modelo de segurança, discutiremos possíveis aplicações e veremos o roteiro do protocolo para o desenvolvimento futuro.

Componentes Principais

Conjunto de Operadores

No coração do NFFL está a 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 exija 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 de validadores existente do Ethereum.

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

Quando um rollup publica novos dados de bloco para a L1, os relayers encaminham para 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 publicar dados de rollup no NEAR DA é necessário para tornar as aplicações que utilizam NFFL mais convenientes para usuários e desenvolvedores.

Depois de recuperarem novos lotes de rollup, os operadores executam-nos nos seus nós de rollup. Dado que todos eles 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 de tal sistema tem uma propriedade muito interessante que decorre da mecânica de corte da EigenLayer:

No EigenLayer, os Serviços Validados Ativamente podem implementar um mecanismo de verificação capaz de detetar atestados inválidos dos operadores e cortar (liquidar) seu depósito posteriormente. Como a NFFL de certa forma “liquida preliminarmente” o estado de rollup off-chain antes de ser resolvido na ponte, é possível detetar objetivamente a fraude aguardando o atraso da 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 detetados 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, arriscando perdas significativas por desonestidade. Quanto mais ETH for reinvestido na NFFL, mais fortes esses incentivos se tornam. 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 entre cadeias em grande escala. Em vez de registar cada atestação de estado na cadeia, o que seria proibitivamente caro, a NFFL introduz um sistema de duas camadas de Mensagens e Tarefas que permite uma operação eficiente fora da cadeia, mantendo garantias de segurança sólidas na cadeia quando necessário.

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 fora da cadeia, circulando entre os operadores e o agregador sem incorrer em custos de gás na cadeia. Existem dois tipos distintos de Mensagens que fluem pelo sistema:

• As mensagens de atualização da raiz do estado 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 a raiz do estado em si, 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.
• As mensagens de atualização do conjunto de operadores rastreiam 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 apenas as atestações sejam aceitas 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 é onde entram as Tarefas. As Tarefas são unidades de trabalho on-chain que fazem um checkpoint do estado do sistema em intervalos regulares. Em vez de submeter cada Mensagem ao Ethereum, os operadores constroem periodicamente uma Árvore Esparsa de Merkle contendo todas as Mensagens de um período de tempo específico. A raiz desta árvore é então submetida como uma resposta da 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, permitindo mecanismos de desafio eficientes, mantendo os custos básicos baixos. Pode pensar nisso como criar 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 através de uma API. Quando os operadores assinam Mensagens, eles as enviam para o agregador, que verifica se as assinaturas atingiram o quórum (ponderado pelo 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 Agregação

O agregador atua como a camada de coordenação do NFFL, gerenciando eficientemente o fluxo de mensagens entre operadores e aplicativos. Embora conceitualmente direto, seu design reflete uma cuidadosa consideração das necessidades práticas dos desenvolvedores e 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 o NFFL precisaria coletar e verificar independentemente assinaturas de todos os operadores - um processo ineficiente e custoso. Em vez disso, o agregador fornece um único ponto de coleta para assinaturas de 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 forma:

• Os operadores assinam independentemente mensagens atestando atualizações de estado
• Estas assinaturas são enviadas para o agregador para recolha
• O agregador verifica a validade da assinatura e acompanha o quórum
• Uma vez que o peso suficiente da participação seja alcançado, a assinatura agregada fica disponível
• As aplicações podem obter essas certificações através da API do agregador

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

Agregação de assinaturas

Vamos explorar a agregação BLS usada pela NFFL ainda mais. As assinaturas BLS têm uma propriedade matemática poderosa que permite combinar várias assinaturas 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 o 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 de 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 montantes apostados para garantir que a segurança económica é devidamente contabilizada. O contrato de registro, então, só precisa executar uma operação de verificação de assinatura para confirmar que o peso da estaca suficiente atestou a atualização do estado.

Aggregator e Pontos de Verificação

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

O agregador também desempenha um papel vital no sistema de pontos de verificação. Ao coletar todas as mensagens ao longo do tempo, ele pode construir as árvores de Merkle esparsas usadas em tarefas de ponto de verificação. Isso cria um registro eficiente de todos os atestados que passaram pelo sistema, permitindo uma verificação posterior, se necessário, para desafios de segurança ou fins de auditoria.

Contratos de Registro

O contrato do Registro, implantado em cada rollup participante, funciona como a ponte crítica entre as atestações off-chain da NFFL e a verificação de estado on-chain. Esses contratos permitem que as aplicações verifiquem de forma confiável o estado de outros rollups, validando as atestações criptoeconomicamente seguras da NFFL.

O que torna o Registo particularmente interessante é a forma como 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 alterações 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 atestados de forma independente.

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

O processo de verificação no Registro é notavelmente eficiente graças à agregação de assinaturas BLS. O contrato só precisa realizar uma única verificação de assinatura contra as chaves públicas ponderadas do conjunto de operadores atual. 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 sem confiança entre rollups que é segura e econômica.

O Registro cria uma ponte minimizada de confiança entre rollups que é segura e econômica. Através 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 de estado recebeu peso de atestado suficiente para ser considerada válida. Isso permite que os aplicativos verifiquem de forma confiável os estados em diferentes pacotes cumulativos enquanto herdam as garantias de segurança econômica da NFFL.

O Registro também desempenha um papel crucial no sistema de desafio da NFFL. Se uma declaração posteriormente for 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 várias camadas de segurança - garantias criptoeconômicas imediatas provenientes de ETH apostados combinadas com proteção contra fraudes a longo prazo por meio de desafios.

Classificação de falhas e design de segurança

O modelo de segurança da NFFL centra-se na deteção e penalização de dois tipos principais de comportamento incorreto do operador: Falhas de Segurança e Falhas de Vivacidade.

As 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:

• A equívoco ocorre quando um operador assina várias mensagens conflitantes para o mesmo evento. Por exemplo, assinar atestações para diferentes raízes de estado na mesma altura de bloco, ou atestar múltiplas timestamps diferentes para o mesmo bloco. Tal comportamento mina a capacidade da rede de chegar a um consenso sobre o estado canônico.
• Atestação inválida ocorre quando um operador assina uma declaração comprovadamente incorreta. Isso poderia ser atestar uma atualização do conjunto de operadores que não corresponde ao delta de estado on-chain, 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 on-chain.

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 da 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 atingir o quórum. O protocolo acompanha a participação dos operadores por meio de tarefas de checkpoint para identificar e penalizar esse comportamento.

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

Para tarefas de checkpoint, os desafiadores podem provar falhas de inclusão ou exclusão de mensagens. Se uma mensagem com atestações válidas do período de tempo do checkpoint foi omitida ou uma mensagem inválida/fora de período foi incluída, o desafio é bem-sucedido. Isso é verificado por meio de provas de Merkle contra a árvore de mensagens do checkpoint.

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

• As mensagens de atualização do conjunto de operadores podem ser invalidadas mostrando o ID de atualização reclamado ou o delta do operador não corresponde ao estado on-chain
• As mensagens de atualização da raiz do estado podem ser contestadas ao demonstrar que a raiz do estado reivindicada é inconsistente com a execução correta da transação.

Este sistema de verificação em várias camadas permite que o protocolo mantenha uma operação rápida através de mensagens fora da cadeia, ao mesmo tempo que preserva garantias de segurança sólidas através de mecanismos cripto-econômicos. Ao tornar o comportamento inválido provavelmente detectável e economicamente punível através do corte do EigenLayer, o NFFL cria fortes incentivos para uma operação honesta, ao mesmo tempo que permite desafios eficientes quando ocorrem violações.

Exemplos de Fluxo do Mundo Real

Ao estabelecer um caminho para leituras de estado rápidas e baratas entre rollups, o NFFL abre uma ampla gama de aplicações que não eram viáveis com o stack tecnológico 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 de hoje.

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 o 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 registrando sua mensagem “olá!” no estado da rede. Neste ponto, a mensagem existe apenas na Rede #1 e normalmente exigiria esperar pelo acordo da ponte canônica (potencialmente horas ou dias) antes que pudesse ser verificada por outras rollups.

É aqui que entra a NFFL. Quando o bloco que contém esta mensagem é produzido, é publicado no NEAR DA pelo relayer da rede. Os operadores da NFFL, que executam nós completos para ambas as redes, verificam se os dados deste bloco correspondem ao que o seu nó da Rede #1 calculou localmente. Após verificação, assinam mensagens atestando a nova raiz de estado.

Estas certificações fluem através do serviço de agregador da NFFL, que recolhe assinaturas até que um peso de participação suficiente tenha atestado o estado. Uma vez que o quórum é alcançado, a assinatura agregada torna-se disponível através da API da NFFL, tipicamente dentro de segundos da produção do bloco original.

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

• A prova de armazenamento que mostra que a mensagem existe no estado da Rede #1
• A prova de atestado do NFFL que comprova 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 dos operadores NFFL. Se for válido, isso comprova que a mensagem existe no estado verificado da Rede #1, permitindo que o protocolo a processe com segurança.

O que torna isso poderoso é a combinação de velocidade e segurança. Todo o fluxo, desde a submissão da mensagem até a verificação intercadeias, 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 respaldadas por ETH reinvestidos por meio do EigenLayer, em vez deoperadores de confiançaou suposições otimistas.

Embora o envio de mensagens “olá” possa parecer trivial, esse mesmo padrão permite aplicativos interligados muito mais sofisticados. A capacidade de verificar rapidamente e de forma confiável o estado através de rollups cria blocos de construção para tudo, desde DeFi interligado até experiências de usuário abstraídas por cadeia.

Transferência Rápida & Barata de Tokens

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

As principais pontes de hoje ilustram claramente esses trade-offs. Stargate, alimentado pela LayerZero, alcança custos relativamente baixos, mas leva de 10 a 30 minutos para concluir transferências devido à sua rede de operadores precisar alcançar e relatar consenso em várias cadeias. Across fornece transferências quase instantâneas, mas a custos 10-100x mais altos, principalmente devido a saídas de oráculo UMA caras e ciclos de rebalanceamento lentos (6 horas) que afetam a eficiência da liquidez.

NFFL introduz um novo paradigma aqui. Ao alavancar o framework AVS da EigenLayer em vez de manter uma rede de operadores separada, a 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 custos do Stargate com uma finalização 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 coletar as atestações suficientes, o contrato de ponte em Base pode verificar imediatamente 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 das otimizações de ponte existentes menos relevantes. Por exemplo, sistemas de ponte baseados em intenção são frequentemente propostos para contornar a baixa finalidade - 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ção 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 da ponte não precisam manter infraestrutura de consenso separada ou pagar por saídas de oráculo caras. Os usuários recebem tokens na cadeia de destino em segundos, pagando 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 rebalanceamento mais rápidos.

Como benefício adicional, o sistema mantém uma segurança forte através dos mecanismos de punição do EigenLayer. Quaisquer atestações fraudulentas resultariam em operadores perdendo seu ETH empenhado, enquanto as pontes ainda podem verificar a liquidação final através de pontes canônicas como uma camada adicional de segurança.

Protocolo de Empréstimo Multi-Chain

Os empréstimos entre cadeias representam talvez a aplicação imediata mais convincente da NFFL. Os atuais protocolos de concessão de empréstimos enfrentam limitações significativas devido à fragmentação da cadeia. Pegue o Aave: apesar de ter sido implantada em vários pacotes cumulativos, cada implantação opera isoladamente. Os utilizadores que pretendam utilizar garantias em cadeias devem fazer a ponte entre ativos e esperar, fragmentando a liquidez e reduzindo a eficiência dos fundos próprios. Além disso, algumas implantações em rollups 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 o 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ários rollups, mas usa NFFL para compartilhar o estado de garantia entre eles. Um usuário pode depositar USDC como garantia na Base e imediatamente pegar emprestado USDT no Arbitrum com essa mesma garantia - mesmo que o USDT não esteja implantado na Base. O contrato do protocolo no Arbitrum simplesmente verifica a posição da garantia 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 ele é mais necessário sem manter posições separadas por cadeia. E como as posições podem ser monitoradas em tempo quase real por meio de atestados NFFL, os protocolos podem oferecer taxas melhores enquanto mantêm 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 poderia depositar garantias em Arbitrum e usá-las para abrir posições alavancadas tanto nas DEXs da Arbitrum quanto da Base simultaneamente. O protocolo pode monitorar todas as posições através de declarações NFFL, possibilitando liquidações rápidas, se necessário, ao mesmo tempo em que 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ços centralizados, os protocolos podem verificar diretamente as posições por meio de contratos de registro. A rápida finalidade do NFFL significa que eles podem operar com margens de segurança mais baixas, mantendo 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 a escalabilidade das 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 enfrentam inicialmente pools sem liquidez e faltando pares de negociação críticos. Considere a implantação recente do Uniswap V3 na ZKsync - apesar do entusiasmo significativo e do fluxo de fundos de um recente airdrop 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 na Arbitrum, Base e outras cadeias estabelecidas mantêm uma grande liquidez, taxas baixas e preços eficientes para milhares de pares.

Esta fragmentação cria fricção em todo o ecossistema. Os provedores de liquidez devem dividir seu capital entre as cadeias, levando a piores preços e maior deslizamento em todos os lugares. Os usuários precisam bridgear tokens e esperar sempre que desejam acessar melhor liquidez em outra cadeia. As equipes de protocolo devem gerenciar múltiplas implantações, cada uma exigindo manutenção e monitorização separadas.

Adivinhou bem: NFFL permite novamente uma abordagem fundamentalmente diferente. 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 favoráveis de gás. Em vez de lançar instâncias separadas em várias cadeias, ele mantém pools de liquidez unificados no Arbitrum, permitindo acesso à negociação 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 pool Arbitrum via declarações NFFL
3. Alice percebe que pode obter preços melhores do que as piscinas 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 dessa liquidez unificada são substanciais. Os provedores de liquidez podem concentrar seu capital em um único lugar, resultando em preços melhores e menor deslizamento. A equipe do protocolo só precisa gerenciar uma implantação, simplificando o desenvolvimento e reduzindo os custos operacionais. E os usuários têm acesso consistente a uma liquidez profunda, independentemente de qual rollup eles estão usando.

Um protocolo desse tipo poderia utilizar o padrão de ponte que exploramos anteriormente para gerenciar perfeitamente o fluxo de troca. No tempo de espera de apenas alguns segundos, o fato real de fazer a ponte pode ser completamente abstractado. Isso nos aproxima emocionantemente da tese de ‘abstração de cadeia’ que recentemente se tornou bastante popular na comunidade cripto: se não importa para o dapp em qual cadeia você está, por que você se importaria com 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. Feito.

Mas a NFFL permite um padrão ainda mais poderoso - envolver protocolos DeFi existentes para acesso entre cadeias. Em vez de construir piscinas de liquidez concorrentes, os desenvolvedores podem criar protocolos “auxiliares” que tornam as enormes piscinas Uniswap da 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 longo prazo na Base. Atualmente, suas opções são limitadas - ou fazer uma ponte para outra cadeia e esperar, ou aceitar uma derrapagem extrema da liquidez reduzida da Base. Com um invólucro alimentado por NFFL em torno da implementação do Uniswap de Arbitrum, Bob poderia:

1. Consultar liquidez disponível em todos os pools de Arbitrum Uniswap através das atestações NFFL
2. Encontre liquidez profunda para o par desejado em uma pool Arbitrum estabelecida
3. Executar a negociação a partir da Base através do protocolo wrapper
4. Receba os tokens dele 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 acessar instantaneamente pools estabelecidos. Isso é dramaticamente mais eficiente em termos de capital e cria uma melhor experiência para o usuário.

As possibilidades vão muito além das simples trocas. Com a verificação de estado em tempo real da NFFL, os protocolos poderiam oferecer recursos sofisticados como ordens de limite entre cadeias. Um usuário poderia colocar uma ordem de limite 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 forem atendidas.

Esse modelo pode remodelar a forma como pensamos sobre a implantação de protocolo entre rollups. Em vez de implantar automaticamente em todos os lugares ou unir os 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

Em seguida, através da NFFL, eles ainda podem atender usuários em todo o ecossistema rollup, enquanto mantêm operações mais simples e eficientes.

As implicações para o 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 uma melhor execução para os utilizadores em todos os rollups.

Como já deve ter notado, este padrão de implementação de cadeia única com acesso a várias cadeias por meio do NFFL poderia estender-se bem além dos DEXs. Qualquer protocolo que beneficie da profundidade de liquidez ou dos efeitos de rede poderia adotar este modelo - protocolos de empréstimo, plataformas de opções, mercados de NFT e outros. A ideia-chave é que o NFFL torna o acesso entre cadeias quase tão simples como a interação na mesma cadeia, permitindo que os protocolos otimizem a sua estratégia de implementação sem sacrificar a acessibilidade. Em outras palavras, o NFFL torna o Ethereum novamente um ecossistema.

Roadmap e Desenvolvimento Futuro

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

Segurança de Protocolo

• Implementando mecanismos abrangentes de desafio e penalização através do EigenLayer
• Ativação da participação do operador sem permissão com gestão robusta de participação
• Aprimorando a verificação de estado entre cadeias cruzadas com primitivas criptográficas melhoradas (BLS→ECDSA)

Escalabilidade de rede

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

Experiência do desenvolvedor

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

Nas seguintes seções, exploraremos em detalhe algumas das melhorias planeadas mais significativas.

BLS para ECDSA

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

O problema surge da forma 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 criou. Isso significa que quando o conjunto de operadores muda no Ethereum, todos os rollups devem atualizar para o mesmo conjunto de operadores antes de poderem verificar novas declarações. Mesmo uma pequena divergê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ção do conjunto de operadores.

As assinaturas ECDSA, embora exijam mais espaço e computação para verificar, 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 difira temporariamente 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 relacionada a outra grande melhoria de protocolo - implementando conjuntos de operadores dinâmicos. 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 operador dinâmico permitiria que novos operadores se juntassem à rede sem permissão apostando através da EigenLayer. Isso introduz vários desafios técnicos que precisam ser cuidadosamente abordados:

Primeiro, o protocolo deve gerir 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 as 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 participação no 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 eficientemente com as atualizações do conjunto de operadores entre cadeias. Quando o conjunto de operadores muda no Ethereum, essas atualizações precisam se propagar para todos os 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

Outra área crítica de desenvolvimento é a ativação de mecanismos de desafio sem permissão e de penalização. Estes mecanismos são essenciais para fazer cumprir comportamentos honestos e fornecer as garantias de segurança econômica de que a NFFL depende.

O sistema de desafio gira em torno do mecanismo de tarefa de ponto de verificação. Quando os operadores enviam pontos de verificação contendo Mensagens merkleizadas de um período de tempo, qualquer pessoa pode desafiar esses pontos de verificação 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 a equivocação - onde um operador assina várias Mensagens conflitantes para o mesmo caso, como atestar diferentes raízes de estado para o mesmo bloco. Também inclui atestações inválidas, onde um operador assina transições de estado provavelmente incorretas ou atualizações do conjunto de operadores.
• Em segundo lugar, falhas de vivacidade que afetam 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 leva em conta o tempo de inatividade legítimo.

O protocolo irá implementar um sistema de desafio baseado em garantias. Os desafiantes devem bloquear uma garantia ao enviar um desafio, que será perdida se o desafio se provar inválido. No entanto, se eles conseguirem provar com sucesso uma falha do operador, eles recebem uma recompensa da participação do operador cortada. Isso cria incentivos econômicos para monitorar o comportamento do operador, evitando desafios frívolos.

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

O mecanismo de corte em si será implementado através dos contratos de middleware da EigenLayer. Quando os desafios têm sucesso, os operadores perdem uma parte de seus ETH apostados. Os parâmetros de corte são projetados de forma que as perdas potenciais excedam significativamente quaisquer ganhos de comportamento malicioso. Parte desse valor cortado é atribuído aos desafiadores bem-sucedidos, enquanto o restante pode ser distribuído a 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 má conduta, os desafiadores são incentivados a monitorar a rede e as aplicações podem contar com garantias criptoeconômicas respaldadas por ETH reinvestido. Os períodos de desafio são muito mais curtos do que as provas de fraude de rollup otimista, ao mesmo tempo em que fornecem segurança sólida por meio dos mecanismos de corte do EigenLayer.

Futuro da Finalidade Rápida

Embora o 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 questão-chave que muitos fazem é: “O NFFL ainda será relevante conforme a tecnologia de rollup avança?”

A resposta torna-se 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 se resolver fundamentalmente mais rápido do que sua janela à prova de fraude — normalmente 7 dias. Embora soluções como a Superchain da Optimism e a Arbitrum Orbit permitam uma comunicação mais rápida entre rollups que compartilham uma ponte, elas não ajudam na interoperabilidade fora de seus ecossistemas específicos — por exemplo, entre esses dois.

Os ZK rollups enfrentam restrições diferentes, mas igualmente importantes. Mesmo à medida que a tecnologia de prova ZK melhora drasticamente, há 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 ZK por bloco em diferentes rollups. Quando isso se tornar possível, a liquidação ainda estará limitada pelo tempo do bloco L1 - pelo menos 12 segundos sob os parâmetros atuais.

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

Importante, o NFFL não deve ser visto como concorrente ou ameaça ao modelo de segurança rollup do Ethereum. Em vez disso, ele fornece uma ferramenta complementar que permite novas possibilidades dentro do ecossistema modular do Ethereum. As aplicações podem usar o NFFL para verificação rápida de estado, mantendo a dependência de acordos canônicos através do L1 quando necessário. Isso cria um conjunto de ferramentas mais completo para os desenvolvedores construírem aplicações cross-chain com modelos de segurança adequados às suas necessidades específicas.

Conclusão

NFFL representa uma abordagem inovadora para resolver um dos desafios mais prementes no ecossistema modular do Ethereum - possibilitando a verificação segura e eficiente do estado cruzado do rollup. Ao alavancar o ETH restaked da EigenLayer para segurança econômica e o DA NEAR 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 criteriosas do protocolo refletem uma compreensão profunda dos desafios na infraestrutura de cadeia cruzada. Em vez de tentar substituir o modelo de segurança dos rollups, a NFFL fornece uma camada complementar otimizada para casos de uso específicos que exigem uma finalidade mais rápida. O sistema de tarefas baseado em pontos de verificação permite uma operação off-chain eficiente, mantendo fortes garantias de segurança on-chain. E a arquitetura do contrato de registro permite que os rollups verifiquem estados sem confiança enquanto herdam a segurança econômica da NFFL.

Talvez o mais importante, NFFL permite uma nova geração de aplicações cross-chain que anteriormente eram impraticáveis. De protocolos de empréstimos unificados que compartilham garantias através de rollups a embrulhos DEX que tornam a liquidez estabelecida universalmente acessível, a rápida verificação 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 experiência do usuário em todo o ecossistema.

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

À medida que o ecossistema rollup da 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 da Ethereum através do restaking, ao mesmo tempo que otimiza a velocidade e a rentabilidade, coloca-a numa posição privilegiada para atender a essa necessidade. Ao permitir novas formas de interação entre cadeias mantendo garantias fortes de segurança, a NFFL contribui para tornar a visão modular da Ethereum uma realidade.

Aviso legal:

1. Este artigo é reproduzido de [[](https://research.2077.xyz/nuffle-ethereums-finality-as-a-service-layer#introduction)[2077 Research](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 Learnequipa e eles vão tratar disso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são realizadas pela equipe de aprendizagem da gate. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.