Blockchains díspares precisam ter uma maneira de se comunicar para que os usuários possam interagir com dados e ativos em múltiplas blockchains facilmente e, assim, o protocolo de Comunicação Inter-Blockchain (IBC) foi estabelecido para funcionar como uma camada de transporte entre blockchains. O ecossistema Cosmos adotou o IBC primeiro, mas, como é um protocolo generalizável, o IBC encontrou seu caminho em muitos outros ecossistemas.

ICS-02 delineia os requisitos para a construção de clientes leves, incluindo como o IBC gerencia os dados do cliente leve. Clientes são necessários para o IBC funcionar, que são algoritmos de verificação arbitrários para provar informações on-chain, que geralmente são codificadas em formato IBC, de um lugar para outro.

Do ponto de vista do IBC, cada cadeia é normalmente identificada pelo seu cliente leve. A verificação mais comum ocorre entre duas máquinas de estado comunicantes; usando um cliente leve, uma cadeia de origem pode verificar atualizações de uma cadeia de destino sem baixar todos os seus dados. Como os clientes leves são uma ferramenta versátil, eles podem usar vários métodos para verificar o estado.

Verificação de Prova de Consenso

Uma Nota Sobre Algoritmos de Consenso

O consenso do blockchain garante que todos os nós que participam de uma rede estejam sincronizados. Usando a verificação de consenso, o cliente leve prova que um número suficiente de validadores assinou o cabeçalho. Este tipo de verificação é o uso mais popular do IBC.

Algoritmos de consenso geralmente variam em seus conjuntos de regras e no que priorizam. No entanto, a heterogeneidade em dois algoritmos de consenso diferentes pode tornar difícil para as cadeias comunicarem-se por meio do IBC. Por exemplo, as cadeias Cosmos usam o algoritmo de consenso Tendermint, que tem finalização em um único slot, também conhecida como finalização rápida. Por outro lado, o consenso do Ethereum não tem finalização em um único slot e, portanto, finalização mais lenta, porque valoriza a vivacidade sobre a segurança, enquanto o IBC é mais compatível com algoritmos de consenso que valorizam a segurança. Devido a essa diferença no momento em que os blocos são considerados 'finais', há dificuldade em como as duas cadeias conseguem enviar e verificar blocos entre si.

Nesse caso, um cliente leve virtual pode ser implementado, que pode ter uma visão do cliente leve em uma determinada altura de bloco antes que a finalidade seja alcançada. Inicialmente, o IBC focou em sua adoção dentro de cadeias baseadas em Tendermint, o que foi evidente na forma como a especificação do cliente e a implementação foram definidas. Após essa fase inicial, oRefatoração do Clienteaumento de flexibilidade e facilidade no desenvolvimento de clientes leves para cadeias com outros algoritmos de consenso e recursos.

Clientes Leves: Máquinas de Estado

Uma “máquina de estados” pode ser uma blockchain inteira (registro replicado) ou um único processo que assina operações com uma chave privada (consenso mínimo), como um laptop ou telefone celular.

Comumente, pensamos em máquinas de estado como blockchains com registros distribuídos, então, ao estabelecer IBC entre blockchains, um cliente leve da cadeia de destino é hospedado pela cadeia de origem. A cadeia de origem também mantém um estado confiável da cadeia de destino, que é estabelecido por um handshake de conexão entre as duas cadeias. O protocolo IBC usa um predicado de validade, que é um algoritmo que verifica se as atualizações de estado de uma cadeia de destino são válidas. Para funcionar, um cliente leve precisa de um predicado de validade e de um estado confiável para a cadeia de origem.

cliente "tipo" vs. cliente "instância"

Os clientes leves são projetados para serem o mais eficientes possível para suportar um grande número de instâncias de cliente para muitas cadeias. Para alcançar isso, o algoritmo do cliente leve não reproduz todas as transições de estado, o que, de outra forma, o tornaria um nó completo.

Clientes Leves: Máquinas Solo

Uma máquina solo é um dispositivo como um laptop, interface web, celular ou um processo off-chain. Uma máquina solo pode estabelecer comunicaçãocom um livro-razão replicado se esse blockchain usar IBC para transporte.

Como exemplo, IBC pode habilitar um protocolo de transferência custodialque reduz os custos de integração para novas cadeias. Isso é importante porque os custodiantes centralizados enfrentam um processo tedioso e caro ao integrar novas redes, o que requer a execução de um nó completo e infraestrutura RPC para cada cadeia integrada. Em vez disso, o custodiante pode operar um cliente de máquina solo que facilita transferências entre cadeias, cunhas / queimas. A verificação seria realizada pelo cliente da máquina conectada executada pelo custodiante.

Os clientes de máquinas solo mostram como a IBC abre a conectividade fora apenas das blockchains. No exemplo acima, ela pode permitir que instituições interajam facilmente com blockchains públicas via IBC. Este é apenas um exemplo de linhas de negócios que envolvem blockchains sem a necessidade de iniciar uma cadeia inteira ou manter hardware pesado para trabalhar com elas.

Verificação Além das Provas de Consenso

Embora haja trabalho sendo feito para tornar os clientes fáceis de implementar e atualizar, há a opção de conduzir a verificação com validade ou provas de fraude.

