Preparar retiradas para validadores comprometidos ou chaves de retirada. FAO Zilm – Página 3 – A fusão

Olá, sou um validador completo do Windows desde o Gênesis… Tenho um problema semelhante onde minha conta costumava fundo meu validador com 32 eth foi comprometido. Disseram-me que ainda não migrei para as credenciais 0x01, estou bem. Isso é verdade? desde já, obrigado

Meu entendimento é que se ele tiver a frase-semente, você precisa definir seu endereço de retirada para uma nova carteira segura o mais rápido possível ou a pessoa que tem sua frase-semente pode fazer isso por você em um endereço que você não controla. @benjaminchodroff você pode confirmar?

Na verdade, respondi às pressas porque estava preocupado com você. Mas pensando bem, sim, você está certo porque o endereço de retirada do validador não é o endereço de depósito, é? contanto que você não tenha perdido o controle da frase-semente do endereço de retirada, você está bem.

Se apenas a frase-semente usada para o seu endereço de depósito foi comprometida, isso não comprometerá a frase-semente do validador (a menos que você tenha feito algo estranho e usado a mesma frase-semente para o seu validador). Como você indicou que ainda não definiu seu endereço de retirada, você ainda pode configurá-lo para um novo endereço que não esteja comprometido. Eu recomendo que todo validador sempre defina seu endereço de retirada gerenciado por uma frase-semente que seja segura, offline e operada com uma carteira de hardware fria.

oi, obrigado por suas respostas! então não acho que a “frase-semente” real tenha sido comprometida, eu uso metamask e acidentalmente executei um contrato inteligente desonesto que comprometeu a “chave privada” da metamask (eu acho)… de qualquer forma, quando eu finalmente migrar para 0x01 irei definitivamente definir um novo endereço de retirada offline como você declarou.

Olá @benjaminchodroff,

Trazendo à tona esse post antigo novamente, mas ainda esperançoso, é claro!
Houve alguns bate-papos sobre discord: Prysm discord + EthStaker discord e gostaria de saber sua opinião sobre isso.

Potuz (no Discord do Prysm) escreveu o seguinte no Twitter (não consigo postar links, mas o nome dele é potuz_eth e a postagem foi feita em 13 de julho deste ano).

Ele propõe resolver isso na “camada social”:

• Coletando alterações semelhantes a como o clwp fez (potencialmente com ainda mais verificações)
• Em seguida, em um hardfork, altere as credenciais.
• Enviando potencialmente uma mensagem de cadeia de execução do endereço de depósito contendo uma mensagem assinada pelo keystore do validador?

A probabilidade de um usuário mal-intencionado ter acesso ao endereço de depósito + chave de assinatura do validador + mnemônico perdido é muito, muito pequena (pode chegar ao ponto de dizer 0).

Existem vários validadores genesis cujos operadores perderam suas sementes, mas possuem a carteira que os financiou. Estamos literalmente falando de milhares de ETH, principalmente de stakers domésticos. Os defensores mais ferrenhos do Ethereum desde o primeiro dia.

Este seria um hard fork, sim, mas não afeta nenhuma transação na cadeia. Não reverte nenhum tx e não perde ETH para ninguém.

O que você acha disso?

Curioso para saber a opinião dos desenvolvedores sobre isso. Ter um esquema de assinatura dupla de ambos os depositantes EL (todos eles devem participar no caso de múltiplos depositantes) + o atual operador de armazenamento de chaves no CL pode obter garantias de segurança suficientes para que isso aconteça no futuro. Restringir credenciais de retirada não atribuídas também reduziu bastante o risco.

Não posso te ajudar a construir essa proposta, mas posso te dar algumas orientações. Concordo com Potuz que a opção mais realista (embora seja muito difícil de convencer a comunidade) é coletar uma série de assinaturas fora da cadeia de maneira semelhante ao CLWP e, em seguida, tentar habilitar um hardfork da camada de consenso para definir/substituir (?!) o endereço de retirada E sair do validador sem exigir as mensagens BLS assinadas.

É claro que, se alguém no futuro perder o mnemônico do validador CL ou o mnemônico do endereço de retirada da camada de execução, esse processo de hardfork poderá ser repetido novamente com novos dados. Além disso, o precedente de incluir quaisquer dados fora da cadeia em clientes validadores para solicitar hard forks é extremamente preocupante para muitos na comunidade, independentemente dos méritos. Pode exigir que os participantes verifiquem voluntariamente esses dados e, opcionalmente, carreguem os dados em seu validador CL – um processo muito mais lento, porém mais seguro. Isso levanta vários desafios de segurança com testes e garantia de que os validadores não sejam cortados.

Tenho certeza de que não pensei bem sobre isso e mudar qualquer aspecto do consenso em cadeia é extremamente arriscado. Boa sorte.

@philrx31 O que você acha de configurar um EIP para isso?

Na verdade, talvez eu consiga escrever uma proposta inicial de sinalização. Aprofunde-se nos diferentes projetos viáveis ​​e considere uma primeira versão que seja altamente restritiva e envolva coordenação e complexidade mínimas de CL. @benjaminchodroff Posso entrar em contato com você novamente no processo para coletar alguns insights e sugestões formais antes de postar.

@philrx31

