Introdução

Houve uma explosão cambriana de rollups no Ethereum. No momento da escrita, existem 91 L2 & L3s ao vivo e 82 futuros de acordo com o L2Beat. Como resultado, também há uma quantidade significativa de fragmentação em termos de liquidez, experiência do usuário e ferramentas de desenvolvedor. As soluções atuais para interoperabilidade deixam muito a desejar, pois dependem de uma combinação de pontes de terceiros, ativos externamente envolvidos e estruturas de intenção, cada uma carregando seu próprio conjunto de problemas.

1. As pontes de liquidez são frequentemente os alvos dos maiores hacks de criptomoedas (por exemplo, o hack da ponte wormhole de $321 milhões)
2. Ativos envolvidos externamente são indesejáveis, e os dados mostram que as pessoas preferem manter os ativos em sua forma nativa sempre que possível (por exemplo, existem $22b em ativos ponteados de forma canônica e apenas $3b em ativos envolvidos externamente, de acordo com L2Beat)
3. Os frameworks de intenção dependem de terceiros que exigem alguma confiança não negligenciável e vêm com taxas adicionais para facilitar a atividade entre rollups (por exemplo, usuário da cadeia Degen perder mais de 80% dos tokensdevido à ponte oficial não ser canónica) a. Os frameworks de intenção centralizados também significam menor concorrência e isso poderia levar a preços e desempenho subótimos

Neste artigo, fazemos um levantamento da paisagem de interoperabilidade sem confiança, definindo e discutindo seis níveis de soluções de interoperabilidade entre ecossistemas de fragmentação de rollup.

Começamos com o caso padrão de retirada de forma assíncrona do rollup de origem para L1 e a transferência manual para o rollup de destino, e terminamos com uma arquitetura hipotética para a composabilidade entre rollups cruzados dentro de uma única transação. Vamos explorar como cada nível de interoperabilidade afetará a experiência do usuário, a experiência do desenvolvedor, o potencial de MEV e os próprios rollups (especificamente relacionados a mudanças de infraestrutura).

Permanecemos principalmente dentro do âmbito do Ethereum e suas L2s para este artigo e focamos exclusivamente na interoperabilidade sem confiança. Neste caso, a “interoperabilidade sem confiança” refere-se a canais em protocolo que não requerem terceiros para facilitar transferências fora da infraestrutura necessária que a maioria dos rollups já requerem.

Preliminares

Definições

Fundamentalmente, a interoperabilidade sem confiança requer algum recurso compartilhado ao qual quaisquer dois protocolos que desejam interoperar devem ter acesso. No caso do Ethereum L1, todos os contratos inteligentes vivem no mesmo ambiente compartilhando o estado completo do Ethereum, então eles sempre terão o mais alto nível de interoperabilidade. No entanto, os L2s compartilham apenas uma camada de liquidação por meio de contratos de ponte separados e, portanto, a interoperabilidade é muito mais limitada.

Os componentes de infraestrutura compartilhada cruciais que podem nos fazer progredir ao longo da escada de interoperabilidade sem confiança são sequenciadores compartilhados, superconstrutores e liquidação compartilhada. As garantias e novas funcionalidades abertas por essas camadas compartilhadas estão relacionadas, mas essencialmente ortogonais na natureza.

1. Sequenciadores/Construtores Partilhados: Principalmente melhorias de velocidade e experiência do utilizador.
2. Compensação Compartilhada: Trocas de ativos sem embrulho externo, bem como mensagens no protocolo.

Para começar, vamos primeiro definir os seis níveis de interoperabilidade sem confiança mencionados na introdução:

1. L1 Assíncrono:
   → Interoperabilidade através da transferência manual de ativos através do L1 que os rollups liquidam.
2. Inclusão Atômica:
   → Uma garantia de que todas as transações em um pacote de transferência cruzada serão incluídas no próximo bloco para cada transferência envolvida no pacote, ou nenhuma será.
3. Partilha de Liquidação:
   → Múltiplos rollups conectando-se ao L1 através do mesmo contrato de ponte.
4. Execução Atómica:
   → Uma garantia de que todas as transações em um pacote de cross-rollup serão incluídas e executadas com sucesso no próximo bloco para cada rollup envolvido no pacote, ou nenhuma será executada. A execução bem-sucedida refere-se a cada transação sendo executada sem reverter e sendo refletida no estado atualizado para cada rollup no pacote.
5. Composição ao nível do bloco:
   → O próximo bloco garante pacotes de transferência cruzada que podem conter transações dependentes (tx B no rollup B é dependente do resultado da tx A no rollup A)
6. Composição ao nível de transação:
   → Interoperabilidade ao nível de contratos inteligentes que requer apenas uma transação que pode causar alterações de estado em vários rollups simultaneamente (sem bundles). Usar qualquer protocolo em qualquer rollup é logicamente equivalente a usar diferentes contratos inteligentes numa única cadeia. Importante, isso implica que as alterações de estado antes de qualquer chamada podem ser revertidas quando esta retorna.

