No dia 23 de abril de 2025, um usuário pediu ajuda numa plataforma de redes sociais, afirmando que durante uma operação de arbitragem na camada 2 do Bitcoin, mais de 100 mil dólares em ativos unibtc ficaram presos e não puderam ser retirados.
Segundo a pessoa envolvida, no dia 17 de abril, ele descobriu que o unibtc apresentava anomalias de preço em uma determinada cadeia L2 de Bitcoin e se desvinculava do BTC, considerando isso uma ótima oportunidade de Arbitragem. Ele transferiu parte do BTC para essa cadeia L2 de Bitcoin, trocou por unibtc e aguardou a reanexação para vender.
Apenas nas últimas 24 horas, o unibtc já foi ancorado, mas quando tentou vender o unibtc que tinha, descobriu que o pool de liquidez unibtc-BTC na cadeia tinha sido retirado oficialmente. Este era o único canal de saída do mercado secundário unibtc na cadeia. Incapaz de vender o unibtc que tinha, tentou transferir o unibtc para outras cadeias.
Quando ele encontrou a única ponte cross-chain que suporta unibtc na cadeia, recebeu a mensagem: "A transação requer autorização de assinatura do projeto". Após entrar em contato com o suporte ao cliente, soube que a chave multi-assinatura do unibtc cross-chain é gerida oficialmente, e sem permissão, os usuários não podem transferir unibtc para outras cadeias.
As partes só podem contatar os funcionários oficiais relevantes para perguntar sobre o assunto, a outra parte respondeu inicialmente: "Podemos permitir que retire o capital, mas se pode retirar os lucros gerados pela sua arbitragem, terá de ficar sujeito a revisão."
Até aqui, as partes perceberam que o caminho de saída do unibtc na cadeia foi completamente cortado, e que os unibtc no valor de cerca de 200.000 dólares estavam "temporariamente congelados". Ele não conseguia vender na cadeia, nem transferir para outras cadeias. Nesse momento, sentiu-se muito impotente, desejando apenas retirar o capital investido com sucesso.
No entanto, a atitude das autoridades oficiais tornou-se ambígua, não esclarecendo quando o capital pode ser retirado, nem fornecendo qualquer compromisso por escrito, adiando com razões como "avaliação de risco" e "verificação técnica".
Após um período de adiamento, a oficial afirmou que o descolamento do unibtc se deve ao fato de alguém ter emprestado em grande escala os ativos unibtc de uma certa plataforma e realizado uma venda massiva, e então sugeriu que a parte interessada "responsabilizasse essa plataforma". No entanto, a parte interessada não obteve resposta após entrar em contato com a plataforma por um longo tempo.
Sem alternativas, o interessado teve que buscar ajuda na plataforma social. Após mais de duas semanas de negociações, finalmente obteve uma resposta positiva da parte envolvida e conseguiu recuperar os ativos.
Esse tipo de encontro não é um caso isolado. De acordo com o feedback de outros envolvidos, métodos semelhantes foram utilizados no ano passado para cortar o caminho de saída dos usuários de unibtc, resultando na "congelação substancial" dessas unibtc.
Do ponto de vista técnico, como evitar e eliminar comportamentos centralizados de má fé é uma questão que merece discussão. Primeiro, como emissor de unibtc e LP inicial do pool de liquidez do mercado secundário, possui naturalmente a autoridade sobre o canal de saída do mercado secundário de unibtc; se quisermos restringir esse poder, isso deve ser feito mais através da governança do que por meios técnicos.
No entanto, a conspiração entre a ponte entre cadeias e o emissor para recusar os pedidos dos usuários expõe uma falha técnica óbvia no "emissão - circulação em uma única cadeia - circulação em múltiplas cadeias" da unibtc: esta ponte entre cadeias é claramente altamente centralizada.
Uma verdadeira ponte sem confiança deve garantir que a ponte oficial não possa impedir a saída dos usuários. No entanto, neste caso, tanto o emissor quanto a ponte entre cadeias detêm um forte poder de centralização e não forneceram um canal de saída resistente à censura.
Casos semelhantes não são raros, e a interrupção do caminho de saída dos usuários é algo que ocorre frequentemente em várias exchanges, enquanto para projetos como pontes cross-chain ou outros tipos, essas situações em que se utilizam poderes centralizados também não são incomuns. Em junho de 2022, uma ponte cross-chain suspendeu o canal de retirada de 57 ativos devido a um ataque de hackers; embora essa ação tenha uma "justificativa legítima", ainda assim gerou preocupações em algumas pessoas.
Em um incidente em 2021, a equipe do projeto desviou 24 milhões de dólares através de uma vulnerabilidade programática previamente reservada. No final, Hong Kong e o Reino Unido mobilizaram um grande número de policiais, e foi somente com a ajuda da comunidade que 91% dos fundos roubados foram recuperados. Vários casos demonstram claramente que, se uma plataforma de custódia de ativos não puder oferecer serviços sem confiança, isso inevitavelmente resultará em consequências desastrosas.
No entanto, alcançar a confiança zero não é uma tarefa fácil. Desde canais de pagamento e DLC até BitVM e ZK Rollup, as pessoas tentaram várias maneiras de implementação, embora isso possa garantir em grande parte a autonomia do usuário e fornecer uma saída confiável para retirada de ativos, ainda existem falhas inevitáveis por trás disso.
Por exemplo, o canal de pagamento requer que as partes monitorem o comportamento malicioso potencial da contraparte, o DLC depende de oráculos; enquanto o BitVM é caro e existem outras suposições de confiança na prática; a cápsula de escape do ZK Rollup precisa passar por um longo período de espera para ser acionada e requer que o Rollup seja desligado primeiro, o que tem um custo muito grande.
Da análise da situação atual das diversas soluções tecnológicas, não surgiu nenhuma solução perfeita de custódia de ativos e saída, e o mercado ainda precisa de inovações. Uma solução de verificação de mensagens sem confiança que combina TEE, ZK e MPC merece atenção; essa solução equilibra indicadores que não podem ser simultaneamente atendidos, como custo, segurança e experiência do usuário, podendo fornecer serviços subjacentes confiáveis para plataformas de negociação, pontes entre cadeias ou qualquer cenário de custódia de ativos.
CRVA: Rede de Verificação Aleatória Criptográfica
Atualmente, a maioria das soluções de gestão de ativos mais amplamente utilizadas no mercado utiliza métodos de multi-assinatura ou MPC/TSS para determinar se um pedido de transferência de ativos é válido. A vantagem dessa solução reside na sua implementação simples, baixo custo e rápida verificação de mensagens, enquanto suas desvantagens são evidentes - não é suficientemente segura e tende a ser centralizada. Em um determinado evento multichain em 2023, 21 nós que participaram do cálculo MPC eram todos controlados por uma única pessoa, caracterizando um ataque de bruxa típico. Este incidente é suficiente para provar que, apenas com base na aparência de dezenas de nós, não se pode garantir uma alta proteção contra a centralização.
Em relação às deficiências das soluções tradicionais de gestão de ativos MPC/TSS, o plano CRVA fez numerosas melhorias. Primeiro, os nós da rede CRVA adotam uma forma de entrada baseada em garantia de ativos, e a mainnet só será oficialmente iniciada após atingir cerca de 500 nós; estima-se que os ativos garantidos por esses nós se mantenham a longo prazo em dezenas de milhões de dólares ou mais.
Em segundo lugar, para melhorar a eficiência do cálculo MPC/TSS, o CRVA selecionará aleatoriamente nós através de um algoritmo de sorteio, por exemplo, sorteando 10 nós a cada meia hora, que atuarão como validadores para verificar se os pedidos dos usuários devem ser aprovados, e então gerar a assinatura de limite correspondente para liberação. Para evitar conluio interno ou ataques de hackers externos, o algoritmo de sorteio do CRVA utiliza um VRF circular original, combinado com ZK para ocultar a identidade dos selecionados, tornando impossível para o exterior observar diretamente os escolhidos.
Para eliminar ainda mais a conivência, todos os nós da CRVA devem executar o código central dentro de um ambiente de hardware TEE, o que equivale a realizar o trabalho central em uma caixa-preta. Assim, ninguém pode saber se foi selecionado, a menos que consiga quebrar o hardware confiável TEE, o que, claro, é extremamente difícil de realizar com as condições tecnológicas atuais.
No fluxo de trabalho real, os nós dentro da rede CRVA devem realizar uma grande quantidade de comunicação de broadcast e troca de informações. O processo específico inclui: os nós apostam ativos e registram a chave pública, geram periodicamente uma chave pública temporária e fornecem uma prova ZKP, realizam uma seleção aleatória através de nós Relayer, e finalmente, o nó selecionado valida e assina no ambiente TEE.
O núcleo deste plano reside no fato de que quase todas as atividades importantes ocorrem dentro do hardware TEE, e o que acontece fora do TEE não pode ser observado. Cada nó não sabe quem são os validadores selecionados, o que previne conluios maliciosos e aumenta significativamente o custo de ataques externos. Para atacar o comitê baseado em CRVA, teoricamente é necessário atacar toda a rede CRVA, além do que cada nó possui proteção TEE, tornando a dificuldade do ataque substancialmente maior.
implementação da solução de auto-hospedagem de ativos da CRVA
Tomando como exemplo a moeda estável baseada em Bitcoin chamada HelloBTU, sua parte do contrato inteligente está distribuída na Ethereum, onde os usuários podem depositar BTC no endereço de recebimento especificado, e depois a ponte oficial transfere o BTC para a cadeia Ethereum, permitindo a interação com o contrato inteligente de estabilidade HelloBTU.
Suponha que o usuário queira colocar 10 moedas BTC em staking na plataforma HelloBTU. A operação específica é primeiro transferir 10 moedas BTC para um endereço Taproot na cadeia do Bitcoin, onde a liberação correspondente requer 2/2 multiassinatura, sendo uma assinatura gerada pelo usuário e a outra assinatura gerada pela CRVA.
Em diferentes situações, o processo de desbloqueio é ligeiramente diferente:
Resgate ativo do usuário: o usuário e o CRVA geram uma assinatura, desbloqueiam o BTC e transferem de volta para o endereço do usuário. Se o CRVA não cooperar por um longo período, após o término do período de bloqueio de tempo, o usuário pode unilateralmente recuperar o BTC.
BTC em liquidação: os usuários devem cooperar com a CRVA para transferir BTC para o canal unidirecional da CRVA. Se os usuários se recusarem a cooperar, o BTC ficará temporariamente preso; após o período da janela de bloqueio de tempo, a CRVA poderá transferi-lo.
Canal unidirecional CRVA: o liquidante pode iniciar um pedido de retirada, que será analisado pelo CRVA e gerará uma assinatura. Se o CRVA não responder por um longo período, após o término do bloqueio de tempo, o BTC será transferido para um endereço controlado pelo DAO.
Este design limita a possibilidade de os usuários não pagarem e praticarem atos maliciosos, ao mesmo tempo que oferece uma solução para situações de força maior, como paragens do CRVA. Para ativos ERC-20, o princípio é semelhante. Se a ponte entre cadeias adotar esta solução de auto-custódia, será difícil que a parte emissora dos ativos controle unilateralmente a situação.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
10 Curtidas
Recompensa
10
6
Compartilhar
Comentário
0/400
ColdWalletGuardian
· 07-31 03:05
O cão do pool está muito arrogante, já caiu na armadilha, não é?
Ver originalResponder0
SchrodingerWallet
· 07-29 08:20
Ai, o risco de ser idiota está a aumentar.
Ver originalResponder0
MEVHunter
· 07-29 08:17
ngmi... caçadores de arb amadores a serem arrasados por exploits básicos de protocolo. aposto que não analisaste primeiro as métricas de fluxo tóxico smh
Ver originalResponder0
SerumSqueezer
· 07-29 08:10
fazer as pessoas de parvas fazer as pessoas de parvas gg
Descubra o plano de custódia de ativos CRVA sem confiança que resolve o dilema do congelamento de ativos Layer2
No dia 23 de abril de 2025, um usuário pediu ajuda numa plataforma de redes sociais, afirmando que durante uma operação de arbitragem na camada 2 do Bitcoin, mais de 100 mil dólares em ativos unibtc ficaram presos e não puderam ser retirados.
Segundo a pessoa envolvida, no dia 17 de abril, ele descobriu que o unibtc apresentava anomalias de preço em uma determinada cadeia L2 de Bitcoin e se desvinculava do BTC, considerando isso uma ótima oportunidade de Arbitragem. Ele transferiu parte do BTC para essa cadeia L2 de Bitcoin, trocou por unibtc e aguardou a reanexação para vender.
Apenas nas últimas 24 horas, o unibtc já foi ancorado, mas quando tentou vender o unibtc que tinha, descobriu que o pool de liquidez unibtc-BTC na cadeia tinha sido retirado oficialmente. Este era o único canal de saída do mercado secundário unibtc na cadeia. Incapaz de vender o unibtc que tinha, tentou transferir o unibtc para outras cadeias.
Quando ele encontrou a única ponte cross-chain que suporta unibtc na cadeia, recebeu a mensagem: "A transação requer autorização de assinatura do projeto". Após entrar em contato com o suporte ao cliente, soube que a chave multi-assinatura do unibtc cross-chain é gerida oficialmente, e sem permissão, os usuários não podem transferir unibtc para outras cadeias.
As partes só podem contatar os funcionários oficiais relevantes para perguntar sobre o assunto, a outra parte respondeu inicialmente: "Podemos permitir que retire o capital, mas se pode retirar os lucros gerados pela sua arbitragem, terá de ficar sujeito a revisão."
Até aqui, as partes perceberam que o caminho de saída do unibtc na cadeia foi completamente cortado, e que os unibtc no valor de cerca de 200.000 dólares estavam "temporariamente congelados". Ele não conseguia vender na cadeia, nem transferir para outras cadeias. Nesse momento, sentiu-se muito impotente, desejando apenas retirar o capital investido com sucesso.
No entanto, a atitude das autoridades oficiais tornou-se ambígua, não esclarecendo quando o capital pode ser retirado, nem fornecendo qualquer compromisso por escrito, adiando com razões como "avaliação de risco" e "verificação técnica".
Após um período de adiamento, a oficial afirmou que o descolamento do unibtc se deve ao fato de alguém ter emprestado em grande escala os ativos unibtc de uma certa plataforma e realizado uma venda massiva, e então sugeriu que a parte interessada "responsabilizasse essa plataforma". No entanto, a parte interessada não obteve resposta após entrar em contato com a plataforma por um longo tempo.
Sem alternativas, o interessado teve que buscar ajuda na plataforma social. Após mais de duas semanas de negociações, finalmente obteve uma resposta positiva da parte envolvida e conseguiu recuperar os ativos.
Esse tipo de encontro não é um caso isolado. De acordo com o feedback de outros envolvidos, métodos semelhantes foram utilizados no ano passado para cortar o caminho de saída dos usuários de unibtc, resultando na "congelação substancial" dessas unibtc.
Do ponto de vista técnico, como evitar e eliminar comportamentos centralizados de má fé é uma questão que merece discussão. Primeiro, como emissor de unibtc e LP inicial do pool de liquidez do mercado secundário, possui naturalmente a autoridade sobre o canal de saída do mercado secundário de unibtc; se quisermos restringir esse poder, isso deve ser feito mais através da governança do que por meios técnicos.
No entanto, a conspiração entre a ponte entre cadeias e o emissor para recusar os pedidos dos usuários expõe uma falha técnica óbvia no "emissão - circulação em uma única cadeia - circulação em múltiplas cadeias" da unibtc: esta ponte entre cadeias é claramente altamente centralizada.
Uma verdadeira ponte sem confiança deve garantir que a ponte oficial não possa impedir a saída dos usuários. No entanto, neste caso, tanto o emissor quanto a ponte entre cadeias detêm um forte poder de centralização e não forneceram um canal de saída resistente à censura.
Casos semelhantes não são raros, e a interrupção do caminho de saída dos usuários é algo que ocorre frequentemente em várias exchanges, enquanto para projetos como pontes cross-chain ou outros tipos, essas situações em que se utilizam poderes centralizados também não são incomuns. Em junho de 2022, uma ponte cross-chain suspendeu o canal de retirada de 57 ativos devido a um ataque de hackers; embora essa ação tenha uma "justificativa legítima", ainda assim gerou preocupações em algumas pessoas.
Em um incidente em 2021, a equipe do projeto desviou 24 milhões de dólares através de uma vulnerabilidade programática previamente reservada. No final, Hong Kong e o Reino Unido mobilizaram um grande número de policiais, e foi somente com a ajuda da comunidade que 91% dos fundos roubados foram recuperados. Vários casos demonstram claramente que, se uma plataforma de custódia de ativos não puder oferecer serviços sem confiança, isso inevitavelmente resultará em consequências desastrosas.
No entanto, alcançar a confiança zero não é uma tarefa fácil. Desde canais de pagamento e DLC até BitVM e ZK Rollup, as pessoas tentaram várias maneiras de implementação, embora isso possa garantir em grande parte a autonomia do usuário e fornecer uma saída confiável para retirada de ativos, ainda existem falhas inevitáveis por trás disso.
Por exemplo, o canal de pagamento requer que as partes monitorem o comportamento malicioso potencial da contraparte, o DLC depende de oráculos; enquanto o BitVM é caro e existem outras suposições de confiança na prática; a cápsula de escape do ZK Rollup precisa passar por um longo período de espera para ser acionada e requer que o Rollup seja desligado primeiro, o que tem um custo muito grande.
Da análise da situação atual das diversas soluções tecnológicas, não surgiu nenhuma solução perfeita de custódia de ativos e saída, e o mercado ainda precisa de inovações. Uma solução de verificação de mensagens sem confiança que combina TEE, ZK e MPC merece atenção; essa solução equilibra indicadores que não podem ser simultaneamente atendidos, como custo, segurança e experiência do usuário, podendo fornecer serviços subjacentes confiáveis para plataformas de negociação, pontes entre cadeias ou qualquer cenário de custódia de ativos.
CRVA: Rede de Verificação Aleatória Criptográfica
Atualmente, a maioria das soluções de gestão de ativos mais amplamente utilizadas no mercado utiliza métodos de multi-assinatura ou MPC/TSS para determinar se um pedido de transferência de ativos é válido. A vantagem dessa solução reside na sua implementação simples, baixo custo e rápida verificação de mensagens, enquanto suas desvantagens são evidentes - não é suficientemente segura e tende a ser centralizada. Em um determinado evento multichain em 2023, 21 nós que participaram do cálculo MPC eram todos controlados por uma única pessoa, caracterizando um ataque de bruxa típico. Este incidente é suficiente para provar que, apenas com base na aparência de dezenas de nós, não se pode garantir uma alta proteção contra a centralização.
Em relação às deficiências das soluções tradicionais de gestão de ativos MPC/TSS, o plano CRVA fez numerosas melhorias. Primeiro, os nós da rede CRVA adotam uma forma de entrada baseada em garantia de ativos, e a mainnet só será oficialmente iniciada após atingir cerca de 500 nós; estima-se que os ativos garantidos por esses nós se mantenham a longo prazo em dezenas de milhões de dólares ou mais.
Em segundo lugar, para melhorar a eficiência do cálculo MPC/TSS, o CRVA selecionará aleatoriamente nós através de um algoritmo de sorteio, por exemplo, sorteando 10 nós a cada meia hora, que atuarão como validadores para verificar se os pedidos dos usuários devem ser aprovados, e então gerar a assinatura de limite correspondente para liberação. Para evitar conluio interno ou ataques de hackers externos, o algoritmo de sorteio do CRVA utiliza um VRF circular original, combinado com ZK para ocultar a identidade dos selecionados, tornando impossível para o exterior observar diretamente os escolhidos.
Para eliminar ainda mais a conivência, todos os nós da CRVA devem executar o código central dentro de um ambiente de hardware TEE, o que equivale a realizar o trabalho central em uma caixa-preta. Assim, ninguém pode saber se foi selecionado, a menos que consiga quebrar o hardware confiável TEE, o que, claro, é extremamente difícil de realizar com as condições tecnológicas atuais.
No fluxo de trabalho real, os nós dentro da rede CRVA devem realizar uma grande quantidade de comunicação de broadcast e troca de informações. O processo específico inclui: os nós apostam ativos e registram a chave pública, geram periodicamente uma chave pública temporária e fornecem uma prova ZKP, realizam uma seleção aleatória através de nós Relayer, e finalmente, o nó selecionado valida e assina no ambiente TEE.
O núcleo deste plano reside no fato de que quase todas as atividades importantes ocorrem dentro do hardware TEE, e o que acontece fora do TEE não pode ser observado. Cada nó não sabe quem são os validadores selecionados, o que previne conluios maliciosos e aumenta significativamente o custo de ataques externos. Para atacar o comitê baseado em CRVA, teoricamente é necessário atacar toda a rede CRVA, além do que cada nó possui proteção TEE, tornando a dificuldade do ataque substancialmente maior.
implementação da solução de auto-hospedagem de ativos da CRVA
Tomando como exemplo a moeda estável baseada em Bitcoin chamada HelloBTU, sua parte do contrato inteligente está distribuída na Ethereum, onde os usuários podem depositar BTC no endereço de recebimento especificado, e depois a ponte oficial transfere o BTC para a cadeia Ethereum, permitindo a interação com o contrato inteligente de estabilidade HelloBTU.
Suponha que o usuário queira colocar 10 moedas BTC em staking na plataforma HelloBTU. A operação específica é primeiro transferir 10 moedas BTC para um endereço Taproot na cadeia do Bitcoin, onde a liberação correspondente requer 2/2 multiassinatura, sendo uma assinatura gerada pelo usuário e a outra assinatura gerada pela CRVA.
Em diferentes situações, o processo de desbloqueio é ligeiramente diferente:
Resgate ativo do usuário: o usuário e o CRVA geram uma assinatura, desbloqueiam o BTC e transferem de volta para o endereço do usuário. Se o CRVA não cooperar por um longo período, após o término do período de bloqueio de tempo, o usuário pode unilateralmente recuperar o BTC.
BTC em liquidação: os usuários devem cooperar com a CRVA para transferir BTC para o canal unidirecional da CRVA. Se os usuários se recusarem a cooperar, o BTC ficará temporariamente preso; após o período da janela de bloqueio de tempo, a CRVA poderá transferi-lo.
Canal unidirecional CRVA: o liquidante pode iniciar um pedido de retirada, que será analisado pelo CRVA e gerará uma assinatura. Se o CRVA não responder por um longo período, após o término do bloqueio de tempo, o BTC será transferido para um endereço controlado pelo DAO.
Este design limita a possibilidade de os usuários não pagarem e praticarem atos maliciosos, ao mesmo tempo que oferece uma solução para situações de força maior, como paragens do CRVA. Para ativos ERC-20, o princípio é semelhante. Se a ponte entre cadeias adotar esta solução de auto-custódia, será difícil que a parte emissora dos ativos controle unilateralmente a situação.