CTO da Paradigm: Interpretando o Hard Fork de Praga após a atualização do Ethereum Cancun

Palavras: Georgios Konstantopoulos, CTO, Paradigm

Compilador: Luffy, Foresight News

O objetivo deste artigo é fornecer uma visão geral das visões da equipe Paradigm Reth sobre quais EIPs devem ser incluídas no Hard Fork de Praga (a próxima grande atualização para o Consensus Ethereum após o Hard Fork de Cancun) e nosso plano geral para “EL Core Dev” em 2024. As visões a seguir estão em constante evolução e representam as visões atuais da equipe Reth e não representam necessariamente toda a equipe da Paradigm.

Acreditamos que o Hard Fork de Praga provavelmente se materializará no EthereumTestnet no 3º trimestre de 2024 e na Mainnet até o final do ano. Deve incluir:

• EIPs relacionadas com staking, como a EIP-7002 que suporta re-staking e pools de staking sem confiança.
• Variações EVM separadas.
• Estamos dispostos a trabalhar com qualquer equipe que queira olhar mais para Praga ou outro futuro EL Hard Fork e estamos felizes em fornecer orientação e assistência onde modificar a base de código Reth.

O que fazer:

• Acreditamos que as seguintes EIPs devem ser priorizadas: 7002, 6110, 2537.
• Apoiamos o EOF descrito na especificação e esperamos finalizar o escopo e criar um meta EIP o mais rápido possível.
• Estamos dispostos a adicionar EIP-4844 Max Blob Gas. Não temos uma opinião sobre números específicos, mas convidamos o pessoal dos dados a trabalhar conosco sobre o tema.
• Estamos felizes em lançar uma versão do EIP-7547: ele contém uma lista para ajudar a camada base a resistir à censura.

O que não fazer:

• Não apoiamos a inclusão do Verkle Tries no Hard Fork de Praga, mas apoiamos a equipe do cliente a começar a trabalhar nisso no segundo trimestre de 2024 com o compromisso de lançar a atualização de Osaka em 2025.
• Não achamos que devemos aumentar o limite de gás de execução L1 ou o tamanho do contrato, mas convidamos o pessoal de dados a trabalhar conosco para investigar seu impacto na rede. Estamos dispostos a mudar nossa perceção porque testes anteriores mostraram que o Reth Node pode lidar com o aumento da carga sem problemas.
• Acreditamos que as EIPs de Abstração de Carteira/Conta precisam ser testadas de forma mais adversária umas contra as outras para entender melhor o espaço de compensação. Se não forem mutuamente exclusivas, estaremos dispostos a implantar várias EIPs relacionadas a AA no futuro.
• Se a comunidade concordar com o rumoroso backdoor da NSA, podemos cruzar a linha no EIP-7212 (secp256r1).
• Outros tópicos do roteiro: Não temos uma compreensão real do acoplamento de garfos CL EIP ou CL/EL, mas os EIPs 7549 e 7251 parecem promissores. Queremos também contribuir tanto quanto possível para o trabalho do PeerDAS do lado da EL. Neste momento, queremos evitar a introdução de raízes SSZ (EIPs 6404, 6465, 6466). Finalmente, vemos uma oportunidade de fornecer uma solução de arquivamento de dados de longo prazo para blobs, histórico e estado expirados, já que tanto o EIP-4844 quanto o EIP-4444 deixam isso claro, e resta determinar se o Ethereum está disposto a fornecer tal solução.

Expanda-o em detalhes abaixo.

Coisas para fazer

No resumo, apoiamos 1) preencher ainda mais a lacuna entre CL e EL, e 2) modificações EVM podem ser realizadas como trabalho solo e podem ser testadas separadamente e em paralelo.

EIP-7002

Este EIP desbloqueia pools de restaking e staking sem confiança, permitindo que o Smart Contract no lado EL controle 1 ou mais validadores no lado CL. Em nossa opinião, pelo menos permitirá que os pools de staking existentes removam uma camada de centralização do Smart Contract que permite retiradas.

Introduzir a pré-compilação stateful para o EVM é uma nova abstração que precisamos obter em nossa implementação EVM, mas além disso, achamos que é uma EIP simples.

EIP-6110

O EIP introduz depósitos no estado EL, simplificando a gestão estatal que precisa ser feita no CL. Em termos de implementação, isso é semelhante ao rastreamento de retiradas de CL, portanto, no geral, achamos que esta também é uma EIP simples e independente.

EIP-2537

Existem atualmente várias implementações de BLS12-381, que é uma curva frequentemente usada em muitos SNARKs, algoritmos de assinatura BLS e EIP-4844. Consideramos que é de baixa complexidade de implementação porque apenas expõe o algoritmo de validação da curva através de uma interface pré-compilada. Também podemos precisar do hash da curva BLS12-381 pré-compilada.

EOF