Para entender melhor cada nível, iremos percorrer os seguintes casos de uso chave para demonstrar o poder de cada nível, bem como as implicações para os utilizadores, programadores, rollups e pesquisadores de MEV.

Exemplos ilustrativos:

1. Transferência do Mesmo Token
   → Enviar para si próprio: Trocar Eth por Eth ou ERC-20 por ERC-20 entre dois rollups
2. Compra de Tokens
   → Limite de ordem cruzada Rollup: Usando Eth/ERC-20 do Rollup A, compre um ERC-20 diferente de um DEX no Rollup B e (opcionalmente) envie de volta para o Rollup A

Implicações:

As seguintes perguntas serão respondidas também para entender melhor o impacto nos principais acionistas em qualquer ecossistema de rollup.

1. Experiência do Utilizador
   Como muda a experiência do utilizador ao atingir este nível de interoperabilidade?
2. Experiência do Desenvolvedor
   Como é que a experiência do programador muda ao atingir este nível de interoperabilidade?
3. Potencial de MEV
   Existe potencial para novas oportunidades de MEV se alcançarmos este nível de interoperabilidade?
4. Implicações de Rollup
   O rollup precisa optar por alguma nova infraestrutura para alcançar isso? Quais são as mudanças na estrutura de taxas para o rollup? Quais poderiam ser os benefícios potenciais para os rollups participarem dessa infraestrutura?

Visão Geral de Alto Nível

Visão geral das mudanças nos principais intervenientes

A Progressão de Seis Níveis em Direção à Interoperabilidade Sem Confiança

1. Assíncrono L1

Infraestrutura necessária:

N/A

Como definido, isso refere-se ao modo padrão atual de interoperabilidade sem confiança. Todos os rollups são definidos como tal porque são construídos em um L1 como uma camada de liquidação e têm acesso a esse L1 apenas através dos contratos de ponte onde periodicamente publicam atualizações de estado para garantir a rede.

A única forma canónica de realizar qualquer atividade sem confiança entre rollups neste caso é retirar ativos do rollup de origem através da ponte canónica e depositá-los manualmente no rollup de destino assim que estiverem disponíveis no L1.

Para rollups otimistas, esta latência de retirada é de cerca de 7 dias para dar conta da janela de prova de falhas. Num rollup ZK, a latência de retirada é menos certa, mas pode variar de 15 minutos a um dia inteiro, como é o caso do ZkSync.

Além disso, as trocas atômicas peer-to-peer usando contratos inteligentes são possíveis, mas este é um caso de uso menor e não escala efetivamente.

Vale a pena notar as soluções de terceiros que atualmente existem:

1. Ponte de liquidez
2. Frameworks de intenção

Ambos os nossos exemplos ilustrativos requerem soluções de terceiros para facilitar.

Enviar-para-si-mesmo:

1. Canonicamente:
   → Retirar ativos do Rollup A
   → Depositar manualmente em Rollup B
2. Terceiros:
   → Ponte de Liquidez / Redes Solver

Ordem de limite entre Rollups

1. Canonicamente:
   → Retirar ativos do Rollup A
   → Depositar manualmente no Rollup B
   → Executar ordem de limite
   Para enviar de volta, seria necessário envolver externamente o ERC-20 alvo
2. Terceiros
   → Espaço de solução nascente para ordens limitadas entre rollups
   → Existem designs abertos em torno do uso de intenções para facilitar isso

Como este é o caso padrão, não é necessário discutir alterações ao UX, DevEx, MEV e rollups.

2. Inclusão Atômica

Infraestrutura necessária

Sequenciador Compartilhado *

A inclusão atômica apenas garante que um pacote de transferência cruzada será incluído no próximo bloco.

Isto requer um sequenciador compartilhado, mas teoricamente pode ser alcançado sem um manualmente, se os sequenciadores em dois rollups dados não estiverem na capacidade máxima (poder-se-ia simplesmente submeter duas transações a cada rollup individualmente). É por isso que adicionamos um asterisco à infraestrutura necessária.

No entanto, não partimos do pressuposto de que o sequenciador partilhado está a executar um nó completo de cada um dos rollups ligados, e por isso não pode garantir a execução bem-sucedida de um conjunto de transações. O sequenciador partilhado neste caso apenas pode garantir que as transações estão bem formadas e que serão incluídas no próximo bloco, mas não necessariamente que serão executadas com sucesso.

Porque não existem garantias de execução, é impossível tirar proveito de forma programática da inclusão atômica de qualquer forma significativa sem correr o risco de uma das transações reverter. Como resultado, estamos essencialmente no mesmo caso exato que a interoperabilidade assíncrona da L1.

