Introdução

Houve uma explosão cambriana de rollups no Ethereum. No momento da redação, há 91 L2 & L3s ao vivo e 82 próximos de acordo com L2Beat. Como resultado, também há uma quantidade significativa de fragmentação em termos de liquidez, experiência do usuário e ferramentas de desenvolvimento. As soluções atuais de interoperabilidade deixam muito a desejar, pois dependem de uma combinação de pontes de terceiros, ativos envolvidos externamente 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 criptomoeda (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 ponteáveis de forma canônica e apenas $3b em ativos envolvidos externamente, de acordo comL2Beat)
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 Degenperder >80% dos tokensdevido à ponte oficial não ser canônica) a. Estruturas de intenção centralizadas também significam menor competição e isso poderia levar a preços e desempenho subótimos

Neste artigo, analisamos a paisagem de interoperabilidade sem confiança definindo e discutindo seis níveis de soluções de interoperabilidade entre ecossistemas de rollup fragmentados.

Começamos com o caso padrão de retirar de forma assíncrona do rollup de origem para L1 e fazer a ponte manualmente para o rollup de destino, e terminamos com uma arquitetura hipotética para a composabilidade entre rollups em 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 escopo do Ethereum e suas L2s para este artigo e focamos exclusivamente na interoperabilidade sem confiança. Neste caso, “interoperabilidade sem confiança” refere-se a canais em protocolo que não exigem terceiros para facilitar transferências fora da infraestrutura necessária que a maioria dos rollups já requer.

Preliminares

Definições

Fundamentalmente, a interoperabilidade sem confiança requer algum recurso compartilhado ao qual quaisquer dois protocolos que desejem interoperar devem ter acesso. No caso do Ethereum L1, todos os contratos inteligentes vivem no mesmo ambiente, compartilhando o estado completo do Ethereum, portanto, 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 por natureza.

1. Sequenciadores Compartilhados/Superconstrutores: Principalmente atualizações de velocidade e experiência do usuário.
2. Partilha de Liquidação: Trocas de ativos sem envolvimento externo, bem como mensagens no protocolo.

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

1. L1 Assíncrono:
   → Interoperabilidade via transferência manual de ativos através do L1 que as rollups liquidam.
2. Inclusão Atômica:
   → Uma garantia de que todas as transações em um pacote cross-rollup serão incluídas no próximo bloco para cada rollup envolvido no pacote, ou nenhuma será.
3. Assentamento Compartilhado:
   → Múltiplos rollups conectando-se à 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. Componibilidade ao nível do bloco:
   → Próximo bloco garante nos pacotes de cruzamento de rollup que podem conter transações dependentes (tx B no rollup B é dependente do resultado da tx A no rollup A)
6. Componibilidade de Nível Tx:
   → Interoperabilidade ao nível do contrato inteligente que requer apenas uma transação capaz de causar alterações de estado em vários rollups simultaneamente (sem pacotes). Utilizar qualquer protocolo em qualquer rollup é logicamente equivalente a usar diferentes contratos inteligentes em uma única cadeia. Importante ressaltar que isso implica que as alterações de estado anteriores a qualquer chamada podem ser revertidas quando ela retorna.

Para entender cada nível mais a fundo, vamos percorrer os seguintes casos de uso principais para demonstrar o poder de cada nível, bem como as implicações para usuários, desenvolvedores, rollups e pesquisadores de MEV.

Exemplos ilustrativos:

1. Transferência do Mesmo Token
   → Enviar para si mesmo: Trocar Eth por Eth ou ERC-20 por ERC-20 em dois rollups
2. Compra de Tokens
   → Limite de Ordem Cross-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 também serão respondidas para entender melhor o impacto nos principais acionistas em qualquer ecossistema de rollup.

1. Experiência do usuário
   Como a experiência do usuário muda ao atingir esse nível de interoperabilidade?
2. Experiência do desenvolvedor
   Como a experiência do desenvolvedor muda ao atingir esse nível de Interoperabilidade?
3. Potencial de MEV
   Existe potencial para novas oportunidades de MEV se alcançarmos esse nível de interoperabilidade?
