DREX e criptografia pós-quântica: o real digital está preparado?

Resumo: O DREX, real digital brasileiro, usa Hyperledger Besu que depende de ECDSA/secp256k1 para assinaturas — a mesma criptografia vulnerável a computadores quânticos que protege Bitcoin e Ethereum. O BACEN não públicou planos de migração para PQC, diferente do BCE que pesquisa ativamente. A janela para construir o DREX quantum-safe desde o lancamento e agora.

O real está se tornando digital — mas está seguro?

O DREX e o projeto mais ambicioso do Banco Central do Brasil desde o Plano Real. Pela primeira vez, o real tera uma versão nativa digital, programavel, capaz de interagir com smart contracts e ativos tokenizados. E uma revolução no sistema financeiro brasileiro.

Mas toda revolução tecnológica carrega riscos. E o risco que poucos estão discutindo sobre o DREX e criptografico: a plataforma que sustenta o real digital usa a mesma familia de algoritmos que computadores quânticos prometem quebrar na proxima decada.

Este artigo analisa a arquitetura criptografica do DREX, compara com iniciativas internacionais, e avalia o que o Brasil precisa fazer para garantir que sua moeda digital nasca preparada para o futuro.

A arquitetura do DREX: Hyperledger Besu

O que e Hyperledger Besu

O BACEN escolheu o Hyperledger Besu como base tecnológica para o DREX. Besu e um cliente Ethereum enterprise — ou seja, uma implementacao da Ethereum Virtual Machine (EVM) voltada para redes permissionadas (onde apenas participantes autorizados operam nos).

Por que Besu foi escolhido

As razoes são solidas:

• Compatibilidade EVM: Permite que smart contracts Ethereum rodem no DREX
• Permissionamento: O BACEN controla quem participa da rede (bancos, instituições financeiras)
• Privacidade: Suporta transações privadas entre participantes específicos
• Maturidade: Usado por diversas instituições financeiras globalmente
• Open source: Auditavel e sem vendor lock-in

O problema: a criptografia de Besu

Hyperledger Besu, sendo um cliente Ethereum, herda a stack criptografica do Ethereum:

Funcao	Algoritmo	Vulnerabilidade quântica
Assinatura de transações	ECDSA/secp256k1	Alta (Shor)
Identidade de nos	ECDSA/secp256k1	Alta (Shor)
Hashing	Keccak-256	Parcial (Grover reduz para 128-bit)
Derivacao de endereco	Keccak-256	Parcial
Consenso (IBFT 2.0)	ECDSA para votes	Alta (Shor)

O ponto crítico: Cada transação no DREX — cada transferencia de real digital, cada liquidação, cada smart contract — será assinada com ECDSA/secp256k1. E este e exatamente o algoritmo que o algoritmo de Shor pode quebrar.

O que "quebrar ECDSA" significa para o DREX

Vamos ser concretos. Se um computador quântico quebrar secp256k1, um atacante poderia:

1. Forjar transações

Derivar a chave privada de qualquer participante da rede (banco, instituição financeira) e assinar transações como se fosse esse participante. Transferir bilhoes de reais digitais para contas controladas pelo atacante.

2. Comprometer o consenso

Os validadores do DREX (bancos autorizados pelo BACEN) assinam votos de consenso com ECDSA. Se um atacante forjar as chaves de validadores suficientes, pode controlar o consenso — aprovando transações fraudulentas ou bloqueando transações legitimas.

3. Roubar identidades institucionais

No Besu permissionado, a identidade de cada no e um par de chaves ECDSA. Forjar a identidade de um no significa se passar por um banco na rede do DREX — com todas as permissoes e acessos que isso implica.

4. Quebrar privacidade retroativamente

Transacoes privadas do Besu usam criptografia para ocultar detalhes entre participantes não envolvidos. Se essa criptografia for baseada em primitivos vulneraveis, todas as transações historicas ficam expostas — incluindo volumes, contrapartes e valores.

O que o BACEN tem dito sobre PQC

Silencio preocupante

Até o momento, o Banco Central do Brasil não públicou documentos, pesquisas ou planos formais sobre migração do DREX para criptografia pós-quântica. Os documentos técnicos do projeto DREX (pilotos fase 1 e fase 2) não mencionam a ameaça quântica.

