Resumo
Proposta para descontinuar credenciais de retirada baseadas em BLS (0x00) no Ethereum devido à sua vulnerabilidade a ataques de computação quântica. Ele estabelece uma recuperação simples da camada de execução, onde os validadores que permanecem em 0x00 após a disponibilização de um método de assinatura criptográfica pós-quântica (PQC) podem ser recuperados por meio de seu endereço de depósito original. Também introduz uma nova credencial de retirada opcional (0x03) protegida por uma chave criptográfica pós-quântica. Um hard fork é necessário para implementar essas mudanças.
Motivação
- Risco Quântico: As chaves públicas do BLS são expostas no depósito e podem ser quebradas por futuros computadores quânticos.
- Chaves perdidas: validadores com chaves BLS perdidas (por exemplo, mnemônico perdido) não podem atualizar credenciais de saque ou sair, deixando os fundos permanentemente bloqueados. Esses validadores correm o risco de serem atacados por estados-nação que usam seus computadores quânticos. Também ajuda as pessoas certas da nossa comunidade a recuperarem os seus fundos no momento certo.
- Necessidade da comunidade: É necessário um método de recuperação descentralizado e sem confiança para validadores perdidos para proteger o ecossistema Ethereum sem introduzir intervenções sociais ou de custódia.
- Análise atual: Em janeiro de 2025, aproximadamente 13.394 validadores ainda tinham credenciais BLS, representando 1,15% dos validadores ativos. Uma grande parte não mostra nenhuma atividade de transação desde o depósito, indicando alto risco de perda da chave. Também inclui 1.172 validadores do Stakehound que foram permanentemente bloqueados quando seu provedor de segurança terceirizado perdeu o acesso às chaves privadas em 2021.
Implementação
Após a introdução futura de assinaturas criptográficas pós-quânticas (PQC) na camada de consenso, qualquer validador que permanecer usando uma credencial de retirada 0x00 se tornará elegível para recuperação da camada de execução (EL).
- Visão geral da recuperação da camada de execução:
- O primeiro endereço de depósito associado ao validador será autorizado a enviar uma transação EL para atualizar as credenciais de retirada do validador.
- O endereço de depósito pode então:
- Defina um novo endereço de retirada da camada de execução 0x01.
- Depois de definirem um endereço de retirada, eles podem usar esse endereço de retirada para acionar uma saída. As saídas podem ser acionadas por EL a partir do endereço de retirada da Pectra
- Substituição e justiça:
- Os validadores que desejam evitar esse fallback devem atualizar suas próprias credenciais, definindo um endereço 0x01 ou 0x02 ou adotando uma credencial PQC 0x03.
- Os validadores que não agem após amplas janelas de aviso e transição estão sinalizando a aceitação do mecanismo de fallback.
- Casos extremos e cuidados:
- Alguns validadores depositados através de serviços de custódia podem não controlar o endereço de depósito; tais validadores podem não ser recuperáveis através deste método.
- Casos extremos envolvendo endereços de depósito compartilhados ou atribuídos incorretamente devem ser cuidadosamente revisados durante a implementação.
- Suporte de partes interessadas terceirizadas:
- Os três provedores de staking com o maior número de validadores ainda em 0x00 (Stakehound, Stakefish e Staked.us: total combinado de 2.907 validadores) apoiam este EIP e ajudarão seus clientes afetados adequadamente.
Especificação
Credenciais de retirada
- 0x00 – Credencial BLS (obsoleta): exposta publicamente e vulnerável a quantum.
- 0x01 – Credencial de endereço de execução: Retirada para um endereço de execução Ethereum.
- 0x02 – Credencial de composição (EIP-7251): Suporta saldos efetivos mais altos.
- 0x03 – Credencial Pós-Quantum (Opcional): Retirada protegida por assinatura criptográfica pós-quântica.
Mecanismo de atualização de credenciais (em apoio à estrutura de migração)
- Uma nova função EL permitirá que o endereço do primeiro depósito:
função requestCredentialUpdate (uint64 validatorIndex, bytes32 newCredential) a pagar
- Somente o DepositOrigin registrado pode chamar esta função.
- Um período de desafio (~27 horas) garante que uma chave BLS válida possa substituir a atualização da origem do depósito, se ainda estiver disponível.
Requisitos de hard fork
- O mecanismo de recuperação de fallback é ativado somente após um hard fork que descontinua as credenciais 0x00 e permite o uso de credenciais PQC.
- Nenhum novo validador usando credenciais 0x00 será aceito após a bifurcação.
Justificativa
- Justiça e Descentralização:
- O depositante original está na rede e pode ser verificado sem a introdução de custodiantes.
- Os validadores receberam um aviso justo e vários caminhos para se protegerem.
- Segurança e mitigação de riscos:
- Evita a perda em massa do validador em um ataque quântico futuro.
- Resgata fundos bloqueados sem recuperação social complexa ou intervenções subjetivas.
- Conscientização de casos extremos:
- Cuidado especial é observado para validadores financiados através de mecanismos de depósito compartilhado.
Considerações de segurança
- Resistência Quântica: A migração para 0x01, 0x02 ou 0x03 evita a dependência de criptografia vulnerável quântica.
- Compromisso de chave: Enfatiza a urgência para que os validadores protejam ou migrem suas credenciais.
- Recuperação do validador: protege a segurança da rede e os fundos individuais do validador.
Apoio Comunitário
Este EIP incorpora feedback recebido da comunidade ETHStaker (Valefar, Yorick Downe), dos principais desenvolvedores do Ethereum (Potuz, Benjamin Chodroff) e dos principais provedores de staking (Stakehound, Stakefish, Staked.us). A sua orientação ajudou a refinar o modelo de recuperação alternativa e a validar a sua imparcialidade.
Considerações de segurança
A recuperação da camada de execução, combinada com opções de credenciais pós-quânticas, garante que o conjunto de validadores do Ethereum permaneça seguro, descentralizado e resiliente contra ameaças quânticas. As mudanças propostas permitem que o Ethereum descontinuar graciosamente as credenciais de retirada do BLS e recuperar validadores perdidos de forma justa, exigindo um hard fork da camada de consenso.
Referências
Minha impressão aqui é que esta proposta é motivada principalmente por chaves perdidas, e não por risco quântico. Proposta na mesma linha que foi apresentada anteriormente pelo que parecem ser pessoas associadas da Stakehound ou Fireblocks.
O risco quântico pode ser mitigado da mesma forma que provavelmente será mitigado na camada de execução – não permitindo validação ou recuperação de fundos sem prova de mnemônicos para a chave BLS. O que é muito ruim para pessoas que perderam mnemônicos, mas provavelmente é inevitável para fundos perdidos ou inativos da camada de execução, portanto, abrir uma exceção para os stakers precisa ter motivação adicional, IMO.
Eu seria a favor que grandes stakers com credenciais perdidas (por exemplo, Stakehound e talvez clientes Stakewise/Staked?) contribuíssem para ajudar na transição para a resistência quântica, e não pegando carona nela.
1 Curtir
Você poderia explicar por que as credenciais de retirada do BLS são consideradas vulneráveis a ataques de computação quântica?
O único compromisso público é o hash da chave pública retirada, e não a própria chave pública. Afaik, isso é suficiente para evitar ataques quânticos úteis.
Porém, não sou um especialista em CQ; é uma questão genuína. No entanto, acho que teremos problemas muito mais significativos do que este se/quando os computadores quânticos puderem quebrar a criptografia BLS.
Também é um bom ponto; eles se tornam vulneráveis quando há uma mensagem para girar as credenciais para 0x01, o que significa que as credenciais perdidas não são um risco quântico, a menos que exista uma mensagem assinada por eles quando ainda não foram perdidas. Isso é muito improvável para um staker regular, mas muito provável para uma configuração BLS de limite avançado à la Stakehounds – eles tiveram que testar a configuração, afinal.
2 curtidas
Obrigado pelo seu tempo e pensamentos – muito apreciado!
Para que conste: não sou afiliado ao Stakehound/Stakefish/Staked.us; apenas um staker pré-gênese (9213, 9219, 9226, 9228) que foi tolo o suficiente para escrever os mnemônicos da rede de teste em vez dos mnemônicos da rede principal. Muito estúpido, sim. E sim, isso também é motivado pela perda de chaves.
No entanto, quando o hardfork para assinaturas PQC acontecer no futuro, isso proporcionará uma oportunidade única para ajudar as pessoas certas em nossa comunidade a recuperar seus fundos E reduzir preventivamente a superfície de ataque quântico da rede.
São pessoas que começaram a apostar quando tudo ainda era muito experimental e apoiam o Ethereum há longos períodos de tempo. Com pouco ou nenhum risco envolvido, não será este o momento e a solução ideais?
Obrigado pelo seu tempo e pensamentos também – muito apreciado!
Você está certo. O algoritmo de Shor requer a chave pública exposta real para calcular a chave privada. Observe também que existem problemas mais significativos para resolver, conforme mencionado acima: esta pode ser a única oportunidade que resta para os validadores que perderam seus mnemônicos. O hardfork terá que acontecer mesmo assim.
A estimativa aproximada é que existem 2.000-2.500 validadores com mnemônicos perdidos. Muitos dos quais são apostadores individuais.
Bem, talvez precisemos esperar centenas de anos até que os ataques sejam viáveis.
FWIW, já existem contas inteligentes pós-quânticas na rede principal Ethereum (por exemplo, Quip Network, Anchor Wallet), pode-se facilmente designar uma conta inteligente como o endereço de retirada sem a necessidade de um hard fork.
Obviamente, isso não resolve o problema de recuperação de chave ou ataques de sofrimento ao validador que atestam históricos de cadeias maliciosas ou DoS do validador, mas seria uma solução viável que está disponível hoje sem qualquer bifurcação.
Por exemplo, a biblioteca hash da Quip Network usa WOTS+ construído em keccak, e a biblioteca ethereum-sdk lida com a troca de assinaturas únicas e a sincronização de seus hashchains locais com o estado onchain. Se um invasor quântico roubasse sua chave de validação e retirasse para a conta Quip, ele não teria a assinatura Winternitz necessária para exfiltrar os fundos para um novo endereço.
Como um validador solo que perdeu a capacidade de definir 0x01 de 0x00, estou olhando para isso com muito interesse.
Enquanto isso, acho que o validador precisa continuar funcionando para evitar que chegue a 0 eth.
Fontesethresear
