Título original: "Atualização 014 da Reunião de Desenvolvedores do Ethereum Core"
Fonte original: Atualização AllCoreDevs
Autor original: Tim Beiko
Compilação original: Ethereum.cn
Bem-vindo a uma nova edição da atualização AllCoreDevs (Ethereum Core Developer Conference) – a última de 2022.
visão geral
O conteúdo da atualização Shanghai/Capella foi finalizado: retiradas, EOF e algumas pequenas modificações... desde que não atrasem as retiradas.
O espaço Blob está chegando: o EIP-4844 estará no centro da próxima atualização do Ethereum e sua cerimônia de convocação começará em breve.
Do lado técnico, estão em curso esforços para coordenar os processos de atualização da camada de execução e da camada de consenso. Também estamos vendo discussões ativas sobre como incorporar melhor a contribuição da comunidade no processo.
A Protocol Guild divulgou um relatório piloto de médio prazo e um plano aproximado para expandir o tamanho dos mantenedores de primeiro nível e apoiá-los melhor em 2023.
Atualização Xangai/Capella
Em um recente AllCoreDevs, a equipe do cliente chegou a um consenso sobre o escopo final da atualização Shanghai/Capella. Embora o nome da atualização possa estar em debate, a equipe é clara quanto ao seu escopo. A principal característica da atualização é a introdução de retiradas da Beacon Chain para os stakers. A implementação desse recurso o mais rápido possível é algo que a equipe do cliente não quer comprometer, portanto, outros recursos da atualização precisam estar prontos ao mesmo tempo ou correm o risco de serem abandonados.
A Especificação da Camada Executiva de Xangai lista todos os EIPs incluídos:
EIP-3540: Formato de objeto EVM (EOF) v1
EIP-3651: Reduza o custo do gás para acessar endereços COINBASE
EIP-3670: EOF – Verificação de Código
EIP-3855: Adicionado código de operação PUSH 0
EIP-3860: Limite o tamanho do código inicial e introduza a medição de gás
EIP-4200: EOF - salto relativo estático
EIP-4750: EOF - Importação de funções
EIP-4895: Retiradas push da cadeia de beacon como operação do sistema
EIP-5450: EOF – Verificação de pilha
Embora a lista seja longa, ela pode ser dividida em três partes diferentes: pequenas melhorias, formatos de objetos EVM e retiradas. A seguir, iremos apresentá-los um por um:
Pequenas melhorias
EIP-3651: Warm COINBASE (reduz o custo do gás para acessar endereços COINBASE)
Este EIP corrige um descuido no EIP-2929, onde o custo do gás para acessar determinados campos de dados foi modificado com base no fato de os dados já estarem na memória do cliente (WARM) ou precisarem ser recuperados do disco (COLD).
EIP-2929 define dois dados na memória do cliente como WARM no início de cada transação: o endereço de envio e o endereço de recebimento. EIP-3651 adiciona um terceiro endereço a esta lista, o endereço COINBASE (ou seja, feeRecipient), pois é também o endereço que o cliente possui na memória ao processar transações em bloco.
EIP-3855: Instrução PUSH 0 (novo código de operação `PUSH 0)
Como o nome sugere, o EIP-3855 introduz um opcode que coloca o valor 0 na pilha. Pressionar 0 é frequentemente usado para preencher valores no EVM, este opcode fornecerá uma maneira mais eficiente e barata de fazer isso.
EIP-3860: Limitar e medir o código inicial (limitar o tamanho do código inicial e introduzir a medição de gás)
Este EIP adiciona um limite ao tamanho do código inicial e introduz a medição de gás com base em seu comprimento. Seu limite superior de tamanho adiciona uma invariante ao EVM, facilitando o entendimento e a proposta de modificações.
Introduz um overhead de 2 gases por 32 bytes para o initcode, que é utilizado para pagar a análise jumpdest que o cliente deve realizar antes da execução, que não está listada no medidor de gás.
formato de objeto
A maior parte do EIP incluído na atualização de Xangai faz parte de um único recurso: o EVM Object Format (EOF). O trabalho foi dividido em 5 EIPs diferentes para ajudar os desenvolvedores clientes a entender cada modificação individual, mas para fornecer uma visão geral de nível superior, os desenvolvedores lançaram uma especificação unificada. Os EIPs desses cinco EOFs são:
EIP-3540: formato de objeto EVM versão 1
EIP-3670: EOF – Verificação de Código
EIP-4200: EOF - salto relativo estático
EIP-4750: EOF – Importação de funções
EIP-5450: EOF – Verificação de pilha
Vale ressaltar que o primeiro passo do EOF foi a atualização London EIP-3541, que reservou o prefixo 0xEF 00 para o contrato EOF. O escopo EOF da atualização de Xangai também mudou nos últimos meses.
Em fevereiro, a equipe do cliente concordou em considerar a atualização em Xangai para incluir os dois EIPs EOF menores: EIPs 3540 e 3670. Todos servirão como blocos de construção, mas não fornecerão funcionalidade completa sem a introdução do EIP 4200, 4750 e 5450. Embora seja possível estender o EOF, a incompatibilidade com versões anteriores pode exigir uma nova versão. Como os contratos pré-EOF ou EOF com uma versão específica devem sempre ser executáveis, cada nova versão EOF significa que os desenvolvedores clientes devem manter um novo conjunto de regras de execução EVM em paralelo com as regras antigas.
Antes do EOF, os clientes mantinham apenas um conjunto de regras EVM por vez. A base de código também suporta regras EVM anteriores, que são modificadas a cada atualização da rede, mas quando chegam ao topo da blockchain, apenas as regras mais recentes devem ser aplicadas. Após a implantação do EOF, o cliente manterá dois conjuntos paralelos de regras EVM, para que possa executar código em contratos EOF e não EOF. Em outras palavras, o aumento de versões de EOF aumenta o número de conjuntos de regras EVM paralelos, em vez de consecutivos, que devem ser mantidos.
Para tanto, nos últimos meses, as equipes dos clientes começaram a favorecer uma abordagem de “grande EOF”. Desta forma, embora tenham que implementar conjuntos de modificações maiores, a versão EOF durará mais e reduzirá o número de “EVMs paralelos” que precisam ser mantidos. Portanto, os desenvolvedores consideraram um “grande EOF” e eventualmente o incluíram na atualização de Xangai.
Dito isto, recursos maiores são obviamente mais difíceis de implementar e testar, e a equipe não quer ver o EOF atrasar severamente as retiradas da cadeia de beacon. Portanto, se a implementação do EOF não for concluída até janeiro e eles não puderem interoperar rapidamente entre si, a equipe do cliente concorda em transferir o EOF de Xangai para atualização.
Com estes contextos em mente, vamos agora apresentar brevemente cada EOF EIP:
EIP-3540: Formato de objeto EVM (EOF) v1 (Formato de objeto EVM versão 1)
Este EIP introduz o “contêiner” no contrato EOF. Ele adiciona tags para distinguir o código e as partes de dados do contrato e evita que contratos EOF que não estejam em conformidade com o formato sejam implantados. Isto garante que qualquer contrato EOF na cadeia seguirá um formato válido, o que simplifica a interação com esses contratos, bem como a análise estática dos mesmos.
EIP-3670: EOF – Validação de Código (EOF – Validação de Código)
Com base no contêiner introduzido pelo 3540, o EIP-3670 garante que o código no contrato EOF seja válido ou impeça sua implantação.
Isto significa que os opcodes indefinidos não podem ser implantados em contratos EOF, o que tem o benefício adicional de reduzir o número de versões EOF que precisam ser adicionadas. Se um novo opcode for adicionado, as regras de validação podem simplesmente ser alteradas para ativá-lo e garantir que nenhum contrato EOF implantado faça referência a ele em sua seção de código.
EIP-4200: EOF – Saltos relativos estáticos (EOF – Saltos relativos estáticos)
O EIP-4200 apresenta os primeiros opcodes específicos de EOF: RJUMP, RJUMPI e RJUMPV, que codificam destinos como valores imediatos assinados. Esses novos opcodes JUMP podem ser usados por compiladores para otimizar a sobrecarga de gás porque eliminam a necessidade de análise jumpdest em tempo de execução, que é exigida pelos opcodes JUMP e JUMPI existentes.
EIP-4750: EOF - Funções (funções introduzidas por EOF)
O EIP-4750 vai um passo além do 4200: não permite o uso de opcodes JUMP e JUMPI e adiciona alternativas para funções que não podem ser copiadas. Ele é implementado introduzindo seções de função específicas no bytecode EOF. Essas funções podem saltar dos novos opcodes JUMPF, CALF e RETF, respectivamente, e usá-los para chamar e retornar.
EIP-5450: EOF - Validação de Pilha (EOF-Stack Validation)
Finalmente, o EIP-5450 adiciona outra verificação de validação para contratos EOF, desta vez na pilha. Este EIP evita que contratos EOF implantem código que pode causar estouro de pilha e estouro em alguns casos. Com este EIP, os clientes podem reduzir o número de verificações de validação ao executar contratos EOF porque têm melhores garantias em relação às exceções relacionadas à pilha.
Como um especialista não-EVM e muito focado no próprio EIP, não há muito que possa dizer sobre isso! Se os leitores quiserem saber mais sobre EOF, recomendo os tweets relevantes postados por lightclients da equipe Geth e Leo da equipe Solidity.
Retirada da Corrente de Beacon
Por último, mas não menos importante, a parte principal de "Shapella" (Nota do tradutor: nome coletivo de Shanghai/Capella) é a retirada da cadeia de faróis. Esta parte da mudança é descrita na especificação da camada de consenso e no EIP-4895. Agora existe uma meta-especificação um pouco desatualizada que une essas mudanças.
Em alto nível, a mecânica das retiradas é a seguinte:
Ao propor um bloco, o validador verifica linearmente o índice do validador para encontrar os primeiros 16 validadores com credenciais 0x01, que precisam atender a uma das seguintes condições:
Ter um saldo acima de 32 ETH (ou seja, ter recompensas de validador acumuladas)
São retiráveis (ou seja, saíram totalmente do conjunto de validadores)
O saldo é superior a 32 ETH (ou seja, a recompensa do validador foi obtida)
É extraível (retirável, ou seja, saiu completamente do conjunto validador)
A partir deles, o validador criará uma lista de saques a serem incluídos em seu ExecutionPayload. Cada item dessa lista contém o seguinte:
O validador criará uma lista de retirada desses validadores e a empacotará em seu ExecutionPayload. Cada item da lista contém o seguinte:
WithdrawalIndex: Índice de todas as transações de saque que foram feitas - isso ajuda a distinguir saques do mesmo valor do mesmo endereço, do mesmo validador
ValidatorIndex: o índice validador onde o saldo foi levantado
ExecutionAddress: O endereço ETH da camada de execução, para onde os saques devem ser enviados
Valor: O valor enviado para ExecutionAddress, esse valor é medido em gwei (não wei)
Os clientes da camada de execução farão essas retiradas após a execução das transações durante a construção ou processamento de blocos. Em outras palavras, as retiradas são processadas de maneira semelhante às recompensas de prova de trabalho registradas e não competem com as transações do usuário por espaço de bloco.
Existem alguns outros detalhes dignos de nota:
Ao processar saques, não há diferença na prioridade/ordem entre “fundos totais” e “fundos parciais”. As retiradas totais ocorrem quando um validador sai da equipe de saída, enquanto as retiradas parciais ocorrem periodicamente, ou seja, quando é realizada uma varredura linear do conjunto de validadores e o número de índice de um determinado validador é varrido.
Para que os saques sejam processados, os validadores devem utilizar credenciais 0x01, que são representadas por endereços ETH. Somente credenciais do par de chaves BLS 0x00 são permitidas quando a cadeia de beacon fica online. Para iniciar uma retirada, um validador com credenciais 0x00 precisará assinar uma mensagem BLSToExecutionChange. Eles serão ativados na atualização Capella. Haverá uma variedade de ferramentas usadas para assinar esta mensagem, e os validadores podem esperar suporte e tutoriais para essas ferramentas.
A verificação dos validadores é feita por bloco. Se não houver 16 retiradas para processar após a digitalização de um subconjunto do conjunto de validadores, o validador irá parar a digitalização e o próximo validador começará a partir do último índice de validador verificado.
Como de costume, haverá vários testnets e testnets de desenvolvedores (talvez até alguns novos testnets!) para que os validadores executem todo o processo e resolvam quaisquer problemas antes que a rede principal entre no ar.
Shanghai/Capella não é a única atualização que está progredindo! A equipe de desenvolvedores ainda está ansiosa pela próxima atualização.
Atualização em Cancún
Como o conteúdo da atualização de Xangai já está completo, muitos EIPs (CFI) considerados para a atualização não puderam entrar na atualização de Xangai. A equipe do cliente começa a discutir quais EIPs devem ser considerados para a próxima atualização: a atualização Cancún (nome da camada de consenso a ser determinado)
Em termos da camada de consenso, o EIP-4844 se tornou o primeiro EIP incluído na especificação após a atualização do Capella. Não há (ainda) uma especificação para a camada executiva que possa implementar esse layout, mas a equipe da camada executiva concordou em seguir um caminho semelhante e centralizar o EIP-4844 na próxima atualização.
Seguindo a convenção de atualizações usando os nomes das cidades onde a Devcon foi realizada, foi criado cancun.md, com o EIP-4844 oficialmente incluído na atualização.
Esta decisão aconteceu no último minuto da última reunião AllCoreDevs de 2022, pelo que não houve tempo para trabalhar noutras propostas. Os EIPs que entraram na atualização CFI em Xangai, mas não foram incluídos no final, foram movidos para a lista CFI para a atualização de Cancun. Uma postagem também foi aberta no fórum Ethereum Magicians para discutir os EIPs candidatos em Cancun. As discussões sobre o escopo das melhorias em Cancún deverão começar a sério no início do próximo ano.
Cerimônia KZG
Outra coisa a se esperar em relação à atualização de Cancún é a Cerimônia KZG, que é um requisito do EIP-4844.
Este ritual irá gerar a aleatoriedade necessária para verificar a validade dos dados do blob. Para que seja considerado seguro, apenas um participante precisa ser honesto. Em outras palavras, se todos os participantes, exceto um, conspirarem, todo o processo será criptograficamente seguro.
A cerimônia começa em janeiro e ficará aberta a todos por vários meses. Com uma meta de 10.000 participantes, está prevista para ser a maior cerimónia do género até à data! Se você quiser não perder nada, siga Trent Van Epps no Twitter!
Processo de atualização pós-fusão
Conforme mencionado na atualização anterior, após a fusão, a coordenação do processo de atualização do Ethereum na camada de execução e na camada de consenso é uma tarefa importante. De uma perspectiva de alto nível, a camada de execução usa Yellow Paper e EIP para descrever as modificações, enquanto a camada de consenso usa especificações executáveis do Python.
A vantagem do processo da camada executiva é que o EIP é bem conhecido da comunidade e está formatado de uma forma que demonstra claramente o raciocínio por trás da proposta. Livros amarelos com muito conteúdo matemático combinados com EIPs e a necessidade de colocar as especificações de volta no contexto de cada EIP tornam as especificações da camada de execução difíceis de entender e estender.
O problema com a camada de consenso é o oposto: ela tem uma especificação clara e compreensível em um único repositório, mas as mudanças não são tangíveis e as propostas ficam enterradas em outros PRs públicos no repositório.
Com a introdução da especificação da camada de execução Ethereum, esperamos reduzir essa lacuna do lado da camada de execução. E, com alguma disputa de processo, poderemos conseguir introduzir o EIP no processo da camada de consenso!
Dito isso, à medida que o escopo da atualização de Xangai foi discutido e finalizado, ficou claro que outra parte do processo poderia estar faltando: permitir que a comunidade expressasse suas preferências relativas por mudanças e se envolvesse em discussões sobre todo o escopo da atualização (em vez de EIPs individuais) Discuta isso no local e torne-o parte das decisões da reunião AllCoreDevs e da camada de consenso.
Ainda não está claro como será – adoraria sugestões! — mas à medida que crescia o número de partes interessadas ativamente envolvidas nas alterações do protocolo, assim como o número de áreas afetadas pelas alterações da camada 1, ficou claro que precisávamos de algo.
Felizmente, não precisamos começar do zero. Ethereum Magicians existe há anos e seus encontros offline, reuniões de grupo dedicadas ou reuniões comunitárias podem ser bons pontos de partida para expansão.
Espere mais progresso nesta frente no início de 2023!
Atualização da Guilda do Acordo
Com o piloto do Protocol Guild (PG) agora na metade, eles divulgaram um relatório para dar uma olhada em como as coisas estão indo e considerar quais são os próximos passos do projeto.
Como lembrete, PG é um mecanismo de financiamento sem permissão para desenvolvedores de clientes Ethereum Layer 1, pesquisadores de protocolo e contribuidores de apoio (como você).
Este mecanismo está centrado no indivíduo e não na organização. Resumindo, cada membro é elegível para uma parte dos tokens da guilda, ponderados com base no tempo que contribuíram para o Ethereum. A adição e exclusão de membros são feitas no verdadeiro estilo Ethereum - com base em um conjunto de padrões e um consenso aproximado dentro do PG. Esta lista será então colocada em cadeia usando o contrato dividido 0xSplit. O doador pode então enviar fundos diretamente para o endereço do destinatário ou para um contrato de aquisição que libere fundos para o endereço do destinatário.
O relatório provisório piloto está resumido neste tweet. Aqui estão alguns destaques
O piloto arrecadou US$ 9,7 milhões de organizações como Lido, Uniswap, ENS, NounsDAO e MolochDAO, bem como doadores regulares de indivíduos (obrigado Tetranode!) - obrigado a todos por tornar isso possível!
O PG tinha 90 membros no lançamento e agora tem 128, com US$ 5 milhões distribuídos entre eles
Em média, cada membro recebeu US$ 39.000, sendo o menor valor de US$ 13.000 e o maior de US$ 79.000.
A arquitetura do PG está mudando e suportará L2 e eliminará a necessidade de multi-sig para atualizar pesos
Esses primeiros resultados mostram que o PG está funcionando conforme planejado: um mecanismo para distribuir uma cesta de tokens para um grupo crescente e autoincubado de contribuidores de protocolo. Este projecto não seria o que é hoje sem o apoio generoso dos doadores-piloto.
Olhando para o futuro, agora é o momento de expandir o alcance do PG e concretizar todo o seu potencial: fornecer aos mantenedores do Ethereum uma remuneração competitiva e ajustada ao risco. A coisa mais fácil a fazer aqui é que o projeto doe para o PG desde o início, como disse Danny Ryan no tweet de lançamento do PG.
A maior parte das doações no piloto veio de grandes projetos com grandes montantes de financiamento. Se a Guilda do Protocolo conseguir convencer esses projetos a doar para o PG desde o primeiro dia, quando seus tokens ainda são verdadeiramente “inúteis”, então os mantenedores do Ethereum poderão se beneficiar de toda a trajetória ascendente desses projetos de sucesso.
Quando há projetos suficientes envolvidos, os incentivos podem manter os melhores talentos em acordos de manutenção, em vez de afastá-los.
Para apoiar este e muitos outros tipos de doação, o PG necessitará de uma revisão tecnológica. A próxima versão suportará L1 e L2 e reduzirá ainda mais a sua pegada de governação na cadeia.
Se você é um projeto que gostaria de doar para o Protocol Guild, entre em contato comigo - meus DMs estão abertos!
Seguir
Isso encerra 2022... Que ano extraordinário! Há três meses, nem éramos fundidos! Agora que o Ethereum tem a prova de aposta rodando silenciosamente em segundo plano, o foco mudou para transações futuras.
Como todos retornam em janeiro, você pode esperar:
Shanghai/Capella atualizou o testnet do desenvolvedor e o shadow fork
Cerimônia KZG vai online
Discussões em torno de Cancún e como o processo de atualização da rede deve evoluir para melhor capturar as preferências da comunidade
O piloto da guilda protocolar terminará e anunciaremos a estrutura pós-piloto.