Isso não significa necessáriamente que o BACEN não está ciente — pode estar em fase de avaliacao interna. Mas a ausencia de comúnicação pública contrasta fortemente com outras instituições.

O que o BACEN poderia argumentar

Ha argumentos legitimos para não priorizar PQC agora:

1. "Computadores quânticos estão longe": Argumento razoavel se o DREX fosse temporario. Mas uma moeda digital nacional deve funcionar por decadas.

2. "Podemos migrar depois": Possivel, mas migrar uma CBDC em produção, com milhoes de usuarios e trilhoes em transações, e exponencialmente mais complexo que construir com PQC desde o início.

3. "Besu pode ser atualizado": Tecnicamente sim, mas requer que Hyperledger Foundation implemente PQC no Besu, que todos os participantes atualizem, e que smart contracts existentes sejam compatíveis — um processo de anos.

Comparacao internacional: quem está se preparando

Banco Central Europeu (BCE) — Euro digital

O BCE tem sido significativamente mais vocal sobre a ameaça quântica ao euro digital:

• Publicou research papers sobre PQC para CBDCs
• Incluiu "quantum resistance" como requisito técnico em documentos de design
• Avalia implementacao hibrida (classico + PQC) desde o início
• Trabalha com ENISA (agencia de cybersecurity da UE) em padroes de migração

Bank of England — Libra digital

O Bank of England mencionou explicitamente a necessidade de "crypto-agility" em seu projeto de CBDC — a capacidade de trocar algoritmos criptograficos sem redesenhar o sistema inteiro. Isso indica consciência da ameaça e planejamento para migração.

People's Bank of China (PBoC) — Yuan digital

A China, que ja lancou o e-CNY (yuan digital) em escala piloto, investiu pesadamente em computação quântica (Zuchongzhi, Jiuzhang). Existe uma tensão interessante: a China está avancada em computação quântica E em CBDC. E provavel que o PBoC esteja avaliando PQC internamente, embora não publique detalhes.

Tabela comparativa

Banco Central	CBDC	Status PQC	Comúnicacao pública
BACEN (Brasil)	DREX	Nenhum plano públicado	Silencio
BCE (Europa)	Euro digital	Pesquisa ativa, requisito de design	Papers públicados
Bank of England	Libra digital	Crypto-agility como principio	Mencionado em documentos
PBoC (China)	e-CNY	Provavel avaliacao interna	Não públicado
Fed (EUA)	FedNow (não CBDC)	CNSA 2.0 manda PQC até 2030	Mandato formal

O que o BACEN deveria fazer

Opcao 1: Implementar PQC hibrido desde o lancamento

A opcao ideal. Manter ECDSA (para compatibilidade) e adicionar ML-DSA como camada adicional. Cada transação teria duas assinaturas: uma classica e uma pós-quântica.

Vantagens: Segurança maxima, sem janela de vulnerabilidade, demonstra lideranca técnica.

Desafios: Requer modificacao do Besu, aumento de tamanho de transações, treinamento de participantes.

Custo estimado: Adicional de 6-12 meses de desenvolvimento sobre o cronograma atual.

Opcao 2: Construir com crypto-agility

Se PQC hibrido não for viavel no lancamento, ao menos construir a arquitetura de forma que a troca de algoritmos seja possível sem redesenho:

• Abstrair a camada criptografica (não hardcode ECDSA)
• Definir pontos de extensão para novos algoritmos
• Testar ML-DSA em ambiente paralelo
• Publicar roadmap de migração com datas

Vantagens: Prazo de lancamento mantido, migração fácilitada no futuro.

Desafios: Não protege contra HNDL até a migração ser completada.

Opcao 3: Status quo (risco)

Lancar com ECDSA puro e "migrar quando necessário."

Vantagens: Nenhuma complexidade adicional, lancamento mais rápido.

Riscos: Migracao em produção e 10-100x mais complexa. Se Q-Day chegar antes da migração, o real digital fica comprometido. HNDL expoe todas as transações desde o lancamento.

Implicacoes para ativos tokenizados que interagem com DREX

