Autor: MIDDLE.X

Título original: "Relatório de pesquisa de cadeia cruzada do Paka Labs (3/4) | Conectando ilhas isoladas a continentes: Interpretação de 20 pontes de cadeia cruzada e 4 paradigmas de tecnologia de cadeia cruzada"

As pontes entre cadeias são geralmente resumidas em três paradigmas técnicos: cadeia cruzada de cliente leve, cadeia cruzada de testemunha externa e troca atômica baseada em bloqueio de tempo de hash. De acordo com a indução de Arjun Bhuptani, estes três paradigmas técnicos também podem ser chamados de verificação nativa, verificação externa e verificação local, respectivamente.

Quase todas as pontes cross-chain mais populares atualmente no mercado (como LayerZero, Multichain, Axelar e Hyperlane) são pontes testemunhas externas.

Embora as testemunhas externas tenham melhor compatibilidade entre pontes de cadeia, elas podem ser expandidas para mais blockchains com relativa facilidade. Mas introduz inevitavelmente novos pressupostos de confiança. Os usuários devem confiar no conjunto de testemunhas externas para não praticarem o mal. Em contraste, a camada de confiança das pontes de clientes leves é mais forte e não há necessidade de introduzir novas suposições de confiança. Desde que a cadeia seja segura, a ponte estará segura. Em alguns cenários onde apenas 2 cadeias (ou um pouco mais de 2 cadeias) precisam ser conectadas, pontes de clientes leves serão mais adequadas.

Neste artigo, faremos um balanço das principais pontes de clientes leves atualmente no mercado e o status de desenvolvimento da tecnologia de cadeia cruzada de pontes de clientes leves.

Princípio do cliente leve

Vamos primeiro dar uma visão geral básica dos princípios dos clientes light. Os clientes leves, também chamados de nós leves, são frequentemente apresentados na forma de contratos inteligentes leves na cadeia. O princípio básico da cadeia cruzada de cliente leve é ​​implantar o contrato do nó leve da cadeia de origem na cadeia de destino para verificar as mensagens da cadeia de origem. Se você deseja obter uma cadeia cruzada bidirecional, precisará implantar os contratos de nós leves da outra cadeia nas duas cadeias.

Comparados aos nós completos, os nós leves são nós leves que não armazenam a sequência de blocos completos, mas apenas a sequência de cabeçalhos de bloco. Embora o cabeçalho do bloco seja pequeno, ele contém um resumo criptográfico dos dados completos do bloco. Quando um nó leve precisa saber se uma transação está incluída na cadeia, ele pode realizar a verificação SPV da transação por meio do cabeçalho do bloco no qual a transação está localizada e do caminho Merkle da transação.

Para manter os nós leves da cadeia de origem implantados na cadeia de destino, o agente fora da cadeia precisa sincronizar continuamente os cabeçalhos de bloco da cadeia de origem com a cadeia de destino. Os contratos de nós leves não pressupõem confiança no agente fora da cadeia responsável pela sincronização dos cabeçalhos dos blocos. Como os contratos de nós leves realizam a verificação dos cabeçalhos de bloco que eles sincronizam, os proxies fora da cadeia não podem enganar os nós leves.

A lógica de verificação de nó leve de cabeçalhos de bloco é a mesma de nós completos e nós mineradores e é dividida em duas partes: verificação de validade e verificação de finalidade.

Para a cadeia PoW, a verificação de validade refere-se principalmente à verificação da prova de trabalho do bloco, e a verificação de finalidade é ver se há mais blocos válidos adicionados após o cabeçalho do bloco (na cadeia BTC, geralmente considera-se que 6 A adição de blocos pode confirmar a finalidade de um bloco. No Ethereum, geralmente acredita-se que a adição de 25 blocos pode confirmar a finalidade de um bloco).

Para cadeias PoS, a verificação de validade refere-se a verificar se o bloco é gerado por um produtor de bloco selecionado aleatoriamente, e a verificação de finalidade consiste em verificar se o bloco é assinado por verificadores com mais de 2/3 do peso de voto. No entanto, os nós leves do PoS não precisam verificar a validade, apenas a finalidade. Porque na cadeia PoS o bloco final deve ser válido, mas não na cadeia PoW.

Abaixo começamos a fazer um balanço:

Relé BTC

BTC-Relay é o primeiro contrato de nó leve e a primeira ponte de cadeia cruzada de cliente leve. Seu princípio de funcionamento é muito simples, ou seja, implantar um nó leve BTC SPV no Ethereum para realizar verificação SPV de transações na cadeia BTC.

A função fora da cadeia "Relayer" é responsável por passar continuamente o cabeçalho do bloco da cadeia BTC para o contrato do nó leve. O contrato do nó leve aceita oficialmente o cabeçalho do bloco após verificar sua validade e finalidade.

