Resumo da última reunião do ETH Workshop Core Developers: Ative a atualização de Cancun no testnet no início de janeiro de 2024

Título Original: Ethereum All Core Developers ution Call #176 Writeup

Artigo original de Christine Kim

Compilação original: Luccy, BlockBeats

Nota do editor:

O ETH Workshop All Core Developer Consensus Calls (ACDEs) é realizado a cada duas semanas para discutir e coordenar mudanças na Camada de Execução do Workshop ETH (EL). Esta é a 176ª teleconferência da ACDE, e cobrirá discussões com a atualização Cancun/Deneb, o progresso dos testes do Devnet #12 e o plano de atualização Praga/Electra.

Os desenvolvedores discutiram como a atualização Cancun/Deneb foi testada no Devnet #12, incluindo o progresso e alguns problemas encontrados por diferentes equipes de clientes, bem como desafios técnicos na propagação de blobs, MEV (Maximum Extractable Value) e muito mais. Para a próxima atualização Praga/Electra, os desenvolvedores propuseram uma série de possíveis mudanças técnicas.

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 7 de dezembro de 2023, os desenvolvedores ETH se reuniram no Zoom for All Core Developers ution (ACDE) chamada #176. A Conference Call do ACDC é uma série quinzenal de reuniões lideradas por Tim Beiko, Chefe de Suporte de Protocolo da Fundação ETH, onde os desenvolvedores discutem e coordenam mudanças na Camada Executiva (EL) do ETH Place. Esta semana, os desenvolvedores discutiram o teste da atualização Cancun/Deneb no Devnet #12. Eles concordaram em coordenar a data de ativação da atualização na rede de teste Goerli em ETH no início de janeiro, após o fim do feriado. Além disso, eles planejam iniciar discussões no início de janeiro sobre quais mudanças de código devem ser incluídas na próxima atualização do workshop ETH, Praga/Electra.

Devnet #12 atualização

Os testes da atualização Cancun/Deneb no Devnet #12 estão indo bem. Parithosh Jayanthi, engenheiro de DevOps da Fundação, revelou que alguns bugs foram encontrados em dois clientes, Reth e Lighthouse, e que as duas equipes de clientes estão trabalhando em uma correção de emergência. Para testar os fluxos de trabalho MEV mais detalhadamente, as equipes de DevOps estão se concentrando mais em habilitar o software MEV-Boost em mais validadores no Devnet #12. De acordo com Jayanthi, sua equipe encontrou pelo menos um bug na implementação do relé MEV dos Flashbots. Danny Ryan, pesquisador da Fundação ETH, enfatizou que, para garantir que os validadores possam mudar para a construção de bloco local no caso de uma falha de relé, testes adicionais são necessários para verificar mecanismos alternativos.

Para atualizações de equipe específicas do cliente, Terence Tsao, o desenvolvedor do cliente Prysm, disse que sua equipe está trabalhando em um design atualizado para a propagação de #122中讨论的 blob do ACDC. Tsao confirmou que o cliente Prysm estará pronto para se juntar ao Devnet #12 para testes na próxima semana, possivelmente na próxima semana. Justin Florentine, o desenvolvedor do cliente Besu, disse que o Besu está pronto para mudar do Devnet #12. Representantes das equipes de clientes Nethermind, Erigon, Lodestar e Teku também disseram que estavam prontos para continuar testando a atualização na testnet pública ETH.

Com base na prontidão do cliente, a Beiko recomenda coordenar uma data de hard fork assim que os desenvolvedores estiverem fora das férias. Supondo que nenhum grande bug seja encontrado no Devnet #12 nas próximas semanas após a entrada do cliente Prysm, Beiko afirma que a ativação de Cancun/Deneb no Goerli provavelmente ocorrerá por volta de meados de janeiro. Ben Edgington da equipe Teku perguntou aos desenvolvedores se eles estavam confiantes em mudar o número de blobs por bloco de dois para três. Ryan sugere testes adicionais dos alvos de bolha aumentados durante o garfo de sombra maciço e ativação de Cancun/Deneb em Goerli. A Beiko confirmou que a ativação da atualização no Goerli será o “último teste significativo” dos três alvos de blob por bloco. Supondo que nenhum problema seja encontrado, os desenvolvedores continuarão a usar o maior número de blobs para ativação da rede principal.

No geral, Beiko disse que os desenvolvedores continuarão a testar atualizações no Devnet #12 até o final das férias. A equipe de DevOps planeja lançar pelo menos um garfo sombra Goerli até o final de dezembro, em preparação para um verdadeiro hard fork Goerli em janeiro. Se os desenvolvedores se reunirem para o Ano Novo, eles discutirão a data da ativação do hard fork Goerli.

