Introdução

No final de 2020, a Ethereum adotou uma abordagem centrada em rolluppara entregar transações rápidas e baratas. No entanto, isso vem com o custo de um aumento da fragmentação, à medida que os utilizadores e a liquidez se dispersam por várias rollups. Esta fragmentação é um desafio para todo o ecossistema que impede uma experiência Ethereum unificada.

Neste artigo, examinaremos as raízes desta fragmentação, analisaremos um dos desafios centrais da interoperabilidade de rollup, a equívoco e categorizaremos as soluções existentes para enfrentar este problema. Ao descrever as diferentes soluções propostas relativas à interoperabilidade de rollup e destacar os compromissos envolvidos, esperamos proporcionar um vislumbre do futuro da interoperabilidade de rollup e de como construir um futuro de rollup mais bem conectado.

O problema da fragmentação

Fragmentação do estado em diferentes rollups resulta numa experiência de utilizador fraca, eficiência de capital reduzida e falta de componibilidade nativa:

Experiência do Usuário: A fragmentação força os utilizadores a mudar frequentemente de redes, a gerir várias cópias do mesmo token e a equilibrar várias carteiras. Isto adiciona atrito e complexidade, tornando mais difícil para os utilizadores desfrutarem de uma experiência Ethereum perfeita e que funcione sem problemas. Por exemplo, suponhamos que a Alice tem os seus fundos no rollup A mas quer comprar um token disponível apenas no Rollup B. Em vez de apenas clicar em 'Comprar', ela deve primeiro mudar de rede, transferir os seus fundos de A para B, esperar pelas confirmações da L1 e só então executar a transação.

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

Composição: Numa única cadeia, um protocolo de empréstimo pode liquidar instantaneamente uma posição chamando um contrato DEX na mesma transação—tudo acontece de forma atômica.síncronoNunca é um processo assíncrono num mundo fragmentado e multi-rollup, o protocolo pode desencadear uma liquidação num rollup e esperar por uma mensagem para finalizar no DEX de outro rollup. Se algo correr mal, reverter o processo não é simples. Além disso, não existem ferramentas fornecidas nativamente pela Ethereum para fazer chamadas de contrato entre rollups ou garantir a execução rápida dessas chamadas. Esta perda de interações imediatas e atómicas mina a composição que torna o ecossistema da Ethereum tão poderoso.

Interoperabilidade

No seu âmago, interoperabilidade significa permitir uma transação que começa num rollup e atualiza o estado noutro - como enviar tokens do Rollup A para o Rollup B. Idealmente, esta ação é tão simples como o seu saldo em A diminuir e o seu saldo em B aumentar, tudo de uma vez. Na prática, alcançar um comportamento “tudo-ou-nada” tão perfeito é desafiante entre diferentes rollups.

Idealmente, as interações entre rollups funcionariam da mesma forma que funcionam no Ethereum L1 - de forma síncrona. Num ambiente síncrono, várias chamadas a contratos diferentes em rollups diferentes podem ser agrupadas numa única transação que ou tem sucesso total ou falha total, proporcionando resultados imediatos e atômicos.

Em contraste, a composabilidade assíncrona envolve múltiplos passos espalhados 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 a tempo e, em seguida, pode precisar reverter essa transição de estado parcial (pois o rollup correspondente não fez sua parte). A composabilidade síncrona e assíncrona compartilham muitos desafios comuns que discutimos aqui.

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

Os desafios da interoperabilidade

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

• A Rollup B só aceita os fundos da Alice se forem transferidos através do Ethereum. Neste caso, a Alice precisa de retirar os seus fundos para L1, 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, processando a transferência diretamente, em vez de liquidar primeiro na camada 1 do Ethereum. No entanto, como explicamos abaixo, isso expõe Rollup B a potenciais riscos de reorganização se Rollup A equivocar, não liquidar ou submeter uma transição de estado inválida.

Quando dois L2 interagem a uma latência mais rápida do que a Ethereum (ou seja, antes mesmo de comprometerem ou resolverem suas transições de estado para L1), existem três questões fundamentais com as quais os rollups precisam lidar: equívoco, invalidade e não resolução.

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

Vamos reiterar aqui que todos esses problemas podem ser trivialmente resolvidos esperando pela finalidade L1 - quando as transições de estado são totalmente resolvidas no Ethereum. No entanto, estamos interessados em permitir interações seguras entre rollups a uma latência mais rápida do que o Ethereum. Exploramos soluções que mantêm a segurança enquanto operam nesta janela de sub-finalidade.

Vamos ilustrar esses desafios com um exemplo: suponha que Alice possui 10 ETH na mainnet do Scroll e deseja transferi-los para Bob no Arbitrum. Idealmente, Alice seria capaz de mover liquidez entre essas duas cadeias nativamente a uma latência mais rápida do que o Ethereum. Suponha que existisse tal solução, em que o Arbitrum creditasse Alice com 10 ETH no Arbitrum antes que o Scroll submetesse qualquer coisa ao L1, o que pode correr mal para o Arbitrum?

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

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

Um aspeto crítico da interoperabilidade do rollup é como os sistemas lidam com o equívoco. Diferentes arquiteturas adotam abordagens diferentes. Em alguns sistemas, como o OP Superchain, os rollups são projetados para se reorganizarem 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 de cadeia cruzada. Outras arquiteturas se concentram em evitar equívocos inteiramente através de vários mecanismos que exploraremos abaixo.