O Relayer pagará ao Ethereum a taxa de gás para armazenar e verificar o cabeçalho do bloco. Ao mesmo tempo, o Relayer receberá taxas como compensação do usuário que iniciou a solicitação de cadeia cruzada e obterá os lucros apropriados. Qualquer pessoa pode se tornar um Relayer e definir o padrão de cobrança para cada chamada. Se outros quiserem se tornar um Relayer, eles podem pagar uma pequena taxa ao Relayer atual e definir um padrão de cobrança mais baixo se o usuário estiver preocupado em ser cobrado demais. , Alto, você também pode executar o serviço Relayer sozinho.

Deve-se notar que o BTC Relay é uma ponte unidirecional que suporta apenas a verificação de informações do BTC no Ethereum e não suporta a verificação de informações na direção oposta. Portanto, o BTC Relay não emite ativos derivativos entre cadeias de BTC e seu caso de uso é limitado a apoiar os usuários no uso do Bitcoin para pagar taxas no Ethereum.

Obviamente, o BTC Relay pode ser usado como um bloco de construção e uma camada de confiança unidirecional para fornecer serviços de verificação de transações na direção BTC→Ethereum para outros derivados de cadeia cruzada BTC.

Site oficial do BTC Relay: http://btcrelay.org/BTC Documentação do Relay: https://github.com/ethereum/btcrelay

Ponte Waterloo

WaterLoo Bridge é uma ponte de cadeia cruzada desenvolvida pela Kyber Network. É também a primeira ponte de cadeia cruzada a implementar verificação de cliente leve bidirecional. Ela implementa cadeia cruzada bidirecional entre Ethereum e EOS. Embora o WaterLoo Bridge tenha recebido pouca atenção devido ao declínio do EOS, a sua solução técnica ainda é representativa.

Waterloo Bridge implementa o cliente leve do EOS por meio de contratos inteligentes Ethereum e também implementa o cliente leve do Ethereum por meio de contratos inteligentes EOS.

Como o Ethereum é relativamente lento para produzir blocos e os recursos de computação e armazenamento no EOS são relativamente suficientes, o contrato do nó leve Ethereum estabelecido pela WaterLoo no EOS é um nó leve SPV. É consistente com o princípio do BTC Relay e armazenará o Ethereum. cabeçalho do bloco. Sincronize com os contratos do nó leve um por um.

No entanto, os blocos EOS são produzidos muito rapidamente e os recursos no Ethereum são escassos. Portanto, o contrato do nó leve EOS no Ethereum é projetado para sincronizar apenas os blocos com alterações no conjunto BP (conjunto produtor de blocos), em vez de um por um. sincronizar continuamente todos os blocos. Mas tal projeto precisa resolver dois problemas:

  • Como verificar os cabeçalhos dos blocos históricos: Quando a transação a ser verificada não está no bloco armazenado, o contrato do nó leve precisa primeiro obter o cabeçalho do bloco correspondente do nó completo. Mas ainda há um processo de verificação necessário aqui. Como o contrato do nó leve verifica esses cabeçalhos de bloco obtidos?

  • Como verificar o último cabeçalho do bloco: Como verificar a finalidade do último cabeçalho do bloco sincronizado sem ter o histórico completo do cabeçalho do bloco?

Como verificar cabeçalhos de blocos históricos

O contrato do nó leve precisa ser capaz de verificar o cabeçalho do bloco obtido do nó completo com base no cabeçalho do bloco armazenado. Como fazer isso? Precisamos entender que o protocolo de consenso do EOS é o DPoS. O Staker do $EOS elege 21 BPs (Block Producers) por meio de votação. Esses 21 BPs se revezam para gerar blocos de forma circular. serão processados ​​por 21 BPs, os blocos assinados por mais de 15 BPs serão considerados finais e essas assinaturas serão refletidas no cabeçalho do bloco.

Embora o EOS produza blocos mais rapidamente, o conjunto de BP não muda com muita frequência. Contanto que o cliente leve tenha a lista de conjuntos de BP (lista de chaves públicas), ele pode verificar todos os cabeçalhos de bloco dentro do prazo do conjunto de BP. Ou seja, caso o cabeçalho do bloco obtido do nó completo tenha sido assinado por 15 BPs no prazo correspondente, ele será aceito pelo contrato do cliente light.

Como verificar o cabeçalho do bloco mais recente

Como a votação eleitoral para o conjunto de BP ocorre na cadeia, os resultados da votação serão refletidos no cabeçalho do bloco de um determinado bloco. Bloco{i} O cabeçalho do bloco do Bloco{i} refletirá a lista do conjunto de BP e seus respectivos. termos. Quando o Bloco{i} e o novo conjunto de BP nele contido forem gerados, o novo conjunto de BP ainda não entrou em vigor e o Bloco{i} será assinado pelo conjunto de BP antigo.

Simplificando, também podemos entender que o antigo conjunto do BP aprovou o novo conjunto do BP assinando um bloco contendo os resultados eleitorais do novo conjunto do BP. Contanto que o cliente leve compreenda corretamente o conjunto BP inicial e compreenda o bloco onde o conjunto BP muda a cada vez, por meio de uma "cadeia de relacionamento de aprovação", ele pode ser rastreado até o conjunto BP mais recente. Ao dominar o conjunto de PA mais recente, você pode verificar o bloco mais recente.

