727 FinanceUm incidente não leva apenas ativos, mas também a confiança. O cripto não pode continuar assim; precisamos nos salvar.
Autor: Robert Mao, fundador e CEO da ArcBlock
Este artigo está autorizado para que qualquer pessoa o reproduza e encaminhe livremente, na esperança de que mais pessoas vejam este apelo para que a indústria se salve.
O Crypto não pode continuar assim. Repetidamente, roubos massivos levam não apenas ativos, mas também a confiança dos participantes em toda a indústria. Precisamos nos salvar.
Em 29 de outubro de 2026, ocorreu um grande incidente de segurança na Binance. Seu anúncio preliminar estimou que aproximadamente US$ 6,3 bilhões em ativos foram afetados, e cerca de US$ 3 bilhões dos ativos afetados haviam sido congelados; a investigação apontou inicialmente para o laptop de um engenheiro de DevOps, e posteriormente outros possíveis pontos de intrusão também foram descobertos. A Binance também declarou que nenhuma evidência de vazamento de chaves privadas de carteiras havia sido encontrada. O valor afetado não é a perda líquida final, e toda a cadeia de ataque permanece sob investigação. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Esta iniciativa é dirigida aos construtores de projetos de blockchain como Ethereum e Solana, e também à Binance, Coinbase, Kraken e todas as exchanges, carteiras, protocolos e construtores de segurança dispostos a participar: vamos reconstruir juntos a base para a proteção de ativos. Estou disposto a participar, e espero que mais pessoas ajam em conjunto.
Isso já é pesado o suficiente. Mas o que mais me preocupa é quanta confiança no Crypto este incidente destruirá, e quantos atacantes ele levará a enxergar esta indústria como um alvo que ainda vale a pena continuar atacando. Mesmo que alguém acabe arcando com as perdas, a compensação não consegue reparar automaticamente a confiança dos usuários, nem impedir que o mesmo tipo de destruição volte a acontecer.
A Binance é apenas o ponto de entrada que nos força hoje a encarar o problema. Olhando para o lado, exchanges, bridges, protocolos on-chain e carteiras há muito deixaram um longo rastro de feridas. Novas redes e produtos não param de surgir, mas os antigos modos de falha se repetem sem cessar. Não podemos emitir um comunicado, esperar um pouco e então tratar o próximo incidente como rotina.
Também precisamos reconhecer que golpes e a prática de apenas criar conceitos sem assumir a responsabilidade de construir prejudicam esta indústria há tempo demais. Equipes que constroem seriamente tecnologia e infraestrutura também precisam arcar juntas com as consequências da perda de confiança. Quando as pessoas passarem a ver todo o Crypto como um golpe, a tecnologia e a exploração que realmente valem a pena preservar também poderão ser abandonadas junto.
Como fundador da ArcBlock e praticante de Crypto e Blockchain, não estou disposto a aceitar tal desfecho. Acredito que esta indústria tem valor que vale a pena proteger, e também acredito que precisamos assumir a responsabilidade pela nossa própria base de segurança. Se continuarmos esperando passivamente pelo próximo incidente, o sangramento repetido pode acabar destruindo tudo o que construímos juntos.Então, quero lançar esta iniciativa: construtores de exchanges, carteiras e blockchains devem reconstruir conjuntamente a base do controle de ativos e da verificação de segurança, para que o escopo do dano de uma única intrusão seja limitado. A linha do tempo abaixo explica por que a mudança é necessária; a proposta técnica que se segue é o trabalho que acredito que podemos começar a fazer.
Em 2008, Satoshi Nakamoto propôs um sistema de dinheiro eletrônico ponto a ponto, tentando tornar os pagamentos menos dependentes de intermediários confiáveis. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) No entanto, incidentes importantes desde então expuseram repetidamente o problema de fundos, autorização e dependências de software se tornarem concentrados novamente.
Abaixo está uma lista cronológica de incidentes representativos em áreas como exchanges centralizadas (CEX), exchanges descentralizadas (DEX), pontes e carteiras. Não é um banco de dados completo de incidentes, nem uma estatística de perdas ano a ano. Onde valores são listados, eles se referem ao impacto bruto aproximado no momento do incidente; roubo, congelamento e recuperação subsequente são descritos separadamente e não podem ser somados como perdas permanentes.
2008 · Whitepaper do Bitcoin
Ponto de partida
O whitepaper do Bitcoin propôs pagamentos ponto a ponto sem instituições financeiras como intermediárias.
Fonte
2011–2014 · Roubo de longo prazo da Mt. Gox
CEX
A Mt. Gox sofreu roubo de longo prazo e eventualmente encerrou suas operações. Uma acusação posterior do Departamento de Justiça dos EUA alegou que aproximadamente 647.000 BTC foram roubados entre 2011 e 2014. Não foi um ataque de um único dia em 2014.
Fonte
2012 · Bitcoinica e Bitfloor
CEX / infraestrutura de custódia
O ambiente de hospedagem Linode da Bitcoinica foi comprometido; no mesmo ano, o backup não criptografado da carteira da Bitfloor tornou-se um ponto de entrada para o ataque. Os servidores e backups por trás da plataforma também fazem parte do limite de segurança dos ativos.
Fonte
2015 · Carteira quente da Bitstamp
CEX
A carteira quente da Bitstamp foi comprometida, e o ambiente operacional foi subsequentemente reconstruído. A distinção oficial entre o escopo do incidente e as reservas offline mostrou que o isolamento pode limitar o escopo da exposição.
Fonte
2016 · Bitfinex
CEX
Aproximadamente 120.000 BTC foram roubados da Bitfinex. Arranjos de multifirma ainda exigem autorização e verificação independentes de ponta a ponta.
Fonte 1 · Fonte 2
2016 · The DAO
Protocolo on-chain
O contrato do The DAO sofreu um ataque de reentrância, e aproximadamente 3,6 milhões de ETH foram transferidos para uma sub-DAO, desencadeando subsequentemente um fork do Ethereum. Um caminho de execução legítimo pode produzir resultados de negócios catastróficos.
Fonte 1 · Fonte 2
2017 · Biblioteca de carteira compartilhada Parity
Carteira de contrato
A biblioteca de carteira compartilhada Parity foi destruída, e aproximadamente 513.000 ETH foram congelados. Mesmo que não sejam transferidos, os fundos podem se tornar inutilizáveis devido a dependências de código compartilhado.
Fonte
2018 · Coincheck
CEXA hot wallet NEM da Coincheck foi roubada. A fronteira entre reservas offline, permissões de hot wallet e necessidades de negócio voltou a ser um problema.
Fonte
2019 · Binance
CEX
A Binance anunciou que 7.000 BTC foram retirados em uma única transação. Saídas de ativos em larga escala precisam ser restringidas antes da assinatura.
Fonte
2020 · KuCoin
CEX
Incidente da hot wallet da KuCoin, com uma grande quantidade de ativos posteriormente recuperada por meio de colaboração multipartidária. O valor bruto roubado e a perda final não são o mesmo número.
Fonte
2021 · Poly Network
Protocolo cross-chain
Aproximadamente US$ 612 milhões em ativos foram transferidos da Poly Network e posteriormente devolvidos em etapas. A autorização cross-chain e o controle de ativos não podem se sustentar apenas por meio dos caminhos normais de negócio.
Fonte
2022 · Ronin bridge
Bridge
As permissões de validadores da Ronin foram comprometidas, e 173.600 ETH e 25,5 milhões de USDC foram transferidos. As chaves de múltiplos validadores também podem cair na mesma cadeia de ataque.
Fonte
2022 · Slope wallet
Wallet
O incidente da Slope wallet no ecossistema Solana. A Solana declarou oficialmente que informações de chave privada foram transmitidas acidentalmente a um serviço de monitoramento de aplicações; não foi um comprometimento do consenso da Solana.
Fonte
2023 · Euler
Protocolo de empréstimo
Aproximadamente US$ 197 milhões em ativos foram transferidos da Euler devido a uma vulnerabilidade do protocolo e posteriormente recuperados. Combinações complexas em uma única transação podem amplificar falhas de lógica de negócio.
Fonte
2023 · Ledger Connect Kit
Ferramenta de conexão de wallet
O Ledger Connect Kit sofreu um ataque de supply chain, e código malicioso entrou no frontend da aplicação. A segurança do dispositivo de hardware não substitui a verificação do conteúdo da transação.
Fonte
2024 · DMM Bitcoin
CEX
Aproximadamente US$ 308 milhões foram roubados da DMM Bitcoin. O FBI e outras agências posteriormente divulgaram ataques de engenharia social direcionados a pessoal relevante e à cadeia de assinatura.
Fonte
2024 · Radiant Capital
Protocolo de empréstimo / assinatura
Aproximadamente US$ 50 milhões foram roubados da Radiant Capital, e múltiplos dispositivos de desenvolvedores foram comprometidos. A assinatura multipartidária ainda pode depender coletivamente de informações de transação contaminadas.
Fonte
2025 · Bybit / Safe
CEX / frontend de wallet
O incidente da Bybit de aproximadamente US$ 1,5 bilhão envolveu o ambiente de desenvolvedor e o frontend da Safe, e os signatários aprovaram uma transação que alterou a lógica de controle da wallet.
Fonte 1 · Fonte 2
2025 · Cetus DEX
DEXO incidente de aproximadamente US$ 223 milhões na Cetus, na Sui, com pesquisadores apontando uma falha em uma biblioteca matemática. Ambientes não EVM também devem examinar seu código e o escopo de exposição de ativos.
Fonte
2026-07 · Falha no gerador de números aleatórios da COLDCARD
Hardware wallet / geração de seedUma falha de firmware enfraqueceu a geração de seeds, permitindo que atacantes reconstruíssem as chaves privadas relevantes enquanto o dispositivo estava offline. A atualização não pode corrigir seeds fracas que já foram geradas; a migração conforme o aviso ainda é necessária.
Fonte
2026-10 · Implante de hardware Ledger
Carteira de hardware / ataque à distribuição
A Ledger confirmou que dispositivos genuínos foram modificados e circularam pelos canais de distribuição no Sudeste Asiático, com componentes implantados roubando frases de recuperação durante a inicialização. O fornecedor afirma que seus chips, sistema operacional e servidores não foram comprometidos.
Fonte
2026 · Incidente multi-chain da Binance
CEX / multi-chain
A Binance estimou inicialmente que aproximadamente US$ 6,3 bilhões em ativos foram afetados, e as investigações sobre outros possíveis pontos de intrusão ainda estão em andamento. Um único sistema operacional pode expor ativos em várias redes simultaneamente.
Fonte 1 · Fonte 2 · Fonte 3
Aqui há CEXs, mas também exchanges descentralizadas, protocolos de empréstimo e bridges; há ativos roubados e ativos congelados. Os ataques ocorrem em diferentes camadas, e os métodos de remediação diferem. Sou contra reduzir tudo isso à única frase "os usuários falharam em proteger suas chaves privadas". Como os usuários podem saber que o ambiente de desenvolvimento de uma determinada ferramenta, uma determinada biblioteca compartilhada ou uma autorização incompreensível se tornarão o ponto de entrada para todos os seus ativos?
As redes distribuídas já fizeram muito, mas o isolamento de falhas para o controle de ativos está longe de ser suficiente. A execução on-chain conclui fielmente uma transação, mas não pode responder por nós por que essa transação tem o direito de mover tanto.
A contribuição do Ethereum é significativa. Ele permitiu que mais pessoas escrevessem aplicações on-chain e fomentou um conjunto rico de ferramentas e experiência de desenvolvimento. Mas hoje, muitas novas chains e L2s (redes de escalabilidade de camada 2) tratam a compatibilidade com a EVM como seu objetivo principal. A EVM, a máquina virtual que executa os contratos inteligentes do Ethereum, está se tornando uma premissa técnica amplamente replicada. A compatibilidade de fato torna a migração de aplicações conveniente; a documentação de projetos como a Unichain cita explicitamente a reutilização das ferramentas do Ethereum como o valor de um ambiente de execução equivalente. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Acredito que tratar a compatibilidade com a EVM como a resposta padrão do setor está criando uma concentração estrutural de risco. Pode haver muitos nomes de redes, e os validadores podem diferir, mas os desenvolvedores podem implantar repetidamente os mesmos contratos, usar os mesmos hábitos de autorização e depender das mesmas bibliotecas de software. Erros em dependências compartilhadas não desaparecem só porque a implantação ocorre em outra chain. Este é um julgamento sobre o caminho técnico, não uma afirmação de que toda implementação da EVM necessariamente tenha a mesma vulnerabilidade.É também aqui que reside a minha crítica ao Ethereum. A capacidade de execução de contratos de uso geral conecta-se diretamente a ativos transferíveis, colocando uma responsabilidade enorme no código da aplicação e nas interações com carteiras. Contratos podem chamar contratos, autorizações podem persistir por muito tempo, e uma confirmação aparentemente comum pode alterar o modo de controle subsequente de uma conta. A segurança depende cada vez mais de que cada equipe de desenvolvimento compreenda corretamente essas combinações, e de que cada usuário compreenda corretamente o que assinou.
O EIP-7702 torna esse problema muito claro. Uma transferência comum é "quanto para quem desta vez"; uma autorização de delegação pode ser "a partir de agora, deixe este trecho de código executar operações em nome da minha conta". Ele tem os objetivos de melhorar a experiência do usuário e refinar permissões, mas configurar uma delegação em si já concede ampla capacidade de execução, e permissões granulares ainda precisam ser corretamente implementadas pelo código delegado. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) O preprint "EIP-7702 Phishing Attack" de Minfeng Qi et al. estuda o caminho de controlar persistentemente uma conta após induzir a assinatura de tais autorizações. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) À medida que a conveniência aumenta, a responsabilidade pela segurança também aumenta; a primeira não pode simplesmente ser repassada aos usuários.
Este incidente da Binance abrange múltiplas chains, e a investigação ainda não está concluída, portanto todo o impacto não pode ser diretamente atribuído ao EIP-7702 ou à EVM. Reentrância, comprometimento de serviços de assinatura e adulteração de front-end também não são a mesma vulnerabilidade. Mas tais distinções não devem se tornar uma desculpa para parar de questionar a arquitetura: por que a camada inferior não retém mais restrições que não possam ser facilmente contornadas, em nome de erros nas camadas superiores?
O MEV também me desagrada. Refere-se ao espaço em que os participantes obtêm valor extra por meio da inclusão, exclusão e ordenação de transações. Para mim, usar o poder de ordenação para intercalar transações de usuários e piorar seus resultados de execução deveria ser tratado como um bug que precisa ser corrigido, não empacotado como uma feature que vale a pena preservar só porque alguém pode lucrar com isso. A própria documentação do Ethereum também reconhece explicitamente o dano do intercalamento de transações aos usuários e o risco do MEV para a estabilidade da rede. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) O MEV não é exclusivo do Ethereum e também inclui diferentes atividades como arbitragem e liquidação; a indústria já possui pesquisas sobre mitigação. Minha crítica é que o incentivo para manter a rede não pode se tornar uma razão para sacrificar as condições de transação dos usuários. Um sistema de transação melhor deveria escrever o resultado mínimo de entrega e as taxas permitidas na autorização, e limitar o espaço para os ordenadores usarem informações não preenchidas para prejudicar os usuários.Sempre senti que o impacto do Ethereum sobre o Crypto é um pouco como o impacto do PHP sobre a Internet: permitiu que muitas pessoas construíssem coisas e também deixou uma dívida de engenharia que levará muito tempo para ser paga. O PHP ainda precisou corrigir uma grave vulnerabilidade de execução remota de código em outubro de 2026. Maturidade e popularidade não substituem o endurecimento contínuo. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) O que é valioso na Internet é que linguagens, frameworks e serviços de nuvem podem evoluir separadamente. Também devemos permitir que diferentes modelos de ativos e métodos de execução continuem se desenvolvendo, em vez de tratar a "compatibilidade com a mesma máquina virtual" como o ingresso para participar do ecossistema.
Portanto, convoco os ecossistemas Bitcoin, Solana e Ripple/XRP Ledger, bem como construtores incluindo a ArcBlock, a participarem seriamente da construção de uma base de segurança comum. Participar de padrões e interoperabilidade não exige primeiro se transformar em Ethereum. A diversidade deve ser implementada no controle de ativos e nos métodos de verificação e estar aberta ao escrutínio público. Os incidentes Slope e Cetus já nos lembraram que o não-EVM também não tem isenção de segurança.
O que espero ver tomar forma é uma especificação de segurança que diferentes ambientes de execução possam todos adotar: os mesmos limites de ativos e requisitos de verificação podem ser implementados separadamente pela EVM e por outros caminhos, e então as garantias e os custos de cada um podem ser publicamente examinados.
1. Deixe os controles de risco subjacentes restringirem o poder de dispor dos ativos
Carteiras grandes devem poder definir listas de destinatários permitidos, limites cumulativos de gastos e períodos de espera para novos destinatários. O ponto crucial é que essas regras não podem ser imediatamente canceladas pela mesma chave de transação cotidiana. Modificar as regras exige autorização independente e deve deixar tempo para monitoramento e revogação.Contas inteligentes existentes já possuem uma base de implementação, por exemplo, o Safe Guards pode adicionar restrições de transação além do multisig. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Precisamos transformar isso em uma capacidade fundamental mais fácil de adotar que cubra todos os caminhos de controle de ativos. Se apenas transferências diretas forem restringidas enquanto bypasses por meio de aprovações ilimitadas, módulos ou upgrades forem permitidos, a proteção falhará. Se o contrato de whitelist pode ser atualizado e se as permissões do destinatário mudaram também devem entrar no escopo de verificação.O Activation Lock da Apple oferece uma inspiração do dia a dia: ele restringe a reativação de dispositivos roubados e limita a calibração de certas peças roubadas, com o objetivo de reduzir o valor que pode ser explorado após o roubo. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) As carteiras também merecem ser projetadas nessa direção. Se um atacante obtiver uma chave, o alcance dos ativos que podem ser sacados permanece limitado, e o retorno esperado de um ataque pode diminuir; riscos como a interrupção de serviços ainda precisam ser tratados separadamente.
É isso que chamo de "constituição" da segurança de ativos: a autoridade operacional pode ser comprometida, mas a autoridade para modificar limites deve permanecer independente. Os processos de recuperação também devem ser restringidos, para evitar que uma única configuração incorreta bloqueie permanentemente os ativos.
II. Fazer as carteiras assumirem a responsabilidade de segurança, em vez de apenas entregar palavras mnemônicas
Tenho uma forte insatisfação com os sistemas de carteira atuais: se um produto pede a uma pessoa comum que copie um conjunto de palavras, exige que ela nunca as vaze, perca ou seja enganada para revelá-las, e então atribui todas as falhas subsequentes à responsabilidade do usuário, considero isso um design irresponsável. A autocustódia deve dar às pessoas controle, e também deve dar às pessoas capacidades utilizáveis de proteção e recuperação. Não deveria exigir que todo usuário primeiro se torne um especialista em segurança. Esse também é um limiar que o Crypto precisa cruzar para alcançar mais usuários comuns.Incidentes recentes colocaram esse problema diretamente em pauta. Em outubro de 2026, a Ledger confirmou que atacantes modificaram dispositivos genuínos e depois os enviaram de volta ao mercado por meio de canais de distribuição no Sudeste Asiático, com componentes implantados roubando palavras de recuperação durante a inicialização. A Ledger definiu isso como um ataque de distribuição localizada após o dispositivo sair da fábrica, e não como um comprometimento de seu chip, sistema operacional ou servidores. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) O incidente da COLDCARD em julho envolveu o enfraquecimento do firmware na geração de seeds: o dispositivo não precisava ser controlado remotamente para que um atacante reconstruísse as chaves privadas relevantes. Atualizar o firmware corrige o processo de geração daqui para frente, mas seeds fracas que já foram geradas ainda precisam ser migradas. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Esses dois incidentes não são o mesmo tipo de vulnerabilidade, mas, juntos, mostram: mesmo que os usuários copiem cuidadosamente as palavras e mantenham o dispositivo offline, eles não podem verificar a aleatoriedade e a integridade da cadeia de suprimentos em nome do fabricante. Fazer o dispositivo exibir as palavras de backup tem o propósito de recuperação offline, mas também faz com que o segredo completo de recuperação passe por um caminho de exibição e backup que precisa de proteção. A segurança do chip não pode substituir a verificação do dispositivo inteiro e do processo de entrega.
O objetivo da melhoria deve ser o ciclo de vida completo da carteira: como as chaves são geradas, como as transações são explicadas, como as permissões são separadas e como a recuperação funciona após a perda de um dispositivo. A abstração de conta, ou seja, permitir que contas verifiquem autorização por meio de regras programáveis, e backups por limiar, como o SLIP-39, já têm padrões e bases de implementação, então não se pode dizer que ninguém no setor está trabalhando nisso. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Mas precisamos transformar essas capacidades em proteções testadas e fáceis de usar, em vez de deixar os usuários montarem esquemas complexos por conta própria.
A simples ofuscação das palavras mnemônicas não é suficiente. Direções mais confiáveis incluem backups criptografados auditados, recuperação por limiar e autorização por dispositivo independente, além de fazer os usuários completarem exercícios de recuperação antes de depositar grandes quantidades de ativos. Fragmentos de backup e multisig são camadas diferentes: os primeiros podem se recombinar no mesmo segredo durante a recuperação, enquanto o segundo exige que vários signatários independentes aprovem uma transação. Serviços de recuperação não devem se tornar silenciosamente uma nova chave mestra, nem uma senha extra deve se tornar outra armadilha em que perdê-la significa perda irrecuperável.Carteiras pessoais e sistemas de carteiras de exchanges podem compartilhar especificações de segurança para descrições de transações, solicitações de assinatura, restrições de ativos e processos de recuperação, adotando limites e políticas de aprovação diferentes. O PSBT do Bitcoin já fornece um formato para transmitir transações não assinadas entre ferramentas, e vale a pena continuar a construir essa interface comum. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) O que é comum são os requisitos de segurança verificáveis; cada cadeia ainda precisa esclarecer suas próprias regras de adaptação. As carteiras devem apresentar claramente o que esta assinatura transferirá e quanta autoridade subsequente ela concede a quem, e políticas independentes devem rejeitar operações fora dos limites; uma página de confirmação mais bonita não é suficiente.
III. Alcançar verificabilidade com o mínimo necessário de divulgação
Provar que uma condição é válida não deve sempre exigir que os usuários divulguem todos os dados subjacentes. Divulgação seletiva, provas de conhecimento zero e acesso de auditoria concedido sob demanda devem se tornar opções normais na infraestrutura. Isso também está relacionado à segurança de ativos: identidade pública e relações entre ativos podem fornecer pistas para enganos direcionados; os dados de que o negócio não precisa devem ser expostos o mínimo possível.
O sistema de credenciais verificáveis do W3C já possui um caminho técnico para divulgação seletiva; no entanto, provar que as entradas são autênticas, que as credenciais permanecem válidas e como o status é revogado ainda precisa ser esclarecido. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Adotar provas de conhecimento zero (ZK) não oculta automaticamente os valores e as relações das transações; provas de escalabilidade e proteção de privacidade são objetivos diferentes.
Por exemplo, quando um negócio só precisa verificar a elegibilidade para participar, um usuário pode apresentar uma conclusão de elegibilidade válida emitida por uma instituição confiável sem divulgar materiais financeiros completos. Quando for necessário provar que um valor oculto satisfaz uma condição, um mecanismo de prova apropriado pode então ser usado. A fonte confiável da credencial e seu status de revogação ainda precisam ser verificados.
Minha iniciativa é primeiro esclarecer "quem precisa verificar o quê" e depois projetar os dados que devem ser tornados públicos. Aqueles que verificam a elegibilidade podem precisar apenas da conclusão de elegibilidade; aqueles que assumem responsabilidades específicas de auditoria podem obter evidências restritas. Restrições verificáveis publicamente devem minimizar as informações pessoais permanentemente expostas a todos.
IV. Tornar os serviços de transação o mais livres possível de custódia centralizadaO casamento de ordens, a descoberta de rotas e a liquidação de ativos devem ser projetados separadamente. Um serviço que fornece um ponto de entrada de negociação deve obter apenas as permissões necessárias para concluir a liquidação atual na medida do possível, para que os ativos do usuário permaneçam sob seu respectivo controle no restante do tempo. Os protocolos de transação existentes baseados em intenções já exploraram parte do caminho, e o setor pode continuar a completá-lo. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
O que os usuários concordam deve ser condições de liquidação claras, incluindo o que é pago, o que é recebido no mínimo, quando expira e as taxas permitidas. Depois que um serviço de negociação for comprometido, o atacante pode negar o serviço, mas não pode alterar arbitrariamente essas condições. As empresas que ainda exigem custódia centralizada também devem separar as permissões de reserva e operacionais, e limitar a exposição de carteiras quentes e os limites de reposição automática.
O IBIT é o produto negociado em bolsa de bitcoin da iShares, e o que é negociado no mercado são suas ações. Seu arranjo fornece um exemplo de isolamento parcial: as ações e o Bitcoin subjacente são registrados separadamente, e as chaves privadas relevantes para o Vault Balance (saldo de custódia) são colocadas em armazenamento a frio. As mudanças no registro de negociação de ações não exigem que o Bitcoin subjacente se mova a cada transação. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) O que se pode aprender com isso é a separação entre direitos de negociação e direitos de disposição de reservas. Seu Trading Balance (saldo do serviço de negociação) tem um arranjo diferente, e a própria custódia também carrega riscos; o armazenamento a frio deve ser acompanhado de instruções independentes e verificação de assinatura.
Comparo o ponto de entrada de negociação a um roteador na esperança de que ele possa ser substituído sem carregar um interruptor mestre sobre todos os ativos dos usuários. A liquidação é mais complexa do que o encaminhamento de pacotes, e a entrega de ativos e a autorização ainda precisam ser verificadas de forma independente. Tornar um serviço não custodial e depois conceder-lhe direitos ilimitados de saque só trará o risco centralizado de volta.
V. Use uma arquitetura em camadas para isolar falhas e preservar a substituibilidadePrecisamos de interfaces de identidade e autorização, políticas de ativos e métodos de verificação de liquidação que possam evoluir de forma independente. Diferentes chains podem manter seus próprios modelos de execução e se conectar por meio de interfaces claras. As interfaces devem declarar as garantias de segurança e suas condições, não apenas dizer "a chamada foi bem-sucedida". A experiência da internet sustenta essa abordagem. No RFC 9518, "Centralization, Decentralization, and Internet Standards", Mark Nottingham discute especificamente situações em que a centralização pode ser útil e também analisa o poder e os riscos que ela traz. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Essa é exatamente a atitude que vale a pena aprender: deixar a arquitetura responder quais responsabilidades podem ser centralizadas, em que grau e como impedir que esse poder se expanda. Um serviço pode ser autorizado a identificar anomalias de forma centralizada, enquanto sua permissão para tocar em ativos é limitada; os usuários devem poder trocar de serviço sem perder suas próprias políticas de ativos e registros de verificação.
A questão de aceitação mais importante é: depois que um serviço de negócios for comprometido, qual camada independente ainda pode rejeitá-lo? Se todas as camadas compartilham uma única chave administrativa, a chamada estratificação é apenas estratificação em um diagrama de implantação.
Esse objetivo pode ser visto como cinco camadas de responsabilidade: o serviço de transação envia solicitações, a wallet expressa a intenção do usuário, a política independente limita a autoridade sobre a disposição de ativos, o componente de verificação checa operações e evidências, e a camada de liquidação impõe restrições e fornece registros verificáveis. Elas podem ser implementadas por equipes diferentes, e suas dependências e condições de falha também devem ser descritas separadamente.
A arquitetura-alvo defendida neste artigo. A camada de liquidação deve impor a política de ativos; prompts na wallet não podem substituir essa restrição. Assinatura diária, mudanças de regras e autoridade de recuperação precisam ser isoladas e submetidas a testes de bypass.
6. Permitir que os usuários verifiquem seus próprios ativos de forma leve
Pessoas comuns não deveriam precisar armazenar e executar todo o histórico da chain inteira para verificar seus próprios saldos e recibos; nem deveriam precisar confiar apenas em um único servidor por trás da wallet. Satoshi Nakamoto já propôs o SPV, verificação de pagamento simplificada, na Seção 8 do whitepaper. O BIP-157 do Bitcoin continua explorando permitir que clientes baixem filtros e encontrem blocos relacionados a si mesmos; Ethereum também tem designs de cliente leve. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Portanto, o problema não é que ninguém nunca tenha pensado nisso, mas que ainda precisamos incorporar capacidade de verificação com condições de segurança claras nas wallets que os usuários usam todos os dias.Tome como exemplo uma cadeia que suporta provas de estado de conta: ao consultar um saldo, o servidor deve retornar tanto o saldo quanto uma prova. A carteira primeiro verifica um resumo curto de bloco, ou seja, o cabeçalho do bloco, de acordo com as regras dessa cadeia, e então verifica se esse saldo é consistente com os dados comprometidos pelo resumo. O servidor fornece a resposta, e a carteira pode verificar a resposta. O SPV do Bitcoin verifica evidências de que transações relevantes foram incluídas; ele não pode ser copiado diretamente como prova de saldo. A carteira também deve exibir claramente até onde sincronizou e quais informações foram verificadas; quando provas estiverem faltando, os dados estiverem desatualizados ou as fontes entrarem em conflito, ela deve alertar ou interromper operações de alto risco que dependam dessas informações, e não deve silenciosamente recair na confiança cega.
A verificação leve ainda tem condições. Provar que uma transação foi incluída em um bloco não é o mesmo que verificar por conta própria que todas as transações no bloco são válidas. Esquemas diferentes podem depender de que a maioria do poder de hash seja honesta, ou de um registro inicial confiável, isto é, um checkpoint; eles também devem se proteger contra servidores que retêm dados ou isolam usuários em um registro de cadeia desatualizado. Se a própria consulta expõe os endereços com os quais o usuário se importa também precisa ser tratado. Nós completos e produtores de blocos não são o mesmo papel; Ethereum hoje usa validadores em vez de mineradores para a produção de blocos.
Mais importante, provar que "esta transferência realmente aconteceu on-chain" não pode provar que "esta é exatamente a transferência que o usuário queria." Clientes leves não podem substituir os limites de ativos e as verificações de assinatura anteriores. Eles permitem que os usuários dependam menos de uma resposta não verificável, enquanto a política de ativos garante que mesmo uma assinatura válida não possa dispor de ativos sem limite. Somente construindo ambas as camadas juntas é que a capacidade de verificação pode ser distribuída entre os participantes.
7. Construir identificação de anomalias e verificação de segurança como infraestrutura pública
Antes de uma transação, alguém deve verificar se a operação está em conformidade com a política de ativos e se ela muda repentinamente o comportamento histórico. Anomalias óbvias podem acionar uma pausa ou uma revisão escalonada; expandir permissões exige outro caminho independente. A IA pode participar do julgamento, mas não deve receber um passe que sobreponha regras rígidas.
Ao mesmo tempo, precisamos manter conjuntamente casos de ataque, testes de permissão e ferramentas de verificação que possam ser executados repetidamente. Somente compartilhando especificações e preservando implementações independentes e verificação independente é que falhas de modo comum podem ser reduzidas. Fundações e exchanges já têm investimentos em segurança, como a Trillion Dollar Security Initiative da Ethereum Foundation. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) A próxima pergunta a fazer é se o investimento pode ser transformado em infraestrutura pública que outras equipes também possam adotar e inspecionar.Nenhum desses sete itens de trabalho pode garantir segurança absoluta. O que eles precisam entregar são limites inspecionáveis: sob quais condições de comprometimento de permissões, quanto de ativos fica exposto no máximo, com que rapidez anomalias podem ser descobertas e de quem a recuperação ainda depende.
Neste ponto, alguns podem dizer: a direção parece certa, mas a indústria já avançou por tantos anos; quantas pessoas e quanto tempo a reconstrução exigiria? Isso não continua sendo idealismo?
Se estimado segundo o modo passado de produção de software, essa dúvida é muito realista. Mas até 2026, acredito que agentes de codificação e engenharia de software habilitada por IA já mudaram a capacidade de construção que podemos mobilizar. Os agentes de codificação mencionados aqui são assistentes de programação por IA que conseguem ler e escrever código, chamar ferramentas, executar testes e continuar trabalhando com base em feedback em um ambiente de desenvolvimento. Os construtores definem metas, estabelecem limites de segurança, usam essas ferramentas para implementar e verificar sistemas, e assumem a responsabilidade pelos resultados.
Trabalho que antes exigia grandes equipes para implementar, adaptar e manter repetidamente agora pode ser tentado por pequenas equipes com essa nova abordagem de engenharia. Uma equipe detém uma camada, entrega componentes em torno de interfaces claras, e então outras equipes os inspecionam e combinam. Organizar o julgamento arquitetural humano, a capacidade de implementação dos agentes de codificação e a verificação de segurança independente é, na minha visão, o caminho de construção que vale a pena reavaliar seriamente.
Pesquisa da Anthropic e da PNNL dá um exemplo concreto: em um ambiente limitado de simulação de infraestrutura crítica, pesquisadores relataram que a reconstrução de ataques foi reduzida de possivelmente várias semanas para cerca de três horas. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Isso não prova que uma pequena equipe já pode reescrever com segurança toda a indústria, mas mostra que trabalho antes caro de verificação e ofensiva-defensiva pode ter novas condições de custo.
Uma abordagem organizacional que pode ser iniciada agora é construir conjuntamente uma Build in Public AI Factory. Especialistas do setor, acadêmicos e praticantes escrevem abertamente requisitos e especificações de aceitação (spec), explicando o que deve ser protegido, quais operações são permitidas e quais limites ainda devem se manter após o comprometimento de quais permissões, e então transformam esses requisitos em testes de aceitação. Grupos de agentes de codificação assumem o trabalho principal de codificação, teste e depuração; diferentes equipes inspecionam projetos e resultados, e os humanos assumem a responsabilidade de julgamento e aceitação.Participantes podem contribuir com ideias, máquinas, poder de computação e cotas de invocação de modelos, ou seja, tokens de IA. Empresas de IA e computação em nuvem também podem apoiar essa construção pública por meio de cotas de modelos, recursos de computação e ferramentas. Especificações, código de protótipo, fluxos de trabalho de agentes, ambientes de teste e resultados de verificação podem todos se tornar infraestrutura mantida em comum, permitindo que a próxima equipe continue diretamente a partir dali. O objetivo é transformar a capacidade de desenvolvimento em instalações públicas reutilizáveis e reduzir a dependência do tempo de qualquer pessoa ou de qualquer equipe.
Os atacantes também estão usando IA, e não temos mais razão para deixar a defesa nos métodos de produção do passado. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Mas a geração de código ser rápida é apenas o ponto de partida. Somente escrevendo restrições com clareza, tornando os testes repetidamente executáveis e fazendo com que um componente seja inspecionável e substituível é que a capacidade de IA pode ser transformada em melhoria de infraestrutura.
Construtores independentes trabalham juntos com a ajuda de agentes de codificação e ferramentas de IA. A oficina espacial é uma metáfora para a construção pública. Quero especialmente dirigir este chamado àqueles que ainda amam construir. O "hacker" aqui se refere a alguém disposto a descobrir como um sistema funciona, disposto a compartilhar o que encontra e disposto a deixar outros testarem seu trabalho. Esse espírito outrora impulsionou a Internet, e hoje pode impulsionar o Crypto também.
Não acredito que esta indústria careça de pessoas inteligentes, e não acredito que as indústrias de Crypto e IA não consigam encontrar os recursos para apoiar este trabalho. O mais difícil é organizar talento, financiamento e responsabilidade sustentada em conjunto. Fundações e empresas capazes deveriam estar dispostas a arcar com o custo de longo prazo de um trabalho fundamental que não gera receita diretamente, mas beneficia a todos.
Espero que todos possam trabalhar juntos para construir uma infraestrutura criptográfica compartilhada globalmente. Diferentes redes e equipes podem colaborar sob restrições de segurança compartilhadas, cada uma implementando suas próprias soluções e testando as umas das outras, e os usuários podem escolher e migrar. Pode começar com um único componente, mas a direção deve ser grande o suficiente para acomodar toda a indústria construindo junta. Todos os participantes, incluindo a ArcBlock, devem contribuir com trabalho verificável.
Devemos construir conjuntamente um tipo de infraestrutura em que, mesmo que alguma parte tenha sido comprometida, os ativos ainda tenham limites, outros sistemas ainda possam rejeitar erros e os usuários ainda tenham caminhos para recuperação e saída. Pegando emprestado o nome de Star Wars, esta é a nossa A New Hope. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) A esperança vem de construtores comuns dispostos a agir, e também deste momento em que agentes de codificação e novos métodos de engenharia lhes permitem assumir mais trabalho de construção.Quero estender um convite aos construtores de projetos como Ethereum, Solana, Bitcoin e XRP Ledger, às exchanges como Binance, Coinbase e Kraken, e também às equipes de carteiras, protocolos, pesquisa de segurança, IA e computação em nuvem: comecem com um piloto de escopo claramente definido e produzam conjuntamente melhorias que outras equipes possam adotar e testar.
Os nomes listados são apenas exemplos, em nenhuma ordem específica. Independentemente do tamanho ou do caminho técnico que vocês seguem, vocês são bem-vindos para participar. Este convite também inclui os construtores dos caminhos técnicos criticados neste artigo; melhorar conjuntamente a segurança dos ativos vale a pena cruzar as fronteiras dos nossos respectivos ecossistemas.
Eu mesmo estou disposto a participar e contribuir com nossa infraestrutura existente, engenharia de software e práticas de colaboração em IA. Somos apenas uma pequena equipe no setor, e o que podemos fazer é limitado. Espero começar com um protótipo e um conjunto de testes repetíveis.
Pessoas com experiência operacional prática podem fornecer cenários de ataque desidentificados, equipes de carteiras e protocolos podem implementar proteções, e pesquisadores independentes podem tentar contorná-las. Cada equipe assume a parte que consegue lidar, testando conjuntamente a solução e decidindo o próximo passo.
Estou disposto a participar da organização dos requisitos de limitação e recuperação de ativos deste artigo na primeira especificação pública, e também estou disposto a contribuir com práticas técnicas e de engenharia relevantes para construir, junto com outros participantes, uma AI Factory pública para este piloto. Primeiro escolham um problema muito específico: uma vez que a chave de transação do dia a dia foi comprometida, como ainda é possível impedir que o atacante drene a carteira de uma só vez? Escrevam a faixa de perda permitida, a autoridade para modificar regras e as condições de recuperação em testes de aceitação, depois façam agentes de desenvolvimento implementarem um protótipo, e façam outro grupo de agentes e pesquisadores independentes procurarem caminhos de contorno. Servidores de dados retornando saldos incorretos, e a recuperação após perda de dispositivo, também podem ser gradualmente adicionados aos testes. O que o protótipo alcança, onde ele falha e quais dependências permanecem devem ser todos explicados publicamente, e o próximo passo deve ser decidido com base em evidências.
Aqueles dispostos a participar são bem-vindos para repostar ou citar publicamente esta iniciativa no X e @mave99a, e falar sobre o problema que querem resolver, casos de ataque desidentificados ou os recursos que podem contribuir. Espero que a discussão ocorra publicamente, para que mais construtores possam vê-la e se juntar.
Crypto não pode continuar assim. Aqueles dispostos a trabalhar juntos, vamos agir agora, começando com uma melhoria que pode ser construída e que resiste a testes.Binance, publicação oficial do anúncio inicial e atualização oficial da investigação de acompanhamento, 2026-10-30; análise multicadeia da TRM. Este rascunho foi verificado em 2026-10-30; o status da investigação e da recuperação pode mudar. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. A concentração de risco de dependências compartilhadas é um julgamento do autor neste artigo, não uma conclusão daquele documento. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, criado em 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, pré-print arXiv v1; não é uma identificação deste incidente da Binance. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), mecanismos de ordenação, diferentes tipos e efeitos negativos; "deveria ser corrigido como um bug" é a posição de engenharia do autor sobre comportamentos que prejudicam usuários. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Arquivo oficial de notícias do PHP de 2026; atualização de 2026-10-26 da CISA sobre vulnerabilidades conhecidas e exploradas, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, descrição de funcionalidades e riscos de permissão. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; descrição atual do suporte ao pareamento de peças. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, declaração do fornecedor sobre um ataque na cadeia de distribuição; Joe Grand, pesquisa de engenharia reversa sobre implantes de hardware. Não apresente estimativas não verificadas de perdas de rede como conclusões definitivas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, acessado em 2026-10-30, registro continuamente atualizado do incidente de julho de 2026 e da remediação; atualização e migração de seed são duas operações distintas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, recuperação por limiar, compatibilidade e riscos adicionais de passphrase. Mecanismos existentes são uma base para construção e não significam que toda implantação seja confiável. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Formato de Transação Bitcoin Parcialmente Assinada, um formato de intercâmbio para transações não assinadas, não uma especificação de estratégia geral de ativos entre cadeias. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Visão Geral de Credenciais Verificáveis v1.0, Nota de Grupo de 2026-07-30; notas de privacidade do Ethereum. O status de padronização das tecnologias descritas na visão geral é independente em cada caso. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Documentação do CoW Protocol, intenções de transação e mecanismos de solver; este artigo não fornece um endosso de segurança abrangente para qualquer implantação específica. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, Relatório Anual IBIT 2025, páginas 8–10 do PDF sobre arranjos de custódia e página 45 sobre divulgações de riscos. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralização, Descentralização e Padrões da Internet, 2023-12, submetido de forma independente, RFC informativo, não uma especificação da trilha de padronização. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Whitepaper do Bitcoin Seção 8 Verificação de Pagamento Simplificada; BIP-157: Filtragem de Blocos no Lado do Cliente; Ethereum, Clientes leves. Diferentes clientes leves têm diferentes escopos de verificação e condições de confiança. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Anunciando a Iniciativa de Segurança do Trilhão de Dólares, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, IA para defender infraestrutura crítica, 2026-01-08, pesquisa em ambiente limitado em colaboração com o PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapeando ameaças cibernéticas habilitadas por IA, pesquisa sobre amostras reais de abuso. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: Uma Nova Esperança (Episódio IV), 1977; este artigo toma emprestado o título e a imagem de autossalvamento conjunto. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)