Em 31 de agosto, os desenvolvedores do Ethereum se reuniram no Zoom para a teleconferência Core Developers (ACDE). Moderada por Tim Beiko da Fundação Ethereum, a teleconferência ACDE é uma série quinzenal onde a equipe do cliente Ethereum discute e coordena mudanças na camada de execução Ethereum (EL). Esta semana, os desenvolvedores discutiram o progresso do desenvolvimento e dos testes em:
Atualização Cancún/Deneb (Dencun)
Conversão Verkle Trie
Atualização de serialização SSZ
1. Atualização em Cancún
Devnet #8 foi lançado há duas semanas, em 16 de agosto. Barnabas Busa, engenheiro DevOps da Fundação Ethereum, disse que a rede de teste de atualização de Cancun focada no desenvolvedor parece estar funcionando bem. Busa mencionou que parece haver alguns problemas com os nós que executam o software cliente Nethermind (EL). Lukasz Rozmej, desenvolvedor do cliente Nethermind, explicou que a natureza do problema se devia a uma configuração incorreta na implementação do pool de transações Blob. (Nota do tradutor: Devnet 8 é a primeira rede de teste dedicada, que contém todos os EIPs finalizados para a atualização Cancún/Deneb)
Em relação ao EIP 4788, os desenvolvedores reconfirmaram brevemente a nova estratégia de implantação para alterações de código. Os contratos que expõem dados da cadeia de beacon no EL serão implantados como contratos inteligentes regulares, que exigem que alguém financie o endereço do contrato antes que a atualização seja ativada. Devnet #9, o próximo testnet para a atualização de Cancún, adotará esse fluxo de trabalho e garantirá que os desenvolvedores estejam familiarizados com ele.
Em vez de atrasar a data de lançamento do Devnet #9, os desenvolvedores concordaram em continuar testando no Devnet #8 até que todos os problemas com a implementação do cliente fossem resolvidos. "Prefiro estar confiante no Devnet #9 do que dizer que esperamos que essas coisas funcionem. ... Prefiro resolver problemas que conhecemos. Caso contrário, se tivermos problemas difíceis no Devnet #9, então definitivamente iremos termos o Devnet #10 novamente, não estou dizendo que não deveríamos ter o Devnet #10. Deveríamos ter um número significativo de devnets. Acho que agora podemos tentar tornar o Devnet #9 realmente confiável." Ether disse Danny Ryan, colega na Fundação Fang e presidente da teleconferência do ACDC.
Outros participantes da teleconferência, incluindo Tim Beiko, Marius Van Der Wijden e Justin Florentine, foram a favor de passar mais tempo testando no Devnet #8 e testando as mudanças no EIP 4788 no Devnet #9 posteriormente. Beiko sugeriu que os desenvolvedores se reunissem novamente para o Devnet #9 durante a próxima teleconferência da ACDE. Em relação à estratégia de implantação da testnet, a Beiko recomenda a seguinte sequência:
Devnet #9: Outro Devnet cuja especificação Dencun foi congelada. Faça um teste de estresse na rede e presuma que os desenvolvedores estão satisfeitos com ela, depois mude para uma rede de teste pública. Caso contrário, inicie o Devnet #10.
Holesky: bifurque a rede de teste Holeksy recém-lançada e implante a atualização Dencun nela.
Goerli: Em seguida, implante Dencun em Goerli. Como o penúltimo lançamento da rede de teste antes da rede principal, as especificações de atualização neste momento devem ser definitivas e fornecer aos usuários e aplicativos tempo suficiente para testar seu software antes que a atualização da rede principal seja ativada. É provável que Dencun seja a última bifurcação de Goerli antes que Goerli seja descontinuado e substituído por Holesky. (Nota do tradutor: A palavra Dencun é uma palavra composta composta por Cancun (Cancun) e Deneb. Cancun é o nome desta atualização da camada de execução Ethereum, e Deneb é o nome da atualização da camada de protocolo. Portanto, a atualização de Cancun está relacionada a Deneb As atualizações são chamadas coletivamente de atualizações Dencun.)
Sepolia: Finalmente, Dencun foi implantado em Sepolia para obter bons resultados.
Ninguém levantou objeções à proposta de Beiko de lançar uma testnet após o Devnet #9. Beiko mencionou que o cronograma acima será compartilhado com a comunidade Ethereum mais ampla em uma postagem no blog assim que a testnet Holesky for lançada oficialmente em 15 de setembro. Além disso, Beiko disse que também há uma rede de teste chamada Ephemery em desenvolvimento. Ehemery é uma rede de teste Ethereum para operadores de nós de verificação que retornará ao estado de gênese após uma semana ou duas. Para obter mais informações sobre a Ephemery Network, leia a página GitHub do projeto aqui.
Antes de prosseguir para discutir Verkle Tries, Busa destacou uma solicitação pull aberta (PR) no GitHub para a testnet Holesky. A pedido da equipa Erigon (EL), o PR propõe remover o tempo de ativação específico para a atualização Dencun em Holesky. Posteriormente, o desenvolvedor definirá um valor para ativação do Dencun no Holesky, em vez de substituir o valor existente. Busa também perguntou sobre como testar o alvo/máximo de 3/6 blob em vez do limite de 2/4. Sobre este tópico, Beiko sugeriu levantar a questão novamente na teleconferência do ACDC da próxima semana, com Ryan mencionando que experimentos recentes com blocos grandes trarão novos insights.
2. Conversão Verkle Trie
Em seguida, os desenvolvedores discutiram a proposta de Vitalik Buterin de combinar os roteiros Verkle Trie e State Expiry para reduzir a complexidade da implementação do Verkle Trie e acelerar os benefícios do State Expiry no Ethereum. Como pano de fundo, Verkle Trie ou Verkle Tree é uma estrutura de dados que permite aos usuários verificar facilmente grandes quantidades de dados, contando com uma única prova criptográfica. Eles não são diferentes do Merkle Patricia Trie (MPT), que é uma estrutura de dados usada para armazenar o estado Ethereum. No entanto, a eficiência de prova das árvores Verkle é relativamente maior do que a do MPT, e é por isso que os desenvolvedores têm trabalhado na transição do MPT para o Verkle.
A expiração do estado é um programa separado projetado para resolver o problema do crescimento ilimitado do estado. O objetivo da expiração do estado é reduzir o tamanho do estado de mais de 100 GB para menos de 50 GB, removendo partes do estado Ethereum que o usuário não acessou dentro de um determinado período de tempo (por exemplo, 365 dias). Andrew Ashikhmin, da equipe de contas da Erigon (EL), preferiu agrupar as duas atualizações, presumindo que as conversões do Verkle Trie seriam bastante simplificadas se combinadas com o State Expiry. Guillaume Ballet, da equipe do cliente Geth (EL), que tem liderado o projeto Verkle Trie, está preocupado com o fato de o acoplamento atrasar Verkle Tries, já que a expiração do estado, pois um tópico de pesquisa foi "abandonado" nos últimos dois anos.
Buterin entrou na conversa com mais informações sobre as motivações de sua proposta, dizendo: “Com [Verkle] O processo de transição, o problema é basicamente converter mais de 50 GB de Merkle Patricia Trie para... Verkle Trie em uma rede ativa é bastante complicado. Na verdade, isso é algo contra o qual a equipe de pesquisa vem lutando há mais de um ano. Lembro-me do ano passado no Devconnect, foi basicamente o tema de um evento de pesquisa e basicamente tanto trabalho de P&D quanto todo o resto do roteiro da Verkle reunido, apenas o processo de como fazer a última transição. De certa forma, a sua complexidade rivaliza com a das fusões. "
Buterin descreveu como o State Expiry reduz significativamente a complexidade da transição para Verkle. No entanto, ele também mencionou que a expiração do estado tem pré-requisitos complexos, como a necessidade de adicionar mais espaço de endereço para suportar novos "períodos de endereço" todos os anos. Portanto, embora a complexidade da implementação do Verkle diminua, os desenvolvedores ainda precisam Resolver o quebra-cabeça é necessário para Além disso, se o Verkle Tries for implementado antes do State Expiry, o State Expiry terá menos urgência, então os desenvolvedores devem considerar o uso do Verkle para a transição ou esperar alguns anos para que o State Expiry seja introduzido após o Verkle. não está claro sobre o valor adicional que resultaria do agrupamento dessas duas atualizações e concordou em continuar discutindo o tópico de forma assíncrona no Discord e Verkle Trie Implementors' Call.
3. Serialização SSZ
Em seguida, Etan Kissling, desenvolvedor do cliente Nimbus (CL), apresentou seu mais recente progresso na atualização das estruturas de dados Ethereum para o formato de serialização SSZ. Para obter mais informações sobre esse assunto, leia a transcrição de uma chamada anterior do desenvolvedor Ethereum aqui. Kissling destacou uma nova abordagem para atualizar a serialização de dados Ethereum usando um formato baseado em SSZ “PartialContainer”. Em comentários na agenda da teleconferência desta semana, Kissling escreveu: "Este [formato] combina essencialmente todas as vantagens [do formato anterior] e também pode ser reutilizado para outros fins, eliminando assim a União SSZ atualmente não utilizada e o tipo opcional SSZ. "(Nota do tradutor: Serialização Simples (SSZ) é o método de serialização usado na cadeia de beacon. Este método substitui a camada de implementação usada em todos os lugares da camada de consenso, exceto o protocolo de descoberta de pares. Serialização recursiva de prefixo de comprimento. O design de serialização simples é determinístico e também pode ser eficientemente Merkleizado.)
Após a atualização, Beiko elogiou rapidamente a implementação de referência EL recém-criada em Python (chamada EELS). Em uma postagem recente no blog da Fundação Ethereum, o editor do EIP e pesquisador da Fundação Ethereum, Sam Wilson, escreveu: "EELS é uma implementação de referência Python dos principais componentes do cliente de execução Ethereum, com foco na legibilidade e clareza. O EELS foi projetado para ser um sucessor espiritual do o Yellow Paper, mais fácil de programar e em sincronia com bifurcações pós-fusão, o EELS pode preencher e executar testes com estado, aderir à rede principal e é um ótimo lugar para criar protótipos de novos EIPs.”
Alguns desenvolvedores já estão usando EELS para reimplementar seus EIPs, e a Fundação Ethereum tem uma doação para qualquer pessoa interessada em atualizar o documento amarelo para incluir atualizações de rede pré-fundidas ausentes, como Londres e Paris, para complementar o EELS.
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 116ª reunião executiva de desenvolvedores principais da Ethereum: atualização de Cancun, conversão Verkle Trie e serialização SSZ
Autor: Christine Kim / Fonte:
Tradução: Huohuo/Blockchain em vernáculo
Em 31 de agosto, os desenvolvedores do Ethereum se reuniram no Zoom para a teleconferência Core Developers (ACDE). Moderada por Tim Beiko da Fundação Ethereum, a teleconferência ACDE é uma série quinzenal onde a equipe do cliente Ethereum discute e coordena mudanças na camada de execução Ethereum (EL). Esta semana, os desenvolvedores discutiram o progresso do desenvolvimento e dos testes em:
Atualização Cancún/Deneb (Dencun)
Conversão Verkle Trie
Atualização de serialização SSZ
1. Atualização em Cancún
Devnet #8 foi lançado há duas semanas, em 16 de agosto. Barnabas Busa, engenheiro DevOps da Fundação Ethereum, disse que a rede de teste de atualização de Cancun focada no desenvolvedor parece estar funcionando bem. Busa mencionou que parece haver alguns problemas com os nós que executam o software cliente Nethermind (EL). Lukasz Rozmej, desenvolvedor do cliente Nethermind, explicou que a natureza do problema se devia a uma configuração incorreta na implementação do pool de transações Blob. (Nota do tradutor: Devnet 8 é a primeira rede de teste dedicada, que contém todos os EIPs finalizados para a atualização Cancún/Deneb)
Em relação ao EIP 4788, os desenvolvedores reconfirmaram brevemente a nova estratégia de implantação para alterações de código. Os contratos que expõem dados da cadeia de beacon no EL serão implantados como contratos inteligentes regulares, que exigem que alguém financie o endereço do contrato antes que a atualização seja ativada. Devnet #9, o próximo testnet para a atualização de Cancún, adotará esse fluxo de trabalho e garantirá que os desenvolvedores estejam familiarizados com ele.
Em vez de atrasar a data de lançamento do Devnet #9, os desenvolvedores concordaram em continuar testando no Devnet #8 até que todos os problemas com a implementação do cliente fossem resolvidos. "Prefiro estar confiante no Devnet #9 do que dizer que esperamos que essas coisas funcionem. ... Prefiro resolver problemas que conhecemos. Caso contrário, se tivermos problemas difíceis no Devnet #9, então definitivamente iremos termos o Devnet #10 novamente, não estou dizendo que não deveríamos ter o Devnet #10. Deveríamos ter um número significativo de devnets. Acho que agora podemos tentar tornar o Devnet #9 realmente confiável." Ether disse Danny Ryan, colega na Fundação Fang e presidente da teleconferência do ACDC.
Outros participantes da teleconferência, incluindo Tim Beiko, Marius Van Der Wijden e Justin Florentine, foram a favor de passar mais tempo testando no Devnet #8 e testando as mudanças no EIP 4788 no Devnet #9 posteriormente. Beiko sugeriu que os desenvolvedores se reunissem novamente para o Devnet #9 durante a próxima teleconferência da ACDE. Em relação à estratégia de implantação da testnet, a Beiko recomenda a seguinte sequência:
Devnet #9: Outro Devnet cuja especificação Dencun foi congelada. Faça um teste de estresse na rede e presuma que os desenvolvedores estão satisfeitos com ela, depois mude para uma rede de teste pública. Caso contrário, inicie o Devnet #10.
Holesky: bifurque a rede de teste Holeksy recém-lançada e implante a atualização Dencun nela.
Goerli: Em seguida, implante Dencun em Goerli. Como o penúltimo lançamento da rede de teste antes da rede principal, as especificações de atualização neste momento devem ser definitivas e fornecer aos usuários e aplicativos tempo suficiente para testar seu software antes que a atualização da rede principal seja ativada. É provável que Dencun seja a última bifurcação de Goerli antes que Goerli seja descontinuado e substituído por Holesky. (Nota do tradutor: A palavra Dencun é uma palavra composta composta por Cancun (Cancun) e Deneb. Cancun é o nome desta atualização da camada de execução Ethereum, e Deneb é o nome da atualização da camada de protocolo. Portanto, a atualização de Cancun está relacionada a Deneb As atualizações são chamadas coletivamente de atualizações Dencun.)
Sepolia: Finalmente, Dencun foi implantado em Sepolia para obter bons resultados.
Ninguém levantou objeções à proposta de Beiko de lançar uma testnet após o Devnet #9. Beiko mencionou que o cronograma acima será compartilhado com a comunidade Ethereum mais ampla em uma postagem no blog assim que a testnet Holesky for lançada oficialmente em 15 de setembro. Além disso, Beiko disse que também há uma rede de teste chamada Ephemery em desenvolvimento. Ehemery é uma rede de teste Ethereum para operadores de nós de verificação que retornará ao estado de gênese após uma semana ou duas. Para obter mais informações sobre a Ephemery Network, leia a página GitHub do projeto aqui.
Antes de prosseguir para discutir Verkle Tries, Busa destacou uma solicitação pull aberta (PR) no GitHub para a testnet Holesky. A pedido da equipa Erigon (EL), o PR propõe remover o tempo de ativação específico para a atualização Dencun em Holesky. Posteriormente, o desenvolvedor definirá um valor para ativação do Dencun no Holesky, em vez de substituir o valor existente. Busa também perguntou sobre como testar o alvo/máximo de 3/6 blob em vez do limite de 2/4. Sobre este tópico, Beiko sugeriu levantar a questão novamente na teleconferência do ACDC da próxima semana, com Ryan mencionando que experimentos recentes com blocos grandes trarão novos insights.
2. Conversão Verkle Trie
Em seguida, os desenvolvedores discutiram a proposta de Vitalik Buterin de combinar os roteiros Verkle Trie e State Expiry para reduzir a complexidade da implementação do Verkle Trie e acelerar os benefícios do State Expiry no Ethereum. Como pano de fundo, Verkle Trie ou Verkle Tree é uma estrutura de dados que permite aos usuários verificar facilmente grandes quantidades de dados, contando com uma única prova criptográfica. Eles não são diferentes do Merkle Patricia Trie (MPT), que é uma estrutura de dados usada para armazenar o estado Ethereum. No entanto, a eficiência de prova das árvores Verkle é relativamente maior do que a do MPT, e é por isso que os desenvolvedores têm trabalhado na transição do MPT para o Verkle.
A expiração do estado é um programa separado projetado para resolver o problema do crescimento ilimitado do estado. O objetivo da expiração do estado é reduzir o tamanho do estado de mais de 100 GB para menos de 50 GB, removendo partes do estado Ethereum que o usuário não acessou dentro de um determinado período de tempo (por exemplo, 365 dias). Andrew Ashikhmin, da equipe de contas da Erigon (EL), preferiu agrupar as duas atualizações, presumindo que as conversões do Verkle Trie seriam bastante simplificadas se combinadas com o State Expiry. Guillaume Ballet, da equipe do cliente Geth (EL), que tem liderado o projeto Verkle Trie, está preocupado com o fato de o acoplamento atrasar Verkle Tries, já que a expiração do estado, pois um tópico de pesquisa foi "abandonado" nos últimos dois anos.
Buterin entrou na conversa com mais informações sobre as motivações de sua proposta, dizendo: “Com [Verkle] O processo de transição, o problema é basicamente converter mais de 50 GB de Merkle Patricia Trie para... Verkle Trie em uma rede ativa é bastante complicado. Na verdade, isso é algo contra o qual a equipe de pesquisa vem lutando há mais de um ano. Lembro-me do ano passado no Devconnect, foi basicamente o tema de um evento de pesquisa e basicamente tanto trabalho de P&D quanto todo o resto do roteiro da Verkle reunido, apenas o processo de como fazer a última transição. De certa forma, a sua complexidade rivaliza com a das fusões. "
Buterin descreveu como o State Expiry reduz significativamente a complexidade da transição para Verkle. No entanto, ele também mencionou que a expiração do estado tem pré-requisitos complexos, como a necessidade de adicionar mais espaço de endereço para suportar novos "períodos de endereço" todos os anos. Portanto, embora a complexidade da implementação do Verkle diminua, os desenvolvedores ainda precisam Resolver o quebra-cabeça é necessário para Além disso, se o Verkle Tries for implementado antes do State Expiry, o State Expiry terá menos urgência, então os desenvolvedores devem considerar o uso do Verkle para a transição ou esperar alguns anos para que o State Expiry seja introduzido após o Verkle. não está claro sobre o valor adicional que resultaria do agrupamento dessas duas atualizações e concordou em continuar discutindo o tópico de forma assíncrona no Discord e Verkle Trie Implementors' Call.
3. Serialização SSZ
Em seguida, Etan Kissling, desenvolvedor do cliente Nimbus (CL), apresentou seu mais recente progresso na atualização das estruturas de dados Ethereum para o formato de serialização SSZ. Para obter mais informações sobre esse assunto, leia a transcrição de uma chamada anterior do desenvolvedor Ethereum aqui. Kissling destacou uma nova abordagem para atualizar a serialização de dados Ethereum usando um formato baseado em SSZ “PartialContainer”. Em comentários na agenda da teleconferência desta semana, Kissling escreveu: "Este [formato] combina essencialmente todas as vantagens [do formato anterior] e também pode ser reutilizado para outros fins, eliminando assim a União SSZ atualmente não utilizada e o tipo opcional SSZ. "(Nota do tradutor: Serialização Simples (SSZ) é o método de serialização usado na cadeia de beacon. Este método substitui a camada de implementação usada em todos os lugares da camada de consenso, exceto o protocolo de descoberta de pares. Serialização recursiva de prefixo de comprimento. O design de serialização simples é determinístico e também pode ser eficientemente Merkleizado.)
Após a atualização, Beiko elogiou rapidamente a implementação de referência EL recém-criada em Python (chamada EELS). Em uma postagem recente no blog da Fundação Ethereum, o editor do EIP e pesquisador da Fundação Ethereum, Sam Wilson, escreveu: "EELS é uma implementação de referência Python dos principais componentes do cliente de execução Ethereum, com foco na legibilidade e clareza. O EELS foi projetado para ser um sucessor espiritual do o Yellow Paper, mais fácil de programar e em sincronia com bifurcações pós-fusão, o EELS pode preencher e executar testes com estado, aderir à rede principal e é um ótimo lugar para criar protótipos de novos EIPs.”
Alguns desenvolvedores já estão usando EELS para reimplementar seus EIPs, e a Fundação Ethereum tem uma doação para qualquer pessoa interessada em atualizar o documento amarelo para incluir atualizações de rede pré-fundidas ausentes, como Londres e Paris, para complementar o EELS.