Portanto, desde que o conjunto inicial correto de BP seja inserido no contrato do cliente light durante a inicialização, o cliente light poderá concluir o trabalho de verificação subsequente por conta própria.

Processo de verificação de mensagens

Quando há uma mensagem no EOS que precisa ser transmitida entre cadeias para Ethereum, o Waterloo Bridge irá: ① Verificar se o cabeçalho do bloco onde a mensagem está localizada já existe no cliente light. prossiga para a etapa ②. Se existir, prossiga para a etapa ③; o Relayer obtém o cabeçalho do bloco onde a mensagem está localizada do nó completo e a envia ao cliente light. no último conjunto de BPs que possui. Em outras palavras, o cliente light verifica o cabeçalho do bloco. Determine se é válido se for assinado por mais de 2/3 do conjunto de BPs. verificação para realizar a verificação SPV na mensagem.

O mecanismo de consenso do EOS pertence ao mecanismo de consenso do tipo BFT, e o método de implementação do cliente leve do EOS tornou-se um paradigma típico dos clientes leves da cadeia pública do tipo BFT.

Introdução à Ponte WaterLoo (Parte 1) https://blog.kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-1c230ac65524 Introdução à Ponte WaterLoo (Parte 2) https://blog .kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-c25b1698f010

Ponte de Arco-Íris

A ponte Rainbow é a ponte cruzada oficial desenvolvida pela Near para conectar o ecossistema Near e o ecossistema Ethereum. A documentação da ponte Rainbow menciona: O principal designer da ponte Rainbow é Anton Bukov, que agora é o CTO da 1inch. Embora não trabalhe mais em tempo integral na Near, ele ainda orienta o desenvolvimento da ponte Rainbow.

estrutura

Os componentes principais do Rainbow Bridge são dois contratos on-chain e três agentes off-chain:

Contrato em cadeia:

  • EthOnNearClient: nó leve Ethereum implementado como um contrato Near em Rust

  • NearOnEthClient: nó quase leve implementado como um contrato Ethereum no Solidity

Proxy fora da cadeia:

  • Eth2NearRelay: Responsável por passar o cabeçalho do bloco Ethereum para EthOnNearClient

  • Near2EthRelay: Responsável por passar o cabeçalho do bloco Near para NearOnEthClient

  • Watchdog: Responsável por desafiar o Near2EthRelay que envia cabeçalhos de bloco inválidos, detalhes posteriormente

EthOnNearClient precisa rastrear cada cabeçalho de bloco no Ethereum. NearOnEthClient só precisa rastrear um cabeçalho de bloco para cada época. Uma época próxima tem cerca de 43.000 blocos, o que leva cerca de 4 horas. Felizmente, o conjunto de validadores do Near só mudará uma vez por época, e cada época terá apenas um cabeçalho de bloco contendo as informações de seleção do conjunto de validadores. O design do NearOnEthClient baseia-se fortemente no EosOnEthClient do WaterLoo Bridge e até reutiliza parte do código do WaterLoo Bridge.

Mas para NearOnEthClient, ainda há um problema técnico, ou seja, Ethereum não é compatível com o formato de assinatura Ed25519 usado por Near, o que torna a verificação de cabeçalhos de bloco Near por NearOnEthClient muito problemática. Portanto, Rainbow Bridge introduz um esquema de verificação otimista.

Quando Near2EthRelay envia o cabeçalho do bloco para NearOnEthClient, ele precisa hipotecar alguns $NEAR na cadeia Near. Durante a janela de 4 horas, os desafiantes chamados Watchdogs podem levantar desafios. o cabeçalho do bloco é oficialmente aceito pelo NearOnEthClient. Se um Watchdog levantar um desafio, e o desafio for bem-sucedido, o Near2EthRelay que enviou o cabeçalho do bloco inválido pagará um preço financeiro, metade de sua garantia será destruída e a metade restante se tornará a recompensa do Watchdog que levantou o desafio .

A introdução da verificação otimista traz uma nova suposição de confiança: pelo menos um Watchdog é leal.

No BTC Relay, apenas um Relayer está em execução ao mesmo tempo, mas no Rainbow Bridge, seja Eth2NearRelay ou Near2EthRelay, vários podem ser executados ao mesmo tempo. Vários Relayers podem competir entre si e tentar enviar o mesmo bloco ao mesmo tempo. Apenas um Relayers pode formar backups entre si. Se um Relayer não enviar um bloco a tempo, outros Relayers ainda o farão. enviá-lo, o que reduz a possibilidade de indisponibilidade do serviço.

Incentivos

Atualmente, o Rainbow Bridge não fornece incentivos econômicos para os dois conjuntos de serviços de retransmissão que encaminham cabeçalhos de bloco, porque Near espera que os principais aplicativos executados no Rainbow Bridge (por exemplo: $ETH Asset Bridge, $NEAR Asset Bridge, ERC20 Asset Bridge, NFT Bridge) executará automaticamente serviços de retransmissão, e pelo menos um par de serviços de retransmissão são oficialmente executados pela Near. Versões futuras do Rainbow Bridge podem aumentar os incentivos econômicos para serviços de retransmissão e aumentar os mecanismos de cobrança correspondentes para usuários/aplicativos entre cadeias.