Considere iniciar uma troca simples de cross-rollup com apenas garantias de inclusão atômica:

1. Pacote de Troca Cruzada Rollup
   → Tx 1: Bloquear/Queimar tokens no rollup de origem
   → Tx 2: Criar tokens para o endereço do utilizador na rollup de destino

Podemos ter garantias de inclusão atômica de que ambas as transações estão de fato incluídas nos próximos blocos para cada rollup, mas se a primeira transação reverter e a segunda não, o usuário seria incorretamente alocado fundos na cadeia de destino sem tê-los bloqueado ou queimado na cadeia de origem e enfrentaríamos um problema de gastos duplos.

Qualquer solução de interoperabilidade, seja uma ponte de liquidez, uma estrutura de intenção ou um swap xERC-20, seria vulnerável a esse risco e é impossível mitigá-lo. Devido a esse risco, as soluções atuais exigem que a transação inicial tenha sido executada com êxito e incluída em um bloco na cadeia de origem antes de usar relayers para passar uma mensagem emitida e executar a segunda transação na cadeia de destino.

Importante ponto de atenção: A inclusão atômica não afeta significativamente o potencial de interoperabilidade

3. Liquidação Partilhada

Infraestrutura necessária:

Camada de agregação de prova // Contrato de ponte compartilhado

Aqui é onde as coisas começam a ficar mais interessantes. Como resultado do contrato de ponte compartilhado, toda a liquidez depositada no ecossistema de rollup do L1 pode ser movida livremente entre todos os rollups conectados. Até este ponto, não podíamos realizar trocas entre rollups sem passar por canais canônicos, envolver ativos externamente ou usar uma solução de terceiros.

Porquê construir um contrato de ponte partilhada? Para entender por que ter um contrato de ponte compartilhada nos permite mover ativos sem confiança entre rollups, primeiro considere o que aconteceria se fosse possível ter Eth no Rollup A, queimá-lo e cunha-lo nativamente no Rollup B sem um contrato de ponte compartilhado em L1.

Vemos que cada rollup ficaria fora de sincronia com seu contrato de ponte na mainnet. O contrato de ponte do rollup B ainda tem 50 Eth, então o usuário não seria capaz de sacar seu 1 Eth para o L1.

Para resolver isso, são construídos protocolos de envolvimento de ativos externos que emitem uma versão envolvida externamente de tokens através de rollups que simbolizam uma versão nativa em algum outro lugar na rede.

Com uma camada de liquidação compartilhada, a situação parece diferente. Porque toda a liquidez para cada rollup conectado está bloqueada no mesmo contrato de ponte, pode-se mover livremente entre rollups, uma vez que o montante total de valor no contrato de ponte permanece o mesmo e pode ser sempre retirado.

É necessário haver uma atualização ao nível do contrato L1 sobreonde a liquidez permite aos utilizadores levantar fundos de qualquer lugar, mas isto é trivial porque todos os rollups ligados podem ler/escrever no contrato partilhado.

Com uma camada de liquidação compartilhada, o fluxo pode parecer o seguinte para um caso simples de envio para si mesmo.

Enviar para si mesmo:

1. O utilizador cria a transação inicial:
   → Tx 1: retirar Eth no rollup A (com mensagem para cunhá-lo no rollup B)
   → A transação é agrupada e submetida ao contrato L1
   → É agregado na raiz da transação que agrupa todos os rollups de liquidação compartilhados
2. O Rollup B importa esta raiz de transação
3. O relayer envia a transação para cunhar juntamente com a Prova de Merkle para rollup B
4. Rollup B verifica a transação de queima usando a Prova de Merkle e a raiz da transação
5. O usuário é cunhado Eth em Rollup B
6. Rollup B submete prova ao L1

Podemos estender este fluxo para qualquer ERC-20 que tenha contratos em todos os rollups no ecossistema de liquidação partilhada.

Pode-se pensar num contrato de ponte partilhada como uma camada de mensagens in-protocolo entre todos os rollups ligados, pelo que teoricamente este fluxo pode ser estendido a qualquer padrão de mensagens arbitrário.

Isso nos aproxima da componibilidade, mas devido às etapas necessárias de agregação de provas e retransmissão de mensagens apenas após as mudanças de estado serem refletidas no L1, existem altas latências (embora notavelmente mais baixas do que no caso assíncrono do L1). Além disso, qualquer atividade complexa entre rollups como usar um DEX no rollup B começando com ativos no rollup A para uma ordem de limite entre rollups ainda seria um processo tedioso para o usuário, pois ainda teriam que enviar para si mesmos e trocar manualmente os ativos no rollup de destino. Não é possível criar pacotes atômicos entre rollups neste caso.