4. Implicações do Rollup
   O rollup precisa aderir a alguma nova infraestrutura para alcançar isso? Quais são as mudanças nas estruturas de taxas para o rollup? Quais poderiam ser os benefícios potenciais para os rollups participarem desta infraestrutura?

Visão Geral de Alto Nível

Visão geral das mudanças para as principais partes interessadas

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

1. L1 Assíncrono

Infraestrutura necessária:

N/A

Conforme definido, isso se refere 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 camada de liquidação e têm acesso a esse L1 apenas por meio dos contratos de ponte, onde eles postam periodicamente atualizações de estado para garantir a rede.

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

Para rollups otimistas, essa latência de saque é de cerca de 7 dias para considerar a janela de prova de falhas. Em um ZK rollup, a latência de saque é menos certa, mas pode variar de 15 minutos a um dia inteiro, como é o caso do ZkSync.

Além disso, 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 ressaltar 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 no Rollup B
2. Terceiro:
   → Ponte de Liquidez / Redes Solver

Ordem Limitada Cruzada-Rollup

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

Como este é o caso padrão, é desnecessário discutir alterações no 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 inter-rollup será incluído no próximo bloco.

Isso 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 (alguém poderia simplesmente enviar duas transações para cada rollup individualmente). É por isso que adicionamos um asterisco à infraestrutura necessária.

No entanto, não assumimos que o sequenciador compartilhado esteja executando um nó completo de cada um dos pacotes cumulativos conectados e, portanto, não podemos garantir a execução bem-sucedida de um pacote de transações. O sequenciador compartilhado, nesse caso, só pode garantir que as transações sejam bem formadas e que sejam incluídas no próximo bloco, mas não necessariamente que serão executadas com sucesso.

Porque não há garantias de execução, é impossível aproveitar programaticamente a inclusão atômica de 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 L1.

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

1. Pacote de troca de rollup cruzado
   → Tx 1: Bloquear/Queimar tokens na rollup de origem
   → Tx 2: Emitir tokens para o endereço do usuário na rollup de destino

Podemos ter garantias de inclusão atômica de que ambas as transações sã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 alocado incorretamente fundos na cadeia de destino sem tê-los bloqueado ou queimado na cadeia de origem e encontraríamos um problema de gastos duplos.

Qualquer solução de interoperabilidade, seja uma ponte de liquidez, um framework de intenção ou uma troca xERC-20, estaria vulnerável a esse risco e é impossível mitigá-lo. Devido a esse risco, as soluções atuais exigem que a transação iniciadora tenha sido executada com sucesso 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: A inclusão atômica não impacta significativamente o potencial de interoperabilidade

3. Liquidação Compartilhada

Infraestrutura necessária:

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

Aqui é onde as coisas começam a ficar mais interessantes. Como resultado do contrato de ponte compartilhada, toda a liquidez depositada no ecossistema de rollup do L1 pode ser movimentada 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.

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

Vemos que cada rollup sairia 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 externamente envolta de tokens em vários rollups que simbolizam uma versão nativa em 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á travada no mesmo contrato de ponte, alguém pode se mover livremente entre rollups, já que o valor total no contrato de ponte permanece o mesmo e sempre pode ser retirado.

Há a necessidade de uma atualização no nível do contrato L1 sobreonde a liquidez é permitir que os usuários saquem de qualquer lugar, mas isso é trivial porque todos os rollups conectados podem ler/escrever no contrato compartilhado.

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

Enviar para si mesmo:

1. O usuário cria a transação inicial:
   → Tx 1: retirar Eth no rollup A (com mensagem para criar no rollup B)
   → A transação é agrupada e enviada para o contrato L1
   → É agregado na raiz da transação que agrupa todos os rollups de liquidação compartilhados
2. O Rollup B importa essa raiz tx
3. Relayer envia transação para cunhar junto com a Prova de Merkle para rollup B
4. Rollup B verifica a transação de queima usando Prova de Merkle e raiz da transação
5. Usuário está cunhando Eth em Rollup B
6. Rollup B envia prova para L1

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

Pode-se pensar em um contrato de ponte compartilhada como uma camada de mensagens em protocolo entre todos os rollups conectados, então teoricamente esse fluxo pode ser estendido a qualquer padrão de mensagens arbitrário.

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

