Blockchains díspares precisam de ter uma forma de comunicar para que os utilizadores possam interagir com dados e ativos em várias 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 primeiro o IBC, mas, como é um protocolo generalizável, o IBC encontrou o seu caminho em muitos outros ecossistemas.

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

Do ponto de vista do IBC, cada rede é normalmente identificada pelo seu cliente leve. A verificação mais comum ocorre entre duas máquinas de estado comunicantes; usando um cliente leve, uma rede de origem é capaz de verificar atualizações de uma rede 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 da blockchain garante que todos os nós que participam numa rede estejam sincronizados. Usando a verificação do 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 através do IBC. Por exemplo, as cadeias Cosmos usam o algoritmo de consenso Tendermint, que tem finalidade de um único slot, também conhecida como finalidade rápida. Por outro lado, o consenso do Ethereum não tem finalidade de um único slot e, portanto, uma finalidade mais lenta, pois valoriza a vivacidade em detrimento da segurança, enquanto o IBC é mais compatível com algoritmos de consenso que valorizam a segurança. Devido a essa diferença em quando os blocos são considerados 'finais', há dificuldade em como as duas cadeias podem enviar e verificar blocos entre si.

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

Clientes Leves: Máquinas de Estado

Uma “máquina de estados” pode ser toda uma blockchain (registo replicado) ou um único processo que assina operações com uma chave privada (consenso mínimo), como um portátil ou telemóvel.

Comumente, pensamos em máquinas de estado como blockchains com ledgers 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 conseguir isso, o algoritmo do cliente leve não replica 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, telemóvel 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, a IBC pode permitir uma protocolo de transferência custodialque reduz os custos de integração para novas cadeias. Isto é 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, cunhagem/queima. A verificação seria realizada pelo cliente da máquina conectada executada pelo custodiante.

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

Verificação Além de Provas de Consenso

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

IBC Otimista: Os clientes podem aceitar otimisticamente cabeçalhos de entrada através de um retransmissor fora da cadeia 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 IBC Otimista 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 base para transferência de ativos - para o Ethereum, são 21.000 unidades de gás.

ZK-IBC: Os cálculos do cliente ocorrem fora da cadeia e são verificados na cadeia via ZKPs. Não há latência mínima e o custo é inferior à verificação ingênua. No entanto, a verificação ZK pode ser cara na cadeia e não há latência máxima, o que significa que um usuário pode ter que esperar 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 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 através da incentivação dos relayers.

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

Segurança e Comportamento Indesejado

IBC não requer quaisquer pressupostos de confiança de terceiros, que são frequentemente assumidos por protocolos de interoperabilidade verificados externamente. É simplesmente um protocolo de transporte e as 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 partilhada através da disponibilidade de dados comuns, etc. O protocolo IBC não precisa de conhecer as identidades das cadeias de 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 relayer, 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 é congelado e esperançosamente existe um sistema de governança para tomar medidas. As repercussões da má conduta são decididas pelas cadeias participantes.

Construção com clientes leves

Embora o 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 o IBC - outro objetivo que temos com esta série de artigos. O que importa aqui é que o IBC é uma ferramenta poderosa, dadas as várias implementações de verificação que os clientes podem adotar.

O ecossistema da IBC está a trabalhar ativamente para tornar a IBC uma solução fácil para os construtores adotarem. Algumas das iniciativas que discutimos incluem a reformulação do cliente e clientes virtuais. Por exemplo, se uma cadeia quiser atualizar o consenso, precisará de atualizar todas as cadeias a que está conectada e os seus clientes leves para permanecerem conectados, o que é um processo dispendioso de governança on-chain. Os clientes WASM estão a ser desenvolvidos para tornar simples o desenvolvimento e a atualização de clientes leves através de instâncias de cliente implantadas como contratos inteligentes. Isso torna mais fácil atualizar clientes leves sem interromper a cadeia e criar clientes em linguagens como Rust, que é uma escolha popular entre várias máquinas de estado.

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

Este artigo foi patrocinado pela Polímero para apoiar a educação comunitária em torno do IBC e da interoperabilidade verdadeiramente descentralizada.

Polymer Labs, composto por engenheiros qualificados em sistemas distribuídos e infraestrutura, pioneiros em criptomoedas e operadores de negócios experientes, está na vanguarda do avanço da interoperabilidade do 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ões e uniforme em todos os ecossistemas. Como criadores do Ethereum Interoperability Hub, o primeiro Layer 2 focado em habilitar a interoperabilidade IBC, a Polymer estabelece um novo padrão na tecnologia blockchain.

Aviso legal：

1. Este artigo é reimpresso de [eshitanandini]. Todos os direitos autorais pertencem ao autor original [ESHITA]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles vão tratar dela prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.