últimos progressos

Near lançou o ambiente compatível com EVM Aurora. Atualmente, o Rainbow Bridge 2.0 suporta a cadeia cruzada entre Ethereum e Aurora. Se você precisar fazer a cadeia cruzada de Ethereum para Near, precisará passar pela transferência Aurora. Deve-se notar que, embora Aurora mantenha um livro-razão independente e tenha um navegador de blockchain independente, não é um blockchain independente, mas um tempo de execução no Near Aurora não possui um conjunto de validadores independentes. A ponte entre Aurora não é uma cruz. -chain bridge, mas uma ponte entre tempos de execução. Também precisamos observar que, no momento em que escrevo este artigo, Ethereum acabava de concluir sua transformação PoS. Portanto, os clientes leves Ethereum projetados para a versão PoW no Rainbow Bridge e WaterLoo Bridge podem ser redesenhados em um futuro próximo.

Documento de introdução próximo:

https://near.org/blog/eth-near-rainbow-bridge/

Ponte de Neve（Forquilha de Neve）

SnowBridge é um projeto oficial de ponte cruzada com Polkadot, desenvolvido pela equipe Snowfork. Seu objetivo é criar uma ponte de verificação nativa entre o ecossistema Polkadot e Ethereum.

Snowbridge é um projeto que ainda está em desenvolvimento. Nosso conhecimento sobre ele vem da documentação atual do SnowBridge, que parece estar inacabada. Em alguns lugares, ainda diz “em breve, só podemos avaliar o snowbridge com base nos materiais existentes”. . Execute a análise.

Snowbridge terá seu próprio parachain, que funcionará como um parachain de bem-estar público no futuro, chamado SnowBridge Parachain. Este parachain será responsável por estabelecer uma ponte com Ethereum. Outros parachains farão uma ponte indireta com Ethereum por meio de SnowBridge Parachain e XCMP. Isso significa que o nó leve Pallet do Ethereum será executado no SnowBridge Parachain.

  • Não há conceito de contrato no Substrate. Os desenvolvedores implantam aplicativos na cadeia adicionando paletes, mas sua essência é a mesma dos contratos e ambos são tempos de execução na cadeia.

Snowbridge será composto pelos seguintes módulos

Contratos implantados no Ethereum:

  • Polkadot RPC: usado para lidar com solicitações entre cadeias no Ethereum

  • VERIFICADOR DE CLIENTE POLKADOT E PARACHAIN ​​​​LIGHT

Palete implantada no Snowbridge Parachain:

  • ETHEREUM RPC é usado para lidar com solicitações entre cadeias no Polkadot

  • VERIFICADOR DE CLIENTE Ethereum LIGHT

Cliente leve Ethereum em Snowbridge Parachain

De acordo com a documentação atual de Snowbridge (2022.10.14), o cliente light Ethereum é projetado como um nó light SPV. O Relayer será responsável por sincronizar os cabeçalhos dos blocos Ethereum um por um. A divisão mais pesada. (Mas para se adaptar ao Ethereum após sua transformação para PoS, Snowbridge deveria ter novas soluções.)

Cliente leve Polkadot no Ethereum

Deve-se notar que, como a cadeia de retransmissão é responsável pelo consenso do SnowBridge Parachain, o cliente leve sincronizará o cabeçalho do bloco da cadeia de retransmissão, não o cabeçalho do bloco do SnowBridge Parachain. Para acompanhar as informações mais recentes do conjunto de validadores, o cabeçalho do bloco que contém a nova seleção do conjunto de validadores deve ser sincronizado, o que significa que pelo menos um cabeçalho de bloco precisa ser sincronizado a cada época. Quando há uma transação que precisa ser verificada, o cabeçalho do bloco SnowBridge Parachain é solicitado da cadeia de retransmissão conforme necessário e sua finalidade é verificada usando o cabeçalho do bloco da cadeia de retransmissão que o contém.

Comparado com WaterLoo, Snowfork tem que enfrentar um novo problema: EOS tem apenas 21 validadores, mas Polkadot tem cerca de 1.000 validadores. Mesmo que apenas 2/3 dos validadores tenham assinado um bloco, 600 serão verificados no Ethereum. assinaturas também é escandalosamente alta. Rainbow Bridge contorna esse problema por meio de autenticação otimista, enquanto Snowfork opta por enfrentá-lo de frente.

A solução de Snowbridge é adotar um mecanismo de amostragem: ao obter o cabeçalho do bloco, o cliente light seleciona aleatoriamente um subconjunto do conjunto de validadores correspondente ao cabeçalho do bloco. O cliente light apenas verificará as assinaturas deste subconjunto sem ter que verificar todas. assinatura. De acordo com a pesquisa de Snowfork, o número de validadores neste subconjunto precisa apenas de ceil(log2(3*N)) (N é o número total de validações). Se N for 1000, apenas 12 assinaturas do validador precisarão ser extraídas.

CARINHOSO