Outro benefício importante com o ajuste compartilhado é que há menos atrito para provedores de liquidez ou solvers que estão preenchendo pedidos em vários ambientes. Como sua liquidez em todos os rollups conectados é refletida no mesmo contrato de ponte, eles não precisam esperar a janela completa de saque para gerenciar sua liquidez entre rollups.

Implicações para as partes interessadas:

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

Ponto importante: O acordo compartilhado permite transferências de ativos não envolvidos externamente e mensagens arbitrárias em todos os rollups que compartilham o contrato de ponte e a camada de agregação de prova, mas ainda haverá latências não negligenciáveis (embora muito mais curtas do que L1 Async) e não é possível criar pacotes atômicos entre rollups.

4. Execução Atômica

Infraestrutura necessária:

Sequenciadores Compartilhados // Superconstrutores

A execução atômica nos permite garantir a execução bem-sucedida de pacotes cruzados, mas, como veremos, o número de casos de uso para pacotes cruzados 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 for revertida, então todas as outras transações se tornam inválidas e também devem ser revertidas, 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 poderíamos dizer 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 superconstrutor que pode criar a transação de destino.

Considere o que teria que ser verdade para que os pacotes de troca entre rollups cruzados fossem construídos sem a necessidade de outra parte além do usuário. Um pacote teria que ser criado para travar / queimar o ativo no rollup de origem e cunhar o ativo no rollup de destino, mas nos deparamos com 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 usuário não pode criar esta tx porque não possui 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/travados 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 ter primeiro criado uma transação de "queima" ou bloqueio na fonte, o que é uma vulnerabilidade massiva.

Podemos ver que, mesmo que pudéssemos garantir a execução de pacotes cruzados de 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 cross-rollup. Um dos quais é a arbitragem cross-rollup:

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

Porque não há dependências estritas entre essas transações, qualquer um pode criar este pacote atômico e enviá-lo para 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 superconstrutor que executaria nós completos de todos os rollups conectados, então o passo da execução atômica para a composabilidade em nível de bloco é bastante pequeno e todas as soluções de sequenciamento compartilhado farão isso. A única mudança necessária é que o construtor de bloco ou outro terceiro deve ser capaz de criar transações em nome do usuário para completar os pacotes dependentes entre rollups.

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

Implicações para as partes interessadas:

1. Usuários:
   Provavelmente nenhuma mudança, embora seja possível que terceiros facilitem soluções como intenções podem ser atômicas, mas especificamente como não está claro
2. Desenvolvedores:
   Provavelmente sem mudanças
3. MEV Searchers:
   A arbitragem de cross-rollup é muito mais segura, dada a execução atômica
4. Rollups:
   Rollups devem optar por usar um sequenciador compartilhado / superconstrutores enviando blocos com transações de cada rollup que deseja interoperar, o que pode alterar a estrutura de receita do rollup. Ainda não está claro como isso mudará.

• Os marketplaces de sequenciamento podem aumentar a receita para rollups, permitindo que o espaço ToB seja comprado por construtores sofisticados

Ponto importante: Embora os pacotes de rollup cruzados 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, então é improvável que a execução atômica por si só afete a interoperabilidade. Seqüenciadores/superconstrutores compartilhados devem, por padrão, construir em vez disso para composabilidade ao nível de bloco.

5. Componibilidade em Nível de Bloco

Infraestrutura necessária:

Sequenciador Compartilhado // Superconstrutor // Camada de agregação de provas// Contrato de ponte compartilhada

(* = opcional)

Em grande 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”.

Nós modificamos ligeiramente este termo para ser mais descritivo. Atualizar a nomenclatura para Componibilidade em Nível de Bloco implica que é possível compor entre dois rollups em um pacote de transações entre rollups que serão incluídas e executadas com sucesso no próximo bloco. A componibilidade síncrona pode ser confundida com a componibilidade em nível de transação, que exploramos na próxima seção. Importante ressaltar que isso requer uma parte intermediária (a infraestrutura de sequenciamento compartilhada) que pode ser o condutor e criador de pacotes de transações dependentes.

Neste nível, começamos a ver a verdadeira composição 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.

Há dois casos a considerar:

1. Componibilidade ao nível do bloco
2. Composição em Nível de Bloco + camada de liquidação compartilhada

Em ambos os casos, podemos criar pacotes inter-rollup 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 atividades inter-rollup DEX, por exemplo.

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

Transferência do Mesmo Token via xERC-20 (Sem Liquidação Compartilhada):

1. Usuário tem ERC-20
2. O usuário cria tx via dapp:
   → Deposite ERC-20 na caixa de depósito xERC-20 para receber a versão envelopada xERC-20
   → Queimar xERC-20
   → Emita uma mensagem sinalizando para a infraestrutura de sequenciamento compartilhada que uma transferência entre rollups foi iniciada juntamente com dados relevantes para facilitar a troca
3. O Superbuilder pega a transação e cria um pacote de interligação entre rollups
   → Tx 1: A transação de embrulhar e queimar mencionada acima
   → Tx 2: Mint xERC-20 no rollup B
4. O Superbuilder submete este cross-rollup ao sequenciador compartilhado
   → Porque o superconstrutor está executando um nó completo dos dois rollups conectados, eles simulam as transações para garantir a execução bem-sucedida do pacote. Se uma das transações reverter, o pacote inteiro é 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 o limite de ordem cruzada para comprar um ERC-20 no Rollup B com um ERC-20 inicial (diferente) do Rollup A e fazer com que o ERC-20 resultante seja 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 uma. A única diferença é não ter que envolver ativos externamente adicionalmente.

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

1. Embrulhar e Queimar ERC-20 em A
2. Mint xERC-20 em B
3. Troque inicial xERC-20 com ERC-20 de destino em B
4. Enrole e queime ERC-20 alvo em B
5. Mint xERC-20 em A

Aqui está um fluxo potencial de como isso poderia funcionar:

Ordem limitada Cross-Rollup em ambiente componível de nível de bloco

Fluxo:

1. Usuário inicia a primeira transação:
   → Envolver e Queimar xERC-20 com mensagem emitida para especificar parâmetros de troca (cadeia de destino, endereço DEX, ERC-20 para trocar, preço de ordem limite, booleano para enviar de volta ou não)
2. Superbuilder vê a transação e cria o pacote:
   → Tx 1: Usuário cria tx descrita acima
   → Tx 2: Emitir xERC-20 no destino (o superconstrutor deve ter privilégios de emissão)
   → Tx 3: Ordem limite usando dados da tx 1
   → Tx 4: Envolva e Queime ERC-20 em B assumindo o cumprimento total da ordem de limite com mensagem para cunhar na cadeia de origem
   → Tx 5: Mint alvo xERC-20 a partir da saída da troca na cadeia de origem

Porque o superconstrutor cria o bloco e ordena transações, ele pode simular cada transação e omitir o pacote se alguma das transações reverter. Por exemplo, se for constatado que o usuário não receberia o cumprimento completo de sua ordem limite, o pacote seria omitido antes que o bloco seja executado.

Neste caso de infraestrutura de sequenciamento compartilhada sem uma camada de liquidação compartilhada, uma versão externamente envolvida de Eth e xERC-20 precisaria ser usada, o que poderia resultar em condições de mercado piores na DEX devido a pools de liquidez mais finas para ativos envolvidos. Neste caso, um usuário pode ter que usar um limite mais suave com mais derrapagem tolerada e poderia receber preços subótimos. Uma exceção a isso é se o USDC estiver envolvido. É possível que um sequenciador compartilhado sem liquidação compartilhada possa trabalhar com a Circle para obter direitos exclusivos sobre os contratos USDC em todos os rollups para facilitar transferências nativas de USDC e trocas entre rollups.

Com uma camada de liquidação compartilhada, essa embalagem externa não é necessária e provavelmente forneceria melhores preços devido a pools de liquidez mais profundos para trocas de ativos nativos, mas o fluxo é essencialmente o mesmo.

Sequenciador confiante otimista

As rollups precisariam confiar otimisticamente no sequenciador/superconstrutor compartilhado para criar pacotes válidos de cross-rollup. Isso se deve principalmente ao fato de que esse pacote de cross-rollup contém transações dependentes que os rollups individuais não podem verificar até após 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 criação de Eth de origem para destino. É crucial que o Eth seja realmente queimado na cadeia de origem antes de ser criado na cadeia de destino, caso contrário, gastos duplos são possíveis.

