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 135ª teleconferência do ACDC. Esta conferência se concentra principalmente na preparação da rede de teste de Propostas de Melhoria Ethereum (EIPs) PeerDAS Devnet 1 e Simple Serialize (SSZ).
Os desenvolvedores tiveram discussões aprofundadas sobre questões como manutenção de pacotes de software, processos de inclusão de EIP e nomeação da nova rodada de atualizações da camada de consenso Ethereum. Além disso, a sessão abordou o progresso da implementação sob a especificação Electra, o impacto das mudanças na rede PeerDAS em como os nós Ethereum processam e validam dados e as complexas questões de engenharia que envolvem o aumento dos limites de gás blob.
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 13 de junho de 2024, os desenvolvedores do Ethereum se reuniram no Zoom para a reunião da chamada nº 135 do All Core Developers Consensus (ACDC). A chamada ACDC é uma série quinzenal apresentada pelo pesquisador da Fundação Ethereum, Alex Stokes, onde os desenvolvedores discutem e coordenam mudanças na Camada de Consenso Ethereum (CL, também conhecida como Beacon Chain). Esta semana, os desenvolvedores discutiram os preparativos para Pectra Devnet 1, PeerDAS Devnet 1 e uma terceira rede de teste dedicada para Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).
anúncio
Os desenvolvedores iniciaram a reunião com dois anúncios. O engenheiro de DevOps da Ethereum Foundation, Parithosh Jayanthi, disse que a equipe ethPandaOps, um grupo de engenheiros que trabalham no Ethereum Foundation DevOps (EF DevOps), assumirá a manutenção e o desenvolvimento do módulo Kurtosis do pacote Ethereum. Este pacote foi usado por desenvolvedores no passado para lançar redes de teste Ethereum e ferramentas relacionadas, como o painel de dados Grafana para monitorar e testar várias implementações de clientes. A migração deste pacote da equipe técnica Kurtosis para a equipe ethPandaOps pode impactar os usuários, pois alguns links redirecionarão para repositórios GitHub gerenciados pela equipe ethPandaOps e não mais pela equipe Kurtosis. Jayanthi aconselha os usuários a atualizarem seus links de software e ficarem atentos aos novos lançamentos da equipe ethPandaOps.
O segundo anúncio foi feito por Tim Beiko, Chefe de Suporte de Protocolo da Fundação Ethereum. Beiko disse que está trabalhando na introdução de um novo processo para incluir EIPs nas atualizações do Ethereum em fases. Ele criou um projeto de EIP que define os rótulos “Proposto para Inclusão”, “Considerado para Inclusão” e “Programado para Inclusão”. Ele espera que os desenvolvedores revisem o documento e forneçam feedback. Ele esperava ter o documento concluído antes da próxima reunião da ACD.
Eletra
As especificações de código para a próxima versão principal do Electra, v1.5.0-alpha.3, estão quase completas. Os desenvolvedores concordaram em mesclar a solicitação pull (PR)#3768no repositório GitHub de especificação de consenso na próxima versão. A solicitação pull foi criada pelo desenvolvedor do Nimbus, Etan Kissling, que apontou que o campo “committee_bits” deveria ser anexado ao final do “Atestado” e não no meio dos dados para evitar problemas de serialização de dados. Além do PR #3768, Stokes perguntou se há algum outro problema em aberto que precise ser resolvido antes do lançamento da próxima versão principal da especificação Electra. Jayanthi mencionou no chat do Zoom que existem alguns problemas pendentes com a integração de validadores acionados por meio da camada de execução (EL). Stokes anotou o acompanhamento do status da integração do validador acionado por EL após a reunião.
Em relação ao progresso da implementação da especificação Electra mais recente, a maioria das equipes de clientes da camada de consenso (CL) presentes na reunião afirmaram que poderão ter a nova versão pronta para teste dentro de uma a duas semanas após a v1.5.0-alpha.3 está finalizado. Os desenvolvedores concordaram em revisitar o cronograma da próxima rede de desenvolvimento Pectra, Pectra Devnet 1, em algumas semanas.
PeerDAS
A seguir, os desenvolvedores discutiram o progresso da implementação do PeerDAS. PeerDAS é uma melhoria de rede para Ethereum que aumentará a capacidade dos nós de processar e verificar grandes quantidades de dados arbitrários enviados por usuários por meio de transações blob. Stokes lembrou a decisão tomada na última reunião do ACDC de que os desenvolvedores desenvolveriam PeerDAS em paralelo com outros EIPs Pectra, ativando um ciclo de ativação separado para PeerDAS na rede de desenvolvimento.
O desenvolvedor do Lodestar, Gajinder Singh, disse que, com base nas discussões em uma sessão recente sobre PeerDAS, os desenvolvedores ativarão o PeerDAS além da atualização do Deneb e em uma rede de desenvolvimento separada de outros EIPs Pectra. O desenvolvedor do Teku, Enrico Del Fante, disse que seria mais fácil para os desenvolvedores construir o PeerDAS nas especificações de código estável já estabelecidas na atualização anterior do Ethereum, Deneb, em vez das especificações de código Pectra em constante mudança. Jayanthi concordou que a fusão da implementação PeerDAS com outras implementações PeerDAS EIP agora poderia causar complicações durante os testes, especialmente ao tentar identificar a origem dos erros. Ele sugeriu manter os dois fluxos de trabalho separados e depois mesclá-los quando suas implementações estiverem mais estáveis. Stokes concordou, dizendo que os desenvolvedores poderiam revisitar a fusão do PeerDAS e outras implementações do PeerDAS EIP em cerca de um mês.
Sobre o lançamento do PeerDAS Devnet 1, a equipe do cliente não tem uma estimativa clara de quando o testnet estará pronto para lançamento. As estimativas individuais nas sessões variaram aproximadamente de 2 semanas a 1 mês. Stokes sugeriu rever o cronograma de desenvolvimento da rede em algumas semanas, quando a equipe do cliente tiver mais tempo para trabalhar na implementação do PeerDAS.
Beiko então apontou que, embora o PeerDAS seja uma melhoria da rede e não uma mudança no protocolo Ethereum principal, ele ainda deseja que as alterações no código sejam incluídas no meta-EIP para a atualização do Pectra. O documento meta-EIP é um documento público que lista todas as principais alterações do protocolo incluídas na atualização do Ethereum. Beiko apontou que PeerDAS é o “maior recurso” do Pectra e, embora não exija uma ativação de hard fork, ainda deve ser incluído na documentação para mostrar que os desenvolvedores levam a sério a ideia de tê-lo pronto a tempo para a ativação da rede principal do Pectra. Nenhuma objeção a isso.
Aumentar o limite de gás blob
PeerDAS muda a forma como os nós processam e propagam dados através da camada de rede peer-to-peer Ethereum. Para que os usuários, especialmente os rollups da Camada 2, se beneficiem dessas mudanças, os desenvolvedores devem aumentar o limite atual de seis blobs por bloco para um limite mais alto, o que permitirá uma taxa de transferência de blob (dados arbitrários) mais alta. Alterar o limite de blob exigiria alterações no protocolo principal do Ethereum, que, como os desenvolvedores discutiram em uma conferência esta semana, pode envolver um trabalho de engenharia mais complexo do que simplesmente ajustar um valor constante na pilha de protocolos.
Stokes propôs dissociar as dependências entre a camada de execução (EL) e a camada de consenso (CL) ao alterar os limites do gás do blob. Atualmente, quaisquer alterações nos limites de blob gas exigem alterações nos protocolos EL e CL. Stokes propôs maneiras de quebrar essas dependências, permitindo que os desenvolvedores removessem com segurança os limites de gás de blob codificados do EL e os deixassem inteiramente para o CL. O pesquisador da Fundação Ethereum (EF), Dankrad Feist, apontou que, além do problema de dependência entre EL e CL, o efeito indireto da alteração do limite de gás do blob no cálculo do gás do bloco também é importante. “A melhor abordagem é mudar a forma como é calculado”, disse Feist. “É provavelmente um erro que o cálculo do preço do gás aconteça em EL. Isso deveria ser em CL, mas é mais difícil de mudar agora. "
Os desenvolvedores concordaram em continuar investigando a melhor maneira de fazer alterações nos limites de gás de blob e nos cálculos de gás em blocos. Os desenvolvedores também concordaram em continuar as discussões sobre se a ativação do PeerDAS no Pectra seria acompanhada por um aumento no limite de gás do blob. Os desenvolvedores estão divididos sobre se as mudanças devem ser implementadas em conjunto ou implementadas em etapas em vários hard forks.
Jayanthi disse que incorporar essas mudanças foi uma decisão “arriscada” porque os desenvolvedores não saberão exatamente como o PeerDAS funcionará até que seja ativado na rede principal. O engenheiro DevOps da Ethereum Foundation (EF), Barnabas Busa, acrescentou que o escopo do hard fork Pectra já é muito grande e não requer alterações adicionais no código. “A chave é que já temos muitos EIPs e sinto que continuamos adicionando mais e isso nunca acaba”, disse Busa. “Então, temos que traçar uma linha em algum lugar e é aí que terminamos. possível lançar PeerDAS e aumentar o número de blobs durante o próximo ano e meio de testes."
Um desenvolvedor cujo nome de tela é “Francesco” sugeriu que se as mudanças na rede não forem acompanhadas por um aumento no número de blobs, o PeerDAS pode ser removido para “reduzir o risco de Pectra”. Francesco perguntou: “Qual é exatamente o benefício do PeerDAS da Pectra se não aumentar o número de blobs?”
Para ilustrar ainda mais a dificuldade de testar o PeerDAS, Jayanthi apontou que o teste do EIP 4844, que introduziu blobs no Ethereum, não simulou totalmente o desempenho real e o impacto dos blobs na rede principal do Ethereum. Jayanthi disse: “O problema é que é muito difícil testar a rede. Tivemos muitos testes excelentes relacionados ao 4844, mas os blobs não tiveram o mesmo desempenho na rede principal como nos testes que vimos. surgem nós mais fracos Pergunta. Vemos desafios de tempo e coisas assim, e é por isso que, embora possamos simular uma situação perfeita na rede de desenvolvimento onde o PeerDAS e o aumento do número de blobs funcionam, isso não tem nenhuma implicação prática para. the mainnet Ou seja, esta é a principal razão pela qual acho que deveríamos fazer isso passo a passo, em vez de fazer tudo de uma vez.”
O pesquisador da EF, Ansgar Dietrichs, comentou que é um erro associar o aumento da contagem de blob ao PeerDAS, uma vez que o PeerDAS por si só já exige que os desenvolvedores escolham um valor de contagem de blob. Embora os desenvolvedores possam escolher o mesmo número da rede principal Ethereum, uma decisão deve ser tomada sobre qual número o PeerDAS deve usar. A única razão para escolher o mesmo número é que os desenvolvedores aumentaram a complexidade do PeerDAS para permitir que ele voltasse ao mecanismo de propagação de blob na especificação Deneb atual no caso de um erro. Dietrichs acrescentou que as preocupações com a complexidade dos testes reforçam ainda mais sua visão de que o Pectra deve ser ativado por meio de dois hard forks em vez de um, mas isso não significa que ele acha que o PeerDAS deva ser dissociado das alterações na contagem de blob.
Atualização SSZ
Kissling compartilhou uma atualização de progresso em três EIPs relacionados a SSZ. Ele observou que a implementação desses EIPs já está em andamento em vários clientes, incluindo Teku, Grandine e Lighthouse. Os desenvolvedores podem começar a discutir o cronograma da rede de desenvolvimento para esses EIPs SSZ e possivelmente incluí-los no escopo da atualização do Pectra na próxima reunião do ACDC, disse ele.
Nomeação F-Star
Há uma postagem no Ethereum Magicians discutindo o nome da próxima atualização da camada de consenso (CL) do Ethereum após Electra. Os desenvolvedores decidiram um nome para a atualização da camada executiva (EL) após Praga: Osaka. Os nomes candidatos à atualização de CL são: Fulu, Felis, Formosa e Funi. Esses nomes seguem a principal convenção de nomenclatura de estrelas começando com "F" e são adequados para a sexta atualização de toda a rede do Beacon Chain. Stokes pediu aos desenvolvedores da teleconferência que opinassem sobre o assunto no tópico Magicians.