É um segredo pouco conhecido que, além de nosso cliente da camada de consenso (eth2), estamos construindo um cliente da camada de execução (eth1) - com o objetivo de que esteja pronto para o merge.
Por que isso é importante? Um dos principais motivos atuais é a diversidade de clientes.
1/ A diverse execution-layer client ecosystem is at the heart of all that we’re building together.
— Ethereum (@ethereum) August 24, 2021
Today, we're excited to announce that @compoundgrants, @krakenfx, @LidoFinance, @synthetix_io, @graphprotocol & @Uniswap are donating $250K each to support #Ethereum client teams.
Para simplificar, quanto mais clientes funcionais e de desempenho tivermos em ambas as camadas (consenso + execução), melhor e mais resiliente o Ethereum poderá ser.
* we already have the most client diversity out of any chain
— carlbeek.eth (@CarlBeek) October 15, 2021
* but we can do better. the beacon chain was built to incentivise this, and so stakers are pushed to run minority clients
* by having ensuring that no one client is dominant, we harden ourselves against bugs
Embora a diversidade de clientes seja crucial para um Ethereum resiliente, por si só não justificaria um esforço de engenharia tão grande de nossa parte.
Nossa visão de alto nível, e o principal motivo pelo qual estamos desenvolvendo nosso próprio cliente de camada de execução, é para uma integração fácil e contínua com o Status - desktop e móvel.
I can't wait to run Nimbus straight from Status Desktop #hyped
— Jarrad Hope | @ethstatus (@0xc1c4da) August 12, 2020
Tal integração requer um cliente Ethereum customizado, "embutível" e ultraeficiente - tanto em ambientes de execução como de camada de consenso.
Relacionamento com o Fluffy
Para alcançar o acima exposto, é necessário otimizar o consumo de recursos de maneiras novas. Na camada de execução, pretendemos oferecer uma combinação única de menor uso de espaço e sincronização mais rápida.
Nosso método de sincronização, que chamamos de sincronização beam-ish, permitirá que os nós participem da rede antecipadamente, enquanto a sincronização de dados continua em segundo plano - este comportamento é semelhante ao Fluffy (nosso cliente leve de Rede do Portal) e nosso trabalho lá será reutilizado aqui - a ideia é que eventualmente iremos integrar o Fluffy em nosso cliente de execução.
Além de integrar o Fluffy, um de nossos principais objetivos de design é facilitar ao máximo que nossos clientes de consenso e execução sejam agrupados em um único software; isso vai melhorar drasticamente a UX da execução de um cliente pós-merge, tornando-o muito semelhante à execução de um cliente PoW (proof-of-work) pré-merge atualmente.
Isso está vinculado à nossa visão abrangente: diminuir significativamente a barreira para executar nós completos e clientes leves e, ao fazer isso, ajudar a tornar o Ethereum o mais acessível e descentralizado possível.
Decentralization is the cost to run a full node. Not because running a full node is inherently anything special, but because it's a means to an end: self-soverignty. Being able to detect when block producers try to change the rules that we the community all agree on.
— John Adler | ✨⛽ (@jadler0) September 4, 2021
Progresso Recente
Alguns destaques dos últimos 6 meses incluem:
- A equipe expandiu significativamente: conheça Jamie e Jordan
- Financiamento renovado da EF para acelerar o desenvolvimento
- Compatibilidade do fork Berlin e London concluída (EIP-1559): agora passamos em quase todo o conjunto de testes EF Hive e 100% dos testes de execução de contrato (47.951 testes)
- Novas APIs GraphQL e WebSocket, complementando JSON-RPC
- Compatibilidade EVMC, com suporte a plug-ins EVM otimizados de terceiros. Até 100x de economia de memória durante a execução do contrato. EVM assíncrono para executar muitos contratos em paralelo (enquanto esperam pelos dados da rede)
- Validação de proof-of-authority para a rede de teste Goerli. Protocolos de rede atualizados para funcionar com os protocolos mais recentes eth/65-66 e snap/1
- Um protótipo de novo mecanismo para sincronização de estado que combina o que foi chamado de Sincronização Rápida, sincronização Snap e sincronização Beam de forma autoajustável e que permite ao usuário participar da rede (ler contas, executar transações etc.) enquanto a sincronização ainda está em progresso
- Um pool de transações de trabalho
Spotted in the @ethnimbus discord today.. pic.twitter.com/1Ffqgd1iDz
— Jacek Sieka (@jcksie) October 8, 2021
nimbus --goerli hoje?"Ainda em Progresso
Embora tenhamos feito um progresso significativo em muitas frentes, ainda temos muito trabalho pela frente na preparação para o merge. Do jeito que está, estamos atualmente trabalhando em:
- Um redesenho significativo do banco de dados de armazenamento para usar menos espaço em disco e funcionar mais rápido
- A capacidade de postar uma transação por conta própria
- Implementação do EIP-3675 (também conhecido como O Merge)
In a month, we would like to launch a larger Merge devnet with better client distribution, once development stabilizes more.
— proto.eth 🚂 🦇 🔊 (@protolambda) October 11, 2021
4/5
Mantenha-se Atualizado
O plano para este mês é participar dos devnets do merge - um por semana - antes do testnet mais persistente planejado para a primeira semana de dezembro. Estamos trabalhando o máximo que podemos para tentar ter nosso cliente da camada de execução pronto a tempo. Nosso objetivo imediato, entretanto, é passar os marcos da interoperabilidade do merge em testes locais.
Se você tiver alguma dúvida ou quiser se manter atualizado sobre nosso progresso, por favor, junte-se ao nosso discord e/ou cadastre-se para receber nossa newsletter.