Introdução

No final de 2020, o Ethereum abraçou um abordagem centrada em rolluppara fornecer transações rápidas e baratas. No entanto, isso vem com o custo de aumento da fragmentação, à medida que os usuários e a liquidez se dispersam entre vários rollups. Essa fragmentação é um desafio em toda a ecossistema que impede uma experiência unificada do Ethereum.

Neste artigo, examinaremos as raízes desta fragmentação, examinaremos um dos principais desafios da interoperabilidade rollup, a equivocação, e categorizaremos as soluções que existem para enfrentar este problema. Ao descrever as diferentes soluções propostas em relação à interoperabilidade rollup e destacar os compromissos envolvidos, esperamos fornecer um vislumbre do futuro da interoperabilidade rollup e como construir um futuro rollup mais conectado.

O problema da fragmentação

Fragmentação do estado em diferentes rollups resulta em uma experiência do usuário ruim, eficiência de capital reduzida e falta de composibilidade nativa:

Experiência do usuário: A fragmentação força os usuários a trocar de redes com frequência, gerenciar múltiplas cópias do mesmo token e equilibrar várias carteiras. Isso adiciona atrito e complexidade, tornando mais difícil para os usuários desfrutar de uma experiência Ethereum perfeita e que "apenas funcione". Por exemplo, suponha que Alice tenha seus fundos no rollup A, mas queira comprar um token disponível apenas no Rollup B. Em vez de apenas clicar em "Comprar", ela deve primeiro trocar de redes, transferir seus fundos de A para B, aguardar as confirmações do L1 e depois executar a negociação.

Liquidez: Com a liquidez dispersa em vários rollups, os pares de negociação têm pouca profundidade e eficiência. Isso leva a preços piores, rendimentos reduzidos para protocolos de empréstimo e execução de negociações subótimas.

Composição: Em uma única cadeia, um protocolo de empréstimo pode liquidar instantaneamente uma posição chamando um contrato DEX na mesma transação—tudo acontece em uma operação atômica, síncronoEm um mundo fragmentado e multi-rollup, esse processo se torna assíncrono. O protocolo pode disparar uma liquidação em um rollup e depois esperar por uma mensagem para finalizar em um DEX de outro rollup. Se algo der errado, reverter o processo não é simples. Também não existem ferramentas fornecidas nativamente pelo Ethereum para fazer chamadas de contrato entre rollups ou garantir a execução rápida dessas chamadas. Essa perda de interações imediatas e atômicas mina a composabilidade que torna o ecossistema do Ethereum tão poderoso.

Interoperabilidade

Em sua essência, interoperabilidade significa permitir uma transação que começa em um rollup e atualiza o estado em outro — como enviar tokens do Rollup A para o Rollup B. Idealmente, essa ação é tão simples quanto ter seu saldo em A diminuir e seu saldo em B aumentar, tudo de uma vez. Na prática, alcançar esse comportamento contínuo “tudo ou nada” é um desafio entre diferentes rollups.

Idealmente, as interações entre rollups funcionariam da mesma forma que funcionam no Ethereum L1 - de forma síncrona. Em um ambiente síncrono, várias chamadas para contratos diferentes em rollups diferentes podem ser agrupadas em uma única transação que ou é bem-sucedida por completo ou falha por completo, fornecendo resultados imediatos e atômicos.

Por outro lado, a composabilidade assíncrona envolve várias etapas ao longo do tempo em diferentes rollups. Em vez de uma única transação atômica, uma ação pode desencadear um evento em um rollup e depois aguardar a confirmação antes de concluir a interação em outro. A composabilidade assíncrona precisa lidar com abortos: apenas um dos rollups pode realizar a ação atempadamente e, em seguida, pode ser necessário reverter essa transição de estado parcial (pois o rollup correspondente não fez a sua parte). A composabilidade síncrona e assíncrona compartilham muitos desafios comuns que discutimos aqui.

Este artigo foca nas soluções de interoperabilidade nativa rollup que exigem integração ao nível do protocolo. Excluímos soluções de ponte externas que dependem de provedores de liquidez e suportam apenas transferências de tokens fungíveis.

Os desafios da interoperabilidade