*Nota do tradutor: EOF significa EVM Object Format, que se traduz para o formato de objeto Ethereum, e contém uma série de EIPs que prometem tornar a execução do Ethereum mais eficiente, consistente e atualizável. Os primeiros planos foram implementados no Shanghai Upgrade, que mais tarde foi removido. *

A EOF suportará Solidity e Vyper. Não há dúvida de que os ajustes de formatação e verificação de código tornarão a análise de bytecode muito mais simples, e recomendamos considerar cuidadosamente qualquer outra coisa. Recomendamos alguns EIPs abaixo, mas estamos dispostos a ajustá-los ainda mais.

Aspetos positivos:

• Mudanças somente EVM que podem ser testadas usando Ethereum / Testnet e implementadas por uma única pessoa.
• Mudanças de EVM que Vyper e Solidity querem
• Ajuda a melhorar o desempenho e aumentar os limites de tamanho do contrato.
• Elimina a necessidade de análise de bytecode em tempo de execução para o EVM. Sem cache envolvido, o tempo para análise pode chegar a 50% e aumenta à medida que o tamanho do contrato aumenta.
• Permitir o carregamento parcial de código para ajudar a executar grandes contratos inteligentes.
• Devex: Permitirá que o problema “stack too deep” seja corrigido através de dupN/swapN e outras melhorias de ferramentas.
• Preparado para o futuro: Novos recursos podem ser introduzidos com segurança em L2, e a ferramenta saberá o que é compatível.

Aspetos ruins:

• Alcance e alvos dinâmicos.
• Não há um forte impulso por parte dos proponentes para incluí-lo.
• O suporte para código legado ainda é necessário
• Antes da adoção, houve um desacordo temporário entre a EthereumMainnet e outras cadeias EVM.

Acreditamos que os seguintes recursos de EOF devem ser implantados em 2024. Recomendamos definir o âmbito e comprometer-se com a implementação o mais rapidamente possível. Qualquer outra coisa deve ser considerada para implantações subsequentes. As nossas recomendações são:

• EIP-3540 (EOF - EVM Object Format v1): Introduz código e contêineres de dados, e adiciona estrutura e versionamento ao bytecode Ethereum.
• EIP-3670 (EOF - Code Validation): Rejeita qualquer contrato que não siga o formato EOF quando implantado. Execute código mais estruturado e desative diretivas inválidas e indefinidas.
• EIP-663 (Infinite SWAP & DUP Instructions): Isso resolve o problema “stack too deep” em solidez e tem efeitos colaterais como um valor instantâneo através da análise JUMPDEST. Uma característica muito desejável da linguagem EVM.
• EIP-4200 (EOF - Static Relative Jumps): Melhor análise estática sem saltos incertos. Melhor compilação AOT. Os saltos são mais propícios à reutilização de código.
• EIP-4750 (EOF - Função): Requer resolução de sub-rotinas que podem usar saltos dinâmicos, mas não saltos estáticos. Ele também permite que o código parcial seja carregado, o que funciona perfeitamente com o Verkle para aumentar o limite de tamanho do contrato.
• EIP-5450 (EOF - Stack Validation): Verificar os requisitos de código e pilha. Remova as verificações de subfluxo e estouro da pilha de tempo de execução para todas as instruções, exceto CALLF (EIP-4750)
• EIP-7480 (EOF - Data Section Access Instruction): Permite o acesso à parte de dados do bytecode.
• EIP-7069 (Diretiva CALL melhorada): Capacidade de remover a observabilidade do gás do CALL, tornando mais fácil reavaliar o preço do gás no futuro. Embora independente da EOF, vemos esta como uma boa oportunidade para a introduzir.

Não temos tanta certeza sobre EIP-6206 (EOF - JUMPF e função non-return). Embora permita a otimização de chamadas de cauda em funções EOF, ainda precisamos ver o que o perfil de linguagem faz por isso. Se não o fizermos, pensamos que podemos removê-lo do âmbito e incluí-lo numa atualização EOF subsequente.

Estimamos que a carga de trabalho acima seja de 1 pessoa trabalhando em tempo integral por 1-2 meses. Estamos dispostos a reduzi-lo ainda mais.

Uma nota sobre bytecode herdado:

• Embora possamos banir novos bytecode legados/não-EOF, não podemos depreciar o bytecode legado existente, que efetivamente atua como EOF “v0”. O bytecode herdado ainda requer análise JUMPDEST após EOF e ainda requer manipulação de código especial para fragmentá-lo em partes no Verkle Trys.
• Tanto quanto é do nosso conhecimento, não é possível verificar uma conversão de bytecode não-EOF para EOF sem acesso ao código-fonte, mas estamos dispostos a estudar mecanismos para facilitar essa conversão.
• Alternativamente, estaríamos dispostos a explorar maneiras de forçar a migração do estado para o EOF.

Aumentar o número de blobs EIP-4844

