Ataques de Replay e EIP-155: Segurança de Transações em Redes EVM e Hard Forks

A Ilusão Entre Redes: Quando uma Assinatura Vale Duas Vezes

No ecossistema de ativos digitais, as assinaturas criptográficas são sinónimo de certeza absoluta. Quando o teu administrador financeiro assina uma transferência de 100.000 € através de uma carteira de hardware, o algoritmo matemático prova à rede que a tua empresa aprovou expressamente aquele movimento.

No entanto, há uma armadilha estrutural grave sempre que duas redes diferentes partilham o mesmo histórico de contas, as mesmas moradas e as mesmas regras matemáticas: o Ataque de Replay (Repetição de Transações).

Imagina o que aconteceria na tua empresa: a tua tesouraria tem saldos na rede principal Ethereum. No seguimento de uma cisão da rede (um hard fork) ou do lançamento de uma nova rede compatível, a tua conta passa a existir de forma idêntica nessa cadeia secundária, com o mesmo saldo e o mesmo número sequencial de transação (nonce). Fazes um pagamento legítimo de 100.000 € a um fornecedor na rede principal. Um hacker que esteja a vigiar o tráfego da rede copia o código da transação e reenvia-o exatamente igual para a rede bifurcada.

Como a tua assinatura digital é autêntica e válida, a rede secundária aceita a operação e transfere outros 100.000 € dos teus fundos para o endereço de destino—sem que ninguém na tua empresa tenha tocado numa tecla.

ANATOMIA DE UM ATAQUE DE REPLAY ENTRE REDES BIFURCADAS

• A TUA EMPRESA ASSINA UMA TRANSAÇÃO LEGÍTIMA: Ordem: “Pagar 1.000 Tokens da Tesouraria ao Fornecedor X”
• TRANSAÇÃO PROCESSADA NA REDE ETHEREUM ORIGINAL (REDE A):
• A rede valida a assinatura digital
• O fornecedor recebe os 1.000 Tokens com sucesso
• UM ATACANTE COPIA OS BYTES DA TRANSAÇÃO NO AR
• A MESMA TRANSAÇÃO É REPETIDA NA REDE SECUNDÁRIA (REDE B):
• A Rede B tem as mesmas carteiras, saldos e histórico!
• A assinatura matemática é considerada 100% autêntica!
• A Rede B transfere mais 1.000 Tokens sem a tua autorização!
• RESULTADO: Pagamento duplicado e prejuízo direto para a empresa!

Na WebXtek e nas revisões de código de tesouraria que desenvolvemos com a Luso Digital Assets, garantimos que todos os fluxos de pagamento da tua empresa estão vinculados a identificadores de rede únicos, eliminando este risco.

O Precedente Histórico: O Caso Ethereum Classic e The DAO

Para compreenderes como este problema foi resolvido, tens de recordar o momento marcante de 2016: o hard fork do Ethereum na sequência do ataque ao projeto The DAO.

Quando a comunidade decidiu bifurcar a cadeia para devolver os fundos aos lesados, nasceram duas redes paralelas: o Ethereum (ETH) e o Ethereum Classic (ETC). No bloco exato da divisão, cada carteira no Ethereum passou a ter uma cópia perfeita no Ethereum Classic, com a mesma chave e exatamente o mesmo número de transação (nonce).

No desenho original do protocolo, uma transação era composta por apenas seis variáveis:

$$\text{Tx} = [\text{nonce}, \text{gasPrice}, \text{gasLimit}, \text{to}, \text{value}, \text{data}]$$

Repara na ausência fatal: não existia nenhum campo a indicar a que rede aquela ordem pertencia.

Grandes corretoras mundiais começaram a processar levantamentos normais de clientes na rede nova (ETH). Minutos depois, utilizadores maliciosos pegavam no código desse levantamento e publicavam-no na rede antiga (ETC). As corretoras acabaram a pagar duas vezes pelo mesmo pedido, sofrendo perdas de milhões de euros decorrentes de ataques de repetição pura.

A Solução Técnica: EIP-155 e a Introdução do ChainID

Para erradicar definitivamente este perigo, a comunidade de desenvolvimento aprovou a proposta EIP-155 (Simple Replay Protection).

A inovação foi simples e genial: introduzir um número identificador exclusivo para cada rede, o chamado ChainID (por exemplo, 1 para a rede Ethereum, 61 para o Ethereum Classic, 137 para a Polygon, 8453 para a Base).

COMO A EIP-155 PRENDE A ASSINATURA A UMA SÓ REDE