Para melhor apoiar a ponte com outras cadeias públicas, Polkadot desenvolveu um gadget final chamado BEEFY com base no consenso GRANDPA (no momento em que este livro foi escrito, o código do BEEFY ainda estava sendo melhorado). Depois que o bloco da cadeia de retransmissão Polkadot for encerrado pelo GRANDPA, haverá um link de assinatura de consenso BEEFY. Nesse link, o validador precisa adicionar enraizamento MMR ao cabeçalho do bloco e, em seguida, conduzir uma rodada separada de assinatura de consenso no bloco. cabeçalho.

Com o BEEFY, os clientes light não precisarão entender os meandros do GRANDPA e só precisarão verificar a assinatura do BEEFY. O mais importante é que o formato de assinatura BEEFY é totalmente compatível com Ethereum, facilitando a verificação no lado Ethereum.

Incentivos

SnowBridge é lançado em duas fases. A primeira fase é a Ponte Básica. Esta fase já possui as funções básicas de uma ponte entre cadeias, mas não há camada de incentivo. Não há incentivos para Head Relayer e Message Relayer. Se os usuários/aplicativos quiserem garantir que suas mensagens sejam retransmitidas com êxito, eles próprios precisarão executar o serviço Relayer. A segunda fase fará a transição para a Ponte de Incentivos, que estabelecerá incentivos para Relayers.

Camada de aplicação

No plano da equipe Snowfork, depois que o SnowBridge estiver online, três pontes de ativos serão lançadas em breve, a saber, DOT Asset Bridge: apoia a criação do snowDOT ETH Asset Bridge no Ethereum, apoia a criação do snowETH ERC20 Asset Bridge no lado Polkadot: apoia o Create; uma versão mapeada do ativo ERC20 no lado Polkadot, com o formato de nomenclatura: neve-[nome do ativo].

Documentação de Snowbridge

https://snowbridge-docs.snowfork.com/

Documentação robusta

https://github.com/paritytech/grandpa-bridge-gadget/blob/master/docs/walkthrough.md

LCMP（Darwinia）

LCMP (Light-client Cross-chain Messaging Protocol) é um protocolo heterogêneo de cadeia cruzada desenvolvido pela Darwinia. É um protocolo de transmissão de cadeia cruzada universal e aberto baseado em uma solução de cliente leve. O protocolo está atualmente na forma de um SDK, permitindo a integração livre de Dapps. Na estrutura ecológica de cadeia cruzada construída por Darwinia, existem duas cadeias, Darwinia Chain e Darwinia Parachain é a cadeia paralela de Polkadot. Ambas têm redes canárias correspondentes, Crab Chain e Crab Parachain, das quais Crab Parachain é Kusama. de cadeias paralelas.

Um ambiente compatível com EVM é implantado no Darwinia Chain, chamado Darwinia Smart Chain. É chamado de Chain porque o Darwinia Smart Chain possui uma máquina de estado e um navegador independentes, mas não é um blockchain independente. (Veja o relacionamento entre Aurora e Near) Correspondentemente, existe um ambiente compatível com EVM no Crab Chain, chamado Crab Smart Chain.

Design de cliente leve

No momento em que este livro foi escrito, o LCMP foi implementado

  • A ponte entre a Cadeia Darwinia e Ethereum

  • Fazendo uma ponte entre a cadeia de caranguejo e o parachain de caranguejo

Entre eles, a solução de cliente light utilizada por este último é a mesma de Waterloo. Focamos no conjunto de clientes light utilizados para fazer a ponte entre Darwinia Chain e Ethereum. Cliente da Darwinia Chain no Eth Como o Beefy ainda não está disponível, a assinatura do cabeçalho do bloco da Darwinia Chain desenvolvida com base no Substrate não é compatível com o Ethereum.

Darwinia atualmente adota um plano de transição e elege um grupo signatário através da governança do parlamento, que é responsável por assinar o cabeçalho do bloco da Cadeia Darwinia. O cliente light verificará se o cabeçalho do bloco é legal, verificando a assinatura do grupo. Embora existam mais de 100 validadores na Darwinia Chain, o grupo de signatários não excede 10 pessoas, e o custo econômico do lado Ethereum de verificar essas assinaturas é aceitável.

Cliente Eth na cadeia Darwinia

A cadeia de beacons Ethereum mesclada, como uma cadeia PoS, tem centenas de milhares de validadores e é obviamente irrealista verificar suas assinaturas. Portanto, Ethereum adicionou um novo link de consenso em uma atualização chamada Altair. Após a atualização do Altair, um comitê de 512 validadores será selecionado entre os validadores da cadeia Ethereum a cada 256 épocas (aproximadamente 27 horas). Eles serão responsáveis ​​por assinar o cabeçalho do bloco finalizado. O cliente light só precisa verificar se 2/3 do comitê assinou para verificar o cabeçalho do bloco. No entanto, 512 ainda é um pouco demais, então Ethereum também usa a tecnologia BLS para agregar as inúmeras assinaturas do comitê em uma única assinatura, o que reduz ainda mais o custo de verificação de clientes leves.

