Por dentro das atualizações do Ethereum: Hegotá

O que a Ethlabs está priorizando para o Hegotá e por quê.

A direção do Ethereum é importante para todos que constroem nele, o utilizam, possuem ETH ou simplesmente acreditam em seu potencial. Embora esse futuro seja, em última análise, determinado pelas pessoas, aplicações e comunidades que constroem no Ethereum diariamente, as atualizações de rede são uma das principais maneiras pelas quais o protocolo evolui para atender às suas necessidades. Hegotá é a próxima atualização de rede do Ethereum planejada após Glamsterdam, e este documento compartilha a visão da Ethlabs sobre o que acreditamos que o Ethereum deve priorizar para ela, e por quê.

A Ethlabs é um laboratório de P&D sem fins lucrativos para Ethereum e ETH com 8 semanas de existência, e nossa missão é tornar o Ethereum a camada de liquidação da economia global. Estamos posicionados entre o uso real do Ethereum e o desenvolvimento do protocolo, e dedicamos nosso tempo ouvindo usuários, carteiras, aplicações, rollups, instituições, detentores de ETH, pesquisadores e equipes de clientes. Às vezes, até construímos on-chain, porque não se pode construir uma arena sem participar dela! Acreditamos que uma boa engenharia de protocolo deve viabilizar grandes produtos, e grandes produtos devem ajudar a informar para onde o protocolo irá em seguida.

O escopo do Hegotá está atualmente nos estágios iniciais de definição através do processo técnico aberto do Ethereum, e as propostas abaixo refletem o trabalho de muitos indivíduos e equipes de pesquisa e clientes. Este documento é um relato transparente do que recomendamos priorizar e onde nossas opiniões ainda estão se formando. Estas são posições que adoraríamos que outros avaliassem, desafiassem e ajudassem a melhorar, e iremos iterar sobre elas à medida que discutirmos e aprendermos mais nos próximos dias e semanas.

Para a atualização Hegotá, considerando todas as EIPs propostas, estas são as áreas que vemos como de maior prioridade para o Ethereum:

1. Resistência à censura mais forte: Qualquer pessoa deve ser capaz de ter uma transação incluída, independentemente de quem seja ou para que use o Ethereum.
2. Ethereum mais rápido: Blocos mais rápidos significam confirmações mais rápidas, preços on-chain mais atualizados e finalidade mais rápida.
3. Account abstraction nativa: As contas devem suportar passkeys, transações patrocinadas, pagamento de gas em tokens, batching e privacidade mais forte, com um caminho para chaves pós-quânticas.
4. Escalabilidade contínua da L1: As aplicações precisam de capacidade que permaneça acessível e previsível, mesmo quando a demanda aumenta.

Trabalhar de forma aberta é um objetivo central para a Ethlabs, e é por isso que escrevemos atualizações semanais e, em ocasiões como esta, publicamos peças técnicas muito longas para compartilhar nosso pensamento 😅. Também publicaremos conteúdo mais resumido nas próximas semanas para aqueles que só querem os destaques. Esta próxima parte será longa e técnica. Para aqueles que lerem tudo, boa sorte!

Primeiramente: como funciona o processo de EIP?

Antes de mergulharmos nas propostas em si, um ponto importante: a segunda fase do processo de definição de escopo do Hegotá acabou de começar. A primeira fase selecionou o FOCIL como o destaque do Hegotá. Em 6 de agosto, havia um prazo para propor EIPs não-destaque, e o processo ACD agora avançará para avaliar a atualização Hegotá em sua totalidade.

Todas as EIPs abaixo estão atualmente no estágio PFI (Propostas para Inclusão), com exceção das EIPs que passaram pelo processo de destaque. Propor uma EIP para inclusão é sem permissão, e a maioria nunca chega à atualização final.

Especificamente, à medida que o trabalho de implementação avança, as propostas passam por estágios progressivamente mais fortes de revisão e confiança de que serão eventualmente lançadas:

• PFI (Proposta para Inclusão): uma ideia foi proposta para a atualização. Este estágio é sem permissão e não implica suporte do cliente ou inclusão eventual.
• CFI (Considerada para Inclusão): as equipes de clientes revisaram a proposta e pretendem prototipá-la e testá-la.
• SFI (Agendada para Inclusão): há uma intenção ampla de incluí-la, assumindo que a implementação e os testes continuem a correr bem.

Para saber mais sobre como esse processo funciona, recomendamos assistir ao rápido resumo de Tim Beiko aqui.

Organização: como navegar neste artigo

Seguimos a classificação por níveis do Forkcast para expressar nossa visão sobre a priorização de EIPs para o Hegotá. Para minimizar a decisão, mapeamos todas as EIPs revisadas em quatro níveis com as seguintes interpretações:

• [Nível S] recomendamos fortemente a inclusão.
• [Nível A] recomendamos a inclusão se os bloqueadores restantes, como complexidade de implementação, análise de impacto ou adoção, forem resolvidos.
• [Nível B] vale a pena, mas é um exagero para esta atualização.
• [Nível D] não recomendamos a inclusão no Hegotá em sua forma atual.
• [formando opinião] ainda estamos formando nossa opinião sobre esta EIP.

Observe que estas são \recomendações\ da Ethlabs. Avaliamos cada proposta principalmente em termos de propósito, especificação e nossa compreensão da complexidade de implementação plausível, exceto onde temos mais certeza ou envolvimento direto (por exemplo, Frames e Quick Slots), e atualizaremos nossa visão com base nas avaliações da ethPandaOps, equipes de teste e clientes à medida que avançamos no processo.

