A Across V4 introduz uma nova e melhorada arquitetura crosschain.
O sistema combina intents e provas de conhecimento zero (ZKPs) para se expandir para mais cadeias, mais rapidamente.
Aqui está a análise técnica. 🧵
Anteriormente, a Across usava "pontes canónicas" ou adaptadores específicos de cadeia para verificar mensagens do HubPool do Ethereum.
Isto funcionou bem para L2s como Arbitrum e Optimism, que expõem o estado finalizado do Ethereum.
Mas este design era limitante…
Para cadeias que não são EVM, como a BSC, este modelo falha.
Não há uma maneira canónica de verificar o estado do Ethereum. Isso significava ou construir adaptadores personalizados ou não suportar essas cadeias de todo.
Nenhuma dessas soluções é ótima. Então, encontramos uma maneira melhor usando ZKPs.
Aqui está o processo:
Quando os relayers preenchem ordens crosschain, as transações são agrupadas em pacotes de reembolso de relayers, que são então verificadas pelo Oracle Otimista da @UMAProtocol.
Isto acontece sempre na mainnet do Ethereum.
Uma vez que um pacote é verificado, o Across HubPool aciona o processo de liquidação.
Em seguida, escreve os hashes das mensagens de reembolso no contrato HubPoolStore em slots de armazenamento específicos.
Este evento de armazenamento também ocorre na mainnet do Ethereum.
Cada hash de mensagem no contrato HubPoolStore corresponde a uma intenção de reembolsar um relayer em uma cadeia de destino.
Note que mensagens L1 → L2 podem representar múltiplos reembolsos (incluindo preenchimentos lentos). Isso ocorre porque são pacotes raiz.
Quando o contrato HubPoolStore grava um hash de mensagem armazenada, ele emite um evento StoredCallData.
Este evento contém o hash da mensagem e o slot de armazenamento.
O evento + os dados armazenados formam a âncora para a verificação ZK a montante.
Um serviço chamado finalizer escuta esses eventos.
Assim que detecta um novo, inicia um processo para provar que o hash da mensagem foi realmente escrito na Ethereum.
Cada mensagem, para a qual o hash está armazenado, tem um alvo que pode ser específico para a sua cadeia.
Esta prova permite que a mensagem seja executada de forma segura na cadeia de destino.
Mas a finalização do Ethereum não é instantânea.
Uma vez que o finalizador envia os dados para a API ZK, a API aguarda através da janela de finalização do Ethereum antes de gerar uma prova.
Para gerar uma prova ZK válida, o comitê de sincronização do Ethereum deve aprovar um bloco finalizado específico.
Se a mensagem foi incluída nesse bloco ou antes, as assinaturas necessárias tornam-se 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 escrito em um slot de armazenamento conhecido do HubPoolStore em um bloco Ethereum finalizado.
Isto permite a verificação sem confiança dos reembolsos dos relayers em qualquer cadeia de destino.
A API ZK prepara entradas de prova incluindo (mas não se limitando a):
- Cabeçalhos de beacon finalizados
- Assinaturas do comitê de sincronização
- Provas Merkle de armazenamento da camada de execução do Ethereum
Estes formam a base para gerar a prova.
A Across implementa uma pilha genérica em cadeias de destino:
- Um contrato Verificador (valida a prova ZK)
- SP1Helios da @Succinct (armazena o estado finalizado do Ethereum)
- Contrato UniversalSpokepool (verifica a autenticidade das mensagens durante a execução)
Uma vez 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.
Isto significa que a Across já não precisa de adaptadores personalizados para cada cadeia.
Apenas um pipeline que funciona em todo o lado:
storeMsg() na Ethereum → prova ZK → executeMsg() em qualquer cadeia de destino que possa verificar a prova SP1Helios.
Sem pressupostos de confiança.
Sem sobrecarga de integração.
Apenas Intenções + ZK.
Por que isso é um grande problema?
Isso expande dramaticamente o alcance da Across ao desbloquear suporte para cadeias de longo prazo que não conseguem verificar o estado do Ethereum nativamente e não têm pontes canônicas.
Isso torna a integração mais rápida, segura e escalável.
A Across não precisa de uma ponte canónica para estas cadeias. Apenas precisa da capacidade de verificar uma prova ZK do estado do Ethereum.
Isto reduz a sobrecarga de integração, evita o risco de pontes centralizadas e reforça o papel do Ethereum como a raiz da verdade entre cadeias.
7,71 mil
42
O conteúdo apresentado nesta página é fornecido por terceiros. Salvo indicação em contrário, a OKX não é o autor dos artigos citados e não reivindica quaisquer direitos de autor nos materiais. O conteúdo é fornecido apenas para fins informativos e não representa a opinião da OKX. Não se destina a ser um endosso de qualquer tipo e não deve ser considerado conselho de investimento ou uma solicitação para comprar ou vender ativos digitais. Na medida em que a IA generativa é utilizada para fornecer resumos ou outras informações, esse mesmo conteúdo gerado por IA pode ser impreciso ou inconsistente. Leia o artigo associado para obter mais detalhes e informações. A OKX não é responsável pelo conteúdo apresentado nos sites de terceiros. As detenções de ativos digitais, incluindo criptomoedas estáveis e NFTs, envolvem um nível de risco elevado e podem sofrer grandes flutuações. Deve considerar cuidadosamente se o trading ou a detenção de ativos digitais é adequado para si à luz da sua condição financeira.