Composição síncrona entre rollups por meio de prova em tempo real – Camada 2

1. Rollups baseados e provas em tempo real

Um rollup baseado é um rollup onde qualquer pessoa pode propor um novo bloco, não há sequenciador privilegiado. Qualquer participante pode pegar o estado atual do rollup, aplicar um conjunto de transações e produzir um novo bloco.

Uma vantagem chave de design surge quando exigimos que a carga útil de disponibilidade de dados e a prova de validade sejam submetidas juntas, como uma única unidade atômica. Nos designs tradicionais de rollup, os dados são publicados primeiro e a prova vem depois, o que introduz uma lacuna que complica o design do incentivo: quem gera a prova? Quando? Como você garante que eles sejam compensados ​​de forma justa e rápida?

Ao publicar dados e provas simultaneamente, eliminamos totalmente essa lacuna. O proponente do bloco é responsável pela execução e prova. Se a prova for inválida ou ausente, o bloco simplesmente não existe. Isto simplifica dramaticamente o mecanismo de incentivo, o proponente do bloco é o provador e a sua recompensa vem da mesma fonte (por exemplo, taxas de transação) sem a necessidade de mercados de prova separados ou períodos de desafio.

Isto é possível graças prova em tempo real a capacidade de gerar provas de validade com rapidez suficiente para que possam ser produzidas junto com a construção do bloco, e não como uma reflexão tardia assíncrona.

A prova em tempo real está se tornando rapidamente prática. A partir de hoje, a prova de um bloco Ethereum completo requer cerca de 12 GPUs com um tempo médio de prova de aproximadamente 7 segundos. Ainda há uma margem significativa para melhorar e reduzir as latências, tanto por meio de melhorias de hardware quanto pela comprovação de otimizações do sistema, embora seja difícil prever exatamente onde estará o limite. A centralização do provador é uma preocupação válida: os requisitos de hardware não são triviais e nem todos os construtores de blocos terão acesso à mesma infraestrutura de prova. No entanto, a prova é inerentemente paralelizável e comoditizável, e a tendência é claramente para provas mais rápidas em hardware mais barato.

2. O que é composibilidade síncrona?

Composição síncrona significa que dentro de uma única transação, um contrato inteligente em uma cadeia (L1 ou rollup) pode CHAMAR um contrato inteligente em uma cadeia diferente (L1 ou outro rollup) e receber o resultado de volta no mesmo contexto de execução, como se ambos os contratos vivessem na mesma cadeia.

Hoje, as interações entre cadeias são assíncronas: você envia uma mensagem na cadeia A, espera que ela seja retransmitida para a cadeia B e, em seguida, processa o resultado separadamente. Isso quebra o modelo de composição que torna o ecossistema DeFi da Ethereum tão poderoso. Os protocolos não podem ser compostos atomicamente através dos limites de rollup.

A composição síncrona restaura isso. Do ponto de vista do desenvolvedor, chamar um contrato em outro rollup parece e se comporta exatamente como chamar um contrato na mesma cadeia. A transação é bem-sucedida atomicamente em todas as cadeias envolvidas ou é totalmente revertida.

3. O caso simples: composibilidade L2 para L2

Antes de abordar o problema mais difícil da interação L1↔L2, vale a pena notar que a composição entre rollups L2 por si só é relativamente simples.

Se estivermos lidando apenas com L2s, podemos agrupar a disponibilidade de dados para todos os rollups afetados em um único blob. O construtor de blocos constrói uma execução combinada que atinge vários estados de rollup, prova todos eles juntos e publica o resultado como um envio atômico de disponibilidade de dados. Como todas as transições de estado afetadas são comprovadas e postadas juntas, a composição ocorre naturalmente, ou todas as transições acontecem ou nenhuma delas acontece.

Esta observação é a base. O problema mais difícil é fazer isso funcionar quando os contratos inteligentes L1 fazem parte da interação.

4. Contratos inteligentes de proxy

O mecanismo principal que permite chamadas entre cadeias é o contrato inteligente de proxy. Um proxy é um contrato inteligente implantado em uma cadeia que representa um contrato inteligente que vive em uma cadeia diferente.

Quando um contrato em L1 deseja chamar um contrato no rollup R, ele não executa de alguma forma o código diretamente em R. Em vez disso, chama o proxy desse contrato R, que existe em L1. O contrato proxy encapsula a chamada entre cadeias: ele sabe qual é o contrato alvo, processa a chamada, aplica as alterações de estado correspondentes no rollup e retorna o resultado, tudo dentro da mesma execução da transação.

Do ponto de vista do chamador, a interação com o proxy é indistinguível da interação com o contrato real. O proxy é a interface local para um contrato remoto.

5. Modelo de interação L1 ↔ L2

Quando uma transação envolve contratos inteligentes L1 e L2, a execução segue um processo estruturado:

Etapa 1: garantir que existam contratos de procuração

Antes da execução, todos os contratos inteligentes de proxy para os contratos L2 que irão interagir com L1 devem ser implantados. Se um contrato no rollup R for chamado de L1, seu proxy já deverá existir em L1.

Etapa 2: construir e enviar a tabela de execução

Um mesa de execução é construído e armazenado temporariamente no estado L1. Esta tabela é uma sequência de entradas, onde cada entrada descreve uma ação e suas consequências. Cada entrada contém:

• Ação: Principalmente um CALL ou um RESULT.
• Um conjunto de transições de estado L2: quais rollups são afetados e de onde/para qual transição de suas raízes de estado.
• próxima ação: O que vem a seguir, um RESULTADO (com dados de retorno) ou outra CHAMADA (para um contrato inteligente L1 diferente).