[CL] significa que uma EIP afeta clientes da camada de consenso e [EL] significa que afeta clientes da camada de execução.

Observe que somos co-autores e estamos envolvidos em várias EIPs (incluindo FOCIL, Frame Transactions e Quick Slots). Embora nos esforcemos para avaliar todas as EIPs independentemente do nosso envolvimento ou não, leve isso em consideração ao avaliar nossa posição.

Resumo

Classificação CL

Você pode iterar sobre esta classificação específica [CL] no Forkcaster aqui.

Classificação EL

Você pode iterar sobre esta classificação específica [EL] no Forkcaster aqui.

Agora, sem mais delongas, aqui estão nossas visões sobre a atualização Hegotá como elas estão hoje, em sua totalidade:

Temas para o Hegotá

0. FOCIL: fortalecer a resistência à censura

A EIP-7805: FOCIL já está SFI e confirmada como o destaque do Hegotá. Três membros da equipe Ethlabs (Francesco, Barnabé e Julian) estão entre seus co-autores, e apoiamos fortemente sua inclusão. Dado que a decisão já está tomada, seremos breves. Apenas uma cadeia que seja neutra para todos pode se tornar a raiz de confiança para todos. É isso que permite que o Ethereum escale para se tornar a verdadeira camada de liquidação para a economia global e para cada pessoa dentro dela.

1. Quick Slots: Ethereum mais rápido

O slot de 12 segundos do Ethereum é um custo de latência que degrada o valor do usuário. Portanto, recomendamos fortemente a inclusão da [CL] EIP-8198: Quick Slots [Nível S] no Hegotá, por quatro razões:

1. UX melhorada na L1 com confirmação de transação mais rápida.
2. Mercados on-chain na L1 operam com preços mais atualizados, melhorando spreads e a economia dos LPs.
3. A finalidade e a regra de confirmação rápida herdam o tempo do slot, então ambos se tornam mais rápidos com blocos mais rápidos, melhorando a interoperabilidade com o Ethereum.
4. Mais proponentes de blocos por segundo significa maior resistência à censura, incluindo resistência à censura econômica: a quantia que você precisa pagar para manter blocos vazios por algum período de tempo.

Acelerar enquanto se preserva a descentralização única do Ethereum torna o blockspace do Ethereum mais valioso, e esse valor é acumulado para a rede e para o ETH. Cada diminuição é mais valor entregue imediatamente aos nossos usuários. Finalmente, blocos mais rápidos estão entre as mudanças mais solicitadas pelos desenvolvedores de aplicações.

O argumento para começar agora é que a redução do tempo de slot nunca será uma mudança única e definitiva. Como na escalabilidade, as reduções entregues dão às aplicações mais certeza do que os compromissos de roadmap. O caminho para slots abaixo de 6 segundos começa com a possibilidade de alterar o tempo do slot e, em seguida, alterá-lo iterativamente. A EIP-8198 divide o trabalho em duas partes:

• Uma refatoração única que torna o tempo do slot mais fácil de atualizar nas especificações e no código do cliente.
• Uma primeira diminuição no Hegotá, seguida por mais diminuições em forks subsequentes, à medida que o roadmap avança e evidências empíricas de segurança são obtidas.

Hegotá é o fork certo para pagar o custo único. O ePBS no Glamsterdam já reestrutura o slot. Hegotá é então um fork comparativamente leve para a camada de consenso, uma janela que se fecha com o consenso desacoplado no I*, então a largura de banda do CL para a refatoração única está disponível agora de uma forma que não estará novamente por vários forks.

Significado: Ou nos comprometemos a ficar em 12 segundos pelos próximos dois anos no mínimo, ou chegamos a 10 segundos em ~um ano no Hegotá, e possivelmente menos de 10 segundos no ano seguinte. Essas duas diminuições não são melhorias teóricas. Elas obtêm diretamente maior valor para o usuário e melhores economias de rede. Achamos que é hora de começar.

As objeções mais comuns

Discutimos aqui 4 pontos importantes que foram levantados durante discussões preliminares com desenvolvedores de clientes e o Protocolo EF:

1. Complexidade de implementação: A temporização de slot com precisão de milissegundos já está mesclada nas especificações de consenso através do trabalho do ePBS, e existem rascunhos de especificações CL e EL para a EIP-8198, com taxa base, limite de gas e cronograma de blob redimensionados para preservar o comportamento por segundo. O custo restante é uma cauda de casos extremos em clientes e ferramentas que assumem um tempo de slot fixo, além de testes. A refatoração única antecipa exatamente este trabalho. Depois disso, cada diminuição é uma alteração de parâmetro.

2. Prova zkEVM: As duas principais questões são o tempo de prova relativo e a sobrecarga de prova constante.

2.1 O tempo de prova relativo mede a parcela do tempo de slot dedicada à prova e como essa parcela muda quando o tempo de slot muda. Aqui está uma breve descrição dos momentos relevantes no slot. Os builders atuais observam a liberação do payload anterior e podem começar a construir imediatamente. O beacon block atual então se compromete com o payload do slot atual. Este payload deve ser provado antes da liberação do bloco do próximo proponente de beacon.

Para a prova, o tempo relativo mínimo é um slot completo, menos a latência da liberação de um beacon block. A latência da liberação do beacon block é incompressível, mas é curta por construção, portanto não nos limita fundamentalmente neste estágio. Há também a possibilidade de builders otimizados coprovarem o payload enquanto ele está sendo construído, permitindo que comecem a provar antes que o payload vencedor seja comprometido pelo proponente do beacon block.