Outra vantagem importante com o acordo partilhado é que há menos fricção para os fornecedores de liquidez ou resolutores que estão a preencher ordens em múltiplos ambientes. Como a sua liquidez em todos os rollups conectados é refletida no mesmo contrato de ponte, eles não têm de esperar pela janela completa de levantamento para gerir a sua liquidez entre rollups.

Implicações para as partes interessadas:

1. Utilizadores:
   Agora é possível transferir ativos de forma nativa sem o período de saque L1
2. Desenvolvedores:
   As alterações são limitadas aos emissores de token que agora podem usar mensagens no protocolo para emitir versões nativas do ERC-20s em todos os pacotes cumulativos conectados
3. Pesquisadores de MEV:
   Como isso acontece em vários blocos para cada rollup, não há novo potencial de MEV
4. Rollups:
   Os Rollups terão de optar por usar um contrato de ponte partilhado e provavelmente adicionar pré-compilações para lidar com mensagens entre Rollups

Ponto importante: A liquidação compartilhada permite transferências de ativos não envolvidas externamente e mensagens arbitrárias em todos os rollups que compartilham o contrato de ponte e a camada de agregação de provas, mas ainda haverá latências não negligenciáveis (embora muito mais curtas do que L1 Async) e não se pode criar pacotes atômicos cruzados entre rollups.

4. Execução Atómica

Infraestrutura necessária:

Sequenciadores Compartilhados // Superconstrutores

A execução atômica permite-nos garantir a execução bem-sucedida de pacotes de transferência entre rollups, mas, como veremos, o número de casos de uso para pacotes de transferência entre rollups que não têm transações dependentes é menor do que se poderia esperar inicialmente.

Se uma única transação em um pacote de transações dependentes reverter, então todas as outras transações se tornam inválidas e também devem reverter, como é o caso da queima e cunhagem de tokens em rollups. A cunhagem de tokens em um rollup de destino depende deles terem sido queimados ou bloqueados no rollup de origem, então diríamos que um pacote de transações de queima e cunhagem é um pacote de transações dependentes.

Criar este pacote é impossível sem uma parte intermediária, como um super construtor que pode criar a transação de destino.

Considere o que teria de ser verdade para que os pacotes de troca entre rollups cruzados fossem construídos sem a necessidade de outra parte além do utilizador. Um pacote teria de ser criado para bloquear/queimar o ativo no rollup de origem e criar o ativo no rollup de destino, mas enfrentamos problemas:

1. Os contratos na rollup de origem só podem emitir uma mensagem ao bloquear/queimar o ativo de origem original, não podem chamar e criar uma transação na rollup de destino.
   → É por isso que existem protocolos de mensagens e redes de retransmissão.
   → A mensagem pode ser usada para estruturar o que a chamada no destino deve ser, mas não pode realmente criar a transação em si.
2. Criando a segunda transação no rollup de destino para cunhar:
   → O próprio utilizador não pode criar esta tx porque não tem direitos de cunhagem para o token no rollup B
   → Ou seja) A cadeia de destino precisa de uma prova de que os tokens foram queimados/trancados na cadeia de origem, mas essa prova não está disponível até depois que a transação inicial foi executada, o que quebraria nosso requisito de atomicidade.
   Qualquer outra parte que possa criar a segunda transação com direitos de cunhagem teoricamente poderia criar uma transação de "cunhagem" na cadeia de destino a qualquer momento sem primeiro criar uma transação de "queima" ou bloqueio na fonte, o que é uma vulnerabilidade massiva.

Podemos ver que, mesmo que possamos garantir a execução de pacotes cross-rollup, encontramos dificuldades em como poderíamos construí-los em primeiro lugar para transferir ativos de valor.

No entanto, ainda existem alguns casos de uso para execução atômica sem pacotes dependentes de transferência entre rollups. Um dos quais é a arbitragem entre rollups.

Arbitragem DEX Cross-Rollup com Execução Atômica

Porque não há dependências estritas entre essas transações, qualquer pessoa pode criar este pacote atômico e enviá-lo a um sequenciador compartilhado que garantirá a execução atômica.

No entanto, para ter garantias de execução atômica em primeiro lugar, os rollups devem optar por um sequenciador compartilhado e super construtor que executaria nós completos de todos os rollups conectados, para que o passo da execução atômica para a composabilidade ao nível do bloco seja bastante pequeno e todas as soluções de sequenciamento compartilhado farão isto. A única mudança necessária é que o construtor de bloco ou outra terceira parte deve ser capaz de criar transações em nome do usuário para completar pacotes dependentes entre rollups.

É improvável que a infraestrutura seja construída apenas permitindo a execução atômica sem avançar para ter composição. O ganho relativo de passar para a composição total ao nível do bloco supera em muito a dificuldade em alcançá-la, dado que a infraestrutura já tem execução atômica.

Implicações para as partes interessadas:

1. Utilizadores:
   Provavelmente não haverá mudanças, embora seja possível que soluções facilitadoras de terceiros, como intenções, possam ser atômicas, mas especificamente como não está claro
2. Desenvolvedores:
   Provavelmente sem alteração
3. Pesquisadores de MEV:
   A arbitragem através de rollups cruzados é muito mais segura dada a execução atómica
4. Rollups:
   Rollups devem optar por usar um sequenciador compartilhado / superconstrutores que enviam blocos com transações de cada rollup que deseja interoperar, o que pode alterar a estrutura de receitas do rollup. Ainda não está claro como isso irá mudar. \

• Os mercados de sequenciamento podem aumentar a receita para rollups ao permitir que o espaço ToB seja comprado por construtores sofisticados

Ponto importante: Embora os pacotes de transferência cruzada sejam garantidos para executar atomicamente, não está claro como esses pacotes serão construídos se não houver um superconstrutor que crie parte do pacote, portanto, é improvável que a execução atômica por si só afete a interoperabilidade. Sequenciadores/superconstrutores compartilhados devem, por padrão, construir em vez disso para a componibilidade ao nível do bloco.

5. Componibilidade ao nível do bloco

Infraestrutura necessária:

Sequenciador Compartilhado // Superconstrutor // Camada de agregação de prova// Contrato de ponte compartilhado

(* = opcional)

Na maior parte do discurso em torno de sequenciadores compartilhados e camadas de liquidação compartilhadas, o termo frequentemente usado para descrever esse nível de interoperabilidade é “componibilidade síncrona”.

Alterámos ligeiramente este termo para ser mais descritivo. A atualização da nomenclatura para Block-Level Composability implica que é possível compor entre dois rollups em um pacote de transações cross-rollup que serão incluídas e executadas com sucesso no próximo bloco. A capacidade de composição síncrona pode ser confundida com a capacidade de composição em nível de transação, que exploraremos na próxima seção. É importante ressaltar que isso requer uma parte intermediária (a infraestrutura de sequenciamento compartilhada) que possa ser o condutor e o criador de pacotes de transações dependentes.

Neste nível, começamos a ver a verdadeira compatibilidade entre rollups além de simplesmente enviar para si mesmo para participar de um dapp em outro rollup.

Com a adição de um sequenciador compartilhado que pode criar transações, agora somos capazes de fazer pacotes cruzados de rollup que os desenvolvedores podem aproveitar programaticamente.

Existem dois casos a considerar:

1. Componibilidade ao nível do bloco
2. Composição ao nível do bloco + camada de liquidação partilhada

Em ambos os casos, podemos criar pacotes de rollup cruzado para atividades mais complexas, mas no segundo caso, com liquidação compartilhada, podemos usar ativos nativos, o que poderia ter melhores implicações de preço para a atividade de DEX de rollup cruzado, por exemplo.

Com a composição ao nível do bloco, temos tanto as vantagens da execução atómica com a capacidade adicional de criar pacotes de transações dependentes. Vamos examinar os nossos dois exemplos ilustrativos.

Mesma transferência de token via xERC-20 (sem liquidação compartilhada):

1. Utilizador tem ERC-20
2. Utilizador cria tx via dapp:
   → Depositar ERC-20 na caixa de depósito xERC-20 para receber a versão embrulhada xERC-20
   → Queimar xERC-20
   Emitir uma mensagem indicando à infraestrutura de sequenciamento compartilhada que uma transferência entre rollups foi iniciada juntamente com os dados relevantes para facilitar a troca
3. O Superbuilder apanha a transação e cria um conjunto de rollup cruzado
   → Tx 1: A referida transação de envolvimento e queima
   → Tx 2: Criar xERC-20 no rollup B
4. O Superbuilder submete este cross-rollup ao sequenciador partilhado
   → Porque o superconstrutor está a executar um nó completo dos dois rollups conectados, eles simulam as transações para garantir a execução bem-sucedida do conjunto. Se uma das transações reverter, todo o conjunto é revertido.
5. O sequenciador compartilhado envia o bloco contendo ambas as transações para a camada DA, bem como para os nós que executam a mudança de estado
6. xERC-20 é cunhado para o usuário no Rollup B

Com uma camada de liquidação compartilhada, o fluxo é ainda mais simplificado porque não haveria necessidade de primeiro embrulhar o ERC-20 como um xERC-20 para trocar.

Vamos agora examinar a ordem de limite cruzado para comprar um ERC-20 no Rollup B com um ERC-20 inicial (diferente) do Rollup A e ter o ERC-20 resultante enviado de volta para o Rollup A. Neste caso, não assumimos que temos uma camada de liquidação compartilhada, embora um fluxo semelhante exista no caso com um. A única diferença é não precisar adicionalmente envolver ativos externamente.

Aqui estão as transações necessárias neste caso:

1. Embrulhe e queime o ERC-20 em uma caneta
2. Hortelã xERC-20 em B
3. Trocar xERC-20 inicial por ERC-20 alvo em B
4. Envolva e queime o alvo ERC-20 em B
5. Mint xERC-20 no A

Aqui está um possível fluxo de como isto poderia funcionar:

Ordem de Limite de Cross-Rollup em Ambiente de Composição de Nível de Bloco

Fluxo:

1. O utilizador inicia a primeira transação:
   → Envolver e Queimar xERC-20 com mensagem emitida para especificar os parâmetros de troca (cadeia de destino, endereço DEX, ERC-20 para trocar, preço do pedido de limite, booleano para enviar de volta ou não)
2. Superbuilder vê a transação e cria um pacote:
   → Tx 1: Utilizador cria tx descrita acima
   → Tx 2: Criar xERC-20 na destinatário (superbuilder deve ter privilégios de criação)
   → Tx 3: Ordem limitada usando dados da tx 1
   → Tx 4: Envolver e Queimar ERC-20 em B assumindo o cumprimento total na ordem de limite com mensagem para criar na cadeia de origem
   → Tx 5: Criar xERC-20 alvo a partir da saída da troca na cadeia de origem

Porque o superconstrutor cria o bloco e ordena as transações, pode simular cada transação e omitir o pacote se qualquer uma das transações for revertida. Por exemplo, se for descoberto que o usuário não receberia o cumprimento completo do seu pedido de limite, o pacote seria omitido antes de o bloco ser executado.

Neste caso de infraestrutura de sequenciamento partilhada sem uma camada de compensação partilhada, uma versão externa de Eth e xERC-20 teria de ser usada, o que poderia resultar em condições de mercado piores na DEX devido a pools de liquidez mais finas para ativos envoltos. Neste caso, um utilizador pode ter de utilizar um limite mais suave com mais deslizamento tolerado e poderia receber preços subótimos. Uma exceção a isto é se o USDC estiver envolvido. É possível que um sequenciador partilhado sem compensação partilhada possa trabalhar com a Circle para obter direitos exclusivos nos contratos USDC em todos os rollups para facilitar transferências nativas de USDC e swaps entre rollups.

Com uma camada de liquidação compartilhada, este embrulho externo não é necessário, e provavelmente proporcionaria melhores preços devido a pools de liquidez mais profundas para trocas de ativos nativos, mas o fluxo é essencialmente o mesmo.

Sequenciador Confiantemente Otimista

Os Rollups teriam de confiar otimisticamente no sequenciador/superconstrutor partilhado para criar lotes cross-rollup válidos. Isto deve-se principalmente ao facto de que este lote cross-rollup contém transações dependentes que os rollups individuais não podem verificar até depois de o bloco ser adicionado à cadeia de cada rollup e agregado a uma camada de liquidação no L1. Um exemplo é a queima inicial e a emissão de Eth da origem para o destino. É crucial que o Eth seja efetivamente queimado na cadeia de origem antes de ser emitido na cadeia de destino, caso contrário, gastos duplos são possíveis.

No entanto, para que este pacote completo seja executado num bloco, todas as transações devem estar presentes nesse bloco, mesmo que a transação represente um estado inválido antes do próprio bloco (como ter Eth na cadeia de destino para a troca se o usuário não tiver nenhum antes do bloco). Por essa razão, devemos confiar no sequenciador de que ele realmente incluiu as dependências válidas no pacote de interligação entre rollups. Poderíamos enviar provas posteriormente para comprovar a validade de cada transação.

Isso é ligeiramente menos importante ao usar ativos envolvidos, no entanto, porque eles não têm impacto na liquidez nativa armazenada no L1, mas os mecanismos de fallback ainda devem estar em vigor para combater o risco de um sequenciador malicioso ou um bug no código que permitiu que um pacote de transações fosse executado com uma transação dependente que foi revertida.

Implicações para as partes interessadas:

1. Utilizadores
   Atualizações massivas para a UX ao permitir ordens limite entre rollups em um único bloco
2. Desenvolvedores
   Seria necessário estar ciente da interoperabilidade entre rollups para a atividade entre rollups, provavelmente aproveitando pré-cálculos personalizados. Em vez de apenas transações, os desenvolvedores têm que pensar em termos de pacotes, mas é provável que os superconstrutores e a infraestrutura de rollup personalizada possam abstrair a maior parte da complexidade do desenvolvedor.
3. Pesquisadores de MEV
   Os pesquisadores de MEV têm essencialmente a mesma oportunidade de usar estratégias L1 em pacotes cross-rollup, mas isso depende de como o PBS (Separação de Propositor-Construtor) é implementado.
   → Os bundles cross-rollup são essencialmente vistos como uma única transação, então MEV poderia ser encontrado através de front-running ou sandwiching desses bundles, desde que não movam os preços fora dos montantes de slippage tolerados (porque então todo o bundle seria revertido e as tentativas de MEV falhariam)
