Resumo da última reunião dos principais desenvolvedores do Ethereum: Ativar o PeerDAS, aumentar o limite de gás de blob

Por Christine Kim

Compilado por Luccy, BlockBeats

Editor’s note: Todas as duas semanas, os principais desenvolvedores do Ethereum realizam uma teleconferência de consenso (ACDC) para discutir e coordenar as mudanças na camada de consenso do Ethereum (CL). Esta é a 135ª teleconferência do ACDC, focada na preparação das redes de teste Pectra Devnet 1, PeerDAS Devnet 1 e nas Propostas de Melhoria do Ethereum (EIPs) para Simple Serialize (SSZ).

Os desenvolvedores discutiram profundamente questões como a manutenção de pacotes de software, EIP, incluindo processos e nomeação de atualizações de consenso na camada Ethereum. Além disso, a reunião abordou o progresso da implementação sob a especificação Electra, o impacto das alterações de rede do PeerDAS no processamento e verificação de dados dos nós Ethereum, e questões complexas de engenharia relacionadas ao aumento do limite de gás blob.

A vice-presidente de pesquisa da Galaxy Digital, Christine Kim, fez um registro detalhado dos principais pontos da reunião, que a BlockBeasts traduziu como se segue:

Em 13 de junho de 2024, os desenvolvedores do Ethereum se reuniram no Zoom para participar da reunião All Core Developers Consensus (ACDC) Call #135. A ACDC é uma série de reuniões realizadas a cada duas semanas, presidida pelo pesquisador da Fundação Ethereum, Alex Stokes, onde os desenvolvedores discutem e coordenam mudanças na camada de consenso do Ethereum (CL, também conhecida como cadeia beacon). Nesta semana, os desenvolvedores discutiram os preparativos para o Pectra Devnet 1, PeerDAS Devnet 1 e uma terceira rede de teste dedicada para Propostas de Melhoria do Ethereum (EIPs) usando a Simple Serialize (SSZ).

Anúncio

Os desenvolvedores começaram a reunião com dois anúncios. Parithosh Jayanthi, engenheiro de desenvolvimento e operações (DevOps) da Ethereum Foundation, anunciou que a equipe ethPandaOps, um grupo de engenheiros de desenvolvimento e operações (EF DevOps) da Ethereum Foundation, assumirá a manutenção e desenvolvimento do módulo ethereum-package Kurtosis. Este pacote de software foi usado por desenvolvedores no passado para iniciar redes de teste Ethereum e ferramentas relacionadas, como o painel de controle de dados Grafana para monitorar e testar várias implementações de clientes. Durante o processo de migração deste pacote de software da equipe técnica do Kurtosis para a equipe ethPandaOps, pode haver impacto nos usuários, pois alguns links serão redirecionados para o repositório GitHub gerenciado pela equipe ethPandaOps, em vez da equipe Kurtosis. Jayanthi recomenda que os usuários atualizem seus links de software e sigam as novas versões lançadas pela equipe ethPandaOps.

O segundo anúncio é feito com o apoio do protocolo da Fundação Ethereum pelo Diretor de Suporte, Tim Beiko. Beiko afirmou que está trabalhando para introduzir novos processos para incluir gradualmente EIPs nas atualizações do Ethereum. Ele já criou um rascunho do EIP, definindo as etiquetas ‘Proposed for Inclusion’ (Proposto para Inclusão), ‘Considered for Inclusion’ (Considerado para Inclusão) e ‘Scheduled for Inclusion’ (Agendado para Inclusão). Ele espera que os desenvolvedores revisem o documento e forneçam feedback. Ele espera completar este documento antes da próxima reunião do ACD.

Electra

O código de conformidade da próxima versão principal do Electra, v1.5.0-alpha.3, está quase concluído. Os desenvolvedores concordaram em mesclar a solicitação pull (PR) #3768 das especificações de consenso no repositório GitHub para a próxima versão. Essa solicitação pull foi criada pelo desenvolvedor do Nimbus, Etan Kissling, que observou que o campo “committee_bits” deve ser anexado ao final da “Attestation”, em vez de no meio dos dados, para evitar problemas de serialização de dados. Além do PR #3768, Stokes perguntou se há outras questões pendentes que precisam ser resolvidas antes do lançamento da próxima versão principal das especificações do Electra. Jayanthi mencionou no chat do Zoom que existem algumas questões pendentes na integração de validadores acionados pela camada de execução (EL). Stokes registrou os problemas pendentes relacionados à integração de validadores acionados pelo EL para acompanhamento após a reunião.

