Resumo da última reunião dos principais desenvolvedores do ETH Place: Haverá um garfo sombra Goerli e um teste da atualização Cancun/Deneb antes do final do ano

Título Original: Ethereum All Core Developers Consensus Call #124 Writeup

Artigo original de Christine Kim

Compilação original: Luccy, BlockBeats

Nota do editor:

O ETH Workshop All Core Developer Consensus Calls (ACDCs) é realizado quinzenalmente para discutir e coordenar mudanças na Camada de Consenso (CL) do ETH Workshop. Esta é a 124ª teleconferência do ACDC, que abrange atualizações para o Devnet #12, progresso na atualização de Cancun/Deneb e tópicos relacionados à disseminação do Slashable. Durante a reunião, os desenvolvedores discutiram ativamente pequenas alterações no protocolo de rede Libp2p para reduzir o efeito de amplificação de mensagens grandes nos nós.

Christine Kim, VP de Pesquisa da Galaxy Digital, deu uma nota detalhada sobre os destaques da reunião, que a BlockBeasts compilou da seguinte forma:

Em 14 de dezembro de 2023, os desenvolvedores ETH se reuniram no Zoom para a sessão #124 do All Core Developers Consensus (ACDC). A teleconferência ACDC é uma série quinzenal de reuniões lideradas por Danny Ryan, pesquisador da ETH Workshop Foundation, onde os desenvolvedores discutem e coordenam mudanças na ETH Workshop Consensus Layer (CL). Esta semana, os desenvolvedores se concentraram no progresso dos testes da atualização Cancun/Deneb no testnet Devnet #12. Desde a reunião All-Core Developer Execution (ACDE) da semana passada, todas as combinações de clientes Execution Layer (EL) e Consensus Layer (CL) foram integradas ao Devnet #12, incluindo o cliente Prysm. O software MEV-Boost está ativado, mas as combinações de clientes com o Prysm não estão incluídas. Os desenvolvedores disseram que estão no caminho certo com os planos de lançar a filial sombra de Goerli nas próximas uma a duas semanas para testar a atualização Cancun/Deneb e incluir todos os clientes. Além disso, os desenvolvedores discutiram as regras para a divulgação de informações sobre o Slashable, bem como o cronograma de chamadas para as próximas duas semanas.

Devnet #12 atualização

Barnabas Busa, engenheiro de DevOps da ETH Foundation, disse que todas as combinações de clientes EL/CL, incluindo aquelas que usam Prysm como um cliente CL, foram integradas com sucesso ao Devnet #12. A carteira de clientes usando Prysm não foi testada para o software MEV-Boost. No entanto, no Devnet #12, o fluxo de trabalho MEV está testando outros clientes CL. Recentemente, o cliente Lighthouse passou por uma atualização de patch para resolver bugs relacionados ao MEV. Além disso, Parithosh Jayanthi, outro engenheiro de DevOps da Fundação, disse que eles notaram um problema com o nó Besu no Devnet #12 e que ainda estão trabalhando para determinar a causa raiz. Como próxima etapa, os desenvolvedores enviarão deliberadamente blocos maliciosos pela rede, testarão geradores de blocos e executarão testes de hive para clientes Prysm recém-adicionados para combinações de clientes de teste de estresse no Devnet. Jayanthi disse em uma mensagem pública do Discord durante a chamada que os desenvolvedores ainda planejam lançar uma ramificação sombra na testnet Goerli até o final do ano.

Informação Slashable atualizada

Em seguida, os desenvolvedores discutiram brevemente várias questões relacionadas à disseminação e ao tempo da mensagem de Slashable no ETH após a atualização de Cancun/Deneb. Para plano de fundo, as informações Slashable incluem a propagação de blocos e blobs duplicados ou inválidos. Dapplion, um desenvolvedor anônimo do cliente Lodestar, fez uma solicitação pull (PR) via GitHub que visa adicionar novos eventos à API Beacon Chain para permitir que os operadores de nó aprendam sobre eventos Slashable mais rapidamente, o que seria especialmente útil se houver uma grande quantidade de informações Slashable. Em seu PR, Dapplion menciona: "Para grandes operadores, o custo total de um evento de corte depende muito de seu tempo de resposta. Se houver muitas chaves envolvidas em erros operacionais, pode levar algum tempo para que essas informações possam ser incluídas na cadeia. O PR da Dapplion foi incorporado à especificação da API Beacon Chain antes da chamada e está sendo implementado por várias equipes de clientes CL, como Prysm e Lighthouse.

Dapplion também propõe uma RP relacionada à medição do tempo de propagação do bloco. Ele observou que medir o tempo de propagação do bloco se tornará mais difícil devido à atualização de Cancun/Deneb e à introdução de transações de blob. Dapplion elabora a solução que propõe em seu PR. Como os desenvolvedores notaram no thread PR, eles tendem a resolver esse problema adicionando um campo de carimbo de data/hora aos eventos de API da Beacon Chain relacionados existentes.

O terceiro tópico que os desenvolvedores discutiram relacionado à propagação de informações Slashable após a atualização de Cancun/Deneb foi as condições de propagação de blob. O desenvolvedor do farol “sean” (ou “realbigsean” no GitHub) apontou que as regras de propagação de blob existentes levaram a consequências não intencionais. Durante a chamada, Sean disse: "Se você estiver usando a API do Beacon para autenticação de transmissão, é inesperado que uma abordagem de fofoca possa levar a mensagens válidas e inválidas. A razão para isso é que, tecnicamente, é possível propagar dois blobs com diferentes índices de blob do cabeçalho Slashable associado a eles. Você tem permissão para propagá-los, mas não aqueles que têm o mesmo índice de blob. 」

Sean acrescentou que o comportamento estranho quando se trata da propagação de informações cortantes de blobs não tem impacto substancial na saúde da rede, além de apenas um resultado “estranho” para os operadores de nó entenderem e analisarem. Portanto, embora não haja urgência para a ativação de Cancun/Deneb, ele sugere que os desenvolvedores considerem fazer alterações nas regras para lidar com a disseminação de informações Slashable em atualizações futuras. Danny Ryan concorda, dizendo que os desenvolvedores devem ter tempo para pensar “holisticamente” sobre como resolver esse problema. Ryan sugere revisitar este tópico em janeiro para dar aos desenvolvedores tempo para elaborar um plano abrangente para atualizar as regras de propagação de blob e bloco do Slashable.

Em seguida, os desenvolvedores discutiram pequenas alterações no protocolo de rede libp2p para reduzir o efeito de amplificação em nós que enviam mensagens grandes, como blocos com um grande número de blobs. Sean destacou a nova mensagem de controle “IDONTWANT”, que pode ser usada para notificar os pares libp2p para pausar o envio de mensagens grandes. Ryan disse que tentará entrar em contato com a equipe libp2p para fundir este PR e, se houver mais atrasos, o assunto será revisitado na teleconferência da ACDE na próxima semana.