Across V4 apresenta uma arquitetura crosschain nova e aprimorada. O sistema combina intenções e provas de conhecimento zero (ZKPs) para expandir para mais cadeias, mais rapidamente. Aqui está o detalhamento técnico. 🧵

Anteriormente, a Across usava "pontes canônicas" ou adaptadores específicos da cadeia para verificar as mensagens do HubPool da Ethereum. Isso funcionou bem para L2s como Arbitrum e Optimism, que expõem o estado finalizado do Ethereum. Mas esse design era limitante...

Para cadeias não EVM como a BSC, esse modelo quebra. Não há uma maneira canônica de verificar o estado do Ethereum. Isso significava construir adaptadores personalizados ou não oferecer suporte a essas cadeias. Nenhuma dessas soluções é ideal. Então, descobrimos uma maneira melhor de usar ZKPs.

Aqui está o processo: Quando os retransmissores preenchem pedidos de cadeia cruzada, as transações são agrupadas em pacotes de reembolso de retransmissão, que são verificados pelo Optimistic Oracle da @UMAProtocol. Isso sempre acontece na rede principal Ethereum.

Depois que um pacote é verificado, o Across HubPool aciona o processo de liquidação. Em seguida, ele grava os hashes da mensagem de reembolso no contrato HubPoolStore em slots de armazenamento específicos. Esse evento de armazenamento também acontece na rede principal Ethereum.

Cada hash de mensagem no contrato HubPoolStore corresponde a uma intenção de reembolsar um retransmissor em uma cadeia de destino. Observe que as mensagens L1 → L2 podem representar vários reembolsos (incluindo preenchimentos lentos). Isso ocorre porque eles são feixes raiz.

Quando o contrato HubPoolStore grava um hash de mensagem armazenado, ele emite um evento StoredCallData. Esse evento contém o hash da mensagem e o slot de armazenamento. O evento + os dados armazenados formam a âncora para verificação ZK downstream.

Um serviço chamado finalizador escuta esses eventos. Depois de detectar um novo, ele inicia um processo para provar que o hash da mensagem foi realmente escrito no Ethereum. Cada mensagem, para a qual o hash é armazenado, tem um destino que pode ser específico para sua cadeia.

Essa prova permite que a mensagem seja executada com segurança na cadeia de destino. Mas a finalidade do Ethereum não é instantânea. Depois que o finalizador envia os dados para a API ZK, a API aguarda a janela de finalidade do Ethereum antes de gerar uma prova.

Para gerar uma prova ZK válida, o comitê de sincronização Ethereum deve aprovar um bloco finalizado específico. Se a mensagem foi incluída nesse bloco ou antes, as assinaturas necessárias ficam disponíveis para começar a gerar a prova ZK.

O finalizador consulta a API ZK para gerar uma prova de que um hash de mensagem específico foi gravado em um slot de armazenamento HubPoolStore conhecido em um bloco Ethereum finalizado. Isso permite a verificação sem confiança dos reembolsos de retransmissão em qualquer cadeia de destino.

A API ZK prepara entradas de prova, incluindo (mas não se limitando a): - Cabeçalhos de beacon finalizados - Sincronizar assinaturas de comitês - Provas de armazenamento Merkle da camada de execução do Ethereum Estes formam a base para gerar a prova.

O Across implanta uma pilha genérica em cadeias de destino: - Um contrato de verificador (valida a prova ZK) - SP1Helios por @Succinct (armazena o estado Ethereum finalizado) - Contrato UniversalSpokepool (verifica a autenticidade das mensagens durante a execução)

Depois que a prova ZK é verificada e o estado é confirmado, executeMsg() pode executar com segurança a carga útil na cadeia de destino. Sem confiança. Seguro. Universal.

Isso significa que o Across não precisa mais de adaptadores personalizados para cada cadeia. Apenas um pipeline que funciona em todos os lugares: storeMsg() no Ethereum → prova ZK → executeMsg() em qualquer cadeia de destino que possa verificar a prova SP1Helios.

Sem suposições de confiança. Sem sobrecarga de integração. Apenas intenções + ZK.

Por que isso é um grande negócio? Ele expande drasticamente o alcance do Across, desbloqueando o suporte para cadeias de cauda longa que não podem verificar o estado do Ethereum nativamente e não possuem pontes canônicas. Isso torna a integração mais rápida, segura e escalável.

Across não precisa de uma ponte canônica para essas cadeias. Ele só precisa da capacidade de verificar uma prova ZK do estado Ethereum. Isso reduz a sobrecarga de integração, evita o risco de ponte centralizada e reforça o papel do Ethereum como a raiz da verdade crosschain.