2.2 A prova zkEVM escala principalmente linearmente com o tamanho do bloco, exceto por alguma sobrecarga fixa. Slots mais rápidos significam que a sobrecarga fixa é paga com mais frequência, o que adiciona mais latência para a mesma quantidade de throughput. Dado um orçamento fixo de latência, deve-se então garantir que um bom throughput ainda possa ser obtido. Aqui vemos duas oportunidades: Primeiro, o progresso da engenharia continuará a reduzir a latência dessas operações fixas. Segundo, adiar o cálculo da raiz do estado, conforme descrito pela EIP-7862, move mais da prova para fora do caminho crítico, o que significa que podemos aumentar nosso orçamento de latência para operações incompressíveis. A convergência dessas duas oportunidades nos diz que slots mais rápidos não prejudicarão aumentos amplos de throughput no futuro.

3. Transição pós-quântica: A abordagem de consenso desacoplado obteve suporte suficiente para ser considerada estável no que diz respeito à arquitetura de consenso futura. Desacoplar significa mover a votação de finalidade para fora do caminho crítico da produção de blocos. Em particular, a agregação em larga escala de assinaturas PQ e toda a maquinaria STARK recursiva relacionada estarão fora do caminho crítico. O que resta para produzir blocos e obter uma regra de escolha de fork para rastrear a cabeça da cadeia resultante é um subcomitê atualmente esperado para compreender 512 validadores, e possivelmente 256. Os tamanhos das assinaturas pós-quânticas são maiores, mas são confortáveis para propagar dentro do tempo de slot proposto de 10s e provavelmente menos no futuro.

4. Contratos inteligentes e infraestrutura: A dependência do tempo de slot em contratos inteligentes e infraestrutura está atualmente sendo pesquisada. Para contratos inteligentes, fizemos uma parceria com a Sourcify para realizar análises em todos os contratos verificados. Estamos estudando os impactos de uma atualização do tempo de slot nas raízes históricas do beacon block, conforme armazenado de acordo com a EIP-4788: Raiz do beacon block na EVM. Com relação à infraestrutura, como anedota, a Etherscan mencionou que uma mudança no tempo de slot provavelmente levaria a mais carga, mas que a infraestrutura foi construída na época dos tempos de slot variáveis no Proof-of-Work, portanto não exigiu muitas mudanças.

2. Account Abstraction: melhorar UX, segurança e privacidade

O Ethereum e seu ecossistema mais amplo estão há muito tempo esperando por AA nativa, que trará benefícios de UX, como carteiras com passkey, transações patrocinadas, pagamentos de gas em ERC20, batching de transações e muito mais.

No entanto, o caminho para a AA nativa tem sido particularmente acidentado porque a AA toca em todas as partes da stack do Ethereum, incluindo clientes, L2s, carteiras, RPCs, ferramentas de desenvolvimento, etc., portanto, requer a adesão de uma enorme variedade de partes interessadas. Isso torna difícil para qualquer EIP de AA avançar no processo de desenvolvimento orientado por consenso do Ethereum, mas também alcançar adoção prática após a EIP ser lançada.

Portanto, colocamos a proposta de AA nativa do Hegotá, Frame Transactions, no Nível A, não porque não seja tecnicamente boa o suficiente para o Nível S, mas porque queremos considerar os riscos práticos de adoção que exigirão uma quantidade massiva de coordenação para serem resolvidos. Dado o histórico de nossa equipe em AA, a Ethlabs pretende desempenhar um papel importante em trazer as Frame Transactions para o mercado, trabalhando com partes interessadas como L2s e carteiras para entregar um lançamento bem-sucedido para a AA nativa.

Agora, vamos às propostas específicas de AA para o Hegotá.

[EL] EIP-8141: Frame Transactions [Nível A]

Acreditamos que a EIP-8141: Frame Transactions é a melhor candidata para o sistema de AA nativa do Ethereum. Em comparação com outras propostas de AA nativa, as Frames têm uma série de propriedades desejáveis que as tornam exclusivamente alinhadas com o mandato CROPS do Ethereum:

• Inovação de conta sem permissão: a lógica de validação é tratada pelo código EVM, então os desenvolvedores são livres para desenvolver qualquer lógica de validação que desejarem, ao contrário de algumas outras abordagens de AA que exigem uma lista de permissões de lógica de validação.
• Suporte de primeira classe para protocolos de privacidade: como um corolário do primeiro ponto, um protocolo de privacidade como o Railgun pode lidar com a lógica de validação das frame transactions, permitindo que os usuários enviem transações privadas sem depender de relayers centralizados como fazem hoje. Isso torna os protocolos de privacidade significativamente mais privados e não censuráveis.
• Segurança pós-quântica: as frame transactions foram desenvolvidas tendo em mente o roadmap PQ mais amplo do Ethereum. Por exemplo, as frame transactions são explicitamente projetadas para que as assinaturas possam ser agregadas, permitindo que o Ethereum eventualmente cobre gas baixo por assinaturas PQ, mesmo que individualmente cada assinatura possa ser muito cara para validar.

A principal fraqueza das Frame Transactions também decorre de sua maior força: como a validação é tratada pelo código EVM, a validação agora induz um custo dinâmico em vez de um custo fixo, o que pode representar desafios para cadeias de alto TPS, como L2s. Estamos otimistas de que esse problema pode ser resolvido através de outras EIPs ou ERCs sobre as frame transactions, como a EIP-7819, onde as transações podem indicar estaticamente sua lógica de validação para que os sequenciadores possam "atalhar" a validação com código nativo, se necessário. Também pretendemos trabalhar com L2s e a EF para realizar benchmarks sobre as frame transactions para que possamos identificar e resolver quaisquer gargalos de desempenho.

