Autores: 142y & MIA_Ether
Fonte: OpenBuild
Link para o texto original: https://mp.weixin.qq.com/s/XB762FQoeMqDbIZNX3EbDg
Aviso: este artigo foi republicado. Os leitores podem obter mais informações por meio do link para o texto original. Caso o autor tenha alguma objeção à forma de republicação, entre em contato conosco e faremos as alterações solicitadas. A republicação tem como único objetivo compartilhar informações, não constitui recomendação de investimento e não representa as opiniões nem o posicionamento da Wu Shuo.
Em 25 de outubro, na conferência de desenvolvedores ETHShenzhen 2026, Vitalik Buterin, cofundador do Ethereum, fez uma palestra sobre IA e segurança de redes.
Recentemente, a IA fez uma série de progressos em áreas como a investigação matemática, a descoberta de algoritmos e a identificação de vulnerabilidades. Isso também suscitou uma questão importante: se a IA continuar a descobrir algoritmos matemáticos mais eficientes, serão ainda fiáveis, no futuro, as hipóteses criptográficas que hoje sustentam a segurança da blockchain?
Partindo desta questão, Vitalik dividiu em três níveis as potenciais ameaças de segurança que a IA pode trazer ao Ethereum: a criptografia subjacente, o código dos clientes e as aplicações e carteiras dos utilizadores. Com base em algoritmos concretos, exemplos históricos e na investigação tecnológica atualmente em curso no Ethereum, abordou a forma como estes riscos poderão surgir e como os programadores e os utilizadores comuns devem responder.
Bom dia a todos.
Hoje quero falar de um tema muito importante: o rápido desenvolvimento da IA e o impacto que poderá ter na segurança do Ethereum.
Recentemente, a IA fez progressos impressionantes na matemática e na cibersegurança. Por um lado, já começou a descobrir vulnerabilidades em sistemas de software e a atacar sites e serviços de rede; por outro, também ajudou a resolver muitos problemas matemáticos que antes eram considerados extremamente difíceis.
Por exemplo, a OpenAI publicou recentemente uma série de resultados de investigação matemática sobre as equações de Navier–Stokes, a hipótese de Riemann generalizada e algoritmos de multiplicação de inteiros mais rápidos do que os limites clássicos de complexidade conhecidos até agora.
Tomemos como exemplo a multiplicação de inteiros: durante muito tempo, acreditou-se que, nos modelos de computação correspondentes, a complexidade temporal da multiplicação de dois inteiros de n bits dificilmente poderia ser inferior a n log n. Surgiram agora resultados de novos algoritmos que ficam abaixo desse limite.
Estes progressos são muito surpreendentes e também me deixam um pouco preocupado.
Um aspeto interessante é que a OpenAI publicou muita investigação matemática, mas não vimos a divulgação pública de avanços criptográficos correspondentes.
Não sabemos se isso se deve ao facto de os investigadores não terem explorado especificamente problemas criptográficos ou a outras razões.
O que realmente vale a pena ponderar é: se a IA conseguir, em pouco tempo, fazer progressos equivalentes a décadas de investigação matemática, durante quanto tempo continuarão a ser válidas as hipóteses criptográficas que hoje sustentam a segurança da Internet e da blockchain?
No caso do Ethereum, acredito que a IA poderá trazer três categorias principais de riscos de segurança.
O primeiro nível diz respeito às hipóteses criptográficas subjacentes ao protocolo.
A segurança da criptografia depende de alguns problemas matemáticos que se considera difícil resolver com eficiência, como a fatorização de inteiros, o logaritmo discreto em curvas elípticas, os problemas de reticulados e os problemas computacionais relacionados com funções hash.
Se a IA encontrar algoritmos matemáticos mais eficientes, estas hipóteses poderão mudar.
O segundo nível diz respeito à segurança do software dos clientes do Ethereum.
O Ethereum tem clientes da camada de execução, clientes da camada de consenso, várias bibliotecas de software criptográfico e componentes de rede. Estes sistemas são constituídos por grandes quantidades de código e podem conter vulnerabilidades ainda não descobertas.
À medida que a capacidade da IA para descobrir vulnerabilidades aumenta, os atacantes poderão encontrar estes problemas com mais facilidade. Naturalmente, também podemos usar IA para ajudar a encontrar e corrigir vulnerabilidades.
O terceiro nível diz respeito à segurança dos utilizadores e das aplicações.
Mesmo que o protocolo subjacente do Ethereum funcione normalmente, ainda podem surgir problemas nas carteiras, nos contratos inteligentes, nas interfaces dos utilizadores ou na gestão das chaves.
Como consequência, os utilizadores podem perder ativos ou expor a sua privacidade.
Vale a pena levar a sério os riscos dos três níveis. Gostaria de começar pelo nível mais fundamental e, ao mesmo tempo, mais difícil de prever: a própria criptografia.
Justin Drake, investigador da Ethereum Foundation, propôs recentemente uma área que merece atenção.
Há muito que falamos de criptografia resistente à computação quântica; agora também precisamos de considerar a segurança criptográfica perante avanços matemáticos impulsionados pela IA.
Estes dois problemas estão relacionados, mas não são exatamente iguais.
A potencial ameaça dos computadores quânticos a alguns algoritmos criptográficos é relativamente clara. Por exemplo, o algoritmo de Shor afeta o RSA e a criptografia de curvas elípticas, enquanto o impacto nas funções hash e na encriptação simétrica é diferente e pode ser mitigado escolhendo parâmetros de segurança adequados.
Os desafios trazidos pela IA são ainda mais difíceis de prever.
A IA poderá descobrir novos algoritmos clássicos ou encontrar atalhos computacionais que ninguém tinha notado antes, com base nas ferramentas matemáticas existentes.
Vamos analisar algumas categorias comuns de técnicas criptográficas.
A primeira é a das funções hash.
As funções hash conseguem mapear uma entrada de comprimento arbitrário para uma saída de comprimento fixo. Uma função hash segura deve satisfazer propriedades como resistência a ataques de pré-imagem, de segunda pré-imagem e de colisão.
Pessoalmente, acredito que as funções hash têm perspetivas de segurança a longo prazo relativamente robustas.
A segunda categoria é a encriptação simétrica, como o AES.
Na encriptação simétrica, quem encripta e quem desencripta têm de possuir o segredo partilhado correspondente. Ela permite encriptar com eficiência, mas não resolve, por si só, todos os problemas da criptografia de chave pública.
Por exemplo, se as partes não tiverem partilhado previamente um segredo, são necessárias outras ferramentas criptográficas para estabelecer uma chave de comunicação de forma segura.
A terceira categoria é a criptografia de curvas elípticas.
O ECDSA e as assinaturas Schnorr, amplamente utilizados pelo Ethereum, bem como esquemas como o secp256k1, estão relacionados com a criptografia de curvas elípticas.
Há também uma categoria de técnicas mais complexas: os emparelhamentos em curvas elípticas.
A criptografia baseada em emparelhamentos é utilizada em assinaturas BLS e em alguns sistemas eficientes de provas de conhecimento zero.
Estes esquemas são muito eficientes e, por isso, são amplamente utilizados no domínio da blockchain.
No entanto, também dependem de problemas com uma estrutura matemática rica. Se a IA encontrar novas relações matemáticas ou algoritmos, poderá alterar o custo dos ataques aos problemas relacionados.
Tenho uma cautela especial em relação aos emparelhamentos em curvas elípticas.
A quarta categoria é a criptografia baseada em reticulados.
Atualmente, considera-se que a criptografia baseada em reticulados é uma das principais áreas da criptografia pós-quântica.
As assinaturas pós-quânticas, como a ML-DSA, bem como muitos estudos sobre encriptação de chave pública, encriptação totalmente homomórfica e obfuscação, estão relacionados com problemas matemáticos baseados em reticulados.
Conseguem resistir aos principais métodos de ataque quântico conhecidos atualmente, mas ainda não compreendemos completamente a sua segurança perante futuras descobertas matemáticas.
Por exemplo, como devemos avaliar a probabilidade de a IA encontrar, nos próximos três anos, um novo algoritmo para atacar problemas de reticulados?
Acredito que isso é muito difícil.
Por isso, ao escolher esquemas de segurança a longo prazo, precisamos de avaliar estas hipóteses matemáticas com ainda mais cautela.
Talvez se perguntem: se a IA descobrir de repente um novo algoritmo de ataque, todos os sistemas que usam a criptografia relacionada vão entrar imediatamente em colapso?
Acredito que devemos estar mais preparados para outro cenário.
A IA poderá encontrar um algoritmo mais eficiente que, ainda assim, exija alguns recursos computacionais.
Isso faria com que parâmetros antes seguros se tornassem gradualmente insuficientes, obrigando-nos a aumentar o comprimento das chaves, o tamanho das assinaturas ou a dimensão das provas.
Para compreender esta situação, podemos recorrer ao exemplo da fatorização de inteiros.
Suponhamos que temos um número inteiro:
351 = 3³ × 13.
Se quisermos encontrar os seus fatores, um método simples é a divisão por tentativa (Trial Division).
Começamos pelos números inteiros mais pequenos e tentamos, um a um, dividir o número sem deixar resto.
É um método bastante intuitivo. Mas, quando os números são muito grandes, é evidente que experimentar um a um não é suficientemente eficiente.
Mais tarde, os matemáticos descobriram algoritmos de fatorização de inteiros mais complexos, como o crivo quadrático (Quadratic Sieve).
O crivo quadrático procura números que satisfaçam certas condições, de modo que os seus quadrados formem relações úteis módulo N.
Ao selecionar números que possam ser decompostos num conjunto de primos pequenos e ao transformar esses resultados numa questão de álgebra linear módulo 2, é possível encontrar uma relação de congruência de quadrados:
x² ≡ y² (mod N).
Depois de obter uma relação deste tipo, é possível encontrar fatores não triviais de N calculando gcd(x − y, N) e gcd(x + y, N).
O exemplo da apresentação é N = 15347, que pode ser fatorizado da seguinte forma:
15347 = 103 × 149.
Mais tarde, os investigadores descobriram o crivo geral do corpo de números (GNFS), ainda mais eficiente.
Isto demonstra algo importante: um problema matemático pode ser considerado difícil durante muito tempo, até alguém encontrar outra forma de o resolver computacionalmente.
A criptografia de curvas elípticas enfrenta uma incerteza semelhante.
Atualmente, conhecemos alguns algoritmos para o problema do logaritmo discreto em curvas elípticas, mas ainda não encontrámos uma solução inovadora e eficiente equivalente ao crivo quadrático ou ao GNFS, usados na fatorização de inteiros.
Será possível existir alguma estrutura matemática que ainda não descobrimos e que torne os ataques a curvas elípticas muito mais fáceis?
A IA poderá ajudar os investigadores a encontrar essa estrutura.
Se isso acontecer, o ECDSA ou a criptografia baseada em reticulados não perderão necessariamente toda a sua segurança de imediato.
Por exemplo, um sistema que atualmente utiliza assinaturas curtas e parâmetros de chave pequenos poderá ter de usar parâmetros muito maiores no futuro para manter o mesmo nível de segurança.
Um objeto criptográfico que hoje talvez ocupe apenas algumas dezenas de bytes poderá vir a precisar de algumas centenas; o tamanho das assinaturas ou das provas de certos esquemas baseados em reticulados poderá ter de aumentar uma ordem de grandeza.
São cenários hipotéticos.
Significam que, mesmo que um esquema criptográfico continue a poder ser utilizado, o seu custo operacional poderá aumentar significativamente.
É também por isso que tenho preferência pela investigação em criptografia baseada em hash.
A função hash MD4 é um exemplo histórico interessante.
A MD4 é uma função hash muito antiga, para a qual foram posteriormente descobertos ataques de colisão graves.
Por outras palavras, um atacante pode encontrar entradas diferentes que produzam o mesmo valor hash.
No entanto, as diferentes propriedades de segurança das funções hash não são equivalentes. Um avanço nos ataques de colisão não significa que o problema da pré-imagem tenha sido resolvido da mesma forma.
Consideremos agora esquemas criptográficos com uma estrutura matemática rica, como as curvas elípticas.
As curvas elípticas têm uma estrutura de operações de grupo. Também conhecemos ferramentas matemáticas como o algoritmo de Schoof, que permite analisar o número de pontos numa curva; além disso, os emparelhamentos proporcionam ainda mais estruturas algébricas utilizáveis nas curvas elípticas.
Estas estruturas permitem-nos construir protocolos criptográficos eficientes.
Mas também levantam uma questão: como sabemos que já descobrimos todas as estruturas matemáticas existentes?
Poderão existir outras estruturas que ajudem os atacantes a encontrar algoritmos mais eficazes.
Em contrapartida, as funções hash seguras são concebidas para não expor, tanto quanto possível, estruturas algébricas que possam ser exploradas.
Deste ponto de vista, acredito que os esquemas criptográficos baseados em funções hash poderão ter maior robustez a longo prazo.
Além disso, as funções hash não conseguem, por si só, implementar todas as funcionalidades criptográficas.
Por exemplo, apenas com funções hash comuns não conseguimos obter diretamente capacidades de encriptação de chave pública ou de encriptação totalmente homomórfica. Por isso, outras técnicas criptográficas continuam a ser indispensáveis.
A minha preferência é a seguinte: sempre que for possível recorrer a esquemas hash bem estabelecidos, devemos fazê-lo; quando forem necessárias outras hipóteses matemáticas, devemos usar parâmetros mais conservadores.
Isto também está a influenciar a investigação do Ethereum sobre a infraestrutura criptográfica do futuro.
No domínio das assinaturas digitais, estamos a investigar esquemas baseados em hash, como o leanWOTS e o leanSPHINCS.
A ideia fundamental é usar cadeias de hash e estruturas de dados relacionadas para construir mecanismos de assinatura e verificação.
Tomemos como exemplo as assinaturas de uso único de Winternitz: o signatário pode gerar antecipadamente várias cadeias de hash.
Para as diferentes partes da mensagem, o signatário publica como assinatura os pontos correspondentes dessas cadeias de hash.
O verificador executa o número de operações hash especificado e verifica se o resultado corresponde à informação associada à chave pública.
Estes esquemas podem basear a segurança das assinaturas sobretudo nas funções hash.
No domínio das provas de conhecimento zero, também estamos a investigar os STARK, que se baseiam principalmente na hipótese de segurança das funções hash.
No entanto, esta abordagem tem um problema evidente de custos.
Em comparação com algumas assinaturas de curvas elípticas e provas baseadas em emparelhamentos existentes, as assinaturas baseadas em hash e os STARK são frequentemente maiores e podem exigir mais Gas quando verificados diretamente na cadeia.
Por isso, também precisamos de melhorar a agregação de assinaturas e provas.
Por exemplo, o EIP-8288 aborda um mecanismo de agregação recursiva de STARK ao nível do conjunto de transações e dos blocos.
Permitir agregar muitas assinaturas ou provas e confirmar a sua validade através do mecanismo de verificação correspondente ajuda a reduzir o custo de incluir e verificar diretamente grandes objetos criptográficos em cada transação.
Tudo isto faz parte da investigação e das propostas de melhoria do protocolo que estão em curso.
Além disso, há uma área muito interessante: a encriptação retardada (Delayed Encryption).
Depois de os utilizadores transmitirem uma transação à rede, mas antes de ela entrar efetivamente num bloco, o conteúdo pode ser observado e ordenado, e ficar sujeito a ataques de antecipação.
Um exemplo típico é o ataque Sandwich relacionado com MEV.
Uma possibilidade seria manter as transações encriptadas quando são transmitidas e só as desencriptar após algum tempo ou quando determinadas condições forem satisfeitas.
Se as transações puderem ser incluídas em segurança num bloco antes de os seus detalhes serem divulgados, será possível reduzir alguns ataques baseados na observação antecipada do seu conteúdo.
Também estamos a explorar a possibilidade de recorrer a mecanismos criptográficos relacionados com hashes para suportar este tipo de funcionalidade.
O objetivo desta investigação é permitir que o Ethereum continue a oferecer a segurança e as funcionalidades de que os utilizadores precisam, mesmo perante novos riscos de ataques matemáticos no futuro.
No entanto, os algoritmos criptográficos resolvem apenas o problema do primeiro nível.
Mesmo que utilizemos esquemas de assinatura e de prova mais fiáveis, o software que executa esses algoritmos pode continuar a ter vulnerabilidades.
Isto leva-nos ao segundo nível de risco: os clientes do Ethereum.
Os clientes do Ethereum são sistemas de software extremamente complexos.
Incluem a camada de execução, a camada de consenso, a rede ponto a ponto, bibliotecas criptográficas e uma grande quantidade de lógica de protocolo que tem de ser implementada corretamente.
À medida que as capacidades de análise de código da IA melhoram, os atacantes poderão encontrar vulnerabilidades com mais facilidade.
Mas é igualmente importante que os defensores também estejam a usar IA para encontrar e corrigir problemas.
Já estamos a experimentar usar IA para verificar a segurança do código dos clientes, e há equipas envolvidas em projetos de segurança de software de código aberto apoiados por IA.
Até agora, este trabalho identificou vários problemas de baixa prioridade ou de impacto relativamente limitado. Pelo que eu sabia na altura, o número de vulnerabilidades realmente graves e críticas era relativamente reduzido.
Outra vantagem do Ethereum é a sua arquitetura com vários clientes.
A rede funciona com clientes desenvolvidos e mantidos por equipas diferentes, o que reduz o risco de uma falha numa única implementação afetar todos os nós.
Se um cliente tiver um problema grave, os outros poderão continuar a funcionar normalmente.
O impacto concreto depende da proporção da rede afetada: a rede poderá continuar a produzir blocos ou poderá ficar temporariamente impossibilitada de alcançar a finalidade.
Em 2016, o Ethereum sofreu um ataque de negação de serviço contra os nós da rede.
Na altura, o comportamento dos diferentes clientes, como o Geth e o Parity, não foi exatamente igual. Quando um cliente foi atacado, outras implementações poderão ter continuado a funcionar.
Isto demonstra o valor prático da diversidade de clientes para a resiliência da rede.
A longo prazo, tenho uma grande confiança na verificação formal (Formal Verification).
O objetivo da verificação formal é provar, através de métodos matemáticos rigorosos, que uma implementação de software satisfaz as propriedades especificadas.
Em sistemas muito complexos, é praticamente impossível verificar manualmente todos os percursos de execução possíveis.
Mas, se conseguirmos associar o código a uma especificação formal clara e depois usar um sistema de provas para verificar a implementação, poderemos obter garantias de segurança mais fortes.
A IA também poderá desempenhar aqui um papel importante.
Podemos pedir à IA que ajude a escrever provas, a encontrar passos de demonstração ou a relacionar o código real com especificações formais.
A comunidade Ethereum já está a trabalhar em áreas relacionadas, como zkEVM, STARK recursivos e bibliotecas criptográficas.
Por exemplo, projetos como o ArkLib estão a usar ferramentas formais como o Lean para verificar estruturas matemáticas e protocolos relacionados com provas de conhecimento zero.
Espero que, no futuro, esta tecnologia seja utilizada em mais componentes críticos.
O nosso objetivo a longo prazo é, tanto quanto possível, sustentar as propriedades de segurança do software mais importante com provas matemáticas verificáveis por máquina.
No entanto, a segurança dos protocolos e dos clientes não abrange todo o ecossistema Ethereum.
Mesmo que a rede funcione perfeitamente, os utilizadores ainda podem perder ativos se houver problemas numa aplicação ou carteira.
Chegamos assim ao terceiro nível, o que afeta mais diretamente os utilizadores.
No desenvolvimento de contratos inteligentes, já temos linguagens de programação como Solidity e Vyper, bem como ferramentas cada vez mais maduras de auditoria, testes e verificação formal.
Estas ferramentas podem ajudar os programadores a encontrar problemas de segurança comuns.
Mas, atualmente, preocupa-me especialmente a segurança da implementação de sistemas de provas de conhecimento zero.
Cada vez mais aplicações começam a depender da tecnologia ZK.
Se o sistema de provas de que uma aplicação depende tiver uma falha grave, poderá aceitar provas inválidas, afetando assim a segurança dos ativos ou o estado do protocolo.
No futuro, a tecnologia ZK poderá tornar-se tão importante como as tecnologias de desenvolvimento de contratos inteligentes, como Solidity. No entanto, as ferramentas de segurança e as capacidades de verificação formal relacionadas ainda precisam de ser melhoradas.
Outro risco que merece atenção é a interface do utilizador.
Os utilizadores recorrem frequentemente a sites, interfaces de carteiras ou outras ferramentas de frontend para gerir os seus ativos na cadeia.
Mesmo que os contratos subjacentes não tenham vulnerabilidades, a interface apresentada aos utilizadores ainda pode ser adulterada por atacantes.
Os ataques relacionados com a Safe ocorridos anteriormente demonstraram os riscos presentes na interface e no processo de assinatura de transações.
Recentemente, também tenho tentado reduzir a minha dependência de interfaces web de terceiros.
Por exemplo, uso IA executada localmente para me ajudar a criar algumas ferramentas de linha de comandos (CLI), realizando operações de forma mais direta e passível de verificação independente.
Isto pode reduzir a dependência de interfaces complexas de terceiros, mas os scripts gerados automaticamente também têm de ser cuidadosamente verificados.
A seguir, gostaria de falar das próprias carteiras.
Para a maior parte dos ativos digitais importantes, continuo a recomendar vivamente a utilização de carteiras multisig (Multisig Wallet).
Por exemplo, pode configurar-se uma carteira multisig 2-de-3.
Há três chaves privadas ao todo e são necessárias duas assinaturas para executar cada transação.
As três chaves privadas podem ser guardadas em três locais diferentes: uma num computador, outra num telemóvel e a terceira a cargo de uma pessoa de confiança ou de um dispositivo independente.
Assim, mesmo que um atacante obtenha uma das chaves privadas, não poderá efetuar uma transferência por si só.
Se uma das chaves privadas estiver temporariamente indisponível, ainda será possível autorizar a operação com as outras duas.
O mais importante é não guardar várias chaves privadas de uma carteira multisig no mesmo dispositivo ou no mesmo ambiente de segurança.
Se todas as chaves privadas estiverem guardadas no mesmo computador, um ataque a esse computador reduzirá drasticamente a proteção oferecida pelo mecanismo multisig.
Para além da gestão das chaves, também temos de considerar a segurança dos próprios dispositivos de hardware.
Recentemente, surgiram alguns casos preocupantes de ataques a carteiras de hardware.
Por exemplo, atacantes adulteraram carteiras de hardware na cadeia de abastecimento e instalaram componentes de comunicação adicionais nos dispositivos.
Quando os utilizadores usam um dispositivo adulterado para gerar ou restaurar chaves privadas, esses componentes podem enviar informações sensíveis aos atacantes.
Isto demonstra que a segurança das carteiras de hardware não depende apenas do software da carteira e do design do chip, mas também da integridade dos dispositivos durante o fabrico, o transporte e a venda.
Outro risco está relacionado com as informações dos utilizadores.
Se forem divulgados os dados dos clientes, os registos de compras ou os endereços de entrega de uma empresa de carteiras de hardware, os atacantes poderão descobrir quem comprou dispositivos especificamente concebidos para guardar ativos digitais.
Isso poderá tornar esses utilizadores alvos mais evidentes.
Por isso, tenho uma atitude cautelosa em relação a modelos de segurança que dependem de um único dispositivo dedicado de carteira de hardware.
A curto prazo, acredito que vale a pena considerar a utilização de um telemóvel dedicado a operações seguras.
Por exemplo, escolher um telemóvel Google Pixel compatível, instalar um sistema operativo com maior foco na segurança, como o GrapheneOS, e depois usar uma ferramenta de assinatura offline como o AirGap Vault.
Depois de preparar o dispositivo, pode mantê-lo offline e usá-lo como ambiente dedicado à assinatura.
A transação pode ser criada num dispositivo ligado à Internet e depois transmitida ao dispositivo offline, por exemplo através de um código QR, para ser assinada.
Assim, o dispositivo que guarda as chaves não precisa de estar diretamente ligado à Internet.
A longo prazo, continuaremos a precisar de melhores tecnologias de segurança de hardware.
Acredito que, no futuro, poderemos alargar o conceito de carteira de hardware a dispositivos de computação segura mais versáteis.
Estes dispositivos não seriam usados apenas para armazenar criptoativos, mas também para autenticação de identidade, serviços bancários, serviços governamentais e outras aplicações que exigem um elevado nível de segurança.
Se um tipo de hardware seguro for amplamente utilizado para diferentes fins, mesmo que terceiros saibam que um utilizador comprou um destes dispositivos, será difícil perceber diretamente se ele possui muitos ativos digitais.
Ao mesmo tempo, uma procura mais ampla por aplicações também pode impulsionar melhorias contínuas no hardware seguro, nos sistemas operativos e nos mecanismos de verificação.
Por isso, temos de continuar a investigar mecanismos fiáveis de verificação de hardware, sistemas operativos mais seguros e dispositivos capazes de suportar diversas aplicações seguras.
Por fim, continuo otimista em relação ao futuro da cibersegurança a longo prazo.
A IA pode ajudar a descobrir vulnerabilidades, mas também pode ajudar os programadores a implementar técnicas criptográficas mais complexas e até melhorar a fiabilidade do software através da verificação formal.
Nos próximos cinco anos, poderemos ter software, sistemas operativos e hardware mais seguros, bem como uma compreensão mais clara de quais os algoritmos criptográficos que resistem verdadeiramente ao teste do tempo.
Mas, antes de chegarmos a essa fase, teremos de atravessar um período de transição muito complexo.
Os riscos poderão surgir nas hipóteses criptográficas, mas também nos clientes, nos contratos inteligentes, nas interfaces dos utilizadores e nas carteiras.
Precisamos de compreender cuidadosamente os riscos de cada nível e adotar as medidas de segurança adequadas.
Ao mesmo tempo, não devemos entrar em pânico perante novos riscos nem transferir precipitadamente os nossos ativos para carteiras ou ferramentas desconhecidas só por ouvirmos dizer que um determinado esquema criptográfico poderá não ser seguro.
As próprias operações também podem criar riscos de segurança.
Eu próprio já perdi mais ativos por cometer um erro ao migrar uma carteira do que por sofrer um ataque informático.
Lembrem-se: o mais importante não é se o vosso APY é de 3,5% ou de 4,3%, mas sim garantir que não se transforma em -100%.
Proteger os ativos é sempre mais importante do que procurar alguns pontos percentuais de rendimento.
Obrigado a todos.