Otímica IBC: Os clientes podem aceitar otimisticamente cabeçalhos de entrada via um relé off-chain que executa um programa em alguma máquina virtual. Neste cenário, existe uma janela de desafio onde uma prova de fraude pode ser submetida. O positivo é que o Otímica IBC reduz o custo de todo o sistema. As desvantagens incluem o longo período de desafio de fraude e, dependendo da rede, pode haver altos custos básicos para transferência de ativos - para o Ethereum, isso é 21.000 unidades de gás.

ZK-IBC: As computações do cliente ocorrem off-chain e são verificadas on-chain via ZKPs. Não há latência mínima e o custo é menor do que a verificação ingênua. No entanto, a verificação ZK pode ser cara on-chain e não há latência máxima, o que significa que um usuário pode ficar esperando um pouco para obter confirmação. Também pode haver problemas de incompatibilidade se o esquema de assinatura não for amigável ao SNARK.

Porque os sistemas separados acima podem ter alguns contras proibitivos, o Gate Optimistic ZK é proposto para aproveitar os benefícios de ambos. Os benefícios de usar ambos reduzem o custo da manutenção da conexão e introduzem um limite máximo de latência via incentivo aos relayers.

ZK Otimista: A cadeia de origem aceita cabeçalhos de forma otimista on-chain (possivelmente há um mecanismo de participação em vigor para segurança). Em seguida, as ZKPs são usadas como provas de fraude em caso de má conduta ou provas de validade para reduzir dinamicamente a latência da conexão.

Segurança e Comportamento Indesejado

IBC não exige quaisquer pressupostos de confiança de terceiros, que são frequentemente assumidos por protocolos de interoperabilidade verificados externamente. Trata-se simplesmente de um protocolo de transporte, e suas propriedades de segurança dependem dos tipos de cliente e conexão subjacentes e não da própria cadeia. Também depende do uso de provas de fraude, pressupostos de maioria honesta, segurança compartilhada por meio de disponibilidade comum de dados, etc. O protocolo IBC não precisa conhecer as identidades das cadeias em ambos os lados de uma conexão, desde que os clientes IBC sejam mantidos em sincronia com atualizações válidas.

No caso de má conduta, ou seja, as regras de consenso estabelecidas pela cadeia de destino são quebradas pelo cliente em uma cadeia de origem, o cliente na cadeia de hospedagem seria congelado se a prova da má conduta for verificada na cadeia de origem. A parte que viu isso, como o relé, pode enviar uma mensagem com evidências dessa má conduta. O predicado de má conduta é um algoritmo que é chamado em situações como esta: se a má conduta for comprovada, o cliente fica congelado e, de preferência, há um sistema de governança em vigor para tomar medidas. As repercussões da má conduta são decididas pelas cadeias participantes.

Construindo com Clientes Leves

Embora a IBC possa exigir alguma proficiência técnica no consenso e nas partes internas da cadeia subjacente, nem todas as complexidades são cruciais para construir usando a IBC - outro objetivo que temos com esta série de artigos. A conclusão aqui é que a IBC é uma ferramenta poderosa, dadas as várias implementações de verificação que os clientes podem adotar.

O ecossistema IBC está trabalhando ativamente para tornar o IBC uma solução fácil para os construtores adotarem. Algumas das iniciativas que discutimos incluem refatoração de cliente e clientes virtuais. Por exemplo, se uma cadeia deseja atualizar o consenso, precisará atualizar todas as cadeias às quais está conectada e seus clientes leves para permanecerem conectados, o que é um processo caro de governança on-chain. Clientes WASM estão sendo desenvolvidos para tornar simples o desenvolvimento e a atualização de clientes leves por meio de instâncias de cliente implantadas como contratos inteligentes. Isso torna mais fácil atualizar clientes leves sem parar a cadeia e criar clientes em linguagens como Rust, que é uma escolha popular entre várias máquinas de estado.

A conclusão importante é que os clientes IBC podem ser usados por qualquer pessoa e por qualquer máquina para verificar o estado em qualquer blockchain, tornando-os um catalisador poderoso para novos negócios e serviços no mundo das criptomoedas.

Este artigo foi patrocinado pela Polymer para apoiar a educação da comunidade em torno do IBC e da interoperabilidade verdadeiramente descentralizada.

Polymer Labs, composto por habilidosos engenheiros de sistemas distribuídos e infraestrutura, pioneiros em criptografia e operadores de negócios realizados, está na vanguarda do avanço da interoperabilidade Ethereum com IBC. Com valores técnicos baseados em TCP/IP, a missão da Polymer é estabelecer a próxima geração da internet, garantindo que a camada de interoperabilidade da web descentralizada seja neutra, aberta, sem permissão e uniforme em todos os ecossistemas. Como criadores do Ethereum Interoperability Hub, o primeiro Layer 2 focado em possibilitar a interoperabilidade IBC, a Polymer estabelece um novo padrão na tecnologia blockchain.

Aviso Legal：

1. Este artigo é reproduzido a partir de [eshitanandini]. Todos os direitos autorais pertencem ao autor original [ESHITA]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Responsabilidade de Isenção de Responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.