[CL][EL] Complementos das Frame Transactions

Há várias EIPs que podem ser vistas como extensões das Frame txs, construindo sobre suas capacidades.

[EL] EIP-8250: Nonces Chaveadas para Frame Transactions [Nível A]

• Consideramos esta EIP como conceitualmente parte da EIP-8141: Frame Transactions e acreditamos que deve ser lançada junto com ela.
• Esta EIP introduz nonces 2D para Frame transactions. Nonces 2D permitem que as contas enviem transações paralelas para o mempool, bem como permitem que protocolos de privacidade armazenem nullifiers como nonces 2D. Isso é importante porque nonces 2D são armazenamentos especiais que custam muito pouco para ler e armazenar, então as transações de privacidade economizam significativamente em gas em comparação com o armazenamento de nullifiers no armazenamento dinâmico regular como hoje. Isso é especialmente importante no contexto da reavaliação de preços de armazenamento do Glamsterdam (EIP-8037: Aumento do Custo de Gas para Criação de Estado).

[EL] EIP-8272: Raízes Recentes para Frame Transactions [Nível B]

• Esta é outra EIP que melhora a experiência de uso de protocolos de privacidade com Frame transactions. Os protocolos de privacidade precisam de acesso a raízes de compromisso recentes durante a validação, que, se armazenadas no armazenamento regular, podem ser não apenas caras, mas também entrar em conflito com as regras do mempool público das Frames. A EIP-8272 resolve esses problemas expondo um contrato de sistema para armazenar essas raízes em um buffer circular que limpa automaticamente as raízes antigas.
• Colocamos no Nível B porque esta EIP adiciona complexidade significativa às frames para um caso de uso específico, e não temos certeza se pode haver uma maneira mais geral/elegante de alcançar o mesmo objetivo.

[CL] EIP-8369: Perfis VOPS para Elegibilidade FOCIL [Nível B]

• Esta EIP aborda a interação entre Frames e VOPS (parcial sem estado apenas de validade), que é uma proposta para permitir que nós do mempool armazenem estado suficiente para validar transações, de modo que, mesmo em um mundo de falta de estado (devido ao zkEVM), o mempool possa permanecer resistente à censura.
• Colocamos no Nível B porque esta EIP está fortemente ligada a uma visão particular de falta de estado na qual a comunidade ainda não se alinhou totalmente.

[EL] EIP-7906: Asserções de Transação via Opcode de Diff de Estado [Nível B]

• Esta EIP melhora a auditabilidade estática dos resultados das transações. Os usuários já podem afirmar o que deve acontecer, mas não que nada mais aconteceu. Provar a ausência de mudanças de estado requer um novo opcode. Combinar asserções positivas (por exemplo, saldo WETH aumentou em pelo menos 1,5) com uma asserção negativa (nenhum outro estado mudou) permite que os usuários limitem todos os efeitos de uma transação por construção, sem simulação, com carteiras de hardware sendo um beneficiário claro.
• Dada a complexidade, incluí-la no hard fork seria uma escolha muito comprometedora. Sugerimos fazer isso apenas se (a) as equipes de clientes realmente entenderem as nuances e implicações desta EIP específica, e (b) a superfície de teste e as complexidades forem muito bem compreendidas.

[EL] Migração de EOA [Nível B]

A [EL] EIP-7851: Delegação de EOA Controlada por Código [Nível B] e a [EL] EIP-8151: ecRecover Restrito por Código de Conta [Nível B] são melhor vistas como padrões emparelhados que juntos apresentam uma história de como as EOAs podem fazer a transição para contas inteligentes. Nesta história, uma EOA primeiro delegaria a uma conta inteligente via EIP-7702. Em seguida, o opcode que a EIP-7851 introduz tornaria a delegação 7702 permanente, desabilitando a chave ECDSA raiz. Por outro lado, a EIP-8151 tornaria o ecrecover ciente da desativação, para que a chave antiga não possa drenar fundos através de fluxos do tipo Permit.

Classificamos este par no Nível B porque é apenas uma das muitas abordagens para migrar EOAs para contas inteligentes, e esta abordagem particular não recebeu ampla revisão ou adesão. Em particular, estamos preocupados que esta abordagem não responda à questão de múltiplas cadeias: como a mesma EOA migra nas L2s? O usuário teria que realizar a mesma ação em TODAS as cadeias, incluindo cadeias que ainda não existem, o que resultará em uma má UX. Suspeitamos que possa haver uma abordagem melhor onde as L2s possam alavancar a L1 como a "raiz de confiança" para a migração de EOA, então reservamos os Níveis A/S para abordagens que permitiriam aos usuários migrar uma vez para todas as cadeias EVM.

[EL] Esquema de assinatura PQ [Nível A]

Hegotá deve estabelecer um caminho crível para assinaturas pós-quânticas, mas devemos confirmar o mecanismo correto antes de nos comprometermos.

• A EIP-8355: Adicionar verificação ML-DSA pré-compila, tornando a segurança de conta pós-quântica concreta junto com as Frame Transactions.
• Alternativa: Pré-registrar o suporte PQ sem ativá-lo, ou definir um formato de derivação que possa acomodar chaves PQ posteriormente.

[EL] EIP-7819: Instrução SETDELEGATE [Nível A]