No entanto, para ter este pacote completo executado em um 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 esse motivo, devemos confiar no sequenciador de que ele realmente incluiu as dependências válidas no pacote de intercâmbio entre rolos. Poderíamos apresentar provas após o fato para provar a validade de cada transação.

Isso é ligeiramente menos importante ao usar ativos envoltos, no entanto, porque eles não têm impacto na liquidez nativa armazenada no L1, mas mecanismos de fallback ainda devem estar em vigor para contrariar 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. Usuários
   Atualizações maciças para a experiência do usuário ao permitir ordens de limite entre rollups em um único bloco
2. Desenvolvedores
   Precisaria estar ciente da interoperabilidade entre rollups para atividades entre rollups, provavelmente aproveitando precompiles personalizados. Em vez de apenas transações, os desenvolvedores precisam pensar em termos de pacotes, mas é provável que superconstrutores e infraestrutura rollup personalizada possam abstrair a maior parte da complexidade do desenvolvedor.
3. Buscadores de MEV
   Os buscadores de MEV têm essencialmente a mesma oportunidade de usar estratégias L1 em pacotes de rollup cruzado, mas depende de como o PBS (Separação de Propositor-Construtor) é implementado.
   → Os pacotes de rollup cruzado são essencialmente vistos como uma única transação, então o MEV pode ser encontrado por front-running ou sanduichando esses pacotes, desde que não movam os preços para fora dos montantes de deslize tolerados (porque então todo o pacote seria revertido e as tentativas de MEV falhariam)
4. Rollups
   Seria necessário optar por uma infraestrutura de sequenciamento compartilhada (incluindo superconstrutores), bem como permitir o acesso à queima/criação de Eth para o sequenciador compartilhado no caso de uma camada de liquidação compartilhada.
   Poderia internalizar o MEV vendendo espaço de bloco para construtores

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

Infraestrutura necessária:

Mudanças de nível VM // Liquidação compartilhada // 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 alterações 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 de rollup e VM. 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 um possível mecanismo aqui em um nível alto. (Esta construção é devido à equipe Espresso conforme nosso conhecimento). Primeiro, um usuário envia uma transação cruzada para todos os rollups cujo estado é alterado pela transação ou 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, um para cada rollup envolvido, que especificam as mensagens cruzadas necessárias e esperadas dentro da transação. (Observe que o superconstrutor só pode fazer isso se tiver direitos de sequenciamento seguros para todos os rollups envolvidos por um período de tempo). O superconstrutor então envia o bloco simulado ao proponente de cada rollup, juntamente com as listas de pares de entrada-saída esperados para cada transação cruzada de rollup. Durante a execução, cada rollup executa sua própria função de transição de estado normalmente, assumindo que as entradas da lista de transações cruzadas de rollup estão corretas. Durante a liquidação, as listas de entrada-saída podem então ser cruzadas comparadas e comprovadas como seguras durante a fase de agregação de provas na camada de liquidação compartilhada. Especificamente, se alguma entrada esperada para uma transação cruzada de rollup não corresponder ao que outro rollup especificou como saída, o processo de liquidação rejeitará toda a transação cruzada.

Embora haja funcionalidades limitadas desbloqueadas com composabilidade ao nível da transação além dos empréstimos instantâneos, a experiência do desenvolvedor para criar aplicativos entre rollups pode ser significativamente melhorada. A capacidade de criar dapps que interajam com todas as blockchains conectadas sem precisar pensar em pacotes entre rollups tornará muito mais fácil inovar em um cenário de vários rollups. Além disso, é possível que novos casos de uso e comportamentos surjam como resultado.

Existem muitas perguntas de design aberto para composabilidade no nível de transação. Por exemplo, 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 como componívelque marca certos pontos de entrada do contrato como cross rollup acionável.

Implicações para as partes interessadas

1. Usuários:
   Mesmas implicações que a composabilidade em nível de bloco com capacidades avançadas adicionais como empréstimos relâmpago
   → A experiência do usuário é virtualmente idêntica ao uso de uma cadeia para dapps que optam por participar
