Discutir a segurança e a descentralização dos protocolos de cadeia cruzada

A questão da segurança dos protocolos de cadeia cruzada tem recebido muita atenção nos últimos anos. Com base nas perdas 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 necessidade intrínseca da interconexão do Web3. Esses protocolos geralmente têm um grande volume de financiamento, com um valor total de bloqueio de (TVL) e o volume de transações também está crescendo continuamente sob a pressão de uma demanda rígida. No entanto, devido à baixa conscientização do público sobre esses protocolos de cadeia cruzada, é difícil avaliar com precisão seu nível de segurança.

Vamos primeiro dar uma olhada em 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, um Relayer é responsável por executar operações específicas, enquanto o Oracle supervisiona o Relayer. Uma das vantagens dessa arquitetura é que evita a necessidade de uma terceira cadeia (geralmente não implementa dApp) para completar o algoritmo de consenso e o processo de validação por dezenas de nós, proporcionando assim uma experiência de "rápida cadeia cruzada" para o usuário final. Devido à leveza da arquitetura, à quantidade reduzida de código e à possibilidade de o Oracle utilizar serviços já existentes como o Chainlink, esses projetos são fáceis de serem lançados rapidamente, mas ao mesmo tempo, são facilmente imitáveis, com uma barreira tecnológica baixa.

No entanto, essa arquitetura apresenta pelo menos dois problemas:

1. Simplificar 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 assumir que o Relayer e o Oracle são mutuamente independentes. No entanto, essa suposição de confiança não pode ser mantida para sempre, faltando características suficientes de Descentralização, que não garantem fundamentalmente que ambos não conspirarão para fazer o mal.

Algumas pessoas podem perguntar se abrir o Relayer e permitir que mais participantes executem os intermediários resolveria os problemas mencionados. Na verdade, simplesmente aumentar o número de operadores não é equivalente à Descentralização. Permitir que qualquer um acesse o sistema apenas realiza a permissão sem restrições (Permissionless), que é uma mudança do lado do mercado, e tem pouca relação com a segurança do próprio produto. O Relayer é essencialmente um intermediário responsável por retransmitir informações, assim como o Oracle, ambos pertencem a terceiros confiáveis. Tentar aumentar o número de entidades confiáveis para melhorar a segurança da cadeia cruzada é fútil, pois não altera as características essenciais do produto e pode até gerar novos problemas.

Se um projeto de token de cadeia cruzada permitir a modificação da configuração dos nós utilizados, um atacante poderá substituir por nós que controla, falsificando assim qualquer mensagem. Essa vulnerabilidade de segurança pode causar consequências mais sérias em cenários mais complexos. Em um sistema grande, basta que um único elo seja substituído para desencadear uma reação em cadeia. E certos protocolos de cadeia cruzada não possuem a capacidade de resolver esse tipo de problema; se realmente ocorrer um acidente de segurança, a responsabilidade poderá ser facilmente atribuída a aplicativos externos.

Para projetos que afirmam ser infraestrutura, se não conseguem fornecer segurança compartilhada como Layer 1 ou Layer 2, então essa posição de "infraestrutura" merece ser questionada. A verdadeira infraestrutura é "fundamental" porque pode fornecer garantias de segurança consistentes para todo o ecossistema. Portanto, a posição de certos protocolos de cadeia cruzada pode ser mais precisamente identificada como middleware, e não como infraestrutura.

Algumas equipes de segurança apontaram vulnerabilidades potenciais em certos protocolos de cadeia cruzada. Por exemplo, se um agente malicioso obtiver acesso à configuração do protocolo, ele pode alterar os oráculos e os retransmissores para componentes que controla, enganando assim o contrato inteligente e resultando no roubo de ativos dos usuários. Também foi descoberto que alguns retransmissores de certos protocolos apresentam vulnerabilidades críticas, que embora atualmente estejam protegidas por múltiplas assinaturas, ainda podem ser exploradas por funcionários internos ou membros da equipe com identidade conhecida.

Ao avaliar protocolos de cadeia cruzada, devemos retornar à origem e referenciar os princípios fundamentais apresentados no white paper do Bitcoin. A característica central do consenso de Satoshi Nakamoto é eliminar terceiros confiáveis, alcançando a desconfiança (Trustless) e a descentralização (Descentralização). O protocolo de comunicação entre cadeias deve, em essência, ser como o Bitcoin, um sistema ponto a ponto que permite que uma parte envie diretamente de Chain A para a outra parte em Chain B, sem a necessidade de intermediários confiáveis.

A "consenso de Satoshi", que possui características de Descentralização e de confiança, tornou-se o objetivo comum de todos os desenvolvedores de infraestrutura subsequentes. Protocolos de cadeia cruzada que não atendem a esse consenso dificilmente podem ser considerados verdadeiros protocolos de cadeia cruzada descentralizados, e não devem usar facilmente termos avançados como "descentralização" e "confiança" para descrever as características de seus produtos.

Um verdadeiro protocolo de cadeia cruzada descentralizado deve ser capaz de gerar provas de fraude ou provas de validade durante todo o processo de cadeia cruzada e registrar essas provas na cadeia para verificação. Só assim se pode realmente alcançar a descentralização e a desconfiança.

Para aqueles que afirmam usar tecnologias inovadoras (como provas de conhecimento zero) para atualizar protocolos de cadeia cruzada, a chave está em saber se realmente reconhecem os problemas que possuem. Somente enfrentando os problemas é que se pode realmente impulsionar o progresso tecnológico e construir um ecossistema de cadeia cruzada mais seguro e mais descentralizado.