• Com a AA nativa provavelmente chegando no Hegota, é importante que o custo de implantação de novas contas inteligentes seja baixo, mas implantar contas ficará mais caro no Glamsterdam devido à EIP-8037. Com a EIP-7819, novas contas usariam ponteiros de delegação simples em vez de contratos proxy, reduzindo vastamente a quantidade de novo estado que precisa ser criado, diminuindo assim o custo de implantação.
• Colocamos esta EIP no Nível A porque acreditamos que um custo de implantação de conta mais baixo reduziria significativamente o atrito para a adoção da AA.

3. Engenharia de desempenho: escalabilidade contínua da L1

Glamsterdam marcou uma mudança na forma como o Ethereum aborda P&D, com o desempenho tratado como uma restrição de P&D de primeira classe, tanto no design do protocolo quanto no trabalho do cliente. Execução atrasada, reavaliações de recursos e muito trabalho de otimização do cliente permitem escalar de 30M para (pelo menos) 200M nos últimos dois anos. Em geral, o trabalho de desempenho nos dá opcionalidade: a margem que ganhamos pode ser usada para escalar, para encurtar slots, para reduzir os requisitos do nó, ou tudo isso.

Hoje, ainda vemos a escalabilidade contínua como uma necessidade. As aplicações decidem onde construir com base não apenas nos preços atuais, mas em saber se o Ethereum pode expandir a oferta de blockspace de forma previsível ao longo do tempo. Entregar aumentos de forma consistente fornece mais certeza do que apenas compromissos de roadmap. A capacidade da mainnet ainda está muito longe de ser capaz de lidar com picos de demanda: no décimo primeiro aniversário do Ethereum, a taxa base mediana diária era de apenas ~0,1 gwei, no entanto, uma cunhagem de NFT a empurrou acima de 10 gwei por algum tempo, com custos de transação medianos atingindo cerca de $1 e o percentil 90 mais de $5. O impulso de escalabilidade do Glamsterdam deve, portanto, continuar no Hegotá.

Em conjunto, as seguintes EIPs continuam o momentum de escalabilidade do Glamsterdam, ao mesmo tempo que reforçam o princípio mais amplo por trás dele: o desempenho deve permanecer uma preocupação de primeira classe tanto no trabalho do cliente quanto no design do protocolo.

[EL] EIP-8131 e EIP-8279 [Nível S]: Pacote de reavaliação de preços de dados

Depois do Glamsterdam, a próxima restrição vinculativa é a propagação de payload, em parte porque diferentes fontes de bytes de payload são refletidas de forma inconsistente, ou nem sequer são refletidas, na contabilização de gas. O EIP-8131: Unified Transaction Content Floor estende o piso de transação existente para o conteúdo conhecido antes da execução, enquanto o EIP-8279: Block Access List Byte Floor cobre os bytes BAL criados dinamicamente durante a execução.

Essa medição dinâmica torna o EIP-8279 claramente o mais complexo dos dois. No entanto, sugerimos pensar neles como um pacote. Juntos, eles estabelecem uma contabilização consistente para os bytes associados a uma transação, limitando o pior caso de payload, deixando a maioria das transações comuns, sem muitos dados, inalteradas. Isso corrige a lacuna subjacente na contabilização de recursos e abre caminho para novos aumentos no limite de gas.

[CL][EL] EIP-8146: Block Access List Sidecars [Tier A]

O EIP-8146 complementa as redefinições de preço ao melhorar o próprio caminho crítico, propagando os BALs separadamente do payload, o que melhora a propagação e dá aos clientes de execução uma vantagem inicial na pré-busca de estado e no cálculo da raiz do estado pós-execução. Vemos isso como o tipo de otimização de baixo custo que não devemos deixar de lado. O trabalho de implementação é principalmente maquinaria familiar de gossip do CL, tornando este um EIP de baixo esforço e alto valor, especialmente num fork que está a revelar-se bastante pesado em EL.

Outros EIPs relacionados

[EL] Recalibração CPSB [Tier A]

• Alterações muito simples, recomendamos mantê-las no pipeline e incluir uma das duas se considerado necessário com base nos aumentos planeados do limite de gas e na utilização observada de gas de estado e execução.
• EIP-8368: CPSB Recalibration for New Gas Limit: Acompanhamento pré-planeado do EIP-8037, compensando o facto de o custo por byte de estado (CPSB) ter sido tornado estático em vez de uma função do limite de gas, puramente como uma simplificação de implementação e teste. A ideia era substituir o ajuste bloco a bloco por ajustes únicos em forks, conforme necessário, para manter o crescimento do estado no alvo à medida que o limite de gas aumenta. Como o CPSB atual foi calibrado para um limite de gas de 150M, é provável que um ajuste no Hegotá seja justificado.
• EIP-8372: Normalized state gas limit: Ainda um superconjunto bastante mínimo do EIP-8368, permitindo um ajuste mais granular do que apenas o CPSB, compensando o facto de o alvo de crescimento do estado ou o alvo regular de gas serem subestimados devido a uma precificação relativa incorreta.

[EL] EIP-7862: Delayed State Root [Tier B]

• Simples de especificar, mas a complexidade das implementações do cliente não é muito bem compreendida, tanto quanto sabemos. A raiz do estado é omnipresente nas bases de código.
• Embora haja algum benefício em baixar a barreira de acesso à construção competitiva (cálculo rápido da raiz do estado), o benefício mais substancial do EIP está no futuro, na nossa opinião (mais tempo para provar o cálculo da raiz do estado).
• O EL já é o lado pesado do Hegotá.

[CL] EIP-8341: Partial Execution Payload Commitments [Tier D]

• Recomendamos rejeitar: benefício pequeno (atrasar ligeiramente o cálculo da raiz do estado), não é urgente e é substituído pelo EIP-7862: Delayed State Root (que dá muito mais tempo para isso).

