Resumo da última reunião dos principais desenvolvedores do ETH Place: Devnet 12 é lançado e o processo de planejamento de atualização está sendo atualizado

Título Original: Ethereum All Core Developers Consensus Call #123 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 123ª teleconferência do ACDC, que se concentrou na avaliação das atualizações de teste Cancun/Deneb e Devnet #12, bem como na resolução dos problemas de saída do validador que surgiram no Devnet #11. Além disso, os desenvolvedores tiveram uma discussão aprofundada sobre o esclarecimento da especificação da rede, o processo de planejamento de atualização e o status do EIP.

Durante a discussão de Cancun/Deneb, os desenvolvedores enfatizaram a estabilidade e discutiram se deveriam ou não iniciar a bifurcação sombra Goerli. No entanto, como o cliente Prysm não estava pronto para testes, foi decidido esperar que estivesse pronto. As discussões sobre ferramentas de teste e reestruturação da cadeia destacaram a necessidade de uma cobertura de teste mais abrangente e fizeram recomendações para o uso dos pacotes de testes Hive e Kurtosis. Sobre a questão do status EIP e rótulos CFI, Beiko levantou preocupações sobre se essas tags devem ser mantidas, e os desenvolvedores ainda não chegaram a um consenso claro sobre essa questão.

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 30 de novembro de 2023, os desenvolvedores ETH se reuniram no Zoom para a sessão #122 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 nos últimos desenvolvimentos nos testes de Cancun/Deneb, incluindo:

· Lançamento do Devnet #12: Testes do software cliente Teku, Lodestar e Lighthouse, bem como de todo o software cliente da camada de execução (EL), no Devnet #12 estão em andamento. A equipe da Prysm espera ter seu software pronto para teste dentro de duas a três semanas no Devnet mais recente.

· Problema de saída do validador no Devnet #11: No Devnet #11, os desenvolvedores identificaram um problema relacionado à saída do validador, que está sendo resolvido pela equipe do cliente Nimbus. O Devnet #11 continuará a funcionar normalmente até que o problema seja resolvido.

· Esclarecimento da especificação de rede: Os desenvolvedores discutiram esclarecer a especificação para solicitações “BlockByRoot” e “BlobSidecarsByRoot”, esclarecendo se os nós da camada de consenso (CL) devem responder a essas solicitações em uma ordem específica.

Além da atualização Cancun/Deneb, os desenvolvedores discutiram algumas das questões do processo levantadas por Tim Beiko, Chefe de Suporte de Protocolo da Fundação ETH, para melhorar a coordenação da atualização do ETH Workshop.

Devnet #12

Na quarta-feira, 30 de novembro de 2023, a atualização Cancun/Deneb foi lançada oficialmente no Devnet #12. Mario Vega, da equipe de testes da Fundação ETH, disse que “nenhum problema importante foi identificado até o momento” nos três clientes CL atualmente em execução na testnet. Barnabas Busa, engenheiro de DevOps da Fundação, mencionou que há um total de 225 validadores espalhados por três nós entre Lighthouse, Teku e Lodestar. Devido à estabilidade do Devnet #12, Parithosh Jayanthi, engenheiro de DevOps da Fundação, perguntou aos desenvolvedores se eles deveriam começar a planejar um fork de sombra Goerli para testar ainda mais Cancun/Deneb. No entanto, considerando que o Prysm, o cliente CL mais popular no momento, ainda não se juntou ao Devnet #12, os desenvolvedores decidiram suspender os planos para um fork sombra Goerli até que o software cliente Prysm esteja pronto para testes. Beiko sugere avançar na bifurcação sombra Goerli algures antes do final do ano. Devido à estabilidade do Devnet #12, os planos são suspensos até que o software cliente Prysm esteja pronto para testes.

Devnet #11

O desenvolvedor Nimbus, que atende pelo nome de tela “Dustin”, compartilha os detalhes da edição Devnet #11 em que sua equipe está trabalhando. Esses problemas foram descobertos pela primeira vez quando os desenvolvedores saíram de um terço dos validadores do Devnet #11 para uso no Devnet #12. Ryan pergunta a Dustin se ele pode detetar esses problemas com testes adicionais. Dustin respondeu que, em sua opinião, a natureza desses erros foi causada por detalhes de implementação fora do escopo da especificação de consenso. No entanto, ele também reconhece que há uma “tensão clara” entre escrever software cliente estritamente para a especificação CL, a fim de testar os benefícios da cobertura e entrar nas áreas cinzentas da especificação, a fim de alcançar um melhor desempenho do nó.