4. Rollups
   Precisaria de optar pela infraestrutura de sequenciamento partilhada (incluindo superconstrutores), bem como permitir o acesso à queima/criação de Eth ao sequenciador partilhado no caso de uma camada de liquidação partilhada.
   → Poderia internalizar MEV ao vender espaço de bloco para construtores

6. Componibilidade ao nível da transação

Infraestrutura necessária:

Alterações ao nível da VM // Liquidação Partilhada // Superconstrutores

A composabilidade ao nível da transação refere-se ao mesmo nível de funcionalidade que os contratos inteligentes em uma cadeia EVM compartilham. Neste caso, uma única transação poderia atualizar o estado em vários rollups simultaneamente e garantir que quaisquer mudanças de estado anteriores a qualquer chamada possam ser revertidas se a chamada não retornar com sucesso. Na prática, um pacote atômico de transações em um ambiente componível ao nível do bloco pode ser feito dentro de uma única transação cruzada entre rollups e VMs. Isso requer alterações ao nível do VM para todos os rollups conectados, além de uma camada de liquidação compartilhada e um superconstrutor.

Descrevemos aqui um possível mecanismo a um nível elevado. (Esta construção é devida à equipa Espresso, segundo o nosso conhecimento). Primeiro, um utilizador envia uma transação cruzada para todos os rollups cujo estado é alterado pela transação ou a um superconstrutor que pode construir blocos em todos os rollups envolvidos. Um superconstrutor simula a transação e forma listas de pares de entrada-saída, uma para cada rollup envolvido, que especificam as mensagens cruzadas necessárias e esperadas dentro da transação. (Note-se que o superconstrutor só pode fazê-lo se tiver direitos de sequenciação seguros para todos os rollups envolvidos por um período de tempo). O superconstrutor envia então o bloco simulado ao proponente de cada rollup, juntamente com as listas de pares de entrada-saída esperados para cada transação cruzada. Durante a execução, cada rollup executa a sua própria função de transição de estado como normal, assumindo que as entradas da lista de transações cruzadas estão corretas. Durante o processo de liquidação, as listas de entrada-saída podem então ser comparadas entre si e provadas como seguras durante a fase de agregação de provas na camada de liquidação partilhada. Especificamente, se alguma entrada esperada para uma transação cruzada não corresponder ao que outro rollup especificou como saída, o processo de liquidação irá rejeitar a transação cruzada inteira.

Embora haja funcionalidades limitadas desbloqueadas com componibilidade ao nível da transação para além de empréstimos instantâneos, a experiência do desenvolvedor para criar aplicações cross-rollup pode ser grandemente melhorada. A capacidade de criar dapps que interagem com todas as cadeias conectadas sem raciocinar sobre os bundles cross-rollup tornará muito mais fácil inovar num panorama multi-rollup. Além disso, é possível que novos casos de uso e comportamentos surjam como resultado.

Existem muitas questões de design abertas para a composabilidade ao nível da transação. Por um lado, como os desenvolvedores podem optar por participar ou não de chamadas entre rollups para atender às necessidades de seus contratos inteligentes precisa ser cuidadosamente considerado. Permitir composabilidade arbitrária sem restrições significa que regredimos para um rollup monolítico. Acreditamos que a resposta aqui é os desenvolvedores indicarem explicitamente onde a composabilidade entre rollups é necessária em seus contratos, por exemplo, através de um modificador Solidity comocomponívelque marca certos pontos de entrada do contrato como rollup intercambiável.

Implicações para as partes interessadas

1. Utilizadores:
   Mesmas implicações que a composabilidade ao nível de bloco com capacidades avançadas adicionais como empréstimos instantâneos \
   → A experiência do utilizador é virtualmente idêntica à utilização de uma cadeia para dapps que optaram por participar
2. Devs:
   A experiência do desenvolvedor melhora consideravelmente, pois os desenvolvedores de dapps podem chamar nativamente contratos entre rollups e usar saídas dessas chamadas como chamadas de rollup único
   → A infraestrutura Superbuilder/Sequencer ainda terá que colocar a transação em blocos para os rollups que a chamada entre rollups cruzados afeta, mas não terá que construir os mesmos pacotes como no caso da composabilidade ao nível do bloco.
3. Pesquisadores de MEV:
   Alto potencial de MEV, uma vez que os pacotes de transferência entre rollups são agora essencialmente equivalentes a transações únicas numa cadeia
4. Rollups:
   Requereria alterações ao nível da VM, bem como adesão a um sequenciador partilhado e camada de liquidação partilhada \
   → Assunções de confiança adicionais envolvidas em ter que confiar nas entradas e saídas de outros rollups antes de poder verificar o estado via provas, mas mecanismos de corte poderiam reduzir o fardo de confiança

