Rotação de chave efêmera nativa por meio de transações de quadros – criptografia

Obrigado a @mvicari por suas contribuições e a @asanso por seu feedback

Resumo

Esta é uma continuação do nosso post anterior Alcançando segurança quântica por meio de pares de chaves efêmeras e abstração de contas.

Propomos a integração da rotação de chaves efêmeras diretamente no formato de transação de quadro (EIP-8141), sem a necessidade de uma camada separada de abstração de conta. Ao adicionar um contrato de registro singleton, a autoridade de assinatura pode ser dissociada da identidade on-chain no nível do protocolo, e o empacotamento nativo das Transações de Quadro nos permite adicionar um quadro para rotacionar o assinante para cada transação, permitindo chaves ECDSA descartáveis ​​com sobrecarga mínima e uniformidade máxima, tornando a rotação de chaves disponível uniformemente para todos os remetentes.

Motivação

O EIP-8141 introduz transações de quadro, que desacoplam a lógica de validação do remetente da transação, abrindo a porta para esquemas de assinatura arbitrários. Independentemente, em nosso trabalho anterior, mostramos que a rotação de chaves após cada transação, implementada na camada AA, neutraliza efetivamente a ameaça quântica ao ECDSA, tornando todas as chaves expostas imediatamente inúteis.

As transações frame já fornecem um local natural para essa lógica de rotação: em vez de implementar a rotação de chaves dentro de cada carteira de contrato inteligente de forma independente, podemos incorporá-la no próprio formato da transação, tornando-a disponível uniformemente para todos os remetentes.

Projeto

A proposta requer dois componentes para funcionar:

1. Um contrato de registro de assinante

Um contrato singleton implantado em um endereço conhecido mantém um mapeamento do endereço da conta até seu assinante autorizado atual:

mapping(address account => address signer) public signerOf;

Construímos um exemplo de implementação deste contrato de registro em nosso repositório git.

No futuro, planejamos atualizar este contrato para conter também o código necessário para lidar com todo o processo VERIFY de transações de quadros usando assinaturas ECDSA.

2. Um quadro adicional na transação de quadros

Para conseguir a rotação é necessário adicionar um quadro que vise o contrato singleton, mudando o signatário autorizado para o próximo signatário. O empacotamento é nativo em transações de quadro, portanto, esse quadro pode ser adicionado a qualquer transação sem exigir alterações de protocolo.

Fluxo de validação

No quadro VERIFY, o signatário atual do tx.sender é pesquisado no registro. A assinatura da transação é verificada contra aquele signatário (em vez de contra tx.sender diretamente).

• Se signerOf(sender) == address(0)a assinatura do usuário é verificada em relação tx.sender diretamente, preservando o comportamento semelhante ao EOA como padrão.
• Se a validação for aprovada, a entrada do registro para tx.sender é atualizado para nextSignercompletando a rotação:

signerOf(tx.sender) = nextSigner;

Esta última etapa é feita em um quadro adicional, pois o quadro de validação não pode fazer alterações de estado.

Essa rotação deve ocorrer mesmo que outros quadros de execução sejam revertidos, espelhando a mesma invariante identificada na abordagem baseada em AA: uma transação com falha não deve deixar o assinante atual exposto sem girá-lo.

Alternar rotação

Se nenhum quadro de rotação for incluído na transação, nenhuma rotação de signatário ocorrerá, tornando o recurso de rotação de chave completamente opcional. O usuário pode decidir ligá-lo e desligá-lo em qualquer conta Ethereum simplesmente adicionando o quadro apropriado a uma transação.

Propriedades

• Assinatura dissociada da identidade onchain: o endereço da conta nunca muda; apenas o signatário autorizado faz a rotação.
• Mitigação quântica: cada chave privada é usada exatamente uma vez; mesmo que posteriormente recuperado por um computador quântico, não poderá autorizar transações futuras.
• Ativar por padrão: contas que nunca gravam no registro (ou definem nextSigner = 0 permanentemente) experimentam comportamento padrão sem sobrecarga.
• Não é necessária lógica por carteira: a dissociação remetente-signatário é tratada na camada de validação da transação, não dentro de cada contrato, eliminando a necessidade de implementações personalizadas de carteira inteligente.
• Compatibilidade BIP44: o nextSigner O endereço pode ser derivado de um caminho BIP44, tornando o esquema compatível com a infraestrutura de carteira HD existente.

Comparação com rotação baseada em AA

A abordagem baseada em AA do nosso post anterior implementa essa mesma rotação dentro da carteira de contrato inteligente validateUserOpmostrando que esta abordagem é viável hoje e demonstrada em ~136k gás para uma transferência ERC20. Esta abordagem de transação de quadros difere porque:

• A rotação é um recurso de protocolo de primeira classe, não uma convenção por carteira.
• Todos os remetentes de transações de quadros se beneficiam sem a necessidade de implantar ou atualizar uma carteira inteligente.