Valefar (no Ethstaker Discord #retiradas canal) tem trabalhado na seguinte solução (potencial) semelhante ao CLWP:
Github: /valefar-on-discord/update-credentials-without-mnemonic

(Infelizmente não é possível postar links)

Este esquema proposto de dupla assinatura parece constituir uma boa solução. Podemos ter o feedback de @benjaminchodroff sobre a probabilidade de vermos a aprovação dos desenvolvedores para este esquema e a aceitação para realizar a atualização de credenciais em um hardfork futuro? Nesse caso, ficaria feliz em anotar o EIP associado no devido formato para solicitar essa bifurcação. Eu também cuidaria do networking para alcançar os usuários que possam estar nesta situação desagradável.

Excelente. Comprometer o depósito não seria suficiente para que o invasor alterasse as credenciais de saque com esta proposta. O invasor também precisaria de acesso ao keystore do validador porque ambas as assinaturas seriam necessárias para provar a propriedade.

Existe absolutamente uma situação em que um usuário pode não querer atualizar suas credenciais do BLS por qualquer motivo e esta proposta pode colocar seus fundos em risco. Mas qual a probabilidade de eles não apenas não quererem atualizar suas credenciais BLS, mas também o endereço de depósito e o armazenamento de chaves estarem comprometidos?

Existem atualmente 14.168 validadores com BLS=0x00. A estimativa conservadora de 1.000 (~7%) destes que perderam seu mnemônico representa algo entre 32.000-35.000 ETH (o que adicionou recompensas). Grande parte desses validadores também são stakers pré-gênese.

Na verdade, 7% parece mesmo ser uma previsão conservadora.

Você pode explicar o cenário que colocaria os fundos em risco?

Eu recomendo que você inicie um novo tópico e tente direcionar os afetados para o novo tópico. Será incrivelmente difícil (leia-se: quase impossível) convencer a comunidade hoje de tal proposta, mas teoricamente pode chegar o momento certo. Prefiro manter a esperança, planejar e começar a preparar uma solução para estar pronto quando chegar a hora certa.

Uma assinatura BLS para retiradas “não é quântica segura” e o Ethereum um dia precisará fazer um hard fork para um novo padrão. Isso poderia fornecer uma oportunidade única para um resgate naquele ponto para que os validadores gerados usando a curva elíptica existente sejam ajudados. Nesse período, todas as opções poderiam ser colocadas sobre a mesa sobre como lidar com validadores que ainda não definiram um endereço de retirada. Você poderia começar a construir uma comunidade e a lista dos impactados com as assinaturas verificadas. Espero que você construa.

“É precisamente por isso que mantenho uma visão positiva sobre a eventual mudança dos esquemas de assinatura antecipada e dos paradigmas de consenso. Concordo que devemos estar prontos quando chegar o momento oportuno, pois será nossa única chance de efetuar essa mudança. Agradeço sua contribuição. Certamente entraremos em contato com @maverickandy e faremos a transição para um tópico diferente para reunir os participantes e coletar as assinaturas necessárias. Enquanto isso, mantenha-nos informados se você notar o momento certo para uma tentativa se aproximando.

Cheguei a este tópico através de uma pesquisa no Google. Inicialmente pensei que tinha errado minhas 24 palavras…

Eu queria alterar minhas credenciais de retirada, mas não importava como eu brincasse com caminhos e índices, o ethdo continuava gerando credenciais de retirada completamente diferentes – nenhuma delas correspondia ao meu validador em execução. Usei a conta ethdo deriva –show-withdrawal-credentials –path=“m/12381/3600/0/0” –mnemonic=“…”. Fiquei muito desesperado e comecei a duvidar se havia escrito meu mnemônico corretamente, embora sempre verifique três vezes.

Então tive a ideia de baixar a mesma versão do CLI de depósito que usei há 4 anos para ver se geraria os mesmos dados de depósito. E aconteceu! As credenciais de retirada combinaram – então o mnemônico é bom!

Em seguida, baixei a versão mais recente da CLI de depósito e ela ainda criou as mesmas credenciais de retirada e dados de depósito. Ufa!

Felizmente, esta nova versão agora tem a capacidade de alterar as credenciais de retirada do BLS para alteração de execução. A transmissão desse JSON finalmente fez com que isso acontecesse – agora posso desistir.

Examinei o código CLI ethdo e de depósito e parece que os caminhos e todo o resto estão corretos, mas de alguma forma ethdo deriva o mesmo mnemônico de forma diferente da CLI de depósito…

Não sei por que isso acontece, mas pensei em compartilhar aqui caso alguém pense que perdeu o acesso ao seu ETH apostado. Caso queira sacar, basta utilizar a mesma ferramenta que utilizou para gerar as contas.

Esqueci de mencionar que tentei ethdomnemônico de teste de util/account_test.go#L74 com um binário estático que eth-docker preparado.

Executá-lo em minha máquina com airgap deu um pubkey completamente diferente… Infelizmente não tenho tempo para investigar mais (estou feliz por ter meu ETH de volta), então estou apenas deixando isso aqui para pessoas que pensam que perderam seu mnemônico… Porque talvez não tenham perdido.

Se você sentir que perdeu seu mnemônico de depósito inicial, tente outra ferramenta, ou de outra forma, ou de outra linha do tempo, e pode funcionar

Olá, mesmo problema em fórum diferente. Eu estaria interessado em iniciar um novo tópico com as pessoas afetadas (endereço de retirada comprometido) e/ou obter algum feedback. Sinta-se à vontade para entrar em contato aqui ou no fórum ethereum-magicians. Também posso ajudar com alguns testes em cadeia, se necessário.
Como não posso postar links aqui, você poderá encontrar minha postagem através da pesquisa ethereum magicans: saída de emergência para endereço de retirada do validador comprometido-2fa

Obrigado

Para todos os validadores que perderam seu mnemônico (e ainda estão presos nas credenciais de retirada 0x00), criei a seguinte iniciativa: deprecatebls.com

Proponho aqui um mecanismo de recuperação, provando a propriedade do seu validador por meio da assinatura de uma mensagem simples com sua chave do validador (keystore JSON).

Mais informações também estão sobre este tópico:

Sinta-se à vontade para entrar em contato comigo no ETHStaker Discord. No #gerenciamento de chaves canal. Estou lá