“Estou dizendo que mais testes são sempre bons, mas descobrir de forma mais sistemática como incorporar mais funcionalidades do lado do cliente na execução de testes, talvez mais automação, seja usando Hive, Kurtosis ou o que for. Se esses problemas puderem ser resolvidos ou as coisas puderem ser bem divididas o suficiente para poder incorporar mais dessas tarefas, acho que isso definitivamente seria útil”, acrescentou Dustin, acrescentando que outro desafio que os desenvolvedores de CL devem considerar abordar é descobrir o nível de detalhe no qual a especificação CL deve ditar e padronizar o comportamento do nó. “O outro desafio aqui é o grau de padronização, que realmente não é apenas uma questão de engenharia de software, quão padronizado deve ser o comportamento?” Dustin perguntou. Todos os clientes CL são testados para verificar o comportamento básico, mas o comportamento fora do escopo desses testes é ambíguo. “São coisas deliberadamente vagas? o que deve ser realmente claramente definido pela especificação e o que deve ser deliberadamente obscuro?” Dustin perguntou.

No mínimo, os desenvolvedores concordaram em adicionar mais testes para futuros Devnets e testnets para um grande número de saídas de validador em Cancun / Deneb. Ryan também reconhece que há espaço para uma cobertura de testes mais rigorosa e abrangente quando se trata de clientes CL e implementação de especificações CL. Vega sugeriu que Dustin criasse um post no HackMD detalhando suas preocupações e discutisse o tema na próxima chamada de teste Cancun/Deneb. Jayanthi acrescentou que, com base em alguns dos problemas recentemente identificados em Cancun/Deneb Devnets, há uma clara necessidade de os desenvolvedores terem ferramentas que possam executar sistematicamente um certo número de comportamentos relacionados à integração on-chain, como retiradas de ETH de stake, retiradas de validadores, etc. Para fazer isso, Jayanthi recomenda usar uma mistura de suítes de teste Hive e Kurtosis para construir tal ferramenta.

Falando sobre a nova ferramenta de teste para a atualização Cancun/Deneb, Jayanthi observou que os desenvolvedores estão trabalhando em uma ferramenta para ativar de forma confiável as reuniões da cadeia em Devnets e testnets. Para garantir que a ferramenta funcione, Jayanthi pediu aos desenvolvedores que compartilhassem detalhes do bug conhecido que desencadeou a reorganização da cadeia no ETH. Jayanthi explicou que usará esses bugs para testar a ferramenta e garantir que ela possa identificar de forma confiável quando uma reorganização ocorre e quando ela é resolvida.

Esclarecimento das especificações da rede

Os desenvolvedores discutiram brevemente uma solicitação de pull aberta proposta por Justin Traglia, um pesquisador da ETH Foundation, sobre a ordem de respostas que os clientes CL devem retornar ao receber uma solicitação “BlockbyRoot” ou “BlobSidecarsByRoot”. Ryan pergunta como as diferentes equipes de clientes CL já estão implementando esse recurso. Nenhum dos desenvolvedores na chamada respondeu a essa pergunta. Ryan sugeriu reavivar a discussão no canal ETH Research & Development Discord para envolver uma gama mais ampla de desenvolvedores de clientes. Ryan reconhece que há ambiguidades nas especificações dos dois pedidos, que “podem ser a causa de problemas e casos de borda estranhos” e “merecem ser esclarecidas e resolvidas”, afirma Ryan.

Ryan também mencionou que lançará uma nova versão da especificação CL nos próximos dias. A versão mais recente adiciona significativamente uma especificação sobre quando um cliente CL pode fornecer blocos e blocos através de uma solicitação RPC “byRoot”. Para obter mais informações sobre a discussão sobre a recuperação de blocos e partes ausentes por meio de solicitações RPC “byRoot”, consulte o registro de chamadas anterior. Ryan enfatiza que as novas adições à especificação CL incluídas na versão mais recente não terão nenhuma alteração de quebra no código que afetará o código para validadores já em execução no Devnet #11 ou #12.

