A importância da segurança do protocolo de cadeia cruzada e as deficiências do LayerZero

A questão da segurança dos protocolos de cadeia cruzada tem recebido muita atenção nos últimos anos. Com base nas perdas financeiras causadas por eventos de segurança em várias blockchains nos últimos dois anos, as perdas relacionadas a eventos de segurança de protocolos de cadeia cruzada estão no topo da lista. A importância e a urgência de resolver os problemas de segurança dos protocolos de cadeia cruzada superam até mesmo as soluções de escalabilidade do Ethereum. A interoperabilidade entre os protocolos de cadeia cruzada é uma exigência intrínseca para a conexão da rede do ecossistema Web3. Esses protocolos geralmente recebem enormes financiamentos, com um valor total de capital bloqueado (TVL) e o número de transações também está aumentando devido à demanda rígida. No entanto, devido à baixa capacidade de reconhecimento do público em geral sobre esses protocolos, é difícil avaliar com precisão seu nível de segurança.

Vamos primeiro olhar para uma arquitetura típica de design de produto de cadeia cruzada. Durante o processo de comunicação entre a Chain A e a Chain B, as operações específicas são executadas pelo Relayer, enquanto o Oracle supervisiona o Relayer. A vantagem dessa arquitetura é que evita o complexo processo de um algoritmo de consenso e a validação de múltiplos nós que exigiria uma terceira cadeia (geralmente não implantada como dApp) na abordagem tradicional, proporcionando assim uma experiência de "cadeia cruzada rápida" para os usuários finais. Devido à leveza da arquitetura, à quantidade reduzida de código e à possibilidade de usar diretamente o Chainlink como Oracle, esse tipo de projeto é fácil de ser lançado rapidamente, mas também é facilmente imitado, com uma barreira técnica quase inexistente.

No entanto, essa arquitetura apresenta pelo menos dois problemas:

1. Simplificou o processo de validação de dezenas de nós para uma única validação Oracle, reduzindo significativamente o coeficiente de segurança.

2. Após a simplificação para uma única validação, deve-se pressupor que o Relayer e o Oracle são independentes um do outro. Esta suposição de confiança é difícil de manter permanentemente, não está de acordo com a filosofia nativa das criptomoedas e não pode garantir fundamentalmente que os dois não conspirarão para fazer o mal.

Alguns protocolos de cadeia cruzada adotaram este modelo básico. Como uma solução de cadeia cruzada "super leve" de tipo de segurança independente, eles são responsáveis apenas pela transmissão de mensagens e não têm responsabilidade pela segurança da aplicação, nem têm capacidade para assumir tal responsabilidade.

Mesmo permitindo que múltiplas partes operem como retransmissores, não é possível resolver completamente os problemas mencionados. Primeiro, a descentralização não significa apenas que o número de operadores aumenta ou que qualquer um pode se conectar. O lado da demanda sempre foi sem permissão, transformar o lado da oferta em sem permissão não é uma mudança revolucionária, é apenas uma mudança do lado do mercado, que não tem muita relação com a segurança do produto em si. Os retransmissores de certos protocolos são essencialmente intermediários responsáveis por encaminhar informações, assim como os Oráculos, ambos pertencem a terceiros confiáveis. Tentar aumentar a segurança da cadeia cruzada aumentando o número de entidades confiáveis de 1 para 30 é em vão, não só não altera as características do produto, mas também pode gerar novos problemas.

Se um projeto de token de cadeia cruzada permitir a modificação de nós de configuração, então pode haver a possibilidade de um atacante substituí-los por seus próprios nós, falsificando assim qualquer mensagem. Do ponto de vista dos resultados, projetos que utilizam este protocolo ainda podem enfrentar enormes riscos de segurança, e esse problema será ainda mais grave em cenários mais complexos. Em um sistema grande, assim que uma parte for substituída, pode desencadear uma reação em cadeia. Certos protocolos de cadeia cruzada não possuem a capacidade de resolver esse problema; se realmente ocorrer um acidente de segurança, é muito provável que eles responsabilizem aplicações externas.