Sobre o progresso da implementação da mais recente especificação do Electra, a maioria das equipes de clientes de camada de consenso (CL) na reunião afirmou que estariam prontas para testar a nova versão uma ou duas semanas após a confirmação final do v1.5.0-alpha.3. Os desenvolvedores concordaram em discutir novamente o cronograma para o próximo Pectra Devnet 1 em algumas semanas.

PeerDAS

A seguir, os desenvolvedores discutiram o progresso na implementação do PeerDAS. O PeerDAS é uma melhoria de rede do Ethereum que aumentará a capacidade dos nós de processar e validar grandes quantidades de dados arbitrários enviados pelos usuários por meio de transações de blob. Stokes revisou a decisão tomada na última reunião ACDC, na qual os desenvolvedores concordaram em desenvolver o PeerDAS paralelamente a outros Pectra EIPs, ativando-o em um ciclo de ativação separado na rede de desenvolvimento.

O desenvolvedor do Lodestar, Gajinder Singh, afirmou que, com base nas discussões da última reunião do grupo sobre o PeerDAS, os desenvolvedores irão ativar o PeerDAS na rede de desenvolvimento separada dos outros Pectra EIPs e com base na atualização Deneb. O desenvolvedor do Teku, Enrico Del Fante, afirmou que é mais fácil construir o PeerDAS com base nas especificações de código estável identificadas no upgrade Deneb anterior do Ethereum, em vez das especificações de código em constante mudança do Pectra. Jayanthi concordou que implementar o PeerDAS agora junto com a implementação de outros Pectra EIPs pode causar problemas complexos durante o processo de teste, especialmente ao tentar identificar a origem dos erros. Ele sugeriu separar esses dois fluxos de trabalho e, em seguida, combiná-los após a estabilização de ambas as implementações. Stokes concordou e afirmou que os desenvolvedores podem discutir a fusão do PeerDAS e a implementação de outros Pectra EIPs novamente em cerca de um mês.

Em relação ao lançamento do PeerDAS Devnet 1, a equipe do cliente não tem uma estimativa clara de quando estará pronta para iniciar o teste da rede. As estimativas individuais na reunião variaram de aproximadamente 2 semanas a 1 mês. Stokes sugeriu que, após algumas semanas, quando a equipe do cliente tiver mais tempo para implementar o PeerDAS, eles reconsiderem o cronograma de lançamento da rede de desenvolvimento.

Beiko então observou que, embora o PeerDAS seja uma melhoria de rede em vez de uma mudança no protocolo principal do Ethereum, ele ainda quer incluir alterações de código no meta-EIP para a atualização do Pectra. Os documentos do Meta EIP são arquivos públicos que lista todas as principais alterações de protocolo incluídas na atualização Ethereum. Beiko observou que o PeerDAS é o “maior recurso” do Pectra e que, embora não exija uma ativação Hard Fork, ele ainda deve ser incluído na documentação para mostrar que os desenvolvedores estão seriamente preparados para tê-lo pronto a tempo para a ativação do Pectra Rede principal. Não há qualquer objeção a isso.

Aumentar o limite de gás do blob

O PeerDAS está mudando a maneira como os nós lidam e propagam dados na camada de rede peer-to-peer do Ethereum. Para que os usuários, especialmente os rollups da camada 2, se beneficiem dessas mudanças, os desenvolvedores precisam aumentar o limite atual de seis blocos por blob para um limiar mais alto, permitindo maior taxa de transferência de blobs (dados arbitrários). A alteração do limite de blobs requer alterações no protocolo central do Ethereum, como discutido pelos desenvolvedores na reunião desta semana, o que pode envolver um trabalho de engenharia mais complexo do que simplesmente ajustar um valor constante na pilha de tecnologia do protocolo.

Stokes propôs desacoplar a camada de execução (EL) e a camada de consenso (CL) ao alterar as restrições de gas blob. Atualmente, qualquer alteração nas restrições de gas blob requer uma mudança nos protocolos EL e CL. Stokes propõe algumas maneiras de quebrar essas dependências, permitindo que os desenvolvedores com segurança removam as restrições de gas blob codificadas no EL e que sejam totalmente determinadas pelo CL. Dankrad Feist, pesquisador da Ethereum Foundation (EF), aponta que, além do problema de dependência entre EL e CL, é importante considerar as reações em cadeia do cálculo de gas em blocos ao alterar as restrições de gas blob. Feist disse: ‘A melhor maneira é mudar a forma de cálculo. É possível que o cálculo de preço do gas na EL seja um erro. Deveria estar em CL, mas agora é mais difícil mudar. … Isso não é fácil.’