Tanto a não resolução como a inviabilidade serão trivialmente resolvidas assim 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 provar que Alice enviou 10 ETH para Bob no Arbitrum, mas não garante que o Scroll irá comprometer 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 preço da vantagem de velocidade do rollup. Assim, concentramo-nos na prevenção do equívoco pré-resolução, ou seja, garantias de prevenção de equívoco antes da resolução para o Ethereum. Como veremos, cada abordagem envolve diferentes compensações, nomeadamente em termos de pressupostos de confiança que discutimos abaixo.

Arquitetura de interoperação

Apresentamos duas abordagens diferentes que foram exploradas para interoperabilidade a uma latência mais rápida do que a do 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 grupo onde todos confiam uns nos outros para não equivocar-se, 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 do que a do Ethereum. Vamos explorar o que essa diferença significa na prática.

Malha

O modelo de malha funciona exatamente como você pode esperar, com rollups se comunicando diretamente uns com os outros enquanto ainda são responsáveis por se resolverem no Ethereum L1 por si mesmos:

À medida que mais e mais rollups se tornam interconectados nessa grande malha, a transitividade da confiança e das dependências torna-se um problema para a escalabilidade. Se a Arbitrum confiar no Scroll, mas não no zkSync, o Scroll não poderá confiar no zkSync enquanto mantém a confiança do Arbitrum. Apenas "grupos de confiança" disjuntos, ou seja, cliques de rollups, podem interagir uns com os outros em uma malha. Este problema de dependência é amplificado à medida que mais e mais rollups estão envolvidos em casos complexos de interoperabilidade, onde 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 de pré-liquidação, podem detetar a equivocação na liquidação, desencadeando reorganizações em todos os rollups conectados.

Portanto, embora este modelo de interoperabilidade tenha algumas deficiências, ele é inteiramente adequado para casos em que as operações de cadeia cruzada desejadas são limitadas a grandes rollups que provaram ser seguros e/ou confiáveis e que estão dispostos a criar essa dependência de confiança em seus sistemas. No entanto, rapidamente se torna evidente que este modelo não escala bem se quisermos adicionar mais e mais rollups, outros L2s e até mesmo appchain L3s na malha.

Porta

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, de modo que vincular mais um rollup à camada seja 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 a do Ethereum.

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

A principal contrapartida dessa abordagem é que todos os rollups têm uma dependência compartilhada comum no hub, que ganha poder significativo.

Especificamente, para prevenir equivocações pré-liquidação, devemos garantir que o hub não irá conspirar com um rollup equivocante. Assim, os sistemas de hub substituem a confiança mútua entre rollups no design de malha, com confiança em uma camada compartilhada única que não deve conspirar com outros rollups para equivocar.

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

• Usar um rollup existente: Esta opção tem a vantagem de ser a mais simples, uma vez que o rollup já existe e, presumivelmente, foi testado em batalha, e seria uma questão de implementar contratos inteligentes nele.
• Criar 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 este novo componente teria um vetor de superfície de bug/exploit minimizado por ser especificamente adaptado para as necessidades intercadeias (e até poderia ser formalmente verificado!).
• Usando o próprio Ethereum L1: Esta opção envolve o usopré-confirmações baseadasdiretamente na Camada 1 para ter o melhor dos dois mundos: usar a camada maximamente descentralizada para máxima vivacidade e segurança, ao mesmo tempo que se têm confirmações quase instantâneas, tempos de retirada minimizados, etc.

Pressupondo que as provas zk estão a ser utilizadas, todas estas três opções podem aproveitar o conceito de agregação de provas 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. OPSuperchaine do ArbitrumCadeias de clusterssão sistemas de malha, onde as cadeias devem liquidar em conjunto - se uma cadeia equivocar, todas as cadeias conectadas devem reorganizar. As cadeias devem confiar umas nas outras para confirmações pré-liquidação.

Estas soluções podem transitar para a utilização de algum tipo de hub, uma vez que os grupos de confiança não conseguem escalar para além de alguns grandes rollups para alcançar a finalidade de pré-liquidação predefinida.

Sistemas de hub. Espresso e do zkSync Cadeia Elásticasão sistemas de hub. Na Scroll, temos estado a explorar um design de hub que poderia permitir soluções de interoperação mais escaláveis e fiáveis.apresentaçãono Columbia CryptoEconomics Workshop 2024 fornece uma visão geral do design, com mais detalhes a seguir num post futuro.

Outros sistemas. Os rollups baseados têm o potencial para 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ívoco.

O 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 pressupostos de confiança adicionais nessa camada compartilhada. Em vez disso, esperam pela liquidação e usam provas pessimistaspara fornecer segurança. A equívoco é assim evitado 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 umparceria com a Espresso Systems, que fornece um mecanismo de sequenciação partilhado.

Conclusão

O desenvolvimento de um mecanismo de prevenção de equívocos para uma interoperabilidade mais rápida do que o Ethereum vem com todos os tipos de compensações que precisam ser cuidadosamente consideradas por uma questão de segurança, descentralização e neutralidade crível. Embora este post tenha se concentrado na prevenção de equívocos, há 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 pontes compartilhadas e contratos de rollup entre diferentes rollups), protocolos de passagem de mensagens e os incentivos econômicos necessários para fazer o sistema funcionar. Mas como disse Vitalik num tweet recenteEstamos mais perto de resolver esses problemas de interoperabilidade do que a maioria das pessoas pensa. Neste fim de jogo de interop, acreditamos que os utilizadores vão sentir verdadeiramente que estão a "utilizar um Ethereum", ao invés de rollups individuais como é hoje.

Aviso legal:

1. Este artigo é reproduzido a partir de [Investigação de Rolagem]. Todos os direitos de autor pertencem ao autor original [Alejandro Ranchal-Pedrosa]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa, e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe do Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.