Resumo e Mapa do Ecossistema

Depois de percorrer os detalhes técnicos de cada nível de interoperabilidade definido aqui, podemos resumir:

1. O Acordo Compartilhado permite trocas entre rollups sem a necessidade de envolver ativos externamente e cria caminhos de mensagens no protocolo entre todos os rollups conectados
2. Os Sequenciadores Compartilhados/Superconstrutores permitem garantias de execução do próximo bloco em pacotes cross-rollup
3. A Composabilidade ao Nível do Bloco permite a criação de pacotes dependentes complexos e rápidos entre rollups cruzados, alcançando um ecossistema componível próximo do nível de contrato inteligente para contrato inteligente.
   Com a adição de compensação compartilhada, esses pacotes de cross-rollup podem ser criados sem usar ativos externamente envolvidos
4. A Componibilidade ao Nível das Transações é possível, e embora os novos casos de uso abertos possam ser para utilizadores mais sofisticados, tem o potencial para atualizar massivamente a experiência de desenvolvimento entre rollups.

Neste momento, existem muitos projetos emergentes para criar esses ecossistemas nativamente interoperáveis. Aqui está uma visão geral de alto nível do cenário:

Mapa do Ecossistema

Mapa do Ecossistema

Pensamentos finais

Ainda existem questões em aberto sobre os pormenores técnicos dentro dos frameworks apresentados neste artigo. Por exemplo, a construção de bundles num ecossistema componível a nível de bloco para ordens de limite entre rollups pode ter designs mais detalhados para lidar com o caso de cumprimento parcial e tolerância ao deslizamento para ordens de mercado. Aqui oferecemos uma solução potencial para reverter um bundle de ordem de limite entre rollups se a ordem não estiver completamente preenchida, mas o espaço de design está aberto.

Além disso, vale a pena relacionar isso com a atualmente crescente atenção no espaço sobre as appchains. As appchains são L2s de cauda longa que são generalizadas ou com permissão com o objetivo de isolar protocolos específicos relacionados em um L2. É provável que, quando alcançarmos a componibilidade ao nível do bloco, também começaremos a ver ambientes de appchain ganhando significativa tração como resultado de ter componibilidade nativa entre todas as redes conectadas.

Neste momento, ainda é difícil criar liquidez para estas appchains, mas uma vez que uma cadeia maior se conecta como uma rampa de acesso ao ambiente interoperável, é provável que vejamos ecossistemas de jardins murados em torno da infraestrutura compartilhada.

Outra questão importante em aberto é como o espaço de design em torno dos superconstrutores se resolverá. O desenvolvimento neste sentido ainda é bastante incipiente e ainda não está claro qual será a forma mais eficiente e eficaz de criar uma rede de construtores sofisticados que possam criar pacotes de interligação entre rollups. Onde esses pacotes de interligação entre rollups serão incluídos de forma ideal num bloco, e o impacto na receita de rollup é uma questão em aberto, com diferentes estratégias sendo exploradas por muitas equipas.

No final, o futuro provavelmente envolverá uma combinação de soluções de interligação em protocolo e fora de protocolo, e elas trabalharão em conjunto para proporcionar um processo de interoperabilidade muito melhor para todos. Acreditamos que a progressão definida neste artigo pode servir como um guia para os desenvolvedores e construtores que estão focados em tornar a interoperabilidade entre rollups mais harmoniosa para os usuários finais.

Também é provável que existam paradigmas completamente novos para a interação entre rollups que ainda não foram descobertos. Se é um construtor a trabalhar em abordagens que expandem sobre os tópicos aqui ou não estão cobertos acima, por favoralcançar(as mensagens diretas estão abertas). A tecnologia finalmente amadureceu o suficiente para exercer uma pressão real na busca de soluções para a fragmentação da liquidez/ecossistema, e estamos sempre à procura de nos conectarmos com fundadores que estão arriscando para construir soluções criativas.

Agradecimentos

Este artigo cresceu a partir de uma discussão de mesa redonda de interoperabilidade rollup incrivelmente esclarecedora realizada por 1kx no EthCC. Um agradecimento especial vai paraNoah Pravecek, Ellie Davidson, e Terrypara ler as primeiras versões deste artigo e fornecer feedback, assim como paraMarti, mteam, e Bo Dupara mais conversas sobre o assunto.

Aviso legal：

1. Este artigo é reproduzido a partir de [espelho], Encaminhe o Título Original 'Interoperabilidade Sem confiança entre Rollups: Paisagem, Construções e Desafios', Todos os direitos autorais pertencem ao autor original [Marshall Vyletel Jr.]. Se houver objeções a esta reimpressão, entre em contato com oPortão Aprenderequipa e eles tratarão disso prontamente.

2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.