Darwinia foi atualizado com base no Altair e implementou um cliente leve de Ethereum na Cadeia Darwinia. O cliente leve só precisa sincronizar um cabeçalho de bloco a cada 27 horas. Este deve ser o primeiro cliente leve on-chain implementado no Ethereum após a transformação do PoS.

Taxas e incentivos

O iniciador cross-chain (que pode ser um usuário ou um Dapp) precisa pagar uma taxa ao enviar uma mensagem cross-chain. A taxa incluirá três partes:

  • Taxas de gás para execução de transações da cadeia de origem.

  • Taxas pagas ao Relayer.

O preço específico é determinado pelo mercado e vários Relayers podem competir em preço. Deve-se notar que o Relayer precisa pagar a taxa do Gas na cadeia alvo, e o Relayer refletirá esse custo no preço. Em outras palavras, o iniciador da cadeia cruzada não precisa mais pagar a taxa do Gas na cadeia alvo. separadamente.

  • Taxas pagas ao Tesouro.

Uma certa porcentagem das taxas de cadeia cruzada pagas pelos iniciadores de cadeia cruzada irá para o Tesouro Darwinia. A Treasure usará parte de seus fundos para subsidiar o Head Relayer.

Documentos de Darwinia:

https://docs.darwinia.network/lcmp-overview

Fork do Altair https://blockdaemon.com/blog/ethereum-altair-hard-folk-light-clients-sync-committees/

zkBridge

No momento em que este livro foi escrito, zkBridge era um projeto nascente com apenas uma pequena parte do desenvolvimento concluído. Mas este projeto é um dos poucos até agora que utiliza tecnologia de prova de conhecimento zero para a construção de pontes entre cadeias. zkBridge usa prova ZK-SNARK para a expansão de nós leves.

Atualmente, zkBridge implementou uma instância do Cosmos Client no Ethereum usando Solidity. De acordo com testes, ele pode gerar um certificado ZK-SNARK para o cabeçalho do bloco Cosmos Zone em 2 minutos e, em seguida, verificá-lo no lado Ethereum gastando apenas 220k de gás. Em contrapartida, se a prova ZK-SNARK não for utilizada, o custo será de 64 milhões de gás.

As principais inovações do zkBridge são:

  • deVirgo: Use um método distribuído para gerar provas ZK-SNARK. Este método é chamado de deVirgo. Este método melhora muito a eficiência de geração de provas ZK-SNARK fora da cadeia, dividindo o trabalho de cálculo e alocando-o para mais dispositivos.

  • Prova recursiva: Para reduzir os custos na cadeia, zkBridge usa um esquema de prova recursiva (uma prova que gera uma prova) para compactar a prova ZK-SNARK para cerca de 131 bytes por meio de duas recursões.

  • Processamento em lote: zkBridge implementa um contrato de atualização de cabeçalho de bloco, que toma a altura do bloco como entrada e retorna o cabeçalho do bloco correspondente. No entanto, zkBridge não chama o contrato de atualização quando cada novo bloco é gerado. O provador pode primeiro coletar N cabeçalhos de bloco para gerar uma única prova. O valor N pode ser definido. Quanto maior for N, maior será o tempo de espera do usuário, mas menor será o custo operacional do sistema.

Deve ser dito que a tecnologia à prova de conhecimento zero é uma tecnologia que pode criar milagres. O principal gargalo que restringe a sua adoção é o elevado limiar técnico e a dificuldade de desenvolvimento. No entanto, no desenvolvimento de tecnologia à prova de conhecimento zero, as recompensas e os esforços são sempre proporcionais.

Post longo do zkBridge no Twitter: https://twitter.com/dawnsongtweets/status/1574775723767783424

papel zkbridge:

https://rdi.berkeley.edu/zkp/zkBridge/uploads/paper.pdf

Protocolo MAP

O protocolo MAP é um protocolo geral heterogêneo de cadeia cruzada baseado em clientes leves e cadeias de retransmissão.

Ao contrário de muitos dos projetos mencionados acima, o MAP optou por estabelecer uma cadeia de retransmissão MAP Chain como uma estação de transferência para transmissão de mensagens entre cadeias. As cadeias de acesso não precisam estar diretamente conectadas entre si, mas estão todas conectadas à Cadeia MAP. Ou seja: cada cadeia de acesso precisa apenas implantar o contrato de nó leve da Cadeia MAP e os nós leves de cada acesso. cadeia são implantados no contrato MAP Chain.

A arquitetura do Protocolo MAP é dividida em três camadas, nomeadamente camada de protocolo, camada de serviço cross-chain e camada de aplicação. em:

  • Camada de protocolo: Podemos entendê-la como a camada de confiança, incluindo a Cadeia MAP e cada programa cliente leve da cadeia de acesso;

  • Camada de serviço entre cadeias: Fornece alguns módulos comuns para a camada de aplicativo, para que a camada de aplicativo não precise "reinventar a roda". Por exemplo, um módulo Vault comum pode bloquear fundos para alguns aplicativos de ponte de ativos, mas os aplicativos também podem escolher. para construir seus próprios Vaults. Este módulo não é usado.

  • Camada de aplicação: refere-se a aplicações que usam o protocolo MAP como meio de transmissão de mensagens entre cadeias.