Processo de planejamento de atualização

Em seguida, os desenvolvedores discutiram os vários itens de processo propostos pela Beiko. De acordo com Beiko, uma postagem no blog alertando os usuários do Goerli testnet sobre a descontinuação iminente dentro de 3 meses após a atualização de Cancun/Deneb ser ativada no Goerli, ou dentro de 1 mês após a ativação da atualização na rede principal ETH, o que for posterior, será publicada no blog da Fundação ETH em 30 de novembro. Desde a conclusão da chamada, o post acima foi publicado e pode ser lido aqui.

A Beiko recomenda a criação de uma pasta específica de atualização no repositório ETH “pm” para organizar vários arquivos relacionados a uma atualização específica em uma única pasta para uso posterior. Os desenvolvedores da chamada concordaram com a sugestão de Beiko.

O segundo item de processo proposto pela Beiko foi criar um documento “Meta EIP” para acompanhar todo o escopo das atualizações de rede que haviam sido concluídas no ETH. “Não há um bom lugar para acompanhar todo o escopo de uma atualização de rede antes de implantá-la e anunciá-la em uma postagem de blog”, escreveu Beiko em um post sobre sua proposta Meta EIP. "Para Dencun, temos EIPs EL em um arquivo de markdown 7 difícil de encontrar, e EIPs CL fazem parte da Beacon Chain Specification 3. Isso não é ótimo, pois ambos são um pouco difíceis de encontrar, cada um usa um ‘formato’ diferente, e levam à duplicação. Como o ERC e os EIPs agora estão separados, eu recomendaria (voltar) ao uso de Meta EIPs para rastrear os EIPs incluídos na atualização da rede. Os desenvolvedores eram a favor da criação desses documentos. Beiko disse que vai elaborar um documento para revisão da atualização Cancun/Deneb esta semana.

Finalmente, Beiko levantou uma questão sobre a utilidade de marcar as alterações de código propostas, ETH Improvement Proposals (EIPs) como “consideradas para incluir” (CFI). De acordo com Beiko, o CFI é um estado que os desenvolvedores historicamente usam como “sinais suaves”, indicando que os autores de EIPs devem continuar a trabalhar duro em propostas que podem ser incluídas em futuros hard forks. Ele é usado apenas para alterações e atualizações de código focadas em EL. 「[CFI] mais do que ideias aleatórias de pessoas aleatórias, mas antes de serem aceitas na bifurcação", disse Beiko.

No passado, os rótulos CFI tinham pouco efeito na indicação de quais EIPs na EL seriam implementadas na atualização ou quando. Ele tem sido aplicado a uma ampla gama de EIPs com diferentes graus de prontidão de código e suporte de equipes de clientes. No caso da proposta EVM Object Format (EOF), os desenvolvedores usam essa tag para indicar seu compromisso com a implementação do EOF na próxima atualização, Cancun/Deneb. No entanto, o EOF, bem como várias outras propostas que também foram marcadas como CFI, foram rejeitadas de Cancun/Deneb, e não está claro o status dessas EIPs marcadas como CFI na próxima atualização Praga/Electra.

Beiko disse que, se esse estado não ajudar, os desenvolvedores devem removê-lo, mas se pretendem mantê-lo, os desenvolvedores de CL também devem usar o mesmo rótulo em alterações de código que consideram implementar em atualizações de CL. Não é claro em que medida o processo de revisão da PEI CL reflete o processo de revisão da PEI da PEI e se devem evoluir da mesma forma no futuro. Normalmente, as alterações de código propostas para a especificação CL são discutidas na teleconferência ACDC, enquanto as EIPs propostas para a especificação EL são discutidas na chamada de conferência ACDE.

Danno Ferrin, da Swirlds Labs, também teve a ideia de criar um campo de espaço reservado para todas as EIPs, sejam elas relacionadas a CL ou EL, que identifique seu status durante o processo de revisão, incluindo o status de CFI. Não houve uma decisão clara sobre o tema do estatuto da PEI e dos rótulos do TPI no presente convite.