Em 30 de novembro de 2023, os desenvolvedores do Ethereum se reuniram no Zoom para a reunião #122 do All Core Developers Consensus (ACDC). A teleconferência ACDC é uma série quinzenal de reuniões moderadas pelo pesquisador da Fundação Ethereum Danny Ryan, onde os desenvolvedores discutem e coordenam mudanças na camada de consenso (CL) do Ethereum. Esta semana, os desenvolvedores se concentraram nos últimos desenvolvimentos nos testes de Cancun/Deneb, incluindo:
· Lançamento do Devnet #12: Os testes do software cliente Teku, Lodestar e Lighthouse no Devnet #12, bem como de todo o software cliente da camada de execução (EL), 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 de processo levantadas por Tim Beiko, Chefe de Suporte de Protocolo da Fundação Ethereum, para melhorar a coordenação da atualização do Ethereum.
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 Ethereum, disse que "nenhum grande problema 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 um desenvolvedor saiu 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ó.
"Quero dizer 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 seja mais automatizado, seja usando Hive, Kurtosis ou o que for. Acho que certamente seria útil se esses problemas pudessem ser resolvidos ou as coisas pudessem ser divididas bem o suficiente para poder incorporar mais dessas tarefas", acrescentou Dustin, acrescentando que outro desafio que os desenvolvedores de CL devem considerar abordar é descobrir o nível de detalhe que 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 passam em testes que verificam o comportamento básico, mas o comportamento fora do escopo desses testes é ambíguo. "São coisas deliberadamente vagas? o que deve ser realmente claro pela norma 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 construir tal ferramenta usando uma mistura de suítes de teste Hive e Kurtosis.
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 essa ferramenta funcione, Jayanthi pediu aos desenvolvedores que compartilhassem detalhes de bugs conhecidos que desencadearam reorganizações de cadeia no Ethereum. 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.
Clarificação das especificações da rede
Os desenvolvedores discutiram brevemente uma solicitação de pull aberta proposta pelo pesquisador da Fundação Ethereum Justin Traglia 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 Ethereum 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 especificações 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 blocos 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 afete 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. Beiko disse que uma postagem no blog alertando os usuários do testnet Goerli sobre a depreciação iminente dentro de 3 meses após a atualização Cancun/Deneb ser ativada no Goerli, ou 1 mês após a atualização ser ativada na rede principal Ethereum, o que for posterior, será publicada no blog da Fundação Ethereum em 30 de novembro. Desde a conclusão da chamada, o post acima foi publicado e pode ser lido aqui.
Beiko sugere a criação de uma pasta específica de atualização sob o repositório Ethereum "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 é sobre a criação de um documento "Meta EIP" para rastrear todo o escopo de atualizações de rede que foram concluídas no Ethereum. "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, usam "formatos" diferentes e levam à duplicação. Como o ERC e os EIPs agora estão separados, recomendo (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 redigir um documento para a revisão da atualização de Cancun/Deneb esta semana.
Finalmente, Beiko levantou uma questão sobre a utilidade de marcar as mudanças de código propostas, Ethereum Improvement Proposals (EIPs), como "Considere a inclusão" (CFI). De acordo com Beiko, o CFI é um status que os desenvolvedores historicamente usam como um "sinal suave", indicando que os autores do EIP devem continuar a trabalhar 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, a rotulagem das ICF pouco ou nada fez para indicar quais as EIP da EL que serão 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, a EOF, bem como várias outras propostas que também são assinaladas como IFC, foram rejeitadas em Cancún/Deneb, e não é claro o estatuto destas EIP assinaladas como IFC 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. Nesta chamada, não houve uma decisão clara sobre o tema do estatuto da PEI e da rotulagem do TPI.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Resumo da última reunião de desenvolvedores principais do Ethereum: Devnet #12启动, processo de planejamento de atualização
Em 30 de novembro de 2023, os desenvolvedores do Ethereum se reuniram no Zoom para a reunião #122 do All Core Developers Consensus (ACDC). A teleconferência ACDC é uma série quinzenal de reuniões moderadas pelo pesquisador da Fundação Ethereum Danny Ryan, onde os desenvolvedores discutem e coordenam mudanças na camada de consenso (CL) do Ethereum. Esta semana, os desenvolvedores se concentraram nos últimos desenvolvimentos nos testes de Cancun/Deneb, incluindo:
· Lançamento do Devnet #12: Os testes do software cliente Teku, Lodestar e Lighthouse no Devnet #12, bem como de todo o software cliente da camada de execução (EL), 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 de processo levantadas por Tim Beiko, Chefe de Suporte de Protocolo da Fundação Ethereum, para melhorar a coordenação da atualização do Ethereum.
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 Ethereum, disse que "nenhum grande problema 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 um desenvolvedor saiu 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ó.
"Quero dizer 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 seja mais automatizado, seja usando Hive, Kurtosis ou o que for. Acho que certamente seria útil se esses problemas pudessem ser resolvidos ou as coisas pudessem ser divididas bem o suficiente para poder incorporar mais dessas tarefas", acrescentou Dustin, acrescentando que outro desafio que os desenvolvedores de CL devem considerar abordar é descobrir o nível de detalhe que 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 passam em testes que verificam o comportamento básico, mas o comportamento fora do escopo desses testes é ambíguo. "São coisas deliberadamente vagas? o que deve ser realmente claro pela norma 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 construir tal ferramenta usando uma mistura de suítes de teste Hive e Kurtosis.
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 essa ferramenta funcione, Jayanthi pediu aos desenvolvedores que compartilhassem detalhes de bugs conhecidos que desencadearam reorganizações de cadeia no Ethereum. 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.
Clarificação das especificações da rede
Os desenvolvedores discutiram brevemente uma solicitação de pull aberta proposta pelo pesquisador da Fundação Ethereum Justin Traglia 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 Ethereum 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 especificações 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 blocos 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 afete 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. Beiko disse que uma postagem no blog alertando os usuários do testnet Goerli sobre a depreciação iminente dentro de 3 meses após a atualização Cancun/Deneb ser ativada no Goerli, ou 1 mês após a atualização ser ativada na rede principal Ethereum, o que for posterior, será publicada no blog da Fundação Ethereum em 30 de novembro. Desde a conclusão da chamada, o post acima foi publicado e pode ser lido aqui.
Beiko sugere a criação de uma pasta específica de atualização sob o repositório Ethereum "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 é sobre a criação de um documento "Meta EIP" para rastrear todo o escopo de atualizações de rede que foram concluídas no Ethereum. "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, usam "formatos" diferentes e levam à duplicação. Como o ERC e os EIPs agora estão separados, recomendo (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 redigir um documento para a revisão da atualização de Cancun/Deneb esta semana.
Finalmente, Beiko levantou uma questão sobre a utilidade de marcar as mudanças de código propostas, Ethereum Improvement Proposals (EIPs), como "Considere a inclusão" (CFI). De acordo com Beiko, o CFI é um status que os desenvolvedores historicamente usam como um "sinal suave", indicando que os autores do EIP devem continuar a trabalhar 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, a rotulagem das ICF pouco ou nada fez para indicar quais as EIP da EL que serão 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, a EOF, bem como várias outras propostas que também são assinaladas como IFC, foram rejeitadas em Cancún/Deneb, e não é claro o estatuto destas EIP assinaladas como IFC 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. Nesta chamada, não houve uma decisão clara sobre o tema do estatuto da PEI e da rotulagem do TPI.