Outros EIPs

Agora cobrimos o resto dos EIPs, agrupados livremente por tópicos. Em alguns EIPs ainda estamos a formar a nossa opinião. Atualizaremos este documento à medida que aprendermos mais com as equipas de clientes e autores de EIPs nos próximos dias e semanas.

Como o Hegotá parece ser um hard fork com viés para EL, sugerimos manter a disciplina e manter um padrão elevado para qualquer EIP do lado do EL ser aprovado. Achamos que manter o Hegotá relativamente leve em CL, para além do FOCIL e do Quick Slots, é desejável: um âmbito mais restrito preserva a largura de banda para dar às equipas de clientes espaço para se prepararem para a transição arquitetónica maior.

[CL] Emissão

Intencionalmente, não atribuímos um tier ao EIP-8363: Tapered Issuance Burn. Achamos que a emissão não é uma decisão que os core devs devam tomar sozinhos, e uma lista de tiers é uma recomendação explícita aos core devs. Para a maioria dos EIPs, o processo ACD funciona bem porque as decisões são principalmente técnicas, e a comunidade delegou-as efetivamente aos core devs. A emissão é diferente, pois é uma questão de política monetária sobre a qual a própria comunidade tem de chegar a um consenso aproximado. As opiniões dos core devs são importantes, mas como contributo para essa discussão pública. Classificar o EIP-8363 ao lado dos outros EIPs tratá-lo-ia como uma decisão ACD normal, o que achamos que não deveria ser.

Tecnicamente, vemos mérito em alterar a emissão em linha com o EIP-8363. Os problemas que aborda são reais: a credibilidade do slashing corrói à medida que mais ETH é staked, rácios de staking elevados significam que as recompensas compensam maioritariamente a diluição, e as economias de escala continuam a alargar o fosso entre grandes operadores e stakers individuais. Uma alteração também tem riscos, desde a incerteza dos efeitos na distribuição do stake até reiniciar o relógio de ossificação da política monetária. O tópico do Ansgar expõe ambos os lados e reflete a nossa posição. Alguns de nós defenderam alterações na emissão no passado e continuam com convicção nesse caminho.

Recomendamos tomar a decisão sobre a emissão depois de todas as outras decisões de âmbito do Hegotá. Isto dá à discussão da comunidade o tempo necessário e evita distrair do próprio processo de definição de âmbito.

[CL] Funcionalidades de staking

Melhorias no staking podem ser valiosas, mas os benefícios para o utilizador devem ter prioridade sobre alterações apenas de infraestrutura, a menos que sejam estritamente necessárias.

[CL] EIP-8015: Remove deposit and eth1data fields [Tier A]

• Limpeza muito simples de dívida técnica. Graças ao EIP-7688: Forward compatible consensus data structures, as provas Merkle de campos não relacionados não são afetadas, portanto, sem impacto nos consumidores da chain.

[EL][CL] EIP-8237: Independent CL/EL Sync [Tier B]

• Baseia-se na separação do bloco beacon e do payload introduzida pelo ePBS, para permitir que o EL e o CL sincronizem de forma independente. Achamos que isto tem o potencial de simplificar uma parte complexa dos clientes Ethereum.

[CL] EIP-8205: Withdrawal credentials preregistration [Tier D]

• Recomendamos rejeitar. Embora o EIP forneça uma solução dentro do protocolo para um problema real no staking delegado, achamos que a solução de pré-depósito existente é adequada e a complexidade da maquinaria adicionada não é atualmente justificada.

[CL] EIP-8148: Custom sweep threshold for validators [Tier D]

• Recomendamos rejeitar. Achamos que o EIP é demasiado complexo (novo contrato de sistema, novo pedido de execução, maquinaria CL) para os seus benefícios, que vemos como principalmente encorajar alguma consolidação adicional marginal do pool de operadores domésticos. Não achamos que isto terá muito efeito na consolidação geral de validadores, dada a forma como o stake está distribuído.