Alcançar verdadeira interoperabilidade entre rollups não é apenas enviar mensagens de um lado para o outro; trata-se de garantir que as transações sejam finalizadas com segurança e rapidez. Depender exclusivamente do Ethereum L1 pode significar longos atrasos e altos custos. Alice tem seus fundos no rollup A, mas deseja comprar um token disponível apenas no Rollup B. Duas opções são possíveis:

• A Rollup B só aceita os fundos de Alice se forem transferidos através do Ethereum. Neste caso, Alice precisa retirar seus fundos para L1, depois depositá-los no Rollup B e, finalmente, comprar o token no Rollup B, incorrendo em atrasos e custos elevados.
• Rollup B fornece um caminho mais rápido e mais barato ao processar a transferência diretamente, em vez de liquidar primeiro na Camada 1 do Ethereum. No entanto, conforme explicamos abaixo, isso expõe Rollup B a riscos potenciais de reorg se Rollup A fizer declarações contraditórias, não liquidar ou enviar uma transição de estado inválida.

Quando dois L2 interagem em latência mais rápida que o Ethereum (ou seja, antes mesmo de confirmarem ou liquidarem suas transições de estado para L1), existem três questões fundamentais com as quais os rollups precisam lidar: equivocação, invalidade e não liquidação.

• Equivocação: Um rollup transmite estados conflitantes para diferentes cadeias, prometendo efetivamente os mesmos ativos várias vezes.
• Inválido: Uma transição de estado pode nunca ser comprovadamente correta no L1.
• Não resolvido: O processo de geração de prova ou resolução pode parar indefinidamente.

Vamos reiterar aqui que todos esses problemas podem ser trivialmente resolvidos ao aguardar a finalidade da L1 - quando as transições de estado estiverem completamente resolvidas no Ethereum. No entanto, estamos interessados em possibilitar interações seguras entre rollups cruzados com latência mais rápida do que a do Ethereum. Exploramos soluções que mantêm a segurança ao operar nesta janela de subfinalidade.

Vamos ilustrar esses desafios com um exemplo: suponhamos que Alice possui 10 ETH na mainnet do Scroll e deseja transferi-los para Bob no Arbitrum. Idealmente, Alice seria capaz de mover a liquidez entre essas duas cadeias nativamente em latências mais rápidas que o Ethereum. Suponhamos que tal solução existisse, e que o Arbitrum creditasse Alice com 10 ETH no Arbitrum antes que o Scroll enviasse qualquer coisa para a L1, o que poderia dar errado para o Arbitrum?

• Equivocação: Scroll equivoca-se ao cometer, na L1, uma transição de estado diferente na qual a transação de Alice não está incluída, efetivamente roubando 10 ETH da Arbitrum (que precisa reorganizar para poder liquidar).
• Invalidade: Scroll não equivale, mas a transição de estado que continha a transação é inválida e, portanto, o Scroll nunca pode liquidá-la (ou seja, prová-la) na L1 e dar os fundos para o Arbitrum. Novamente, o Arbitrum precisa se reorganizar para poder liquidar.
• Não liquidação: o Scroll não se equivoca e a transição de estado é válida, mas os provadores designados do Scroll ficam offline e, portanto, a liquidação nunca acontece. Arbitrum precisa se reorganizar novamente.

Ao integrar a 10 ETH enviada por Alice em Scroll antes que Scroll comprometa na L1 (no caso de equivocação) e antes que Scroll resolva (no caso de invalidez e não resolução), Arbitrum assume um risco em sua cadeia dependente das considerações de segurança do Scroll.

Um aspecto crítico da interoperabilidade de rollup é como os sistemas lidam com a equivocação. Arquiteturas diferentes adotam abordagens diferentes. Em alguns sistemas como o OP Superchain, os rollups são projetados para reorganizar juntos - se um rollup equivocar, todos os rollups conectados devem reorganizar seu estado para manter a consistência em todo o sistema, uma propriedade chamada blocos contingentes entre cadeias. Outras arquiteturas focam em prevenir a equivocação completamente por meio de vários mecanismos que exploraremos abaixo.

