Neste artigo, apresentamos uma visão geral das pontes do tipo trustless (que independem de confiança em terceiros) e o importante papel que elas desempenham para a interoperabilidade e o futuro da comunicação entre cadeias.
Um relatório recente da Chainalysis estima o valor total perdido em hacks relacionados a pontes em mais de US$ 2 bilhões. Além disso, os três primeiros lugares na tabela de classificação da Rekt são ocupados por pontes: Ronin Network ($624 milhões), Poly Network ($611 milhões) e BNB Bridge ($586 milhões).
Conforme observado pelos principais participantes da indústria, a falta de segurança das pontes enfraquece a confiança do consumidor nas criptomoedas, alimenta percepções negativas na grande mídia e pode até mesmo levar a uma regulação excessiva. Muitas propostas foram feitas para melhorar a segurança da comunicação entre cadeias, mas nenhuma foi tão promissora quanto a introdução de pontes que independem de confiança em terceiros.
Diferentemente dos projetos de pontes atuais, as pontes que não dependem de confiança em terceiros eliminam a necessidade de confiar em um pequeno conjunto de participantes para transmitir informações honestas sobre eventos entre cadeias. Embora uma pesquisa anterior sugira a impossibilidade de comunicação entre cadeias sem uma parte confiável, as pontes do tipo trustless tentam reduzir a necessidade de confiança validando as informações repassadas com provas de conhecimento zero (zero-knowledge proofs).
A segurança das pontes é certamente complexa, com vários vetores de ataque a serem considerados, mas a maioria concorda que as suposições de confiança inerentes aos projetos de pontes contribuíram para muitos ataques. É por isso que o uso da tecnologia de conhecimento zero para facilitar a comunicação entre cadeias sem necessidade de confiança pode ser um divisor de águas para o espaço de interoperabilidade da blockchain.
ELI5: O que é uma ponte trustless?
Uma ponte trustless é uma ponte entre cadeias que utiliza primitivos criptográficos - por exemplo, provas de conhecimento zero - para validar informações passadas entre blockchains em vez de depender de incentivos econômicos ou suposições de honestidade para segurança. Para entender o papel dos incentivos criptoeconômicos e das suposições de honestidade nas pontes atuais, vamos avaliar um caso de uso comum para as pontes hoje: movimentação de ativos.
Suponha que um usuário (que chamamos de Alice) queira mover um token da cadeia A para a cadeia B. O método usual (embora existam outros meios) é bloquear os tokens de Alice na cadeia de origem (cadeia A) e emitir um ativo derivado na cadeia de destino (cadeia B).
Para pontes entre cadeias, a parte crítica da operação é fazer com que a cadeia B aceite que um evento (ou seja, tokens de bloqueio) tenha sido realizado na cadeia A. Mas isso é difícil de implementar, pois a cadeia A e a cadeia B não podem interpretar e validar o estado uma da outra, especialmente se tiverem mecanismos de consenso, conjuntos de validadores e propriedades de segurança diferentes..
Uma solução é executar um light client na cadeia de destino que armazena os cabeçalhos de bloco da cadeia de origem. A cadeia de destino poderia então verificar a existência de determinadas transações verificando as provas de Merkle de transações em relação às raízes de estado contidas nos cabeçalhos de bloco. A desvantagem é que essa abordagem pode exigir muita computação e requer um investimento significativo em taxas de gas.
A maioria das pontes tenta contornar esse problema substituindo a verificação do light client pela validação de eventos on-chain por terceiros. Nesse arranjo, alguém observa as duas cadeias em busca de transações específicas (por exemplo, depósitos e queimas de tokens) e aprova as retiradas e os depósitos nas blockchains interligadas.
Se Alice usar uma ponte centralizada, o "alguém" poderá ser um operador de ponte centralizada ou o membro de um comitê autorizado. Nesse caso, o retransmissor seria confiável para retransmitir informações corretas sobre eventos on-chain para o protocolo da ponte.
Uma ponte descentralizada permitiria que qualquer pessoa retransmitisse mensagens entre cadeias, mas exigiria que os participantes fizessem stake de algum capital primeiro. Como essa participação pode ser reduzida se outro participante detectar fraude, os retransmissores são incentivados economicamente a agir com honestidade. Ainda assim, essa abordagem exige que os usuários confiem na existência de pelo menos um ator honesto para contestar mensagens inválidas por meio de provas de fraude.
Diferentemente dos projetos de ponte mencionados anteriormente, uma ponte trustless elimina a necessidade de confiar nas partes que retransmitem mensagens entre diferentes blockchains. Especificamente, as pontes trustless combinam atualizações de estado de verificação do light client em uma cadeia com provas de conhecimento zero para fornecer um mecanismo robusto de comunicação segura entre cadeias.
Devemos observar que as pontes sem necessidade de confiança em terceiros, descritas neste artigo, não se referem a pontes de rollup canônicas (por exemplo, Arbitrum Bridge), que também têm a confiança minimizada por design. Em vez disso, descrevemos um tipo de ponte trustless que conecta duas blockchains quaisquer e que também valida as mensagens retransmitidas com provas de validade.
A arquitetura das pontes trustless
Light clients
Um light client que sincroniza os cabeçalhos de bloco da cadeia de origem é implementado como um contrato inteligente na cadeia de destino. Isso garante que a cadeia de destino possa verificar informações sobre o estado da cadeia de origem sem depender de uma parte externa. Além disso, permite que qualquer pessoa prove a existência de determinadas transações na cadeia de origem no contexto da cadeia de destino (usando provas de Merkle).
Retransmissores.
A tarefa de retransmitir cabeçalhos de bloco da cadeia de origem para a cadeia de destino pode ser realizada por um único operador, uma federação ou um conjunto de partes incentivadas. Embora a natureza exata de uma ponte trustless (com ou sem permissão) não afete sua integridade, ela pode afetar aspectos como vivacidade e resistência à censura.
Provas de validade
As partes encarregadas de retransmitir os cabeçalhos de bloco mais recentes devem gerar uma prova de conhecimento zero confirmando a validade dos cabeçalhos de bloco retransmitidos para o contrato light client. Observe que essa prova atesta a validade do estado da blockchain (representada nos cabeçalhos de bloco) de acordo com o protocolo de consenso.
Para ser mais específico, a prova de validade verifica apenas se o último bloco em uma cadeia específica foi aprovado pela maioria dos validadores da cadeia. No entanto, ela não pode provar que o bloco em si é válido de acordo com as regras do protocolo. Portanto, a prova de validade é descrita como uma "prova de consenso" e não uma "prova de validade" (tiro o chapéu para a Succinct Labs pela inspiração).
A prova de validade gerada para um novo cabeçalho de bloco verifica que:
i. O último bloco finalizado foi assinado pela maioria do conjunto de validadores. Um bloco é considerado finalizado se não puder ser revertido sem que uma grande parte dos validadores perca sua participação. Atualmente, as redes de Proof of Stake (prova de participação), como Ethereum e Cosmos, exigem > ⅔ das assinaturas dos validadores para finalizar os blocos.
ii. As assinaturas no bloco mais recente são válidas e correspondem a um conjunto de chaves públicas disponíveis publicamente associadas ao conjunto atual de validadores.
Além de garantir a validade das mensagens, as provas de validade também ajudam a reduzir o custo de execução de uma ponte trustless. Para contextualizar, tentativas anteriores de implementar a verificação de light clients de eventos entre cadeias tiveram problemas devido à complexidade e ao alto custo da verificação de assinaturas de validadores on-chain.
As pontes trustless resolvem o problema dos custos de verificação aproveitando a concisão das provas de conhecimento zero. Por concisão, queremos dizer que as provas de validade permanecem constantes em tamanho, independentemente do tempo gasto na computação da testemunha original. Como diz Vitalik Buterin:
“Um zkSNARK permite que você gere uma prova de que alguma computação tem algum resultado específico, de forma que a prova possa ser verificada com extrema rapidez, mesmo que a computação subjacente leve muito tempo para ser executada.”
A concisão das provas ZK possibilita a verificação econômica de assinaturas off-chain e o cálculo de uma prova que atesta a validade das assinaturas. Como as provas são de tamanho constante, o custo de verificá-las possui uma ordem de grandeza menor do que a verificação de assinaturas de vários validadores on-chain.
Contratos de pontes
Assim como as pontes tradicionais entre cadeias, as pontes trustless terão contratos implantados em blockchains em ponte para processar depósitos e saques. Normalmente, um depósito ou saque é aprovado somente se o contrato da ponte tiver recebido uma mensagem assinada de um retransmissor de que a solicitação do usuário é válida.
As pontes trustless são diferentes, pois só reconhecem retiradas ou depósitos depois de receber um cabeçalho do contrato do light client que comprove a existência de uma transação de depósito ou retirada. Isso exigiria que os usuários simplesmente fornecessem uma prova de Merkle que mostrasse a inclusão da transação em qualquer cadeia a partir da qual eles estejam fazendo a ponte. O infográfico abaixo mostra como isso pode funcionar na prática:
Fluxo de trabalho possível para um protocolo de ponte trustless (fonte)
Por que a interoperabilidade da blockchain precisa de pontes trustless
Conforme explicado, as pontes trustless reduzem a necessidade de confiar que os agentes externos envolvidos na comunicação entre cadeias ajam honestamente. Mais importante ainda, a combinação de verificação do light client e provas de validade reduzem a probabilidade de os contratos de ponte agirem com base em informações incorretas ou falsas.
Isso não significa que as pontes que independem de confiança de terceiros possam eliminar totalmente a necessidade de confiança ("pontes com confiança minimizada" pode ser um termo mais preciso por esse motivo) na comunicação entre cadeias. Os usuários ainda precisam confiar que uma blockchain é economicamente segura, de modo que qualquer tentativa coordenada de criar blocos inválidos resulte em grandes perdas para os possíveis invasores.
Por exemplo, um ataque a uma ponte pode funcionar se a maioria dos validadores (⅔) assinar um bloco inválido e ficar off-line para evitar o corte. No entanto, isso não é viável, pois os validadores off-line estão sujeitos a pesadas penalidades em redes PoS como Ethereum ou Cosmos.
Além de aprimorar a validação de informações entre cadeias, as pontes com minimização de confiança também podem solucionar dois problemas que afetam os projetos de pontes atuais: centralização e ineficiências operacionais. Ambos os problemas estão interligados e fazem parte do trilema de interoperalidade de blockchain.
As pontes centralizadas aumentam a eficiência usando um operador central ou um pequeno conjunto de entidades aprovadas para verificar as mensagens entre cadeias. No entanto, isso dá abertura a vários vetores de ataque, incluindo a censura de usuários e a possibilidade de os operadores de ponte ficarem comprometidos.
As pontes descentralizadas são do tipo sem permissão (permissionlles), permitindo que um grupo diversificado de partes incentivadas atue como oráculos, fornecendo informações sobre eventos que ocorrem em outras cadeias. Para garantir a segurança da ponte, os retransmissores podem ser obrigados a fazer stake de capital que pode ser cortado em caso de fraude. Esse sistema, no entanto, promove a ineficiência do capital, pois força os participantes a bloquearem o capital que poderia ser usado em outro lugar.
Além disso, o mecanismo de arbitragem de disputas só funciona se as partes honestas tiverem tempo suficiente para detectar atividades maliciosas entre os retransmissores e iniciar desafios. Assim, as pontes otimistas (optimistic) podem forçar os usuários a esperar por um período específico antes de sacar fundos.
Ao usar provas de validade não interativas para verificar as operações em blockchains em ponte, as pontes com minimização de confiança resolvem os problemas descritos acima. Por exemplo, mesmo que o controle de uma ponte seja centralizado, é impossível que os envolvidos transmitam atualizações de estado inválidas ou inexistentes. (Isso pressupõe que o protocolo criptográfico subjacente para gerar provas seja sólido, de modo que seja inviável gerar provas falsas).
Além disso, sem a necessidade de contar com a arbitragem de disputas para se defender contra operações inválidas, as pontes podem reduzir a latência para os usuários a um valor insignificante. Nesse cenário, o atraso na retirada corresponderia ao tempo necessário para gerar uma prova de conhecimento zero para cabeçalhos de blocos retransmitidos.
Pontes trustless em produção
Construir pontes trustless é difícil, o que explica por que essas pontes não estão sendo usadas atualmente. Alguns desses motivos incluem os custos de verificação de provas de validade on-chain e a natureza intensa de computação da geração de provas.
Felizmente, os avanços na tecnologia de prova (por exemplo, computação de prova distribuída e prova recursiva) e a crescente demanda por interoperabilidade (impulsionada pela explosão dos ecossistemas de blockchain) estão fomentando os esforços para criar pontes de confiança minimizadas para os usuários de blockchain. Destacamos abaixo alguns dos principais projetos que trabalham com soluções de confiança minimizada para o problema de interoperabilidade de blockchain:
Telepathy
A Succinct Labs dedica-se a criar um protocolo de interoperabilidade descentralizado e sem permissão para a Ethereum. A equipe já criou uma prova de conceito de uma ponte de light client habilitada para ZK entre a Gnosis Chain e a Ethereum.
A Telepathy, como a Succinct chama sua ponte trustless, baseia-se no protocolo de light client da Ethereum para rastrear blocos recentes finalizados na Ethereum. A ponte consiste em um componente off-chain que gera provas para cabeçalhos de blocos retransmitidos e um componente on-chain responsável por verificar as provas enviadas pelos retransmissores.
ZK-Bridge
A ZK-Bridge é um esforço de acadêmicos afiliados ao Research and Development Institute (RDI) da Universidade de Berkeley. Assim como o Telepathy, o ZK-Bridge depende de uma rede de retransmissão descentralizada para enviar cabeçalhos de bloco e computar provas de validade.
A principal inovação da ZK-Bridge é o uso de um mecanismo de geração de provas em duas camadas. As provas são geradas em paralelo pelos nós da rede de retransmissão usando uma versão modificada do provador Virgo (chamado deVirgo) e agregadas em uma única prova. Essas provas são enviadas a um provador Groth16, que gera uma prova ZK-SNARK de tamanho constante que atesta a execução correta do protocolo Virgo (e a validade da prova).
Isso é importante porque, embora o Virgo reduza significativamente o tempo de prova, as provas geradas são muito grandes para serem verificadas on-chain. O provador Groth16 é mais lento, mas gera provas menores e reduz os custos de verificação. Assim, a combinação do deVirgo com o Groth16 permite que a ZK-Bridge acelere a geração de provas e reduza os custos (alcançando eficiência e custo-benefício).
ZK-IBC
A Electron Labs está trabalhando em uma ponte entre Cosmos e Ethereum que utiliza um protocolo de light client e ZK-SNARKs para provar mudanças de estado em cadeias Cosmos para nós Ethereum. O nome da ponte deriva parcialmente de IBC (Inter-Blockchain Communication), um protocolo para passar mensagens entre cadeias no ecossistema Cosmos.
Como observado em um artigo introdutório no Etheresear.ch, o custo e a latência do uso da ponte ZK-IBC estão sujeitos a vários fatores. Por exemplo, as cadeias Cosmos têm tempos de bloqueio mais rápidos (~ 7 segundos). Se as provas fossem geradas para cada novo bloco, é possível que, na pior das hipóteses, o custo de geração e verificação de uma prova fosse arcado por um único usuário.
Por outro lado, se os operadores de pontes esperassem que os depósitos se acumulassem, os usuários sofreriam algum atraso na obtenção de fundos de pontes. No entanto, o time do ZK-IBC planeja implementar soluções como a geração de provas com máquinas paralelas para reduzir os custos e a latência.
Topos
Diferentemente dos projetos descritos anteriormente, o Topos é um protocolo de interoperabilidade completo que permite que cadeias heterogêneas troquem informações, ativos e dados arbitrários independentemente de confiança de terceiros. Os leitores podem achar isso um pouco semelhante ao que o Cosmos e o Polkadot pretendem alcançar com o IBC e o XCM (Cross-Consensus Message Format), respectivamente.
No entanto, o Topos difere do Polkadot e do Cosmos porque reforça a exatidão das informações de consenso transferidas entre cadeias (chamadas Subnets) usando provas de validade. Os usuários de uma Subnet podem acionar operações em Subnets remotas (por exemplo, cunhagem de tokens ou chamadas de contrato), mas somente se um certificado de Subnet (que faz referência ao cabeçalho mais recente e às mensagens pendentes entre cadeias) e a prova de validade que o acompanha tiverem sido aceitos na cadeia de destino.
O futuro da interoperabilidade de blockchain sem necessidade de confiança em terceiros
As pontes trustless ainda estão longe de serem práticas e nenhum dos projetos destacados tem uma implementação pronta para produção (ainda). No entanto, a ponte com minimização de confiança provavelmente se tornará acessível em alguns anos.
Mesmo assim, é importante observar que uma ponte de confiança minimizada não resolverá automaticamente todos os problemas associados a transferências entre cadeias. A movimentação de ativos entre blockchains sempre envolverá riscos, especialmente quando se faz a ponte entre duas cadeias que não compartilham segurança.
Suponha que haja uma ponte Ethereum-Solana que (a) emita Wrapped Ether (WETH) para usuários na Solana após verificar depósitos de ETH em Ethereum e (b) libere ETH depositado após verificar provas de tokens WETH sendo queimados na Solana. Nesse cenário, um invasor pode lucrar ao realizar um ataque de 51% em qualquer cadeia e reverter blocos:
Primeiro, o invasor enviaria o recibo de prova de queima para o contrato de ponte na Ethereum (ou seja, depois de queimar tokens WETH na Solana) para retirar o depósito de ETH. A verificação de validade seria aprovada nessa situação, pois a transação está incluída em um cabeçalho de bloco verificado.
Mas se um ataque de 51% na Solana for bem-sucedido, é fácil reverter o bloco que contém a transação queimada e fazer parecer que a retirada anterior nunca aconteceu. Isso liberaria o invasor para trocar WETH na Solana por outros tokens ou converter para moedas fiduciárias usando um câmbio.
Esses tipos de ataques destacam os pontos fracos inerentes à comunicação entre cadeias. Na verdade, outra variante desse ataque é descrita por Vitalik Buterin abaixo, com consequências semelhantes para os usuários de pontes entre cadeias:
Uma variante do ataque de 51% relacionado à ponte descrito por Vitalik Buterin
Entretanto, se as estatísticas TVL de ponte forem algo a ser seguido, o risco de hacks não impedirá os usuários que desejam explorar novos ecossistemas de usar pontes entre cadeias. Portanto, o desenvolvimento de soluções para a interoperabilidade segura - como a prometida pelas pontes trustless - é fundamental para a obtenção de um ecossistema multicadeia.
Na Infura, estamos construindo um futuro multichain para a web3 e suportamos 10 redes incluindo Ethereum, Polygon, Optimism, Starnet, e continuaremos a adicionar constantemente novas cadeias. Estamos vendo novas L2s surgirem todos os dias, como a Base, a nova L2 criada pela Coinbase na OP Stack, assim como a nova zk-rollup ConsenSys está construindo. À medida que surgem novas cadeias, esperamos ver como a interoperabilidade amadurece com o suporte para pontes trustless e estaremos presentes para fornecer a infraestrutura resiliente e a disponibilidade de dados que os aplicativos de blockchain precisam para serem escaláveis.
Esse artigo foi escrito por Emmanuel Awosika e traduzido por Fátima Lima. O original pode ser lido aqui.
Latest comments (0)