2. Devs:
   A experiência do desenvolvedor melhora significativamente, pois os desenvolvedores de dapp podem chamar nativamente contratos entre rollups e usar os resultados dessas chamadas como chamadas únicas de rollup
   → A infraestrutura do Superbuilder/Sequencer ainda terá que colocar a transação em blocos para os rollups que a chamada entre rollups cruzados afeta, mas não precisará construir os mesmos pacotes como no caso da composabilidade ao nível do bloco.
3. Pesquisadores de MEV:
   Alto potencial de MEV, já que pacotes cross-rollup são essencialmente equivalentes a transações únicas em uma única cadeia agora
4. Rollups:
   Exigiria mudanças no nível de VM, bem como adesão a um sequenciador compartilhado e camada de liquidação compartilhada \
   → 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 por meio de provas, mas os mecanismos de corte poderiam reduzir o ônus da 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 embrulhar 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 de transferência entre rollups
3. A Composição ao Nível de Bloco permite a criação de pacotes complexos, rápidos e dependentes entre rollups cruzados, alcançando um ecossistema componível quase ao nível de contratos inteligentes para contratos inteligentes.
   → Com a adição de liquidação compartilhada, esses pacotes cruzados de rollup podem ser criados sem usar ativos externamente envolvidos
4. A Composabilidade em Nível de Transação é possível, e embora os novos casos de uso abertos possam ser para usuários mais sofisticados, ela tem o potencial de atualizar massivamente a experiência de desenvolvimento entre rollups.

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

Mapa do ecossistema

Mapa do ecossistema

Considerações finais

Ainda existem questões em aberto sobre as nuances técnicas dentro dos frameworks delineados neste artigo. Por exemplo, a construção de bundles em um ecossistema componível em nível de bloco para ordens de limite cruzado entre rollups pode ter designs mais detalhados para lidar com o caso de cumprimento parcial e tolerância ao deslizamento para ordens de mercado. Oferecemos uma solução potencial aqui para reverter um pacote de ordens de limite cruzado entre rollups se a ordem não for completamente preenchida, mas o espaço de design está aberto.

Além disso, vale a pena relacionar isso com a atual conscientização crescente no espaço sobre as appchains. As appchains são L2 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 composabilidade ao nível do bloco, também começaremos a ver ambientes de appchain ganhando significativa tração como resultado de ter composabilidade nativa entre todas as redes conectadas.

No momento atual, ainda é difícil gerar liquidez para essas 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 de infraestruturas compartilhadas.

Outra questão aberta importante é como o espaço de design em torno dos superconstrutores se resolverá. O desenvolvimento nesta frente ainda é bastante incipiente e ainda não está claro qual será a maneira mais eficiente e eficaz de criar uma rede de construtores sofisticados que possam criar pacotes de interconexão de rollup. Onde esses pacotes de interconexão de rollup serão incluídos de forma ideal em um bloco, e o impacto na receita do rollup é uma questão aberta com diferentes estratégias sendo exploradas por muitas equipes.

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

Também é provável que existam paradigmas completamente novos para interação entre rollups que ainda não foram descobertos. Se você é um construtor trabalhando em abordagens que expandem os tópicos aqui ou não estão cobertos acima, por favor alcançar(dms are open). A tecnologia finalmente amadureceu o suficiente para exercer uma pressão real na busca por soluções para a fragmentação da liquidez/ecossistema, e estamos sempre procurando nos conectar com fundadores que estão assumindo riscos para construir soluções criativas.

Agradecimentos

Este artigo surgiu de uma discussão incrivelmente esclarecedora sobre interoperabilidade de rollup realizada por 1kx na EthCC. Um agradecimento especial vai paraNoah Pravecek, Ellie Davidson, e Terrypara ler as primeiras versões deste artigo e fornecer feedback, bem como paraMarti, mteam, e Bo Dupara conversas adicionais sobre o assunto.

Aviso legal：

1. Este artigo é reproduzido a partir de [espelhoEncaminhe 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 essa reimpressão, entre em contato com oGate Aprenderequipe e eles vão lidar com isso prontamente.

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

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.