Outra reunião @ethereum #AllCoreDevs foi concluída em 15 de setembro: foram discutidas atualizações na rede de desenvolvimento, adições ao Dencun e uma visão geral abrangente de Reth!
Agenda: Link ao vivo:
Abaixo está um resumo do encontro de @TimBeiko.
1. Atualização de status do Devnet-8
Primeiro, uma atualização de status no devnet-8: a rede está em desenvolvimento final e muitos clientes já enviaram novas atualizações para ela. Enquanto isso, começamos a testar o processo de construção de MEV/bloco usando @KurtosisTech. @NethermindEth afirmou que seu pool de transações de blob agora está pronto e após alguns dias de testes em um único nó, eles o implantaram em todos os nós de teste Dencun.
O pool de transações blob do Geth também está quase completo. Besu está fazendo grandes melhorias em seu pool de transações (limitando o tamanho total de transações blob e não blob) que deverão ser lançadas em seu próximo lançamento. A Erigon continua a melhorar seu pool de transações e espera estar pronta para o devnet-9. Prysm também observa que há alguma latência no recebimento de sidecars de blob, que, segundo eles, normalmente chegam com um atraso de cerca de 500 milissegundos após o bloco (enquanto o bloco leva cerca de 15 milissegundos para ser processado).
Eles estão investigando esse problema para determinar se ele pode ser causado por uma condição de corrida entre importações de blob e pedaços. Em relação à questão de permitir o suporte para transações de blob no pool de memória antes do hard fork, a equipe concordou por unanimidade em não fazê-lo.
##2、EIP-7514
Em seguida, continuamos a discussão da ligação do ACDC da semana passada sobre a possibilidade de adicionar um limite constante à fila de ativação do validador. Esta proposta foi formalmente formada como EIP-7514. Em suma, isto irá desacelerar o crescimento percentual do staking de ETH no pior cenário. Dankrad expressou apoio à proposta durante a teleconferência, dizendo que nos daria tempo para fazer mudanças potencialmente mais complexas nas recompensas dos validadores.
Todas as equipes do CL são a favor desta mudança, com a ressalva de que isso se aplica apenas à fila de depósitos e não à fila de saques. Depois de mais discussão, decidimos definir o limite para 8. Portanto, o EIP-7514 fará parte da atualização do Dencun! Espera-se que nos próximos dias, o EIP e a especificação PR relacionada ao CL sejam atualizados para refletir essa mudança.
3. EVM e Blob
A seguir, discutimos outra proposta provisória: adicionar um opcode à Máquina Virtual Ethereum (EVM) para expor as taxas básicas do blob. Esta proposta foi apresentada por @PlasmaPower0 da Arbitrum, que disse no R&D Discord no início desta semana que seria útil para eles (e outras soluções da Camada 2). Já temos um opcode semelhante que expõe o BASEFEE no EIP-1559, que foi introduzido ao mesmo tempo que o EIP foi ativado. Isso torna mais fácil para as soluções da Camada 2 determinar o preço correto do gás a ser cobrado dos usuários com base nos custos de dados L1.
@protolambda do Optimism também participou da reunião e sugeriu que esta não é a única maneira de obter a taxa base do blob para L2, pois eles podem olhar o cabeçalho do bloco (que contém os valores usados para calcular a taxa base do blob) e fornecer Merkle contra esses valores provam. Ainda assim, ele concorda que é um recurso interessante. Atualmente, o Arbitrum não realiza análise de cabeçalho de bloco e confiar nisso pode ser problemático para soluções imutáveis da Camada 2, pois isso pode causar problemas se o formato do cabeçalho do bloco acabar mudando.
Um dos autores do EIP-4844, @adietrichs, mencionou que esse opcode não foi incluído na especificação original porque havia o desejo de desenvolver uma maneira mais geral de acessar as informações do cabeçalho do bloco (em vez de adicionar um opcode único). Ainda assim, adotar esta mudança mais ambiciosa seria uma tarefa mais ambiciosa do que introduzir este opcode.
A informação exposta por este opcode já é o que o cliente EL precisa calcular e semanticamente é quase idêntica ao opcode BASEFEE. A equipe do cliente concordou por unanimidade que deveríamos adicionar este opcode, mesmo que apenas para ser consistente com o BASEFEE. Se no futuro criarmos um mecanismo "slicker", qualquer funcionalidade redundante neste novo opcode também se tornará um problema para outros opcodes que usam informações de cabeçalho de bloco. Além disso, vale a pena enfatizar que esta é uma mudança tão pequena: @vdWijden a implementou em Geth antes da existência do EIP, e levou apenas cerca de 20 minutos, e a equipe Reth cometeu uma mudança sobre isso durante a chamada ACD PR.
4、EIP-4788
A seguir, discutimos algumas atualizações do EIP-4788, uma proposta para armazenar raízes de farol em contratos na cadeia principal Ethereum. Nas últimas semanas, conduzimos diversas auditorias e testes fuzz do contrato, que resultaram em algumas pequenas alterações descritas neste PR. Embora nem todas as auditorias tenham sido concluídas e os relatórios ainda não tenham sido publicados, @lightclients deu uma visão geral das mudanças consideradas até agora. A primeira mudança é lidar explicitamente com carimbos de data/hora 0 para que eles causem uma reversão (assim como outros carimbos de data/hora inválidos) em vez de retornar 0. A segunda mudança diz respeito ao tamanho do buffer. Supondo que o horário do slot mude, o contrato original resultará em desperdício de armazenamento devido à forma como a aritmética modular funciona.
5. Otimização de gás
Por fim, existe uma otimização de gás que reduz o número de vezes que CALLDATA é carregado. Os auditores irão analisar estas alterações e esperamos ter o seu relatório final antes da próxima reunião da ACDE. Para manter o andamento dos testes fuzz e do trabalho de implementação, concordamos em mesclar as alterações propostas agora.
@shemnon também mencionou que essas mudanças devem ser documentadas no EIP real - estamos trabalhando nisso! A seguir, discutimos como os clientes devem lidar com isso se o endereço do contrato do sistema fizer parte do estado, mas estiver vazio no final da execução. Embora seja improvável que isso aconteça na rede principal (pelo que entendi!), Este é um caso extremo que ocorreu no teste ao definir o endereço no bloco genesis.
Dado que este é um caso extremo bastante especial e não há um comportamento canônico claro, concordamos em passar mais tempo pensando sobre esta questão e continuar a discussão na reunião de teste da próxima semana. Isso é tudo sobre as mudanças nas especificações! Todos os itens acima estão planejados para inclusão no devnet-9. A equipe do cliente concorda que tudo deve ser implementado e testado antes do ACDC da próxima semana. Nessa teleconferência, chegaremos a um acordo sobre uma data de lançamento para o devnet-9.
O próximo ACDE está programado para ser realizado no dia 28 de setembro, às 14h, horário UTC. Até então, siga @terencechain para um resumo da reunião de teste, @benjaminion_xyz para informações sobre a reunião do ACDC e @christine_dkim para uma cobertura mais detalhada de todo o evento.
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.
EIP-7514 fará parte da atualização Ethereum Dencun
Autor: @TimBeiko Tradução: Huohuo/Vernacular Blockchain
Outra reunião @ethereum #AllCoreDevs foi concluída em 15 de setembro: foram discutidas atualizações na rede de desenvolvimento, adições ao Dencun e uma visão geral abrangente de Reth!
Agenda: Link ao vivo:
Abaixo está um resumo do encontro de @TimBeiko.
1. Atualização de status do Devnet-8
Primeiro, uma atualização de status no devnet-8: a rede está em desenvolvimento final e muitos clientes já enviaram novas atualizações para ela. Enquanto isso, começamos a testar o processo de construção de MEV/bloco usando @KurtosisTech. @NethermindEth afirmou que seu pool de transações de blob agora está pronto e após alguns dias de testes em um único nó, eles o implantaram em todos os nós de teste Dencun.
O pool de transações blob do Geth também está quase completo. Besu está fazendo grandes melhorias em seu pool de transações (limitando o tamanho total de transações blob e não blob) que deverão ser lançadas em seu próximo lançamento. A Erigon continua a melhorar seu pool de transações e espera estar pronta para o devnet-9. Prysm também observa que há alguma latência no recebimento de sidecars de blob, que, segundo eles, normalmente chegam com um atraso de cerca de 500 milissegundos após o bloco (enquanto o bloco leva cerca de 15 milissegundos para ser processado).
Eles estão investigando esse problema para determinar se ele pode ser causado por uma condição de corrida entre importações de blob e pedaços. Em relação à questão de permitir o suporte para transações de blob no pool de memória antes do hard fork, a equipe concordou por unanimidade em não fazê-lo.
##2、EIP-7514
Em seguida, continuamos a discussão da ligação do ACDC da semana passada sobre a possibilidade de adicionar um limite constante à fila de ativação do validador. Esta proposta foi formalmente formada como EIP-7514. Em suma, isto irá desacelerar o crescimento percentual do staking de ETH no pior cenário. Dankrad expressou apoio à proposta durante a teleconferência, dizendo que nos daria tempo para fazer mudanças potencialmente mais complexas nas recompensas dos validadores.
Todas as equipes do CL são a favor desta mudança, com a ressalva de que isso se aplica apenas à fila de depósitos e não à fila de saques. Depois de mais discussão, decidimos definir o limite para 8. Portanto, o EIP-7514 fará parte da atualização do Dencun! Espera-se que nos próximos dias, o EIP e a especificação PR relacionada ao CL sejam atualizados para refletir essa mudança.
3. EVM e Blob
A seguir, discutimos outra proposta provisória: adicionar um opcode à Máquina Virtual Ethereum (EVM) para expor as taxas básicas do blob. Esta proposta foi apresentada por @PlasmaPower0 da Arbitrum, que disse no R&D Discord no início desta semana que seria útil para eles (e outras soluções da Camada 2). Já temos um opcode semelhante que expõe o BASEFEE no EIP-1559, que foi introduzido ao mesmo tempo que o EIP foi ativado. Isso torna mais fácil para as soluções da Camada 2 determinar o preço correto do gás a ser cobrado dos usuários com base nos custos de dados L1.
@protolambda do Optimism também participou da reunião e sugeriu que esta não é a única maneira de obter a taxa base do blob para L2, pois eles podem olhar o cabeçalho do bloco (que contém os valores usados para calcular a taxa base do blob) e fornecer Merkle contra esses valores provam. Ainda assim, ele concorda que é um recurso interessante. Atualmente, o Arbitrum não realiza análise de cabeçalho de bloco e confiar nisso pode ser problemático para soluções imutáveis da Camada 2, pois isso pode causar problemas se o formato do cabeçalho do bloco acabar mudando.
Um dos autores do EIP-4844, @adietrichs, mencionou que esse opcode não foi incluído na especificação original porque havia o desejo de desenvolver uma maneira mais geral de acessar as informações do cabeçalho do bloco (em vez de adicionar um opcode único). Ainda assim, adotar esta mudança mais ambiciosa seria uma tarefa mais ambiciosa do que introduzir este opcode.
A informação exposta por este opcode já é o que o cliente EL precisa calcular e semanticamente é quase idêntica ao opcode BASEFEE. A equipe do cliente concordou por unanimidade que deveríamos adicionar este opcode, mesmo que apenas para ser consistente com o BASEFEE. Se no futuro criarmos um mecanismo "slicker", qualquer funcionalidade redundante neste novo opcode também se tornará um problema para outros opcodes que usam informações de cabeçalho de bloco. Além disso, vale a pena enfatizar que esta é uma mudança tão pequena: @vdWijden a implementou em Geth antes da existência do EIP, e levou apenas cerca de 20 minutos, e a equipe Reth cometeu uma mudança sobre isso durante a chamada ACD PR.
4、EIP-4788
A seguir, discutimos algumas atualizações do EIP-4788, uma proposta para armazenar raízes de farol em contratos na cadeia principal Ethereum. Nas últimas semanas, conduzimos diversas auditorias e testes fuzz do contrato, que resultaram em algumas pequenas alterações descritas neste PR. Embora nem todas as auditorias tenham sido concluídas e os relatórios ainda não tenham sido publicados, @lightclients deu uma visão geral das mudanças consideradas até agora. A primeira mudança é lidar explicitamente com carimbos de data/hora 0 para que eles causem uma reversão (assim como outros carimbos de data/hora inválidos) em vez de retornar 0. A segunda mudança diz respeito ao tamanho do buffer. Supondo que o horário do slot mude, o contrato original resultará em desperdício de armazenamento devido à forma como a aritmética modular funciona.
5. Otimização de gás
Por fim, existe uma otimização de gás que reduz o número de vezes que CALLDATA é carregado. Os auditores irão analisar estas alterações e esperamos ter o seu relatório final antes da próxima reunião da ACDE. Para manter o andamento dos testes fuzz e do trabalho de implementação, concordamos em mesclar as alterações propostas agora.
@shemnon também mencionou que essas mudanças devem ser documentadas no EIP real - estamos trabalhando nisso! A seguir, discutimos como os clientes devem lidar com isso se o endereço do contrato do sistema fizer parte do estado, mas estiver vazio no final da execução. Embora seja improvável que isso aconteça na rede principal (pelo que entendi!), Este é um caso extremo que ocorreu no teste ao definir o endereço no bloco genesis.
Dado que este é um caso extremo bastante especial e não há um comportamento canônico claro, concordamos em passar mais tempo pensando sobre esta questão e continuar a discussão na reunião de teste da próxima semana. Isso é tudo sobre as mudanças nas especificações! Todos os itens acima estão planejados para inclusão no devnet-9. A equipe do cliente concorda que tudo deve ser implementado e testado antes do ACDC da próxima semana. Nessa teleconferência, chegaremos a um acordo sobre uma data de lançamento para o devnet-9.
O próximo ACDE está programado para ser realizado no dia 28 de setembro, às 14h, horário UTC. Até então, siga @terencechain para um resumo da reunião de teste, @benjaminion_xyz para informações sobre a reunião do ACDC e @christine_dkim para uma cobertura mais detalhada de todo o evento.