Autor: Christine Kim, galáxia; Tradução: Huohuo/Blockchain em vernáculo
Em 31 de agosto, os desenvolvedores do Ethereum se reuniram no Zoom para uma teleconferência do Core Developers ution (ACDE). Organizada por Tim Beiko da Fundação Ethereum, a chamada ACDE é uma série quinzenal de reuniões 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 parecia haver alguns problemas com os nós que executam o software cliente Nethermind (EL). O desenvolvedor do cliente Nethermind, Lukasz Rozmej, explicou que a essência do problema se devia a uma configuração incorreta na implementação do pool de transações do blob. **(Nota do tradutor: Devnet 8 é a primeira testnet 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 os testes no Devnet #8 até que todos os problemas com a implementação do cliente sejam resolvidos. "Prefiro ter confiança no Devnet #9 do que dizer que queremos que essas coisas funcionem. ... Prefiro consertar problemas que conhecemos. Caso contrário, se tivermos um problema difícil 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 alterações no EIP 4788 na Devnet #8 e posteriormente na Devnet #9 *. Beiko sugeriu um momento para os desenvolvedores se reunirem novamente no Devnet #9 durante a próxima teleconferência da ACDE. Em relação às estratégias de implantação da testnet, a Beiko recomenda a seguinte sequência:
Devnet #9: Mais um Devnet cuja especificação Dencun está congelada. Faça um teste de estresse na rede e presuma que os desenvolvedores estão satisfeitos com ela, depois passe para a 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, atualização de Cancun Combinado com a atualização Deneb é conhecida como atualização 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 mencionado será compartilhado com a comunidade Ethereum em geral 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.
** State Expiration é 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 por 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 que no ano passado no Devconnect, foi basicamente o tema da atividade de pesquisa, basicamente tanto trabalho de P&D reunido quanto todo o resto do roteiro de Verkle, exatamente como estava indo a última transição. De certa forma, a sua complexidade rivaliza com a das fusões. "
Buterin continua explicando como o State Expiry reduz significativamente a complexidade da transição para Verkle. No entanto, ele também mencionou que existem pré-requisitos complexos para a expiração do estado, 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 seja reduzida, os desenvolvedores ainda precisam para resolver o quebra-cabeça para fazer as duas coisas. Além disso, se 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 fazer a transição ou esperar alguns anos antes que o Verkle Then State Expiry seja introduzido. Os desenvolvedores não estavam claros sobre o valor adicional que resultaria do agrupamento das duas atualizações e concordaram em continuar discutindo o tópico de forma assíncrona no Discord e na Chamada dos Implementadores Verkle Trie.
3. Serialização SSZ
Em seguida, Etan Kissling, desenvolvedor do cliente Nimbus (CL), apresentou uma atualização sobre seu 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". Kissling escreveu em comentários na agenda da teleconferência desta semana, "Este [formato] combina essencialmente todas as vantagens do [formato anterior] e também pode ser reutilizado para outros fins, eliminando os tipos opcionais SSZ Union e SSZ atualmente não utilizados ." (Nota do tradutor: Serialização Simples (SSZ) é o método de serialização usado na cadeia de beacon. Este método substitui todos os aspectos da camada de consenso, exceto o protocolo de descoberta de pares. Serialização recursiva de prefixo de comprimento usada na camada de execução. Serialização simples é determinístico por design e também pode ser efetivamente 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 Ethereum Foundation, o editor EIP e pesquisador da Ethereum Foundation Sam Wilson escreveu: "EELS é a implementação de referência Python dos principais componentes do cliente de execução Ethereum, com foco na legibilidade e clareza. EELS pretende ser um sucessor espiritual ao Yellow Paper, mais amigável ao programador e em sincronia com bifurcações pós-fusão, o EELS pode preencher e executar testes de estado, seguir a rede principal e é um ótimo lugar para criar protótipos de novos EIPs."
Alguns desenvolvedores já estão usando o EELS para reimplementar seus EIPs, e a Fundação Ethereum está oferecendo uma doação a qualquer pessoa interessada em atualizar o Livro 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 última reunião executiva de desenvolvedores principais da Ethereum
Autor: Christine Kim, galáxia; Tradução: Huohuo/Blockchain em vernáculo
Em 31 de agosto, os desenvolvedores do Ethereum se reuniram no Zoom para uma teleconferência do Core Developers ution (ACDE). Organizada por Tim Beiko da Fundação Ethereum, a chamada ACDE é uma série quinzenal de reuniões 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 parecia haver alguns problemas com os nós que executam o software cliente Nethermind (EL). O desenvolvedor do cliente Nethermind, Lukasz Rozmej, explicou que a essência do problema se devia a uma configuração incorreta na implementação do pool de transações do blob. **(Nota do tradutor: Devnet 8 é a primeira testnet 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 os testes no Devnet #8 até que todos os problemas com a implementação do cliente sejam resolvidos. "Prefiro ter confiança no Devnet #9 do que dizer que queremos que essas coisas funcionem. ... Prefiro consertar problemas que conhecemos. Caso contrário, se tivermos um problema difícil 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 alterações no EIP 4788 na Devnet #8 e posteriormente na Devnet #9 *. Beiko sugeriu um momento para os desenvolvedores se reunirem novamente no Devnet #9 durante a próxima teleconferência da ACDE. Em relação às estratégias de implantação da testnet, a Beiko recomenda a seguinte sequência:
Devnet #9: Mais um Devnet cuja especificação Dencun está congelada. Faça um teste de estresse na rede e presuma que os desenvolvedores estão satisfeitos com ela, depois passe para a 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, atualização de Cancun Combinado com a atualização Deneb é conhecida como atualização 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 mencionado será compartilhado com a comunidade Ethereum em geral 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.
** State Expiration é 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 por 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 que no ano passado no Devconnect, foi basicamente o tema da atividade de pesquisa, basicamente tanto trabalho de P&D reunido quanto todo o resto do roteiro de Verkle, exatamente como estava indo a última transição. De certa forma, a sua complexidade rivaliza com a das fusões. "
Buterin continua explicando como o State Expiry reduz significativamente a complexidade da transição para Verkle. No entanto, ele também mencionou que existem pré-requisitos complexos para a expiração do estado, 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 seja reduzida, os desenvolvedores ainda precisam para resolver o quebra-cabeça para fazer as duas coisas. Além disso, se 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 fazer a transição ou esperar alguns anos antes que o Verkle Then State Expiry seja introduzido. Os desenvolvedores não estavam claros sobre o valor adicional que resultaria do agrupamento das duas atualizações e concordaram em continuar discutindo o tópico de forma assíncrona no Discord e na Chamada dos Implementadores Verkle Trie.
3. Serialização SSZ
Em seguida, Etan Kissling, desenvolvedor do cliente Nimbus (CL), apresentou uma atualização sobre seu 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". Kissling escreveu em comentários na agenda da teleconferência desta semana, "Este [formato] combina essencialmente todas as vantagens do [formato anterior] e também pode ser reutilizado para outros fins, eliminando os tipos opcionais SSZ Union e SSZ atualmente não utilizados ." (Nota do tradutor: Serialização Simples (SSZ) é o método de serialização usado na cadeia de beacon. Este método substitui todos os aspectos da camada de consenso, exceto o protocolo de descoberta de pares. Serialização recursiva de prefixo de comprimento usada na camada de execução. Serialização simples é determinístico por design e também pode ser efetivamente 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 Ethereum Foundation, o editor EIP e pesquisador da Ethereum Foundation Sam Wilson escreveu: "EELS é a implementação de referência Python dos principais componentes do cliente de execução Ethereum, com foco na legibilidade e clareza. EELS pretende ser um sucessor espiritual ao Yellow Paper, mais amigável ao programador e em sincronia com bifurcações pós-fusão, o EELS pode preencher e executar testes de estado, seguir a rede principal e é um ótimo lugar para criar protótipos de novos EIPs."
Alguns desenvolvedores já estão usando o EELS para reimplementar seus EIPs, e a Fundação Ethereum está oferecendo uma doação a qualquer pessoa interessada em atualizar o Livro Amarelo para incluir atualizações de rede pré-fundidas ausentes, como Londres e Paris, para complementar o EELS.