Autor: Lisa A., Taiko Labs; tradução: Jinse Finance xiaozou
Este artigo discutirá diferentes métodos de mensagens L2 cross-chain da perspectiva do rollup, com foco na comunicação cross-chain sem confiança. Examinaremos brevemente a abordagem de leitura de estado direto, a abordagem de cliente leve e a prova de armazenamento. Também abordaremos o mecanismo de agregação de provas, a transmissão confiável de mensagens de cadeia cruzada de terceiros e as principais soluções de cadeia cruzada ZK. Por fim, vamos ver como diferentes L2s implementam mensagens entre cadeias hoje.
1. Introdução às mensagens cross-chain
Para comunicação entre cadeias, todas as partes (L2, L3, etc.) devem ter acesso direto à raiz do estado Ethereum mais recente.
Todas as camadas de depósito possuem um mecanismo de cadeia cruzada "embutido" que pode ser usado para acessar a raiz do estado L1, que será passada para L2 como uma mensagem de depósito.
1**.1** Dois tipos de acesso à raiz do estado
Tipo 1: Leia o estado raiz diretamente - pode ser feito via opcode ou pré-compilado. No entanto, não foi implementado até agora, portanto, nenhuma prova é necessária.
Brecht Devos descreve um possível método de ler diretamente o estado em um trabalho de pesquisa: "... podemos expor um contrato pré-compilado que pode chamar diretamente um contrato inteligente na cadeia de destino. Isso pré-compilado diretamente em A cadeia de origem insere e executa o código de contrato inteligente de outra cadeia Isso garante que os contratos inteligentes sempre tenham acesso ao estado mais recente disponível de maneira eficiente e facilmente demonstrável.”
· Também descrito na RFP da Optimism "Prova de Conceito de Invocação Estática Remota".
Tipo 2: Geração de prova - ou seja, provar uma declaração sobre um blockchain em outro blockchain.
"Mensagens de cadeia cruzada com provas" tem duas abordagens:
· Comunicação cross-chain sem confiança — ou seja, sem terceiros confiáveis (por exemplo, usando light clients ou proof-of-storage). A abordagem sem confiança pode ser usada tanto para a geração de provas por terceiros quanto para os participantes da comunicação entre cadeias gerarem as próprias provas.
As provas são compartilhadas entre diferentes rollups para garantir operações entre cadeias. Essa abordagem, que não é muito discutida neste artigo, está atualmente em fase de pesquisa e exploração e não é considerada uma solução potencialmente amplamente aplicável.
1**.2** Método "Cross-Chain Messaging with Proof"
1.2.1Mensagens de cadeia cruzada de cliente light
Prove os dados na cadeia B
Obtenha dados de prova Merkle do nó completo da cadeia B (nó de arquivamento de arquivo se a prova de armazenamento para determinados estados históricos for necessária);
Envie o cabeçalho do bloco e os dados de prova correspondentes ao bloco da cadeia B contendo o estado que queremos verificar para o contrato do provedor na cadeia A como calldata;
O contrato provador calcula o valor do hash do bloco com base nos dados do cabeçalho do bloco, consulta o contrato inteligente do cliente leve na cadeia A (rastreia o valor do hash do bloco da cadeia B) e verifica se o valor do hash é válido;
Os dados de prova são verificados em relação à raiz do estado bytes32 no cabeçalho do bloco.
1**.2.2** Comprovante de Armazenamento
O Proof of Storage tem duas opções de "fluxo de trabalho":
· Gerar prova de armazenamento → usar on-chain
· Gerar prova de armazenamento → gerar prova zk → usar na cadeia
Também é possível para uma entidade agrupar várias coleções de provas em uma única prova (prova de armazenamento e prova de zk). Esta é uma etapa de otimização opcional e ainda não foi discutida.
Vamos dar uma olhada nos três estágios principais do "fluxo de trabalho" da prova de armazenamento: gerar prova de armazenamento, gerar prova zk e usá-la na cadeia.
(1) Gerar Prova de Armazenamento
· A prova de armazenamento nos permite usar um compromisso confidencial para provar que determinada informação existe no blockchain e é verdadeira;
A prova de armazenamento faz parte do espaço criptográfico desde o advento das árvores Merkle em 1979. No entanto, as provas de armazenamento de baunilha geralmente são bastante grandes. A inovação moderna consiste em combinar prova de armazenamento com computação comprovável para criar provas sucintas que podem ser verificadas na cadeia.
Para gerar uma prova de armazenamento, um bloco específico de dados e seu caminho Merkle ou Verkle associado em uma árvore Merkle devem ser fornecidos. O caminho consiste nos hashes irmãos necessários para reconstruir o hash raiz usando o mesmo algoritmo de hash.
Para verificar uma prova de armazenamento, o destinatário pode usar os dados fornecidos e o caminho Merkle ou Verkle para recalcular o hash raiz. Se o hash raiz recalculado corresponder a um hash raiz conhecido, o destinatário pode ter certeza de que os dados são autênticos e fazem parte do conjunto de dados enviado.
(2) Gerar ZKP (prova de conhecimento zero)
No entanto, uma prova de armazenamento do tipo Ethereum tem cerca de 4kb - bastante grande para postar toda a prova de armazenamento na cadeia de destino, pois a verificação da prova seria muito cara. Portanto, é razoável usar ZKP (por exemplo, ZK-SNARK) para compactação, o que pode tornar a prova menor e mais barata de verificar.
（3）A****rollZKP
Depois de ganhar ZKPs, os usuários na cadeia de destino podem desenrolar suas provas conquistadas (por exemplo, acessar o estado histórico por meio de cabeçalhos de bloco ou hashes de bloco).
O desenrolar pode ser feito da seguinte forma:
Acumulação na cadeia: Todo o processo de reconstrução dos cabeçalhos dos blocos a partir das provas é realizado diretamente na cadeia de blocos. Desvantagens: alta taxa de gás, consome recursos computacionais; vantagens: sem tempo adicional de prova, baixa latência, pois não há necessidade de geração de provas fora do blockchain.
Compressão na cadeia: remova informações redundantes ou desnecessárias dos dados ou use estruturas de dados otimizadas para eficiência de espaço. Os dados compactados são enviados para o blockchain e podem ser descompactados quando necessário. Contras: compactar e descompactar dados pode significar computação adicional, mas essa latência pode ser insignificante. O algoritmo de compressão utilizado pode ter um impacto negativo na segurança dos dados; vantagem: reduz os custos dos dados.
Armazenamento off-chain: armazene dados off-chain e coloque blocos de dados específicos on-chain sob demanda. Isso é relevante para soluções que precisam armazenar grandes quantidades de dados por algum motivo (por exemplo, nós de arquivo Ethereum do bloco genesis). Contras: Igual à compressão on-chain; Prós: reduz ainda mais os custos de dados.
1**.2.3** Terceiro confiável
Uma solução completa de cadeia cruzada também deve envolver soluções de mensagens cruzadas com terceiros confiáveis (como oráculos, pontes centralizadas, etc.).
1**.2.4** Sistema de Prova “Universal”
No caso de um mecanismo de plataforma de prova de agregação compartilhado, o envio de mensagens pode ser acelerado ao receber hashes de bloco que são liquidados na plataforma de agregação, e o assentamento aqui também lidará com mensagens (mas se houver um problema com a plataforma de agregação o que fazer?).
1**.2.5 Alguns problemas desconhecidos das mensagens cruzadas do ZK******
As mensagens entre cadeias são viáveis sem um terceiro confiável (que pode ser uma única entidade ou várias entidades)? Qual é um mecanismo eficiente para a passagem de mensagens entre cadeias? Em geral, para Ethereum L2 (com acesso direto aos hashes do bloco L1) e Ethereum em si, se uma cadeia pode executar um cliente leve, etc., o que é suficiente para mensagens cruzadas sem confiança.
O circuito ZK usado para geração de prova de cadeia cruzada está devidamente dimensionado? Em alguns casos, especialmente quando a camada de consenso (que precisa ser verificada para operações cross-chain) é muito grande, o circuito usado para a passagem de mensagens ZK cross-chain pode ter ordens de magnitude maiores do que rollup e armazenamento on-chain, e a sobrecarga computacional também é muito grande. Presumivelmente, esse problema pode ser superado com uma abordagem mais centralizada.
2**、Exemplo de solução de mensagens cross-chain**
· Su****ccinct Labs usa um cliente leve para verificar o consenso da cadeia de origem para a camada de consenso da cadeia de destino. A ideia é que exista um protocolo de cliente leve para garantir que os nós possam sincronizar os cabeçalhos de bloco do estado final da blockchain. O ZKP é usado para gerar provas de consenso.
· La****grange Labs constrói uma prova de estado de cadeia cruzada não interativa. Lagrange prova que a rede é responsável por criar a raiz do estado. Cada nó Lagrange contém uma parte da chave privada de um shard, que atesta o estado de uma determinada cadeia. Cada raiz de estado é uma raiz Verkle com sinal de limite que pode ser usada para atestar o estado de uma determinada cadeia em um determinado momento. A raiz do estado é completamente geral e pode ser usada em uma prova de estado para provar o estado atual de qualquer contrato ou carteira na cadeia.
· He****rodotus usa prova de armazenamento ZKP para fornecer contratos inteligentes e acessar dados na cadeia de outras camadas Ethereum de forma síncrona. Para validação, ele usa mensagens nativas L1<>L2 para sincronizar hashes de bloco entre rollups Ethereum.
=nil; Foundation (Mina, L1) permite contratos inteligentes no Ethereum para verificar a validade do estado Mina. Gere provas de estado para fins especiais, baratas para verificar no Ethereum (as provas locais da Mina no Ethereum são caras). Hipoteticamente (em algum momento no futuro), os aplicativos podem usar diretamente a ferramenta de geração de provas da Mina para verificar a validade das transações entre cadeias. =nil; A Foundation também possui um Proof Market onde usuários/projetos podem comprar/vender principalmente provas SNARK que permitem acesso a dados sem confiança.
Axiom: Se o Axiom gerou um ZKP para o ledger até agora - ele não precisa gerar um ZKP para um bloco específico - ele pode passar esse ZKP para a cadeia (como um relayer) ou até mesmo fornecer acesso a este ZKP.
3. Mensagens de cadeia cruzada L2
*Isenção de responsabilidade: as mensagens entre cadeias ainda estão evoluindo para a maior parte do L2. Todas as análises abaixo são baseadas em informações de código aberto. Dito isso, as soluções mencionadas no artigo podem estar em fase de exploração e teste, e o rollup pode eventualmente adotar outros métodos. *
**（1）**Taiko
Taiko armazena hashes de bloco para cada cadeia. Para cada par de cadeias, ele implanta dois contratos inteligentes que armazenam os hashes um do outro. No exemplo de L2←→L1, toda vez que um bloco L2 é criado no Taiko, os valores de hash dos blocos periféricos em L1 são armazenados no contrato TaikoL2. Também no caso de L1←→L2, o modo de operação é o mesmo.
A última raiz Merkle conhecida armazenada na cadeia de destino pode ser obtida chamando getCrossChainBlockHash(0) no contrato TaikoL1/TaikoL2 e obtenha o valor/mensagem para verificar. O hash irmão da raiz Merkle conhecida mais recente pode ser obtido chamando a solicitação eth_getProof usando um RPC padrão na "cadeia de origem".
Em seguida, basta enviá-los para serem verificados em relação aos últimos hashes de bloco conhecidos armazenados em uma lista na "cadeia de destino". O validador pegará um valor (uma folha na árvore Merkle) e hashes irmãos para recalcular a raiz Merkle e verificar se ela corresponde à raiz armazenada na lista de hashes de bloco da cadeia de destino.
**（2）**Starknet
A Starknet usa Proof of Storage para mensagens de cadeia cruzada sem confiança.
Protocolo de mensagens L2→L1
· Durante a execução de uma transação Starknet, um contrato na Starknet envia uma mensagem L2→L1.
Os parâmetros da mensagem (contendo o contrato do receptor e os dados relacionados em L1) são então anexados à atualização de estado relevante (árvore de armazenamento principal).
· As mensagens L2 são armazenadas em L1 do contrato inteligente.
· Emitir um evento em L1 (armazenar parâmetros da mensagem).
Endereços receptores em L1 podem acessar e usar a mensagem como parte de uma transação L1, fornecendo novamente os parâmetros da mensagem.
· As mensagens de cadeia cruzada são armazenadas na árvore tronco.
L2 → L1
L1 → L2
**(3)**Otimismo
A comunicação entre L1 e L2 é implementada por dois contratos inteligentes especiais chamados "mensageiros".
· Para transações de Otimismo (L2) para Ethereum (L1), é necessário fornecer uma prova Merkle da mensagem em L1 após a gravação da raiz do estado. Depois que essa transação de prova se torna parte da cadeia L1, o período de desafio de erro começa. Após esse período de espera, qualquer usuário pode "finalizar" a transação acionando uma segunda transação no Ethereum, enviando uma mensagem para o contrato L1 de destino.
· As mensagens de cadeia cruzada são armazenadas na árvore tronco.
（4）Ar****bitrum
Bilhetes com nova tentativa são o método canônico que a Arbitrum usa para criar mensagens L1 para L2, ou seja, transações L1 que inicializam mensagens a serem executadas em L2. Um Retryable pode ser enviado em L1 por uma taxa fixa (dependendo apenas do tamanho de seus dados de chamada). A árvore de estado principal é usada para comunicação entre cadeias de formatos de dados personalizados em contratos inteligentes. O envio de um tíquete repetível em L1 é separável/assíncrono da execução em L2. Retryables fornecem atomicidade entre as operações de cadeia cruzada. Se a solicitação de transação L1 for enviada com sucesso (ou seja, sem reversão), a execução Retryable em L2 terá uma forte garantia de que será bem-sucedida.
Arbitrum tem dois troncos: A cadeia Nitro é mantida no formato de árvore de estado do Ethereum, uma árvore Merkle. A Assertion Tree armazena o estado da cadeia Arbitrum confirmado no Ethereum via "assertion". As regras que avançam na cadeia Arbitrum são determinísticas. Isso significa que, dado o estado de uma cadeia e alguns novos valores de entrada, há apenas uma saída válida. Portanto, se a árvore de prova contiver várias folhas, no máximo uma folha poderá representar um estado de cadeia válido.
O sistema Outbox da Arbitrum permite qualquer chamada de contrato de L2 para L1, ou seja, uma mensagem é iniciada de L2 e finalmente executada em L1. As mensagens L2 para L1 (também conhecidas como "mensagens de saída") têm muito em comum com as mensagens L1 para L2 do Arbitrum (Retryable), embora existam algumas diferenças notáveis. Parte do estado L2 de uma cadeia Arbitrum - ou seja, a parte atestada em cada RBlock - é a raiz Merkle de todas as mensagens L2 para L1 no histórico da cadeia. Depois que o RBlock comprovado é confirmado (geralmente cerca de uma semana após a prova), a raiz Merkle é incluída no contrato Outbox e publicada em L1. O contrato de caixa de saída permite que os usuários executem suas mensagens.
**(5)**Polygon zkEVM
· O Bridge SC deste zkEVM usa uma árvore Merkle especial chamada Exit Tree para cada rede que participa da comunicação ou transação de ativos.
Ele usa raízes Merkle (em uma árvore de estado separada), um diagrama de arquitetura de ponte pode ser encontrado no github.
A implantação do zkEVM Bridge SC fez várias alterações com base no contrato de depósito Ethereum 2.0. Por exemplo, ele usa uma árvore Merkle somente anexada especialmente projetada, mas usa a mesma lógica do contrato de depósito Ethereum 2.0. Outras diferenças estão relacionadas a hashes de base e nós de folha.
A principal característica do contrato inteligente Polygon zkEVM Bridge é o uso da árvore de saída e da árvore de saída global, onde a raiz da árvore de saída global é a principal fonte do estado de verdade. Portanto, L1 e L2 têm dois gerenciadores de raiz de saída globais diferentes e o Bridge SC tem uma lógica separada.
（6）S****rolagem
· Contratos de ponte implantados em Ethereum e Scroll permitem que os usuários passem mensagens arbitrárias entre L1 e L2. Além desse protocolo de mensagens, também construímos um protocolo de ponte confiável para permitir que os usuários façam a ponte entre ativos ERC-20 entre L1 e L2. Para enviar uma mensagem ou fundos de Ethereum para Scroll, um usuário chama a transação sendMessage no contrato Bridge. Os retransmissores irão indexar esta transação no L1 e enviá-la ao ordenante para inclusão nos blocos L2. No contrato de ponte L2, o processo de envio de uma mensagem de Scroll back para Ethereum é semelhante.
· As mensagens entre cadeias são armazenadas em filas de mensagens regulares. O solicitador ingere mensagens de cadeia cruzada dessa fila e as adiciona à cadeia como transações regulares.
**（7）**Era zksync
Isenção de responsabilidade: o conteúdo desta seção é apenas sobre zksync Era, que pode ser diferente das mensagens cross-chain no ZK Stack, que é uma estrutura modular para construir uma superchain ZK soberana. *
· Cada pacote de transação possui uma única mensagem L2->L1.
· Não é possível enviar transações diretamente de L2 para L1. No entanto, você pode enviar mensagens de qualquer comprimento do zkSync Era para o Ethereum e, em seguida, processar as mensagens recebidas no Ethereum usando o contrato inteligente L1. O zkSync Era possui uma função de comprovação de solicitação que retornará um parâmetro booleano indicando se a mensagem foi enviada com sucesso para L1. Recupere a prova Merkle contida na mensagem observando Ethereum ou usando o método zks_getL2ToL1LogProof da API zksync-web3.
· Para L1→L2, o contrato inteligente zkSync Era permite que o remetente solicite uma transação no Ethereum L1 e passe os dados para zkSync Era L2.
· Contrato-ponte:
4. Conclusão
A comunicação entre cadeias é essencial para aplicativos "obrigatórios" para adoção em massa de blockchain (por exemplo, a carteira de recuperação social entre cadeias descrita no artigo Vitalik). A maioria das soluções de cadeia cruzada atualmente em uso são projetadas para L1←→L2 para cobrir a função de retirada. Essas soluções podem ser estendidas para mais blockchains. Mas, ao mesmo tempo, soluções de comunicação cross-chain mais avançadas podem ser implementadas, como "estado de leitura direta" sem prova alguma ou "prova de armazenamento" sem confiança. Para a maioria dos L2s, ainda há espaço para melhorias na comunicação entre cadeias.
Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Explore a comunicação entre cadeias a partir da perspectiva do rollup
Autor: Lisa A., Taiko Labs; tradução: Jinse Finance xiaozou
Este artigo discutirá diferentes métodos de mensagens L2 cross-chain da perspectiva do rollup, com foco na comunicação cross-chain sem confiança. Examinaremos brevemente a abordagem de leitura de estado direto, a abordagem de cliente leve e a prova de armazenamento. Também abordaremos o mecanismo de agregação de provas, a transmissão confiável de mensagens de cadeia cruzada de terceiros e as principais soluções de cadeia cruzada ZK. Por fim, vamos ver como diferentes L2s implementam mensagens entre cadeias hoje.
1. Introdução às mensagens cross-chain
Para comunicação entre cadeias, todas as partes (L2, L3, etc.) devem ter acesso direto à raiz do estado Ethereum mais recente.
Todas as camadas de depósito possuem um mecanismo de cadeia cruzada "embutido" que pode ser usado para acessar a raiz do estado L1, que será passada para L2 como uma mensagem de depósito.
1**.1** Dois tipos de acesso à raiz do estado
Tipo 1: Leia o estado raiz diretamente - pode ser feito via opcode ou pré-compilado. No entanto, não foi implementado até agora, portanto, nenhuma prova é necessária.
Brecht Devos descreve um possível método de ler diretamente o estado em um trabalho de pesquisa: "... podemos expor um contrato pré-compilado que pode chamar diretamente um contrato inteligente na cadeia de destino. Isso pré-compilado diretamente em A cadeia de origem insere e executa o código de contrato inteligente de outra cadeia Isso garante que os contratos inteligentes sempre tenham acesso ao estado mais recente disponível de maneira eficiente e facilmente demonstrável.”
· Também descrito na RFP da Optimism "Prova de Conceito de Invocação Estática Remota".
Tipo 2: Geração de prova - ou seja, provar uma declaração sobre um blockchain em outro blockchain.
"Mensagens de cadeia cruzada com provas" tem duas abordagens:
· Comunicação cross-chain sem confiança — ou seja, sem terceiros confiáveis (por exemplo, usando light clients ou proof-of-storage). A abordagem sem confiança pode ser usada tanto para a geração de provas por terceiros quanto para os participantes da comunicação entre cadeias gerarem as próprias provas.
As provas são compartilhadas entre diferentes rollups para garantir operações entre cadeias. Essa abordagem, que não é muito discutida neste artigo, está atualmente em fase de pesquisa e exploração e não é considerada uma solução potencialmente amplamente aplicável.
1**.2** Método "Cross-Chain Messaging with Proof"
1.2.1 Mensagens de cadeia cruzada de cliente light
Prove os dados na cadeia B
Obtenha dados de prova Merkle do nó completo da cadeia B (nó de arquivamento de arquivo se a prova de armazenamento para determinados estados históricos for necessária);
Envie o cabeçalho do bloco e os dados de prova correspondentes ao bloco da cadeia B contendo o estado que queremos verificar para o contrato do provedor na cadeia A como calldata;
O contrato provador calcula o valor do hash do bloco com base nos dados do cabeçalho do bloco, consulta o contrato inteligente do cliente leve na cadeia A (rastreia o valor do hash do bloco da cadeia B) e verifica se o valor do hash é válido;
Os dados de prova são verificados em relação à raiz do estado bytes32 no cabeçalho do bloco.
1**.2.2** Comprovante de Armazenamento
O Proof of Storage tem duas opções de "fluxo de trabalho":
· Gerar prova de armazenamento → usar on-chain
· Gerar prova de armazenamento → gerar prova zk → usar na cadeia
Também é possível para uma entidade agrupar várias coleções de provas em uma única prova (prova de armazenamento e prova de zk). Esta é uma etapa de otimização opcional e ainda não foi discutida.
Vamos dar uma olhada nos três estágios principais do "fluxo de trabalho" da prova de armazenamento: gerar prova de armazenamento, gerar prova zk e usá-la na cadeia.
(1) Gerar Prova de Armazenamento
· A prova de armazenamento nos permite usar um compromisso confidencial para provar que determinada informação existe no blockchain e é verdadeira;
A prova de armazenamento faz parte do espaço criptográfico desde o advento das árvores Merkle em 1979. No entanto, as provas de armazenamento de baunilha geralmente são bastante grandes. A inovação moderna consiste em combinar prova de armazenamento com computação comprovável para criar provas sucintas que podem ser verificadas na cadeia.
Para gerar uma prova de armazenamento, um bloco específico de dados e seu caminho Merkle ou Verkle associado em uma árvore Merkle devem ser fornecidos. O caminho consiste nos hashes irmãos necessários para reconstruir o hash raiz usando o mesmo algoritmo de hash.
Para verificar uma prova de armazenamento, o destinatário pode usar os dados fornecidos e o caminho Merkle ou Verkle para recalcular o hash raiz. Se o hash raiz recalculado corresponder a um hash raiz conhecido, o destinatário pode ter certeza de que os dados são autênticos e fazem parte do conjunto de dados enviado.
(2) Gerar ZKP (prova de conhecimento zero)
No entanto, uma prova de armazenamento do tipo Ethereum tem cerca de 4kb - bastante grande para postar toda a prova de armazenamento na cadeia de destino, pois a verificação da prova seria muito cara. Portanto, é razoável usar ZKP (por exemplo, ZK-SNARK) para compactação, o que pode tornar a prova menor e mais barata de verificar.
（3）A****roll ZKP
Depois de ganhar ZKPs, os usuários na cadeia de destino podem desenrolar suas provas conquistadas (por exemplo, acessar o estado histórico por meio de cabeçalhos de bloco ou hashes de bloco).
O desenrolar pode ser feito da seguinte forma:
Acumulação na cadeia: Todo o processo de reconstrução dos cabeçalhos dos blocos a partir das provas é realizado diretamente na cadeia de blocos. Desvantagens: alta taxa de gás, consome recursos computacionais; vantagens: sem tempo adicional de prova, baixa latência, pois não há necessidade de geração de provas fora do blockchain.
Compressão na cadeia: remova informações redundantes ou desnecessárias dos dados ou use estruturas de dados otimizadas para eficiência de espaço. Os dados compactados são enviados para o blockchain e podem ser descompactados quando necessário. Contras: compactar e descompactar dados pode significar computação adicional, mas essa latência pode ser insignificante. O algoritmo de compressão utilizado pode ter um impacto negativo na segurança dos dados; vantagem: reduz os custos dos dados.
Armazenamento off-chain: armazene dados off-chain e coloque blocos de dados específicos on-chain sob demanda. Isso é relevante para soluções que precisam armazenar grandes quantidades de dados por algum motivo (por exemplo, nós de arquivo Ethereum do bloco genesis). Contras: Igual à compressão on-chain; Prós: reduz ainda mais os custos de dados.
1**.2.3** Terceiro confiável
Uma solução completa de cadeia cruzada também deve envolver soluções de mensagens cruzadas com terceiros confiáveis (como oráculos, pontes centralizadas, etc.).
1**.2.4** Sistema de Prova “Universal”
No caso de um mecanismo de plataforma de prova de agregação compartilhado, o envio de mensagens pode ser acelerado ao receber hashes de bloco que são liquidados na plataforma de agregação, e o assentamento aqui também lidará com mensagens (mas se houver um problema com a plataforma de agregação o que fazer?).
1**.2.5 Alguns problemas desconhecidos das mensagens cruzadas do ZK******
As mensagens entre cadeias são viáveis sem um terceiro confiável (que pode ser uma única entidade ou várias entidades)? Qual é um mecanismo eficiente para a passagem de mensagens entre cadeias? Em geral, para Ethereum L2 (com acesso direto aos hashes do bloco L1) e Ethereum em si, se uma cadeia pode executar um cliente leve, etc., o que é suficiente para mensagens cruzadas sem confiança.
O circuito ZK usado para geração de prova de cadeia cruzada está devidamente dimensionado? Em alguns casos, especialmente quando a camada de consenso (que precisa ser verificada para operações cross-chain) é muito grande, o circuito usado para a passagem de mensagens ZK cross-chain pode ter ordens de magnitude maiores do que rollup e armazenamento on-chain, e a sobrecarga computacional também é muito grande. Presumivelmente, esse problema pode ser superado com uma abordagem mais centralizada.
2**、Exemplo de solução de mensagens cross-chain**
· Su****ccinct Labs usa um cliente leve para verificar o consenso da cadeia de origem para a camada de consenso da cadeia de destino. A ideia é que exista um protocolo de cliente leve para garantir que os nós possam sincronizar os cabeçalhos de bloco do estado final da blockchain. O ZKP é usado para gerar provas de consenso.
· La****grange Labs constrói uma prova de estado de cadeia cruzada não interativa. Lagrange prova que a rede é responsável por criar a raiz do estado. Cada nó Lagrange contém uma parte da chave privada de um shard, que atesta o estado de uma determinada cadeia. Cada raiz de estado é uma raiz Verkle com sinal de limite que pode ser usada para atestar o estado de uma determinada cadeia em um determinado momento. A raiz do estado é completamente geral e pode ser usada em uma prova de estado para provar o estado atual de qualquer contrato ou carteira na cadeia.
· He****rodotus usa prova de armazenamento ZKP para fornecer contratos inteligentes e acessar dados na cadeia de outras camadas Ethereum de forma síncrona. Para validação, ele usa mensagens nativas L1<>L2 para sincronizar hashes de bloco entre rollups Ethereum.
=nil; Foundation (Mina, L1) permite contratos inteligentes no Ethereum para verificar a validade do estado Mina. Gere provas de estado para fins especiais, baratas para verificar no Ethereum (as provas locais da Mina no Ethereum são caras). Hipoteticamente (em algum momento no futuro), os aplicativos podem usar diretamente a ferramenta de geração de provas da Mina para verificar a validade das transações entre cadeias. =nil; A Foundation também possui um Proof Market onde usuários/projetos podem comprar/vender principalmente provas SNARK que permitem acesso a dados sem confiança.
Axiom: Se o Axiom gerou um ZKP para o ledger até agora - ele não precisa gerar um ZKP para um bloco específico - ele pode passar esse ZKP para a cadeia (como um relayer) ou até mesmo fornecer acesso a este ZKP.
3. Mensagens de cadeia cruzada L2
*Isenção de responsabilidade: as mensagens entre cadeias ainda estão evoluindo para a maior parte do L2. Todas as análises abaixo são baseadas em informações de código aberto. Dito isso, as soluções mencionadas no artigo podem estar em fase de exploração e teste, e o rollup pode eventualmente adotar outros métodos. *
**（1）**Taiko
Taiko armazena hashes de bloco para cada cadeia. Para cada par de cadeias, ele implanta dois contratos inteligentes que armazenam os hashes um do outro. No exemplo de L2←→L1, toda vez que um bloco L2 é criado no Taiko, os valores de hash dos blocos periféricos em L1 são armazenados no contrato TaikoL2. Também no caso de L1←→L2, o modo de operação é o mesmo.
A última raiz Merkle conhecida armazenada na cadeia de destino pode ser obtida chamando getCrossChainBlockHash(0) no contrato TaikoL1/TaikoL2 e obtenha o valor/mensagem para verificar. O hash irmão da raiz Merkle conhecida mais recente pode ser obtido chamando a solicitação eth_getProof usando um RPC padrão na "cadeia de origem".
Em seguida, basta enviá-los para serem verificados em relação aos últimos hashes de bloco conhecidos armazenados em uma lista na "cadeia de destino". O validador pegará um valor (uma folha na árvore Merkle) e hashes irmãos para recalcular a raiz Merkle e verificar se ela corresponde à raiz armazenada na lista de hashes de bloco da cadeia de destino.
**（2）**Starknet
A Starknet usa Proof of Storage para mensagens de cadeia cruzada sem confiança.
Protocolo de mensagens L2→L1
· Durante a execução de uma transação Starknet, um contrato na Starknet envia uma mensagem L2→L1.
Os parâmetros da mensagem (contendo o contrato do receptor e os dados relacionados em L1) são então anexados à atualização de estado relevante (árvore de armazenamento principal).
· As mensagens L2 são armazenadas em L1 do contrato inteligente.
· Emitir um evento em L1 (armazenar parâmetros da mensagem).
Endereços receptores em L1 podem acessar e usar a mensagem como parte de uma transação L1, fornecendo novamente os parâmetros da mensagem.
· As mensagens de cadeia cruzada são armazenadas na árvore tronco.
L2 → L1
L1 → L2
**(3)**Otimismo
A comunicação entre L1 e L2 é implementada por dois contratos inteligentes especiais chamados "mensageiros".
· Para transações de Otimismo (L2) para Ethereum (L1), é necessário fornecer uma prova Merkle da mensagem em L1 após a gravação da raiz do estado. Depois que essa transação de prova se torna parte da cadeia L1, o período de desafio de erro começa. Após esse período de espera, qualquer usuário pode "finalizar" a transação acionando uma segunda transação no Ethereum, enviando uma mensagem para o contrato L1 de destino.
· As mensagens de cadeia cruzada são armazenadas na árvore tronco.
（4）Ar****bitrum
Bilhetes com nova tentativa são o método canônico que a Arbitrum usa para criar mensagens L1 para L2, ou seja, transações L1 que inicializam mensagens a serem executadas em L2. Um Retryable pode ser enviado em L1 por uma taxa fixa (dependendo apenas do tamanho de seus dados de chamada). A árvore de estado principal é usada para comunicação entre cadeias de formatos de dados personalizados em contratos inteligentes. O envio de um tíquete repetível em L1 é separável/assíncrono da execução em L2. Retryables fornecem atomicidade entre as operações de cadeia cruzada. Se a solicitação de transação L1 for enviada com sucesso (ou seja, sem reversão), a execução Retryable em L2 terá uma forte garantia de que será bem-sucedida.
Arbitrum tem dois troncos: A cadeia Nitro é mantida no formato de árvore de estado do Ethereum, uma árvore Merkle. A Assertion Tree armazena o estado da cadeia Arbitrum confirmado no Ethereum via "assertion". As regras que avançam na cadeia Arbitrum são determinísticas. Isso significa que, dado o estado de uma cadeia e alguns novos valores de entrada, há apenas uma saída válida. Portanto, se a árvore de prova contiver várias folhas, no máximo uma folha poderá representar um estado de cadeia válido.
O sistema Outbox da Arbitrum permite qualquer chamada de contrato de L2 para L1, ou seja, uma mensagem é iniciada de L2 e finalmente executada em L1. As mensagens L2 para L1 (também conhecidas como "mensagens de saída") têm muito em comum com as mensagens L1 para L2 do Arbitrum (Retryable), embora existam algumas diferenças notáveis. Parte do estado L2 de uma cadeia Arbitrum - ou seja, a parte atestada em cada RBlock - é a raiz Merkle de todas as mensagens L2 para L1 no histórico da cadeia. Depois que o RBlock comprovado é confirmado (geralmente cerca de uma semana após a prova), a raiz Merkle é incluída no contrato Outbox e publicada em L1. O contrato de caixa de saída permite que os usuários executem suas mensagens.
**(5)**Polygon zkEVM
· O Bridge SC deste zkEVM usa uma árvore Merkle especial chamada Exit Tree para cada rede que participa da comunicação ou transação de ativos.
Ele usa raízes Merkle (em uma árvore de estado separada), um diagrama de arquitetura de ponte pode ser encontrado no github.
A implantação do zkEVM Bridge SC fez várias alterações com base no contrato de depósito Ethereum 2.0. Por exemplo, ele usa uma árvore Merkle somente anexada especialmente projetada, mas usa a mesma lógica do contrato de depósito Ethereum 2.0. Outras diferenças estão relacionadas a hashes de base e nós de folha.
A principal característica do contrato inteligente Polygon zkEVM Bridge é o uso da árvore de saída e da árvore de saída global, onde a raiz da árvore de saída global é a principal fonte do estado de verdade. Portanto, L1 e L2 têm dois gerenciadores de raiz de saída globais diferentes e o Bridge SC tem uma lógica separada.
（6）S****rolagem
· Contratos de ponte implantados em Ethereum e Scroll permitem que os usuários passem mensagens arbitrárias entre L1 e L2. Além desse protocolo de mensagens, também construímos um protocolo de ponte confiável para permitir que os usuários façam a ponte entre ativos ERC-20 entre L1 e L2. Para enviar uma mensagem ou fundos de Ethereum para Scroll, um usuário chama a transação sendMessage no contrato Bridge. Os retransmissores irão indexar esta transação no L1 e enviá-la ao ordenante para inclusão nos blocos L2. No contrato de ponte L2, o processo de envio de uma mensagem de Scroll back para Ethereum é semelhante.
· As mensagens entre cadeias são armazenadas em filas de mensagens regulares. O solicitador ingere mensagens de cadeia cruzada dessa fila e as adiciona à cadeia como transações regulares.
**（7）**Era zksync
· Cada pacote de transação possui uma única mensagem L2->L1.
· Não é possível enviar transações diretamente de L2 para L1. No entanto, você pode enviar mensagens de qualquer comprimento do zkSync Era para o Ethereum e, em seguida, processar as mensagens recebidas no Ethereum usando o contrato inteligente L1. O zkSync Era possui uma função de comprovação de solicitação que retornará um parâmetro booleano indicando se a mensagem foi enviada com sucesso para L1. Recupere a prova Merkle contida na mensagem observando Ethereum ou usando o método zks_getL2ToL1LogProof da API zksync-web3.
· Para L1→L2, o contrato inteligente zkSync Era permite que o remetente solicite uma transação no Ethereum L1 e passe os dados para zkSync Era L2.
· Contrato-ponte:
4. Conclusão
A comunicação entre cadeias é essencial para aplicativos "obrigatórios" para adoção em massa de blockchain (por exemplo, a carteira de recuperação social entre cadeias descrita no artigo Vitalik). A maioria das soluções de cadeia cruzada atualmente em uso são projetadas para L1←→L2 para cobrir a função de retirada. Essas soluções podem ser estendidas para mais blockchains. Mas, ao mesmo tempo, soluções de comunicação cross-chain mais avançadas podem ser implementadas, como "estado de leitura direta" sem prova alguma ou "prova de armazenamento" sem confiança. Para a maioria dos L2s, ainda há espaço para melhorias na comunicação entre cadeias.