Tanto a não resolução quanto a invalidade serão trivialmente resolvidas uma vez que a geração em tempo real da prova zk se torne prática (também conhecida como prova em tempo real). O problema da equívoco, no entanto, é fundamentalmente diferente. Uma prova zk pode comprovar que Alice enviou 10 ETH para Bob no Arbitrum, mas não garante que o Scroll irá confirmar essa transição no L1. Provas zk sozinhas não resolvem e nunca resolverão o equívoco. Por outro lado, esperar pela resolução do L1 resolve o equívoco, mas ao custo da vantagem de velocidade do rollup. Assim, focamos na pré-resolução do equívoco, ou seja, garantias de prevenção do equívoco antes da resolução para o Ethereum. Como veremos, cada abordagem envolve diferentes compensações, especialmente em termos de pressupostos de confiança que discutiremos abaixo.

Arquitetura de interoperabilidade

Apresentamos duas abordagens diferentes que foram exploradas para interoperabilidade em latência mais rápida do que o Ethereum, que chamamos de malha e hub.

Em suma, o modelo de malha é onde os rollups estão diretamente interligados uns aos outros em um clique onde todos confiam uns nos outros para não equivocar a fim de alcançar a finalidade de pré-liquidação predefinida.

O modelo de hub introduz uma camada compartilhada, na qual os rollups dependem para lidar com a prevenção de equívoco das interações entre cadeias a uma latência mais rápida que a do Ethereum. Vamos explorar o que essa diferença significa na prática.

Malha

O modelo de malha funciona exatamente como você poderia esperar, com rollups se comunicando diretamente entre si enquanto ainda são responsáveis por liquidar o Ethereum L1:

À medida que mais e mais rollups se tornam interconectados nessa grande malha, a transitividade da confiança e das dependências se torna um problema para a escalabilidade. Se a Arbitrum confia no Scroll, mas não no zkSync, então o Scroll não pode confiar no zkSync enquanto mantém a confiança do Arbitrum. Somente "grupos de confiança" disjuntos, ou seja, cliques de rollups, podem interagir uns com os outros em uma malha. Esse problema de dependência é amplificado à medida que mais e mais rollups estão envolvidos em casos complexos de interoperabilidade, em que a segurança do todo é limitada à segurança do rollup mais fraco.

Enquanto os sistemas de malha dependem da confiança para a segurança pré-liquidação, eles podem detectar a equívoco na liquidação, desencadeando reorganizações em todas as rollups conectadas.

Portanto, embora este modelo de interoperabilidade tenha algumas falhas, é totalmente adequado para casos em que as operações desejadas de interligação de cadeias são limitadas a rollups principais que provaram ser seguras e/ou confiáveis e que estão dispostas a criar essa dependência de confiança em seus sistemas. No entanto, torna-se rapidamente aparente que este modelo não escala bem se quisermos adicionar mais e mais rollups, outros L2s e até mesmo L3s de appchain na malha.

Hub

No modelo de hub, as deficiências do modelo de malha são abordadas pela introdução de uma camada compartilhada. Cada rollup precisa confiar nesta camada, que atua como a fonte da verdade para as interações, então vincular mais um rollup à camada é muito mais fácil. Naturalmente, precisamos que esta camada seja o mais segura possível para oferecer as melhores garantias de não-equivocação com uma latência mais rápida que o Ethereum.

A vantagem desta solução é que adicionar rollups extras na mistura não cria mais problemas de dependência, uma vez que a camada de interoperabilidade age como um "escudo" entre cada rollup. Isso pode incluir quaisquer cadeias L2 arbitrárias, bem como L3s e rollups de aplicativos - tudo o que precisam fazer é se integrar ao hub e desfrutar dos benefícios.

O grande trade-off desta abordagem é que todos os rollups têm uma dependência compartilhada comum no hub, que ganha poder significativo.

Especificamente, para prevenção de equívocos pré-liquidação, devemos garantir que o hub não seja conivente com um acúmulo de equívocos. Os sistemas de hub, portanto, substituem a confiança mútua entre os rollups no design da malha, pela confiança em uma única camada compartilhada que não deve conspirar com outros rollups para se equivocar.

Não é surpresa que o hub deva ser construído com segurança e descentralização em mente. Existem algumas opções diferentes para a construção de um hub desse tipo:

• Usando um rollup existente: Esta opção tem a vantagem de ser a mais simples, já que o rollup já existe e, presumivelmente, foi testado em batalha, e seria uma questão de implantar contratos inteligentes nele.
• Criando um componente dedicado: Em vez de pedir aos rollups que confiem em todas as propriedades de segurança de um rollup existente, criamos um novo componente dedicado para atuar como o hub. A vantagem aqui é que esse novo componente teria um vetor de superfície de bug/exploit minimizado por ser especificamente projetado para as necessidades de interoperabilidade (e até mesmo poderia ser formalmente verificado!).
• Usando o próprio Ethereum L1: Esta opção envolve usarpré-confirmações baseadas diretamente na Camada 1 para ter o melhor dos dois mundos: use a camada descentralizada ao máximo para obter o máximo de vivacidade e segurança, ao mesmo tempo em que tem confirmações quase instantâneas, tempos de retirada minimizados, etc.

Supondo que as provas zk estejam sendo usadas, todas essas três opções podem aproveitar o conceito de agregação de prova para reduzir ainda mais os custos envolvidos, fazendo com que o L1 verifique uma única prova que agrupa muitas provas individuais de todos os rollups suportados pelo hub.

Sistemas existentes

Vários projetos propuseram várias soluções de interoperabilidade, que podem ser categorizadas da seguinte forma.

Sistemas de malha. OPSupercadeiae do ArbitrumClusters de cadeiassão sistemas de malha, onde as cadeias devem liquidar em conjunto - se uma cadeia se equivoca, todas as cadeias conectadas devem se reorganizar. As cadeias devem confiar umas nas outras para confirmações de pré-liquidação.

Essas soluções podem fazer a transição para o uso de algum tipo de hub, pois os cliques de confiança não podem escalar além de alguns grandes rollups para alcançar a finalidade pré-liquidação.

Sistemas de hub. Espresso e zkSync Cadeia Elástica são sistemas de hub. Na Scroll, temos explorado um design de hub que possa permitir soluções de interoperabilidade mais escalonáveis e confiáveis. Nosso apresentação no Columbia CryptoEconomics Workshop 2024 fornece uma visão geral do design, com mais detalhes a seguir em um próximo post.

Outros sistemas. Os rollups baseados têm o potencial de permitir a composição síncrona não apenas entre si, mas até mesmo com o Ethereum L1 e, por sua vez, podem usar o Ethereum L1 para prevenção de equívocos.

A AggLayer da Polygon é outro tipo de sistema de hub que fornece uma camada compartilhada com a qual todos os rollups se comunicam. No entanto, difere ao evitar suposições de confiança adicionais nesta camada compartilhada. Em vez disso, eles esperam o ajuste e usam provas pessimistaspara fornecer segurança. A equívoco é assim evitada apenas no momento da liquidação. Pré-confirmações poderiam ser usadas opcionalmente para oferecer garantias de finalidade mais rápidas. A AggLayer anunciou recentemente um parceria com a Espresso Systems, que fornece um mecanismo de sequenciamento compartilhado.

Conclusão

Desenvolver um mecanismo de prevenção à equívoco para interoperabilidade mais rápida que o Ethereum vem com todo tipo de compensações que precisam ser cuidadosamente consideradas em prol da segurança, descentralização e neutralidade credível. Embora este post tenha se concentrado na prevenção à equívoco, existem vários outros desafios críticos de interoperabilidade que não discutimos profundamente aqui, como disponibilidade de dados, design de camada de liquidação (por exemplo, implementação de contratos de ponte compartilhada e rollup entre diferentes rollups), protocolos de passagem de mensagens e os incentivos econômicos necessários para fazer o sistema funcionar. Mas, como Vitalik disseem um tweet recenteEstamos mais próximos de resolver esses problemas de interoperabilidade do que a maioria das pessoas pensa. Neste fim de jogo de interop, acreditamos que os usuários realmente sentirão que estão 'usando um Ethereum', em vez de rollups individuais como hoje.

Aviso legal:

1. Este artigo é reproduzido a partir de [Pesquisa Scroll]. Todos os direitos autorais pertencem ao autor original [Alejandro Ranchal-Pedrosa]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe 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. A equipe Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.