• DADOS DA TRANSAÇÃO ANTES DE SEREM ASSINADOS (NORMA EIP-155): [nonce, gasPrice, gasLimit, to, value, data, CHAIN_ID, 0, 0]
• CÁLCULO DA ASSINATURA ECDSA: PAR (r, s, v)
• FÓRMULA MATEMÁTICA PARA CALCULAR O PARÂMETRO v: v = {0, 1} + (CHAIN_ID * 2) + 35
• EXEMPLO NA REDE ETHEREUM PRINCIPAL (CHAIN_ID = 1): v = 0 + (1 * 2) + 35 = 37 (ou 38)
• EXEMPLO NA REDE ETHEREUM CLASSIC (CHAIN_ID = 61): v = 0 + (61 * 2) + 35 = 157 (ou 158)
• O QUE ACONTECE QUANDO ALGUÉM TENTA REPETIR A TRANSAÇÃO?
• Se o atacante reenviar uma transação com v=37 na rede Classic:
• Os validadores calculam a chave pública usando o ChainID 61
• A matemática não bate certo e a assinatura dá erro!
• A TRANSAÇÃO É REJEITADA IMEDIATAMENTE PELOS NÓS DA REDE!

Como o ChainID passa a fazer parte dos dados antes do cálculo do hash da assinatura, o parâmetro matemático v fica intimamente ligado àquela rede específica. Se alguém tentar repetir a ordem noutra blockchain, a verificação da assinatura falha e a rede rejeita o bloco de imediato, tal como documentado nas especificações técnicas em Ethereum.org.

O Perigo Moderno: Mensagens EIP-712 e Autorizações Off-Chain

Apesar de as transações nativas estarem blindadas pela EIP-155, hoje em dia as finanças descentralizadas utilizam muitas autorizações assinadas fora da cadeia (mensagens sem gás e licenças de movimentação de tokens como o padrão EIP-2612 Permit).

Se a tua empresa assinar uma autorização digital e o contrato inteligente não tiver sido bem programado, o ataque de replay pode voltar a acontecer!

Para resolver isto, deves garantir que todos os contratos utilizam o padrão EIP-712, que exige a definição de um separador de domínio criptográfico:

bytes32 SEPARADOR_DOMINIO = keccak256(
    abi.encode(
        keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
        keccak256(bytes("CofreTesourariaEmpresa")),
        keccak256(bytes("1")),
        block.chainid,        // Vincula a assinatura à rede atual!
        address(this)         // Vincula a assinatura a este contrato exato!
    )
);

Se o programador se esquecer de incluir o block.chainid ou o endereço do contrato (address(this)), uma assinatura feita na rede de testes ou numa rede secundária de baixas taxas pode ser copiada e executada na rede principal, esvaziando as permissões da tua empresa. A Autoridade Europeia dos Valores Mobiliários e dos Mercados (ESMA) recomenda atenção acrescida a este tipo de autorizações em auditorias de conformidade.

Como Blindares as Operações da Tua Empresa Contra Ataques de Replay

Para que a tua organização transacione com total tranquilidade em ambientes multi-rede:

1. Exige Bibliotecas com Suporte EIP-155: Garante que todos os softwares, scripts de automatização e sistemas ERP utilizam bibliotecas modernas que incluem o ChainID em cada envio.
2. Audita Mensagens EIP-712: Nos smart contracts desenvolvidos para a tua empresa, certifica-te através da nossa arquitetura web3 blockchain de que todos os separadores de domínio incluem o identificador da rede e o endereço do contrato.
3. Cuidado com Hard Forks Inesperados: Se uma rede onde tens ativos sofrer uma cisão polémica, suspende os pagamentos automáticos durante as primeiras 24 horas até confirmares que as duas cadeias têm identificadores diferentes.
4. Separa os Cofres em Redes Diferentes: Não uses a mesma chave ou morada para gerir operações críticas em redes Layer 1 e Layer 2; utiliza carteiras distintas configuradas através da nossa plataforma segura.
5. Agenda Revisões de Segurança Periódicas: Recorre à nossa consultoria técnica para testares as tuas rotinas de assinatura e impedires surpresas desagradáveis entre redes.

Com estas precauções técnicas, a tua empresa assegura que cada aprovação de fundos tem efeito exclusivamente onde e quando a administração assim o determinou.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como plataformas de corretagem cripto e web3 e wallets web3 e gateways de pagamento. Quando alinhas a tua estrutura através de desenvolvimento web3 & blockchain e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.