Estamos abertos a esta mudança, que corresponderá a um aumento em MAX_BLOB_GAS_PER_BLOCK e TARGET_BLOB_GAS_PER_BLOCK. O EIP-4844 diz:

Selecione os valores de TARGET_BLOB_GAS_PER_BLOCK e MAX_BLOB_GAS_PER_BLOCK para corresponder a um destino de 3 blobs (0,375 MB) por bloco (até 6 blobs). Esses pequenos limites iniciais são projetados para minimizar a tensão na rede causada pelo EIP, e espera-se que o número de blobs aumente em atualizações futuras à medida que a rede demonstra confiabilidade em blocos maiores.

Na verdade, esta é uma pequena alteração de código e precisamos investigar seu impacto real no pool de transações, mas pensamos que poderíamos reutilizar a infraestrutura de teste de estresse EIP-4844 para isso. Pode ser difícil para o CL espalhar mais bolhas, e respeitamos as opiniões da equipe do CL.

Não faça

Tentativas Verkle

Tl; TL;DR: Não vemos uma tentativa de implantar o Verkle no final de 2024/início de 2025. Recomendamos que a equipe aloque recursos para isso no 2º trimestre de 2024 e se comprometa a implantar no Hard Fork de Osaka no 2º ao 3º trimestre de 2025.

Aspetos positivos:

• Permite clientes leves mais baratos com provas de armazenamento menores.
• Execução sem estado, incluindo pré-estado de leitura no cabeçalho do bloco, o que também pode levar a ganhos de desempenho devido ao acesso ao estado estático.
• Aumente o limite de tamanho do contrato dividindo o bytecode e permitindo o carregamento parcial do código.
• A expiração do status tornou-se mais aceitável devido ao menor custo de “restauração” do status.

Desvantagens:

• O impacto das mudanças e dos esforços para implementar e testar.
• Alterações no cálculo do gás: Verkle Tries introduz o tamanho da testemunha no recurso de cálculo de gás. Preocupa-nos o facto de ainda não terem sido exploradas alterações nos preços de armazenagem (por exemplo, qual é o custo dos principais consumidores de gás depois da Verkle)?
• Integração de aplicativos: O que um aplicativo com um validador Merkle Patricia Trie deve fazer quando a transição de sobreposição é executada? Como eth_getProof deve se comportar?

Embora compreendamos os benefícios do Verkle Try, achamos que é necessário considerar mais como as ferramentas/contratos de terceiros precisam se encaixar e qual o impacto que isso terá na Camada 2 e similares durante o período de transição. Inicialmente tivemos dúvidas sobre a estratégia de migração porque afirmava que a tentativa de Verkle deveria ser atualizada quando o estado fosse lido a partir de um MPT pré-existente, mas isso não parece ser mais o caso. Por conseguinte, apoiamos a abordagem de sobreposição como uma via de migração viável.

A documentação para a estratégia de migração Verkle parece desatualizada, pois a maioria dos recursos ainda afirma que o Verkle trie deve ser atualizado ao ler o estado do MPT. Gostaríamos de ver a documentação de transição com as abordagens mais recentes, como esta excelente. Gostaríamos também de ver um projeto de PEI sobre a estratégia de transição.

Portanto, ainda apoiamos seu lançamento em 2025, em vez de implantar no Hard Fork de Praga.

Limite de gás L1

Não acreditamos que aumentar o limite de gás L1 faça muita diferença na prática. Também acreditamos que a maioria dos clientes pode lidar com um aumento médio de carga, mas queremos estar atentos ao pior cenário, por isso não recomendamos aumentar o limite de gás L1 neste momento. Acreditamos que aumentar o limite de gás bolha é uma solução mais promissora a curto prazo.

Convidamos outras pessoas a trabalhar conosco em pesquisas nessa direção, muitas vezes em torno da quebra da medição de recursos no EVM. A dissertação Broken Meter é um bom ponto de partida para a investigação nesta área.

Abstração da Conta

Adoraríamos incluir 1 ou mais EIPs, mas gostaríamos de ver mais comparação da experiência do usuário e da experiência do desenvolvedor entre cada proposta para entender melhor as compensações e o esforço de integração de ferramentas. Estamos a analisar as seguintes PEI/ERC, mas não hesite em aconselhar-nos:

• EIP-3074: Código de Operação AUTH e AUTHCALL
• ERC-4337: Usando Alt Mempool para abstração de conta
• EIP-5806: Transação delegada
• EIP-5920: Código de Operação PAY
• EIP-6913: Diretiva SETCODE
• EIP-7377: Transações de migração
• RIP-7560: Native Account Abstraction - Core EIP - Fellowship of Ethereum Magicians

O que precisamos notar acima é que “abstração de conta” é como “função de verificação abstrata, o objetivo principal é implementar a rotação de chaves secretas, fazer chave multisig e nos fornecer um caminho para alcançar automaticamente a resistência quântica”.