Em 11 de janeiro, todos os principais desenvolvedores do Ethereum participaram da 125ª teleconferência do All Core Developers Consensus (ACDC).
Escrito por: Christine Kim
Compilado por: Luccy, BlockBeats
Nota do Editor: A Chamada de Consenso de Todos os Desenvolvedores Principais (ACDC) do Ethereum é realizada a cada duas semanas para discutir e coordenar mudanças na Camada de Consenso (CL) do Ethereum. Esta é a 125ª teleconferência do ACDC. A conferência forneceu uma breve atualização sobre a situação de teste da próxima atualização Cancun/Deneb e envolveu dois tópicos de pesquisa, como a transformação da especificação Beacon API e a otimização da sub-rede de certificação da camada de consenso.
A equipe de teste lançou o terceiro e último shadow fork da testnet Goerli em 11 de janeiro para se preparar para a atualização Cancun/Deneb que será ativada em 17 de janeiro. Ao mesmo tempo, os desenvolvedores discutiram a especificação de seleção do fork e tomaram a decisão de lançar um fork de consenso de forma assíncrona próximo à ativação da rede principal de Cancún/Deneb. Além disso, o desenvolvedor Lodestar "Dapplion" compartilhou o progresso mais recente no mapeamento de especificação SSZ para JSON de roteamento de API de beacon e discutiu pequenas mudanças relacionadas às sub-redes de afirmação de longevidade (attnets).
Christine Kim, vice-presidente de pesquisa da Galaxy Digital, registrou detalhadamente os pontos-chave desta reunião. BlockBeasts compilou o texto original da seguinte forma:
Em 11 de janeiro de 2024, os desenvolvedores Ethereum se reuniram no Zoom para participar da reunião nº 125 do All Core Developers Consensus (ACDC). A chamada ACDC é uma série quinzenal de reuniões organizadas pelo pesquisador da Fundação Ethereum Danny Ryan, onde os desenvolvedores discutem e coordenam mudanças na Camada de Consenso Ethereum (CL). Esta semana, os desenvolvedores apresentaram brevemente o progresso dos testes de atualização de Cancun/Deneb e discutiram dois tópicos de pesquisa, ou seja, a conversão da especificação da API Beacon para o modo OpenAPI e a otimização da sub-rede de atestado CL aproveitando os prefixos de ID do nó.
Cancún/Deneb Goerli Shadow Fork
A equipe de testes da Fundação Ethereum lançou um shadow fork da testnet Goerli em 11 de janeiro. Esta é a terceira e última bifurcação sombria de Goerli antes de Cancun/Deneb ser ativado em Goerli em 17 de janeiro. As versões finais do cliente de todas as atualizações do Goerli são testadas no Goerli Shadow Fork (GSF) #2. Parithosh Jayanthi, engenheiro DevOps da Fundação Ethereum, observou que a análise inicial do GSF#2 é positiva, dizendo: “Blobs e blocos parecem estar se espalhando suavemente”. Mais detalhes podem ser encontrados em uma postagem do blog publicada pela Fundação Ethereum em 10 de janeiro.
Alterações no filtro de seleção de garfo
Conforme discutido em ACDC #114 e ACDC #115, há algumas pequenas alterações na especificação de seleção de garfo CL, e espera-se que as equipes do cliente implementem gradualmente essas mudanças de maneira assíncrona perto da ativação da rede principal de Cancun/Deneb. Mikhail Kalinin, da equipe de contas da Teku, explicou: “Anteriormente, decidimos implementar gradualmente essa mudança no Deneb e fazê-lo de uma forma vagamente coordenada.” Portanto, essas mudanças deveriam basicamente ser habilitadas na versão mainnet. Kalinin sugeriu que as equipes dos clientes podem começar a mesclar essas alterações em seus lançamentos nas próximas semanas ou optar por aguardar um limite de bifurcação de época, como a época de ativação de Cancun/Deneb, para acionar essas alterações após um carimbo de data/hora específico. tempo em todos os clientes. Para obter mais detalhes sobre as alterações de filtragem de seleção de bifurcação, leia esta solicitação pull (PR) do GitHub.
Os desenvolvedores concordaram por unanimidade em mesclar essas alterações o mais rápido possível, sem ter que esperar ou coordenar os limites da época, mostrando a confiança da equipe do cliente em ser capaz de incorporar rapidamente as alterações em seu próximo lançamento.
Definição do tipo OpenAPI da API Beacon
O desenvolvedor Lodestar “Dapplion” compartilhou o mapeamento canônico SSZ para JSON de todas as rotas de API de beacon concluídas nesta semana. Os benefícios deste mapeamento incluem a simplificação do código. “O código é muito mais conciso e parece muito mais claro”, disse Dapplion. "Por enquanto, isso não é muito importante, mas para futuras bifurcações isso deve aliviar muita manutenção e, se necessário no futuro, poderíamos facilmente converter tudo para SSZ. Essa ideia já existe há algum tempo. Tempo, isso vai tornar esse processo muito fácil." Para obter informações básicas sobre as discussões de coordenação da SSZ, leia a transcrição da chamada ACDE #153.
Dapplion perguntou aos desenvolvedores o que eles achavam de migrar do OpenAPI para o SSZ como o próximo passo. Nenhuma oposição significativa foi ouvida. Dapplion disse que se comunicará com as equipes relevantes sobre as mudanças nas especificações listadas na solicitação pull (PR) e garantirá uma transição tranquila.
Modifique o cálculo da sub-rede de prova
Os desenvolvedores também discutiram pequenas mudanças nas attnets, sub-redes de atestado de longo prazo dos nós. Attnets são as redes às quais os operadores de nós de piquetagem se conectam ao publicar provas de blocos. Os desenvolvedores melhoraram os attnets pela última vez em maio de 2023. Para otimizar ainda mais as attnets, o desenvolvedor do Lighthouse, Age Manning, propôs melhorar o uso de prefixos de ID de nó para ajudar na descoberta de nós na sub-rede, ou nas palavras de Manning, "procurar o prefixo para encontrar todos os nós na sub-rede". poderia ter na rede e os vetores de ataque relacionados ao uso de prefixos de ID de nó para localizar nós são brevemente discutidos. Ryan disse que as mudanças propostas por Manning exigiriam um hard fork de qualquer maneira. Ele pediu a Pop Chunhapanya, um dos desenvolvedores da teleconferência, que investigasse estratégias para implementar a proposta de Manning e coletasse feedback sobre este tópico de outros desenvolvedores em PRs.
Discussão Electra
Finalmente, Ryan abriu sugestões para mudanças de código ou Propostas de Melhoria Ethereum (EIPs) a serem priorizadas na próxima atualização pós-Deneb (codinome Electra). Ryan disse que conduziria uma “conversa mais estruturada” sobre o assunto na próxima teleconferência do ACDC em duas semanas. Enquanto isso, Ryan incentivou os desenvolvedores a verificar os EIPs propostos no Ethereum Magicians e no GitHub e compartilhar suas idéias nesses fóruns.
Ansgar Dietrichs, pesquisador da Fundação Ethereum, disse que, em sua opinião, a Amostragem de Disponibilidade de Dados (DAS) é uma atualização de “maior prioridade” com foco na camada de consenso. 「 [DAS] Em grande medida, tendo recursos que normalmente fariam parte de um EIP, mas apenas por causa da forma como estruturamos o 4844, ele realmente não requer um hard fork ou um EIP adicional, e acho que o risco que vem com isso é que pode não haver a mesma visibilidade", disse Dietrichs. Ryan contestou este comentário, dizendo que, em sua opinião, o DAS será incluído no EIP porque a mudança estaria naturalmente ligada às discussões sobre a modificação dos limites de gás de dados do Ethereum. Para obter mais informações sobre o que é DAS e como ele é implementado em outras blockchains, como Celestia, leia este relatório da Galaxy Research.
Ryan mencionou que existe um PR preliminar para o DAS e que um número EIP formal será proposto dentro de duas semanas. Ryan incentivou as equipes de contas presentes na teleconferência a considerar quais deveriam ser suas prioridades na Electra durante a próxima teleconferência do ACDC em 25 de janeiro.
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: conversão de especificação da API Beacon, otimização da sub-rede à prova de CL
Escrito por: Christine Kim
Compilado por: Luccy, BlockBeats
Nota do Editor: A Chamada de Consenso de Todos os Desenvolvedores Principais (ACDC) do Ethereum é realizada a cada duas semanas para discutir e coordenar mudanças na Camada de Consenso (CL) do Ethereum. Esta é a 125ª teleconferência do ACDC. A conferência forneceu uma breve atualização sobre a situação de teste da próxima atualização Cancun/Deneb e envolveu dois tópicos de pesquisa, como a transformação da especificação Beacon API e a otimização da sub-rede de certificação da camada de consenso.
A equipe de teste lançou o terceiro e último shadow fork da testnet Goerli em 11 de janeiro para se preparar para a atualização Cancun/Deneb que será ativada em 17 de janeiro. Ao mesmo tempo, os desenvolvedores discutiram a especificação de seleção do fork e tomaram a decisão de lançar um fork de consenso de forma assíncrona próximo à ativação da rede principal de Cancún/Deneb. Além disso, o desenvolvedor Lodestar "Dapplion" compartilhou o progresso mais recente no mapeamento de especificação SSZ para JSON de roteamento de API de beacon e discutiu pequenas mudanças relacionadas às sub-redes de afirmação de longevidade (attnets).
Christine Kim, vice-presidente de pesquisa da Galaxy Digital, registrou detalhadamente os pontos-chave desta reunião. BlockBeasts compilou o texto original da seguinte forma:
Em 11 de janeiro de 2024, os desenvolvedores Ethereum se reuniram no Zoom para participar da reunião nº 125 do All Core Developers Consensus (ACDC). A chamada ACDC é uma série quinzenal de reuniões organizadas pelo pesquisador da Fundação Ethereum Danny Ryan, onde os desenvolvedores discutem e coordenam mudanças na Camada de Consenso Ethereum (CL). Esta semana, os desenvolvedores apresentaram brevemente o progresso dos testes de atualização de Cancun/Deneb e discutiram dois tópicos de pesquisa, ou seja, a conversão da especificação da API Beacon para o modo OpenAPI e a otimização da sub-rede de atestado CL aproveitando os prefixos de ID do nó.
Cancún/Deneb Goerli Shadow Fork
A equipe de testes da Fundação Ethereum lançou um shadow fork da testnet Goerli em 11 de janeiro. Esta é a terceira e última bifurcação sombria de Goerli antes de Cancun/Deneb ser ativado em Goerli em 17 de janeiro. As versões finais do cliente de todas as atualizações do Goerli são testadas no Goerli Shadow Fork (GSF) #2. Parithosh Jayanthi, engenheiro DevOps da Fundação Ethereum, observou que a análise inicial do GSF#2 é positiva, dizendo: “Blobs e blocos parecem estar se espalhando suavemente”. Mais detalhes podem ser encontrados em uma postagem do blog publicada pela Fundação Ethereum em 10 de janeiro.
Alterações no filtro de seleção de garfo
Conforme discutido em ACDC #114 e ACDC #115, há algumas pequenas alterações na especificação de seleção de garfo CL, e espera-se que as equipes do cliente implementem gradualmente essas mudanças de maneira assíncrona perto da ativação da rede principal de Cancun/Deneb. Mikhail Kalinin, da equipe de contas da Teku, explicou: “Anteriormente, decidimos implementar gradualmente essa mudança no Deneb e fazê-lo de uma forma vagamente coordenada.” Portanto, essas mudanças deveriam basicamente ser habilitadas na versão mainnet. Kalinin sugeriu que as equipes dos clientes podem começar a mesclar essas alterações em seus lançamentos nas próximas semanas ou optar por aguardar um limite de bifurcação de época, como a época de ativação de Cancun/Deneb, para acionar essas alterações após um carimbo de data/hora específico. tempo em todos os clientes. Para obter mais detalhes sobre as alterações de filtragem de seleção de bifurcação, leia esta solicitação pull (PR) do GitHub.
Os desenvolvedores concordaram por unanimidade em mesclar essas alterações o mais rápido possível, sem ter que esperar ou coordenar os limites da época, mostrando a confiança da equipe do cliente em ser capaz de incorporar rapidamente as alterações em seu próximo lançamento.
Definição do tipo OpenAPI da API Beacon
O desenvolvedor Lodestar “Dapplion” compartilhou o mapeamento canônico SSZ para JSON de todas as rotas de API de beacon concluídas nesta semana. Os benefícios deste mapeamento incluem a simplificação do código. “O código é muito mais conciso e parece muito mais claro”, disse Dapplion. "Por enquanto, isso não é muito importante, mas para futuras bifurcações isso deve aliviar muita manutenção e, se necessário no futuro, poderíamos facilmente converter tudo para SSZ. Essa ideia já existe há algum tempo. Tempo, isso vai tornar esse processo muito fácil." Para obter informações básicas sobre as discussões de coordenação da SSZ, leia a transcrição da chamada ACDE #153.
Dapplion perguntou aos desenvolvedores o que eles achavam de migrar do OpenAPI para o SSZ como o próximo passo. Nenhuma oposição significativa foi ouvida. Dapplion disse que se comunicará com as equipes relevantes sobre as mudanças nas especificações listadas na solicitação pull (PR) e garantirá uma transição tranquila.
Modifique o cálculo da sub-rede de prova
Os desenvolvedores também discutiram pequenas mudanças nas attnets, sub-redes de atestado de longo prazo dos nós. Attnets são as redes às quais os operadores de nós de piquetagem se conectam ao publicar provas de blocos. Os desenvolvedores melhoraram os attnets pela última vez em maio de 2023. Para otimizar ainda mais as attnets, o desenvolvedor do Lighthouse, Age Manning, propôs melhorar o uso de prefixos de ID de nó para ajudar na descoberta de nós na sub-rede, ou nas palavras de Manning, "procurar o prefixo para encontrar todos os nós na sub-rede". poderia ter na rede e os vetores de ataque relacionados ao uso de prefixos de ID de nó para localizar nós são brevemente discutidos. Ryan disse que as mudanças propostas por Manning exigiriam um hard fork de qualquer maneira. Ele pediu a Pop Chunhapanya, um dos desenvolvedores da teleconferência, que investigasse estratégias para implementar a proposta de Manning e coletasse feedback sobre este tópico de outros desenvolvedores em PRs.
Discussão Electra
Finalmente, Ryan abriu sugestões para mudanças de código ou Propostas de Melhoria Ethereum (EIPs) a serem priorizadas na próxima atualização pós-Deneb (codinome Electra). Ryan disse que conduziria uma “conversa mais estruturada” sobre o assunto na próxima teleconferência do ACDC em duas semanas. Enquanto isso, Ryan incentivou os desenvolvedores a verificar os EIPs propostos no Ethereum Magicians e no GitHub e compartilhar suas idéias nesses fóruns.
Ansgar Dietrichs, pesquisador da Fundação Ethereum, disse que, em sua opinião, a Amostragem de Disponibilidade de Dados (DAS) é uma atualização de “maior prioridade” com foco na camada de consenso. 「 [DAS] Em grande medida, tendo recursos que normalmente fariam parte de um EIP, mas apenas por causa da forma como estruturamos o 4844, ele realmente não requer um hard fork ou um EIP adicional, e acho que o risco que vem com isso é que pode não haver a mesma visibilidade", disse Dietrichs. Ryan contestou este comentário, dizendo que, em sua opinião, o DAS será incluído no EIP porque a mudança estaria naturalmente ligada às discussões sobre a modificação dos limites de gás de dados do Ethereum. Para obter mais informações sobre o que é DAS e como ele é implementado em outras blockchains, como Celestia, leia este relatório da Galaxy Research.
Ryan mencionou que existe um PR preliminar para o DAS e que um número EIP formal será proposto dentro de duas semanas. Ryan incentivou as equipes de contas presentes na teleconferência a considerar quais deveriam ser suas prioridades na Electra durante a próxima teleconferência do ACDC em 25 de janeiro.