[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [Tier D]

• Recomendamos rejeitar. Achamos que isto provavelmente levará a mais side-channeling. Além disso, anos de discussões sobre estratégias de queima de MEV não levaram a nenhuma proposta que alcançasse um amplo consenso de investigação.

[CL] EIP-7716: Anti-correlation attestation penalties [Tier D]

• Recomendamos rejeitar. Não achamos que haja evidências claras suficientes de que uma alteração tão grande nos incentivos ao staking seja justificada. Além disso, os incentivos ao staking provavelmente serão reformulados como parte do consenso desacoplado.

[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [Tier D]

• Recomendamos rejeitar. Embora seja uma boa limpeza, achamos que vale a pena adiá-la para a próxima grande transição de consenso desacoplado.

[CL] EIP-8359: Beacon Block Reporting Field [formando opinião]

[CL] Mais preparação PQ

Estas propostas reduzem as dependências BLS restantes antes de uma futura transição pós-quântica.

[CL] EIP-8365: BLS withdrawal credential retirement [Tier A]

• Retira uma credencial de retirada legada, preparando o terreno para simplificações do protocolo e simplificando a futura transição PQ.
• Dado o quão simples é, achamos que vale a pena incluir agora.

[CL] EIP-8367: Balance sunset for retired BLS validators [Tier D]

• Recomendamos rejeitar. Achamos que é provável que a maioria dos validadores 0x0 faça uma alteração de credencial (BLSToExecutionChange) antes ou depois de o EIP-8365: BLS withdrawal credential retirement ser ativado, seja para retirar os seus fundos ou para poder continuar a fazer staking. Não achamos que haja grande urgência em introduzir um mecanismo para lidar com o stake 0x0 restante. Recomendamos apenas incluir o EIP-8365 e ver o resultado disso antes de decidir os próximos passos.

[CL] EIP-8321: Hash-Chain RANDAO [Tier D]

• Recomendamos rejeitar. Tornar o RANDAO seguro pós-quântico isoladamente fornece pouca segurança a nível do protocolo enquanto as chaves BLS do validador permanecerem vulneráveis, mas adiciona cerca de 32 bytes por validador, nova maquinaria de gestão de segredos e um mecanismo em grande parte de propósito único. O design mais amplo do consenso PQ permanece indefinido. Apoiamos uma transição iterativa, mas o seu primeiro passo deve seguir um roadmap acordado, em vez de arriscar ser substituído pelo design eventual.

[EL][CL] Preparação zkEVM

A maioria da preparação para zkEVM oferece benefícios limitados a curto prazo, para além de tornar a operação de nós completos mais fácil para um conjunto restrito de utilizadores, enquanto consome largura de banda de implementação e potencialmente torna a EVM mais cara. Devemos incluir apenas alterações cujo valor a longo prazo justifique claramente esses custos imediatos.

[CL] EIP-8025: Optional Execution Proofs [Tier D]

• O EIP não requer um hard fork. A proposta de o agrupar com o Hegotá é puramente uma expressão de priorização, e discordamos dessa escolha. Achamos que o trabalho deve continuar nele, mas o Hegotá não deve ser bloqueado por ele.
• Antes de lançar provas opcionais, devemos primeiro trabalhar para definir o estado final e depois acelerar nessa direção, em vez de lançar provas opcionais antes de uma visão clara do modelo de validador/estado a longo prazo.
• A questão central em aberto é qual o papel que os validadores devem ter em relação ao estado: se devem continuar a servir ou a deter parte dele, em vez de se tornarem completamente stateless. Como os validadores são um grupo central de nós com valor real de hardware e rede, as alterações que enfraquecem esse papel devem ultrapassar uma barreira mais elevada.

[EL] EIP-7666: EVM-ify the identity precompile [Tier A]

• útil, alteração pequena

[EL] EIP-8200: EVMification [Tier B]

• O EIP-8200 substitui três precompiles nativas por bytecode EVM equivalente. Duas têm pouco uso e parecem diretas de migrar. A terceira é amplamente usada na verificação SNARK, por isso gostaríamos de uma avaliação de impacto antes de apoiar a sua remoção.
• Se a análise de impacto encontrar baixos custos de migração para os utilizadores afetados, ou se a terceira precompile for removida do âmbito, moveríamos o EIP-8200 para [Tier A].

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [Tier D]

• Bastante disruptivo devido ao grande aumento no custo de gas, não é urgente
• Mitigar o risco poderia envolver uma análise de impacto, ou fazê-lo mais tarde com alguma forma de warming a nível de bloco (ou warming ad-hoc destes valores) para reduzir o impacto.

[EL] EIP-8268: Storage Roots in Block Access Lists [Tier B]

• Pode ser necessária uma análise do impacto concreto nos tamanhos dos BALs e no impacto relacionado nos custos de tx (EIP-8279 está a propor cobrar pelos bytes BAL), uma vez que a entrada BAL para cada conta tocada recebe uma raiz de trie de armazenamento adicional.

[EL] Funcionalidades EVM

O Hegotá ainda exigirá algumas decisões EVM ad hoc. Acreditamos que, após o Hegotá, o Ethereum deve trabalhar para um roadmap EVM de longo prazo moldado pelo ecossistema EVM mais amplo. A Ethlabs contribuirá para isso.

[EL] EIP-5920: PAY opcode [Tier A]

• Muito simples, e achamos que é um bom primitivo para a EVM ter
• Seria importante compreender melhor os casos de uso concretos

[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [Tier A]

• Muito útil para L2s, sem custo real para L1 (apenas informacional)

[EL] Reutilização / desduplicação de código [Tier B]

• O EIP-8058: Contract Bytecode Deduplication Discount e o EIP-8298: SETCODEFROM Code Reuse Instruction ambos tentam aproveitar o facto de o código do contrato ser armazenado separadamente da conta correspondente nos clientes, com o hash do código como ponteiro entre eles. Assim, o código partilhado idêntico pode ser armazenado de forma desduplicada. Ambos os EIPs permitem uma forma de definir o codehash da conta para o hash de um código existente noutro local de forma barata.
• Consideramos esta uma ideia geral atraente, mas seria importante compreender as implicações e a compatibilidade futura com árvores binárias. Sem preferência por enquanto entre os dois.

[EL] Reforma da precificação de memória [Tier B]

• Precisamos de decidir se queremos ou não fazer uma reforma da memória no Hegotá. Não nos parece claro que tenhamos atualmente uma compreensão suficiente do espaço de design para fazer esta avaliação.

EIP-7686: Linear EVM memory limits

• Alteração mais pequena, apenas elimina o custo de expansão de memória quadrática.

EIP-7923: Linear, Page-Based Memory Costing

• Reformulação mais profunda e mais baseada em princípios, mas mais complexa.

[EL] EIP-8219: Checked Arithmetic Opcodes [Tier B]

• No geral, adicionar matemática segura à EVM parece útil.
• A precificação precisaria de ser confirmada com benchmarks, quão complexo é isso?
• Com benchmarks e uma análise de impacto (quantas txs poderiam beneficiar, quanto, quais compiladores adicionariam suporte?) poderia ser Tier A.

[EL] EIP-8360: TCREATE Opcode [Tier B]

• O EIP introduz a capacidade de criar contratos temporários com âmbito de transação. Este é um bom primitivo para se ter em geral.
• O EIP adiciona complexidade significativa. Com uma avaliação mais aprofundada da complexidade de implementação e teste, poderia ser Tier A.

[EL] EIP-7645: Alias ORIGIN to SENDER [Tier D]

• Recomendamos rejeitar: Alteração disruptiva, uso impróprio de ORIGIN.

[EL] EIP-8182: Private ETH and ERC-20 Transfers [Tier D]

• Recomendamos rejeitar: Alteração enorme, adiciona dependências zk. Se alguma vez for introduzido, achamos que deveria ser um headliner.

[EL] EIP-2488: Deprecate the CALLCODE opcode [formando opinião]

[EL] EIP-4758: Deactivate SELFDESTRUCT [formando opinião]

[EL] EIP-7979: Call and Return Opcodes for the EVM [formando opinião]

[EL] EIP-8173: Foundations of EVM Control Flow [formando opinião]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [formando opinião]

[EL] EIP-8030: P256 algorithm support [formando opinião]

[EL] Precificação EVM

O Glamsterdam aumentou os preços para operações subprecificadas que restringiam o throughput geral. As propostas de precificação EVM do Hegotá abordam principalmente o outro lado: baixar os preços para operações individuais cujo custo atual limita o seu uso, mas não a escalabilidade da rede. Estas são, portanto, melhorias desejáveis com menor impacto por EIP. Estamos abertos a redefinições de preço direcionadas, mas propostas que introduzam novos mecanismos de medição só devem ser incluídas se o seu design for sólido e suficientemente mitigado por um champion comprometido.

[EL] EIP-8358: Net Gas Metering for Account Changes [Tier B]

• Não estamos convencidos do impacto. Em 900 blocos mainnet amostrados, ~400k txs: 2,07% de todas as transações poupariam gas e 1,14% do gas do bloco seria poupado

[EL] EIP-7973: Warm Account Write Metering [formando opinião]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [formando opinião]

[EL] EIP-7971: Hard Limits for Transient Storage [formando opinião]

[EL] EIP-3298: Removal of refunds [formando opinião]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [formando opinião]

[EL] EIP-8115: Batch priority fees at end of block [formando opinião]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [formando opinião]

[EL][CL] Dados de execução e indexação

[EL][CL] EIP-7668: Remove bloom filters [formando opinião]

[EL][CL] EIP-7807: SSZ execution blocks [formando opinião]

[EL] EIP-8116: Replace cumulative receipt fields [formando opinião]

[EL] EIP-8304: Trustless log and transaction index [formando opinião]

[EL][CL] Rede

A camada P2P do Ethereum tem espaço para melhorias direcionadas, especialmente na forma como transações, blobs e atestações são propagadas pela rede.

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [Tier A]

• Geralmente evita que a reconstrução completa e o desempenho do nó de custódia completa sejam um gargalo para escalar o número de blobs.
• Valioso, eventualmente alguma forma de reconstrução distribuída deve definitivamente entrar no protocolo. Isto poderia permitir-nos remover a custódia do validador.
• Precisamos de compreender melhor a complexidade.

[CL] EIP-8142: Block-in-Blobs (BiB) [Tier D]

• Prematuro, sem grande urgência, bastante em cima da hora, muitas questões em aberto (KZG ou não? Novos tópicos de gossip ou não?).
• Não queremos introduzir KZG no caminho crítico da produção de blocos, as alternativas não são claras e adicionariam mais complexidade.

[CL] EIP-8243: Batching Attestations at Source [Tier D]

• Não está claro se podemos confiar nisto para diminuir o tempo até à finalidade, não coloca um limite claro na carga.
• A resistência a DoS do mecanismo não está totalmente clara.

[EL] EIP-8077: eth/XX - announce transactions with nonce [formando opinião]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [formando opinião]

[CL] EIP-8334: Bundled Attestation Propagation [formando opinião]

Se de alguma forma ainda está connosco, obrigado por ler até ao fim. Sinta-se à vontade para responder com quaisquer perguntas, e faremos o nosso melhor para lhe responder! Se saltou e veio parar aqui porque ler um muro de texto gigantesco não era como decidiu passar o seu domingo, terá prazer em saber que a próxima parte é breve.

Mais (algumas) palavras...

As atualizações do Ethereum são complexas porque os riscos são elevados. Milhares de nós em todo o mundo mudam para novas regras no mesmo slot, e a rede não para nem por um segundo enquanto o fazem. Esse rigor tem acompanhado todas as atualizações que o Ethereum lançou, resultando numa rede descentralizada que celebrou 11 anos de 100% de uptime.

As nossas posições sobre o Hegotá são as nossas melhores avaliações até à data, mas atualizaremos o nosso pensamento sempre que novas evidências de discussões ou trabalhos de implementação mudarem a nossa visão.

Alguns destes EIPs foram escritos ou avançados por membros da Ethlabs, outros vêm do vasto, talentoso e bem-intencionado grupo de investigadores, devs de clientes e contribuidores individuais em todo o Ethereum. No entanto, todos eles exigirão colaboração entre equipas de clientes, wallets, aplicações, L2s, fornecedores de infraestrutura, instituições, operadores de nós e, em última análise, utilizadores para terem sucesso. O Ethereum é o projeto partilhado do mundo, e o progresso significativo da rede nunca é o trabalho de uma única organização.

Estamos gratos por ser uma pequena parte deste ecossistema e ansiamos por ajudar o Ethereum a realizar o seu potencial.

– Ethlabs