Além disso, o protocolo MAP inclui três funções fora da cadeia

  • Mantenedor: Responsável por atualizar os cabeçalhos dos blocos de cada contrato de nó leve e pode obter recompensas de inflação de $ MAP.

  • Mensageiro: Responsável pela entrega de mensagens entre cadeias e pode obter taxas entre cadeias pagas pelos usuários, mas precisa adiantar as taxas de gás na cadeia de destino e na cadeia de retransmissão.

  • Verificador da Cadeia MAP: Responsável pelo processo de consenso da Cadeia MAP e precisa prometer $MAP para obter recompensas de inflação de $MAP. A MAP Chain usa atualmente o mecanismo de consenso IBFT-PoS.

Fluxo de mensagens entre cadeias

O documento do Protocolo MAP não menciona muito sobre o mecanismo de transmissão de mensagens. Pelas poucas palavras atuais, o fluxo de mensagens deve ser assim: Quando o aplicativo na cadeia de origem inicia uma solicitação de cadeia cruzada, a mensagem de cadeia cruzada M é incluída. em uma transação T1, ele é enviado para a cadeia de retransmissão pelo mensageiro. Após receber a transação T1, a cadeia de retransmissão inclui a transação T1 e a mensagem M que ela carrega na transação T2. O mensageiro retransmite T2 para a cadeia de destino. a cadeia de destino recebe para T2 e a envia para o aplicativo de destino após verificação.

Embora o Protocolo MAP seja um projeto lançado em 2019, até o momento, as únicas cadeias suportadas são Ethereum, BSC e Polygon. A palavra “universal” não faz jus ao seu nome. Na verdade, uma vez que os contratos de nós leves não podem ser reutilizados quando expandidos para cadeias diferentes e precisam ser desenvolvidos separadamente, as pontes entre cadeias baseadas em contratos de nós leves são difíceis de serem "universais".

Documentação do protocolo MAP https://docs.maplabs.io/

Cosmos IBC

IBC é um protocolo de cadeia cruzada isomórfico muito bem projetado e uma parte importante da rede de cadeia cruzada Cosmos. A rede de cadeia cruzada Cosmos é composta principalmente de Hub e Zona e Hub são interligados por meio do protocolo IBC (InterBlcokChain). . Zonas e pontes são estabelecidas entre zonas usando o hub como retransmissão. A rede cross-chain Cosmos também inclui Peg Zone e partes de ponte heterogêneas, que não estão dentro do escopo do IBC. Tanto o Hub quanto a Zona estão abertos para acesso. Qualquer blockchain construído com base no Cosmos SDK pode se tornar um Hub ou se tornar uma Zona e registrar-se como uma cadeia de acesso com qualquer Hub. Ao contrário da cadeia de retransmissão de Polkadot, o Cosmos’ Hub não é único.

cliente leve

Cada Zona cadastrada no Hub precisa implantar um módulo IBC, que contém o contrato de cliente light do Hub. O módulo IBC no Hub também integrará o contrato de cliente light de cada Zona conectada.

Não existe conceito de época no mecanismo de consenso do Tendermint, e cada bloco pode resultar em mudanças nos validadores. Porém, o contrato do cliente light no IBC tem o conceito de TrustPeriod (período de confiança), que é um parâmetro que o cliente light precisa definir durante a inicialização. Dentro de um TrustPeriod, o conjunto de verificadores pode fazer pequenas alterações, e verificadores individuais Você. poderá aderir ou sair, mas não haverá grandes mudanças.

Esta pequena alteração é aceitável porque cada assinatura raramente terá exatamente 2/3 do poder de voto e sempre haverá um certo excesso. Mesmo que os validadores individuais entrem ou saiam, o cliente light seguirá a verificação antes da alteração. o conjunto do usuário verifica o cabeçalho do bloco, há uma grande probabilidade de ainda ser observado que 2/3 do poder de voto foi assinado.

Portanto, o contrato de cliente leve no IBC só precisa atualizar as informações do conjunto de validadores uma vez por TrustPeriod, o que significa que cada TrustPeriod precisa sincronizar apenas um cabeçalho de bloco.

O trabalho de sincronização dos cabeçalhos dos blocos será realizado pelo Relayer.

Conceitos e princípios fundamentais

O IBC constrói três conceitos abstratos, nomeadamente Conexão, Canal e Pacote.

  • Conexão

Conexão refere-se à conexão entre duas Zonas. Estabelecer uma Conexão pode ser entendido como emparelhar duas Zonas. Neste momento, as duas Zonas solicitam o último cabeçalho de bloco do cliente light uma da outra do Hub. O estabelecimento da conexão segue o princípio do handshake de três vias (a comunicação do handshake é acionada pelo Relayer). Após a conclusão do handshake, o Connection é aberto.