Se um protocolo não pode compartilhar segurança como Layer1 ou Layer2, então não pode ser chamado de infraestrutura. A razão pela qual a infraestrutura é "fundamental" é porque ela pode compartilhar segurança. Se um projeto se autodenomina infraestrutura, então deve fornecer segurança consistente para todos os seus projetos ecológicos, assim como outras infraestruturas, ou seja, todos os projetos ecológicos compartilham a segurança dessa infraestrutura. Portanto, para ser preciso, certos protocolos de cadeia cruzada não são infraestrutura, mas sim middleware. Desenvolvedores de aplicações que utilizam este middleware SDK/API podem realmente definir livremente suas políticas de segurança.

Algumas equipes de pesquisa apontaram que é incorreto supor que os proprietários de aplicativos (ou as pessoas que possuem a chave privada) não agirão de forma maliciosa. Se um agente mal-intencionado obtiver acesso à configuração do protocolo de cadeia cruzada, ele poderá alterar os oráculos e os retransmissores dos componentes padrão para componentes controlados por ele, manipulando assim os contratos inteligentes que utilizam esse mecanismo, resultando no roubo de ativos dos usuários.

Além disso, estudos mostram que alguns revezadores de cadeias cruzadas apresentam vulnerabilidades críticas. Embora atualmente estejam em estado de múltiplas assinaturas, essas vulnerabilidades só podem ser exploradas por insiders ou membros da equipe com identidade conhecida, mas ainda assim existem riscos potenciais. Essas vulnerabilidades podem permitir o envio de mensagens fraudulentas a partir de múltiplas assinaturas, ou a modificação de mensagens após os oráculos e mensagens ou transações de múltiplas assinaturas terem sido assinadas, o que pode resultar no roubo de todos os fundos dos usuários.

Ao retroceder na origem do Bitcoin, podemos ver a ideia central proposta por Satoshi Nakamoto no white paper: um sistema de moeda eletrônica totalmente ponto a ponto, que permite pagamentos online diretamente de uma parte para outra, sem a necessidade de instituições financeiras. Essa ideia enfatiza as características de descentralização e de não confiança, que se tornaram o objetivo comum de todos os desenvolvedores de infraestrutura posteriores.

No entanto, certos protocolos de cadeia cruzada exigem na prática que os papéis de Relayer e Oracle não conspirem para fazer mal, ao mesmo tempo que exigem que os desenvolvedores que utilizam o protocolo para construir aplicações sejam considerados terceiros confiáveis. Todos os entes confiáveis envolvidos na "multisig" são papéis privilegiados previamente designados. Mais importante ainda, durante todo o processo de cadeia cruzada, não foram geradas provas de fraude ou provas de validade, muito menos essas provas foram registradas em cadeia e verificadas em cadeia. Portanto, esses protocolos na verdade não satisfazem o "consenso de Satoshi Nakamoto" e não podem ser considerados verdadeiros sistemas descentralizados e sem confiança.

Quando confrontados com problemas de segurança, a atitude de resposta de alguns protocolos de cadeia cruzada tende a ser "negação" e depois "negação". No entanto, a história nos ensina que antes do Bitcoin, houve muitas tentativas de moedas eletrônicas, mas todas falharam, porque não conseguiram alcançar os objetivos de descentralização, resistência a ataques e valor intrínseco. O mesmo se aplica aos protocolos de cadeia cruzada; independentemente da escala de financiamento, do volume de usuários ou da "linhagem" ser tão pura, desde que o produto não consiga alcançar uma verdadeira segurança descentralizada, é muito provável que falhe no final devido à sua capacidade insuficiente de resistência a ataques.

Construir um verdadeiro protocolo de cadeia cruzada descentralizado é um desafio complexo. Algumas soluções emergentes, como o uso de tecnologia de provas de conhecimento zero para aprimorar os protocolos de cadeia cruzada, podem trazer novas inovações para este campo. No entanto, a chave está em saber se os desenvolvedores do protocolo reconhecem os problemas existentes e estão dispostos a tomar as medidas necessárias para melhorar.