O DREX não existira isolado. Sua grande promessa e a interoperabilidade com ativos tokenizados: titulos públicos, debentures, imoveis, commodities — todos interagindo em um ecossistema DeFi regulado.

O problema de interoperabilidade

Se o DREX usa ECDSA e um ativo tokenizado usa ML-DSA (como o ouro.capital), a interacao entre eles cria um ponto de vulnerabilidade: a transação no lado DREX permanece protegida apenas por ECDSA.

Exemplo prático:

1. Investidor quer comprar tokens ouro.capital usando DREX
2. No lado ouro.capital: transferencia protegida por ML-DSA (quantum-safe)
3. No lado DREX: pagamento protegido por ECDSA (vulnerável)
4. A cadeia de segurança e tao forte quanto seu elo mais fraco

O que plataformas quantum-safe podem fazer

Até que o DREX adote PQC, plataformas como o ouro.capital podem:

• Minimizar exposicao ao DREX (transação rápida, não armazenamento)
• Registrar provas ML-DSA do lado do token antes da interacao DREX
• Manter registros off-chain com assinaturas quantum-safe de cada operação
• Oferecer canais alternativos de pagamento com PQC end-to-end

O custo de corrigir depois vs construir certo agora

A história da tecnologia financeira mostra repetidamente que corrigir depois custa ordens de magnitude mais que construir certo:

Exemplo histórico	Custo de correcao vs prevenção
Bug Y2K (1999)	US$ 300 bilhoes para corrigir vs fracoes para prevenir
Migracao SWIFT ISO 20022	10+ anos, bilhoes em custos para o setor
PCI DSS compliance	Trilhoes acumulados vs design seguro desde início

A migração criptografica do DREX, se deixada para depois, enfrentara:

• Milhoes de carteiras para migrar
• Trilhoes em transações historicas para re-proteger
• Centenas de smart contracts para atualizar
• Anos de coexistencia com dois sistemas
• Risco de vulnerabilidade durante a transicao

O paralelo com o proprio real

Ha um paralelo histórico interessante. Quando o Brasil criou o Real em 1994, tomou decisões técnicas que pareciam "excessivas" na epoca — como a URV (Unidade Real de Valor) como mecanismo de transicao. Muitos consideraram desnecessáriamente complexo. Mas foi exatamente essa engenharia cuidadosa que permitiu ao Plano Real funcionar onde outros falharam.

O DREX está em momento similar: decisões técnicas tomadas agora — incluindo a escolha criptografica — definirão se o real digital será resiliente por decadas ou se precisara de uma "migração de emergencia" custosa e arriscada no futuro.

O que investidores devem observar

Se você e investidor e pretende operar no ecossistema DREX (e eventualmente todo investidor brasileiro operara), observe:

1. Pronunciamentos do BACEN sobre PQC: Qualquer menção a "quantum", "pos-quântico", "crypto-agility" ou "ML-DSA" em documentos oficiais do DREX
2. Atualizacoes do Hyperledger Besu: Se a Hyperledger Foundation incorporar PQC no Besu, o DREX herdaria o benefício
3. Regulamentacao CVM: Se a CVM 88 ou normas subsequentes exigirem PQC para tokens regulados
4. Prazo de lancamento vs segurança: Se o BACEN acelerar o lancamento sem enderecor PQC, o risco permanece para toda a vida útil do sistema

Conclusao: a janela está aberta — mas não por muito tempo

O DREX e inevitavel. O real digital transformara o sistema financeiro brasileiro. A questão não e se, mas como.

Se o BACEN incorporar criptografia pós-quântica no design do DREX antes do lancamento — mesmo que de forma hibrida — o Brasil tera uma das CBDCs mais seguras do mundo. Se deixar para depois, teremos uma moeda digital nacional com a mesma vulnerabilidade quântica do Bitcoin.

Para o investidor, a implicacao e clara: enquanto o DREX não for quantum-safe, manter reserva de valor em plataformas que JA são quantum-safe — como tokens de ouro protegidos por ML-DSA com custódia física em Zurique — e uma decisão de gestão de risco racional.

O ouro protege patrimônio ha 5.000 anos. A criptografia pós-quântica protege para os proximos 50. Juntos, oferecem algo que o DREX ainda não pode: segurança verificavel contra a ameaça quântica.