Sinalizadores de substituição do construtor

Em seguida, Tsao perguntou à equipe do cliente sobre seu progresso na implementação do sinalizador de substituição do Builder. O sinalizador de substituição do Builder é um novo campo booleano na atualização de Cancun que o cliente da camada de execução pode usar para indicar ao cliente da camada de consenso que, quando o Builder deteta atividade de censura, o validador deve voltar para a geração de bloco local em vez de usar um Builder, de terceiros. Como Tsao enfatiza, os detalhes da implementação sobre como detetar as atividades de revisão do Construtor são subjetivos e deliberadamente deixados para a equipe do cliente projetar. Para obter mais informações sobre sinalizadores de substituição do Builder, consulte as atas do ACDC#112 e do ACDE#165.

O desenvolvedor da equipe do cliente Geth, que atende pelo nome de tela “Lightclient”, disse que sua equipe implementou a bandeira, mas não a fundirá no lançamento oficial “em um futuro próximo”. Representantes das equipes Besu e Nethermind afirmaram que esta bandeira opcional ainda não foi implementada em seus clientes. Tsao enfatizou que a bandeira pode ser uma ferramenta útil, e é melhor implementá-la o mais cedo possível para desencorajar e desencorajar pools de staking ou grandes operadores de nó validador de participar de certos “jogos de tempo”. Tsao explicou que os validadores podem ganhar mais MEV (Valor Máximo Extraível) atrasando a propagação do bloco, e que após a introdução de blobs após a atualização de Cancun, haverá um atraso na propagação do bloco. Durante esses atrasos, os validadores podem optar por incluir transações MEV mais lucrativas no bloco, o que é subideal para propagação oportuna de blobs.

Confirmando que as transações de blob terão que competir com as transações regulares, um desenvolvedor pseudônimo da equipe Prysm, que atende pelo nome de tela Potuz, acrescentou: "Os Blobs precisam competir não apenas com taxas, mas também com a própria latência e todo o MEV ganho ao atrasar blocos. Ao conceber o mecanismo de taxas para as bolhas, pensei que se tratava de um mercado que não tinha sido bloqueado nem tido em conta. Tsao disse que traria o assunto novamente no Ethereum Research Discord para uma discussão mais aprofundada. Além disso, Ryan destacou o último post dos pesquisadores da Fundação Ethereum Caspar Schwarz-Schilling e Mike Neuder sobre “jogos de cronometragem” no site da Ethresearch.

Progresso do Projeto

Em seguida, Beiko compartilhou três atualizações relacionadas ao processo de planejamento de atualização do ETH Workshop. Primeiro, como no #123上讨论的那样 ACDC, a Beiko criou um documento Meta EIP para a atualização de Cancun/Deneb, que lista todas as Propostas de Melhoria ETH (EIPs) que foram incluídas em Cancun/Deneb. Ele foi criado no GitHub com o número EIP 7569. Além disso, a Beiko criou o EIP 7568 como o documento Meta EIP para todas as atualizações anteriores, e os desenvolvedores não criaram um documento dedicado para acompanhar a lista de EIPs incluídos na atualização. O EIP 7568 está vinculado à especificação do código de atualização.

Em segundo lugar, Beiko anunciou que havia criado um novo tópico de discussão no site Ethereum Magicians para identificar a próxima atualização de rede, Praga/Electra. Ele pediu aos desenvolvedores que pensassem criticamente sobre a possibilidade de agrupar as atualizações da Camada de Execução (EL) e da Camada de Consenso (CL) juntas, como os dois últimos hard forks fizeram. A ativação de certas alterações de código, como a EIP 7002, exigirá alterações tanto na EL como na CL, pelo que as atualizações de Praga e Electra terão de ser coordenadas. No entanto, para outras alterações de código, como a árvore Verkle, há uma maneira de redesenhar a implementação e só precisa atualizar a CL.

Ryan observou que os desenvolvedores da camada de consenso (CL) que trabalham em paralelo com a árvore Verkle também estão fazendo alterações de código para dar suporte à amostragem de disponibilidade de dados. Beiko aconselha os desenvolvedores a não entrar em detalhes sobre todos os EIPs que eles querem ver na atualização Praga / Electra, mas sim rever todas as alterações de código candidato durante as férias e estar pronto para discuti-los seriamente em janeiro. Potuz concorda, acrescentando que um EIP projetado para resolver o problema crescente do tamanho do conjunto do validador ETH seria uma mudança de código importante em Praga/Electra. Com base na complexidade das alterações de código, a Beiko recomenda que, para determinadas EIPs, como Verkle ou amostragem de disponibilidade de dados, os desenvolvedores organizem reuniões dedicadas após as férias para discutir essas mudanças de protocolo maiores em detalhes.