Introdução

2024 provavelmente será lembrado como um dos anos que marcam a aceleração da ameaça dos computadores quânticos. O Google, sob a liderança do CEO Sundar Pichai, finalmente revelou seu chip quântico, Willow, através de um tweet alto!

Scott Aaronson, um dos especialistas em quântica mais famosos do mundo, mudou sua mensagem para as pessoas que perguntam se devem se preocupar com os computadores quânticos. Ele mudou de dizer

… Talvez, eventualmente, alguém precise começar a pensar em migrar da criptografia RSA, Diffie-Hellman e curva elíptica para criptografia baseada em rede ou outros sistemas que possam suportar plausivelmente ataques quânticos,...

para

Sim, sem dúvida, preocupe-se com isso agora. Tenha um plano.

Vitalik já escreveu sobre como fazer um hard-fork para salvar a maioria dos fundos dos usuários em uma emergência quântica. Além disso, alguns dias atrás, ele destacou em um podcastos quatro principais componentes Ethereum potencialmente vulneráveis a ataques quânticos. Eles são:

1. Assinaturas de transação Ethereum (notadamente usando ECDSA)
2. Assinaturas BLS em consenso
3. Amostragem de disponibilidade de dados (alavancando compromissos KZG)
4. Árvores Verkle (se enviado com Bandersnatch)

Um leitor atento pode ter notado que esses quatro pontos têm algo em comum - sim, são minhas amadas curvas elípticas. Infelizmente, o problema do logaritmo discreto para curvas elípticas (ECDLP) é quebrado pelo Algoritmo de Shor, um famoso algoritmo quântico.

Nesta breve nota, vamos analisar uma possível substituição pós-quântica para o primeiro ponto, nomeadamente uma potencial assinatura de transação Ethereum pós-quântica.

Que assinatura PQ?

Agora, uma pergunta legítima é: quais assinaturas pós-quânticas (PQ) devemos usar? Felizmente, não precisamos pensar demais nisso, se tivéssemos que escolher agora. Zhenfei Zhang, um ex-criptógrafo da Ethereum Foundation, já escreveu sobre oProcesso de Padronização de Criptografia Pós-Quântica do NIST 26. Se analisarmos as três possíveis opções de assinatura (duas das quais utilizam criptografia baseada em reticulado), fica claro (pelo menos por agora) que o Falcon parece ser o candidato mais promissor. O cálculo para o verificador deve ser aproximadamente o mesmo que outros esquemas de assinatura baseados em reticulados (como o Dilithium), ou seja, limitado por uma FFT. No entanto, Falcontem de facto um tamanho de assinatura menor.

Enviar!!!

Agora que 'decidimos' a assinatura a usar, a próxima questão é: como a vamos enviar? Agora existe uma grande dicotomia: uma implica um hard fork e a outra não. Vamos aprofundar um pouco mais.

O caminho da Abstração de Conta

A primeira abordagem que discutiremos, talvez a mais elegante e promissora, envolve a Abstração de Conta (AA). Ela tem sido defendida por Justin Drake e Vitalik em várias ocasiões.

Para pessoas não familiarizadas com isso, AA é uma melhoria proposta para tornar o ecossistema Ethereum mais flexível e fácil de usar, alterando como transações e contas são gerenciadas. Ele desloca certas funcionalidades tradicionalmente reservadas para contas de propriedade externa (EOAs) para contratos inteligentes, efetivamente 'abstraindo' as diferenças entre EOAs e contas de contrato inteligente.

Os desenvolvedores do Ethereum têm apresentado várias propostas para implementar AA, incluindo ERC-4337. Esta é uma solução prática que alcança AA sem exigir uma atualização da camada de consenso. Utiliza um mecanismo chamado objetos de Operação do Utilizador e introduz uma camada de Aglutinador separada para lidar com transações.

Adicionar o Falcon como a assinatura de transação Ethereum neste cenário significa codificar um contrato verificador Falcon que é responsável por verificar a validade dos objetos de Operação do Usuário antes que sejam executados pelo contrato de Ponto de Entrada.

Agora, isso pode soar como tudo são rosas e arco-íris, mas há pelo menos um problema subjacente substancial. Codificar Falcon em Solidity pode não ser a melhor experiência (e provavelmente é bastante caro em termos de gás). Além disso, existem problemas ainda mais desagradáveis, como o fato de que o Falcon lida com números de 13 bits, enquanto o Solidity suporta apenas U256. Este último é o tipo de problema que poderia ser resolvido adicionandoSIMDeEVMMAXpara o EVM.

• Prós: É uma solução elegante e flexível.
• Contras: É dispendioso em termos de consumo de gás.

O caminho da divisão

O método que discutimos aqui é provavelmente o mais simples tecnicamente. Inspira-se em trabalhos anteriores realizados por Marius Van Der Wijden e envolve essencialmente a introdução de um novo tipo de transaçãoassinado com assinaturas de Falcãoem vez de assinaturas BLS. O maior problema aqui é que, ao fazê-lo, estamos fortemente ligados (por meio de um novo EIP) a um esquema de assinatura mestre favorecido.

Portanto, para recapitular essa abordagem

• Pros: Fácil de programar e rápido.
• Contras: Não é à prova de futuro.

Híbrido

Uma abordagem realmente tentadora seria pegar o melhor dos dois métodos acima e combiná-los em um único. Em suma, poderíamos alavancar AA de forma semelhante a RIP-7212faz, mas é claro que precisaríamos de um novo RIP para Falcon. Isso pode fornecer o tempo para experimentar o recurso em rollups e determinar se Falcon é realmente o caminho a seguir. No entanto, é importante observar que essa abordagem não resolve o problema original de introduzir um novo esquema de assinatura no nível L1.

• Prós: Fácil de programar e rápido.
• Contras: Temporário (não resolve o caso de uso L1).

Conclusão

O surgimento da computação quântica exige ação urgente para garantir o Ethereum, especialmente suas assinaturas de transação vulneráveis ao Algoritmo de Shor. Falcon, um esquema de assinatura baseado em retícula, surge como um forte candidato devido à sua eficiência e tamanho compacto. Estratégias de implantação, incluindo Abstração de Conta, forks rígidos ou uma abordagem híbrida, cada uma oferece benefícios e compensações distintos. Uma avaliação cuidadosa é essencial para garantir que o Ethereum permaneça robusto contra ameaças quânticas, mantendo escalabilidade e usabilidade.

Aviso Legal:

1. Este artigo foi republicado a partir de [ ethresear]. Todos os direitos autorais pertencem ao autor original [asanso]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Gate Aprenderequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da gate. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.