A tabela captura o rastreamento completo das interações entre cadeias. Por exemplo, considere um cenário de chamada aninhada:

A (on L1) calls B (on Rollup 2)
  → B (on Rollup 2) calls C (on L1) 
    → C (on L1) returns  
  → B (on Rollup 2) returns
A (on L1) continues execution

Neste caso, a tabela de execução conteria duas entradas:

| # | Action                | L2 State Transitions          | nextAction          |  
|---|-----------------------|-------------------------------|---------------------|
| 1 | CALL B (on Rollup 2) -| Rup2: stateRoot₀ → stateRoot₁ | CALL C (on L1)      |
| 2 | RETURN from C (on L1) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A (on L1) |

A primeira entrada diz: “quando A chama B no Rollup 2, o rollup faz a transição de stateRoot₀ para stateRoot₁, e a próxima coisa que precisa acontecer é uma chamada para C em L1.” A segunda entrada diz: “depois que C retorna, o Rollup 2 faz a transição de stateRoot₁ para stateRoot₂ e o resultado final é retornado para A.”

A tabela de execução codifica toda essa sequência de chamada/retorno, juntamente com todas as transições de estado de rollup que ocorrem em cada etapa. Crucialmente, a mesa é acompanhada por uma única prova de validade que garante a correção de cada etapa de execução da tabela. Esta prova é verificada uma vez quando a tabela é submetida.

Etapa 3: Execução L1 com resolução de proxy

Agora as transações L1 são executadas normalmente. Quando a execução atinge um ponto em que um contrato L1 chama um contrato proxy, o proxy faz o seguinte:

1. Procura o correspondente CALL ação na tabela de execução.
2. Verifica e aplica as alterações de raiz de estado para os rollups afetados.
3. Se houver chamadas L1 aninhadas na sequência, executa-as.
4. Remove as entradas consumidas da tabela de execução (para evitar o desperdício de armazenamento L1).
5. Retorna o RESULT ao contrato L1 de chamada.

Do ponto de vista do ambiente de execução L1, a chamada aconteceu normalmente e retornou um resultado. A complexidade da interação entre cadeias é totalmente abstraída pelo proxy e pela tabela de execução.

Etapa 4: transações iniciadas por L2

Uma transação originada em L2 que interage com L1 segue o mesmo modelo, mas a primeira ação na tabela de execução é uma L2TX em vez de um CALL. A transação L2 inicia a execução e quaisquer chamadas para contratos L1 tornam-se entradas aninhadas na tabela, resolvidas da mesma maneira.

Etapa 5: Tratamento de reversões

Duas ações especiais: REVERT e REVERT_CONTINUE lidar com reversões através dos limites da cadeia de uma forma que espelhe como as reversões funcionam dentro de uma única cadeia.

Quando ocorre uma reversão durante a execução em L2, um REVERT a ação é enviada para L1. L1 então processa a reversão desfazendo quaisquer chamadas L1 aninhadas que faziam parte do caminho de execução revertido e atualizando as raízes de estado de rollup afetadas adequadamente. Assim que L1 terminar de desenrolar as chamadas revertidas, um REVERT_CONTINUE a ação é enviada de volta para L2, permitindo que a execução seja retomada. O resultado final é que as reversões funcionam da mesma maneira que funcionam atualmente em uma única cadeia.

6. Notas Adicionais

Abstração de contas e alinhamento de incentivos

Garantir que os contratos de proxy sejam implantados e que os incentivos entre o usuário e o construtor do bloco estejam devidamente alinhados pode ser feito usando os padrões Ethereum existentes – especificamente EIP-7702 (definir código de conta EOA) e EIP-4337 (abstração de conta). Esses padrões fornecem a flexibilidade necessária para coordenar a fase de configuração sem exigir alterações no protocolo principal.

Os rollups não estão limitados ao EVM

Os rollups que participam deste sistema não precisam ser nativos de EVM. Qualquer rollup que possa aceitar e gerar `CALL`s para outros rollups pode participar. Cada rollup define sua própria função de transição de estado por meio de um Chave zkVerification. Um rollup pode até ter um proprietário com controle total sobre sua raiz estatal.

A única restrição que o sistema principal impõe é Responsabilidade do Éter: o sistema deve rastrear quanto Ether cada rollup contém e não deve permitir que um rollup faça uma `CALL` com um valor superior ao seu saldo total de Ether.

Tokens nativos e transferências de valor

Os rollups podem definir seu próprio token nativo. A única restrição é que a função de transição de estado não deve aceitar ou fazer CALLs com um valor Ether diferente de zero de ou para um rollup externo se o rollup usar um token nativo diferente. Isso evita incompatibilidades contábeis entre o token interno do rollup e o Ether rastreado pelo sistema L1.

Não é necessário garfo L1

Todo este mecanismo pode ser implementado sem bifurcação L1. Tudo funciona através de contratos inteligentes implantados na rede Ethereum existente.

Ortogonal às pré-confirmações

Esta proposta é totalmente ortogonal aos mecanismos de pré-confirmação. Não depende nem entra em conflito com pré-confirmações. Na verdade, ele pode se beneficiar das pré-confirmações L1 assim que estiverem disponíveis, pois uma finalização L1 mais rápida reduziria a latência das interações entre cadeias.

Implementação de referência

Um primeiro rascunho de como esses contratos inteligentes funcionariam está disponível em: https://github.com/jbaylina/sync-rollups