Neste ponto, o Canal pode ser estabelecido sobre a Conexão. A Conexão de Canal conecta duas Zonas, enquanto o Canal conecta um par de aplicativos nas duas Zonas (o par de aplicativos pode vir do mesmo aplicativo ou de aplicativos diferentes). Duas aplicações estabelecem um canal através do princípio de handshake de três vias (a comunicação de handshake é acionada pelo Relayer). Depois que o canal é estabelecido, as duas aplicações podem enviar pacotes entre si.

  • Canal

Canal é o conceito central do IBC, que permite que os aplicativos estabeleçam conexões diretamente. Como conceito abstrato, Canal não existe como entidade. Para o aplicativo receptor, Canal define o remetente. Se você souber de qual canal a mensagem vem, saberá de qual aplicativo a mensagem vem. , No que diz respeito às aplicações, Canal define o destinatário para qual aplicação você deseja enviar uma mensagem, coloque a mensagem no Canal correspondente.

O canal também define o tempo da mensagem. As mensagens no mesmo canal seguem uma fila e têm uma relação de tempo estrita. A mensagem enviada primeiro sempre chega primeiro. Não há relação de tempo entre mensagens em canais diferentes.

O que precisa ser observado aqui é que é melhor para um aplicativo usar um Canal de forma estável. Por exemplo, se um aplicativo de ponte de ativos usar vários canais para criar ativos mapeados na cadeia de destino, vários canais gerarão ativos mapeados diferentes, o que causará problemas desnecessários.

  • Pacote

Pacote é uma estrutura de dados padronizada e um formato prescrito para mensagens cross-chain que podem ser transmitidas no Canal. A transmissão de pacotes é dividida em três etapas:

  • sendPacket: A aplicação do lado remetente cria um pacote com número de série N na cadeia de origem e o adiciona à fila de espera;

  • recvPacket: O Relayer retransmite o pacote para a cadeia de destino, onde é armazenado pelo aplicativo na extremidade receptora.

  • reconhecimentoPacket: O Relayer transmite a prova de que o aplicativo receptor armazenou o pacote de volta para a cadeia de origem, e a cadeia de origem exclui o pacote com número de série N na fila de saída.

Se o contrato receptor não armazenar o Pacote por um longo período, o Relay retornará uma mensagem de tempo limite. Deve-se observar que o Cosmos IBC é diferente do protocolo MAP. Os pacotes são enviados diretamente da zona de origem para a zona de destino e não precisam ser transitados no Hub. Isso ocorre porque a zona de destino pode consultar diretamente o hub em busca do cabeçalho do bloco da zona de origem e, em seguida, realizar a verificação do pacote. Isso significa que o Hub só precisa encaminhar o cabeçalho do bloco.

Especificamente, há um nó leve da zona de origem no hub, que pode verificar o cabeçalho do bloco da zona de origem. Há um nó leve do hub na zona de destino, que pode verificar o cabeçalho do bloco do hub. a zona de destino requer um determinado cabeçalho de bloco da zona de origem SourceZoneBlockHead{i }, você pode permitir que o Relayer o obtenha do Hub. O nó leve na zona de destino verifica HubBlockHead{i} e usa HubBlockHead{i} para verificar SourceZoneBlockHead{i. }. Depois disso, você pode usar SourceZoneBlockHead{i} para verificar o pacote da zona de origem.

Taxas e incentivos

Existe um módulo de taxa configurável no IBC, e o iniciador do Connection pode personalizar o padrão de cobrança e o padrão de pagamento do Relayer. No entanto, de acordo com nossa observação, as partes do projeto Zone e as partes do projeto de aplicativo geralmente são motivadas a executar o Relayer por conta própria.

Documentos do Cosmos IBC

https://ibc.cosmos.network/Cosmos Análise de código IBC https://blog.csdn.net/mutourend/article/details/122576435

resumo

Atualmente, em termos de design de soluções de clientes leves, os clientes leves PoW ainda são baseados em clientes leves SPV, que sincronizam todos os cabeçalhos de bloco da cadeia de origem um por um, enquanto os clientes leves PoS adotam principalmente um esquema de sincronização de salto de cabeçalhos de bloco Apenas os cabeçalhos dos blocos que alteram o conjunto de validadores são sincronizados. Só precisamos deixar o cliente light captar as alterações no conjunto de validadores se a inicialização estiver correta, para que o cliente light possa captar o conjunto de validadores mais recente.

Na prática, a construção de clientes leves também encontrará problemas como altos custos de verificação de cabeçalho de bloco e incompatibilidade de esquemas de assinatura. Diferentes projetos adotarão métodos diferentes para lidar com eles, incluindo verificação otimista (RainbowBridge), amostragem de conjunto de validadores (Snowfork), Provas de conhecimento zero (zkBridge) são geradas fora da cadeia. Além disso, para melhor suportar cadeias cruzadas, as cadeias públicas também são motivadas a se transformar e atualizar, como a atualização Ethereum Altair e o desenvolvimento do módulo Beefy pela Polkadot.

Em suma, a tecnologia de clientes leves ainda está em intensa evolução. Com mais pesquisa e exploração, a dificuldade de construir clientes leves diminuirá gradativamente no futuro.