Os desenvolvedores concordaram em continuar a investigar a melhor maneira de alterar as restrições de gás no blob e o cálculo de gás no bloco. Eles também concordaram em continuar discutindo se o aumento das restrições de gás no blob acompanhará a ativação do PeerDAS no Pectra. Os desenvolvedores discordam se essas alterações devem ser combinadas em uma única hard fork ou implementadas em várias fases separadas.

Jayanthi afirmou que combinar essas mudanças é uma decisão ‘arriscada’, pois os desenvolvedores não saberão como o PeerDAS se comportará na rede principal até que seja ativado. Barnabas Busa, engenheiro de DevOps da Ethereum Foundation (EF), acrescentou que o escopo do hard fork Pectra já é bastante amplo e não requer mais alterações de código adicionais. Busa disse: ‘A chave é que já temos muitos EIPs e acho que se continuarmos adicionando mais conteúdo, isso nunca vai acabar. Então, precisamos traçar uma linha em algum lugar, e isso é o nosso fim. Acredito que seja impossível lançar o PeerDAS e aumentar a quantidade de blobs nos próximos 18 meses de tempo de teste.’

Um desenvolvedor de tela chamado ‘Francesco’ sugeriu que, se a mudança de rede não resultar no aumento do número de blobs, o PeerDAS pode ser removido para ‘reduzir o risco do Pectra’. Francesco pergunta: ‘Qual é o benefício do PeerDAS do Pectra se o número de blobs não aumentar?’

Para ilustrar ainda mais as dificuldades do teste PeerDAS, Jayanthi apontou que a introdução de blobs no EIP 4844 do Ethereum não simula completamente o desempenho e o impacto dos blobs na rede principal do Ethereum. Jayanthi disse: ‘O problema é que a rede de testes é muito difícil. Fizemos muitos testes excelentes relacionados ao 4844, mas o desempenho dos blobs na rede principal não é totalmente consistente com o desempenho nos testes. Vimos que os nós mais fracos apresentaram problemas. Vimos desafios de tempo e situações semelhantes, por isso é por isso que mesmo que possamos simular PeerDAS e aumentar o número de blobs funcionando perfeitamente em uma rede de desenvolvimento, isso não tem nenhum significado real para a rede principal, e é a principal razão pela qual acredito que devemos fazer isso passo a passo em vez de fazê-lo de uma vez.’

O pesquisador EF Ansgar Dietrichs comentou que associar o aumento do número de blobs ao PeerDAS é um erro, pois o PeerDAS já exige que os desenvolvedores escolham um valor numérico para os blobs. Embora os desenvolvedores possam optar pelo mesmo número utilizado na rede principal do Ethereum, a decisão sobre qual número o PeerDAS deve usar deve ser feita. A única razão para escolher o mesmo número é aumentar a complexidade do PeerDAS, permitindo que ele volte ao mecanismo de propagação de blobs definido na especificação atual do Deneb em caso de erro. Dietrichs acrescentou que as preocupações com a complexidade dos testes reforçam sua visão de que o Pectra deve ser ativado por meio de duas bifurcações rígidas, em vez de apenas uma, mas isso não significa que ele acredite que o PeerDAS deva ser separado das alterações no número de blobs.

Atualização SSZ

Kissling partilhou atualizações sobre o progresso de três EIPs relacionados com SSZ. Ele indicou que o trabalho de implementação desses EIPs já está em andamento em vários clientes, incluindo Teku, Grandine e Lighthouse. Ele afirmou que os desenvolvedores podem começar a discutir o cronograma de lançamento desses EIPs SSZ na rede de desenvolvimento e possivelmente incluí-los no âmbito da atualização Pectra na próxima reunião ACDC.

F-Star 命名

Há um post no Ethereum Magicians discutindo o nome da próxima atualização da camada de consenso (CL) após Electra. Os desenvolvedores já determinaram o nome da atualização da camada de execução (EL) após Prague: Osaka. Os nomes candidatos para a atualização da CL são: Fulu, Felis, Formosa e Funi. Esses nomes seguem a convenção de nomeação principal de estrelas com a letra ‘F’, adequados para a sexta atualização da rede Beacon Chain. Stokes, por favor, peça aos desenvolvedores na chamada para comentarem sobre esse tópico no post do Magicians.