Começamos a construir Reth em 2022 para fornecer resiliência ao Ethereum L1 e resolver a escalabilidade da camada de execução na Camada 2.

Hoje estamos entusiasmados por partilhar o percurso da Reth rumo a 1 gigagás por segundo em L2 em 2024, e o nosso roteiro a longo prazo para ir além disso.

Convidamos o ecossistema a colaborar connosco enquanto impulsionamos a fronteira do desempenho e da avaliação rigorosa no mundo das criptomoedas.

Estamos escalados ainda?

Existe um caminho muito simples para as criptomoedas alcançarem escala global e escaparem da especulação como o caso de uso dominante: as transações precisam ser baratas e rápidas.

Como mede a performance? O que significa gás por segundo?

O desempenho é tipicamente medido pela métrica “Transações Por Segundo” (TPS). Especialmente para Ethereum e outras blockchains EVM, uma medida mais matizada e talvez precisa é “gás por segundo.” Esta métrica reflete a quantidade de trabalho computacional que a rede pode lidar a cada segundo, onde “gás” é uma unidade que mede o esforço computacional necessário para executar operações como transações ou contratos inteligentes.

Padronizar em torno do gás por segundo como uma métrica de desempenho permite uma compreensão mais clara da capacidade e eficiência de uma blockchain. Também ajuda a avaliar as implicações de custo no sistema, protegendo-se contra potenciais ataques de Negação de Serviço (DOS) que poderiam explorar medições menos refinadas. Esta métrica ajuda a comparar o desempenho em diferentes correntes compatíveis com a Máquina Virtual Ethereum (EVM).

Propomos à comunidade EVM que adote gás por segundo como métrica padrão, juntamente com a incorporaçãooutras dimensões do preço do gáscriar um padrão de desempenho abrangente.

Onde estamos hoje?

O gás por segundo é determinado dividindo o uso de gás alvo por bloco pelo tempo de bloco. Aqui, mostramos a taxa atual de gás por segundo e latência em várias cadeias EVM L1s e L2s (não exaustivas):

Enfatizamos o gás por segundo para avaliar minuciosamente o desempenho da rede EVM, capturando tanto os custos de computação quanto de armazenamento. Redes como Solana, Sui ou Aptos não estão incluídas devido aos seus modelos de custos distintos. Incentivamos esforços para harmonizar os modelos de custos em todas as redes blockchain, a fim de permitir comparações abrangentes e justas.

Estamos a trabalhar numa suite de benchmarking contínuo para Reth replicando carga de trabalho real, se quiser colaborar nisto, por favor entre em contacto. Precisamos de um TPC Benchmarkpara nodos.

Como é que o Reth chegará a 1 gigagas por segundo? E depois disso?

Fomos parcialmente motivados a construir Reth em 2022 pela necessidade premente de ter um cliente construído para rollups em escala web. Acreditamos que temos um caminho promissor pela frente.

Reth já alcança 100-200mgas/s durante a sincronização ao vivo (incluindo a recuperação dos remetentes, a execução de transações e o cálculo do trie em cada bloco); 10x a partir daqui leva-nos ao nosso objetivo a curto prazo de 1 gigagás/s.

À medida que avançamos no desenvolvimento do Reth, nosso plano de escalonamento tem que equilibrar escalabilidade com eficiência:

• Dimensionamento Vertical: O nosso objetivo aqui é maximizar a utilização de cada "caixa" ao máximo. Ao otimizar como cada sistema individual lida com transações e dados, podemos melhorar significativamente o desempenho geral, tornando-o também mais eficiente para os operadores individuais de nós.
• Escalonamento Horizontal: Apesar das otimizações, o volume de transações em escala web excede o que qualquer servidor único pode lidar. Para resolver isso, queremos implementar uma arquitetura escalonada horizontalmente, semelhante a um modelo Kubernetes para nós de blockchain. Isso significa distribuir a carga de trabalho por vários sistemas para garantir que nenhum nó único se torne um gargalo.

As otimizações que estamos a explorar aqui não envolvem a resolução crescimento do estado, que estamos a investigar separadamente.

Aqui está um resumo de como pretendemos chegar lá:

Em toda a pilha, também estamos otimizando para IO e CPU usando o modelo de ator, para permitir que cada parte da pilha seja implantada como um serviço com controle fino sobre sua utilização. Finalmente, estamos avaliando ativamente bancos de dados alternativos, mas ainda não decidimos sobre um candidato.

O roadmap de escalabilidade vertical da Reth

O nosso objetivo aqui é maximizar o desempenho e a eficiência de um único servidor ou portátil a executar o Reth.

EVM Just-In-Time & Ahead-of-Time

Em ambientes de blockchain como a Máquina Virtual Ethereum (EVM), a execução de bytecode ocorre através de um interpretador, que processa sequencialmente as instruções. Este método introduz overhead porque não executa instruções nativas de montagem diretamente, operando em vez disso através da camada VM.

A compilação Just-In-Time (JIT) aborda isso convertendo o bytecode em código de máquina nativo imediatamente antes da execução, melhorando assim o desempenho ao contornar o processo interpretativo da VM. Esta técnica, que compila contratos em código de máquina otimizado antecipadamente, está bem estabelecida em outras VMs como Java e WebAssembly.

No entanto, o JIT pode ser vulnerável a código malicioso projetado para explorar o processo JIT, ou pode ser muito lento para ser executado ao vivo durante a execução. Reth irá compilar Antes do Tempo (AOT) os contratos com maior demanda e armazená-los no disco, para evitar que o bytecode não confiável tente abusar da nossa etapa de compilação de código nativo durante a execução ao vivo.

Temos estado a trabalhar num compilador JIT/AOT para o Revm, que está atualmente a ser integrado com o Reth. Vamos tornar isto de código aberto nas próximas semanas, assim que terminarmos os nossos testes de benchmarking. Cerca de 50% do tempo de execução é gasto no intérprete EVM em média, por isso isto deverá proporcionar uma melhoria na execução do EVM de cerca de 2 vezes, embora em alguns casos mais intensivos em computação possa ser ainda mais impactante. Vamos partilhar os nossos testes de benchmarking e a integração do nosso próprio JIT EVM no Reth nas próximas semanas.

EVM Paralelo

O conceito de uma Máquina Virtual Ethereum Paralela (Parallel EVM) permite o processamento simultâneo de transações, divergindo do modelo tradicional de execução em série da EVM. Temos 2 caminhos a seguir aqui:

1. Histórico de Sincronização: Na sincronização histórica, podemos calcular o melhor cronograma de paralelização possível analisando transações passadas e identificando todos os conflitos de estado histórico. Veja nossa tentativa inicial nisso em um antigo ramo em Github.
2. Sincronização ao Vivo: Para sincronização ao vivo, podemos usar Bloco STM-como técnicas para executar especulativamente sem qualquer informação adicional como listas de acesso. Este algoritmo tem um desempenho fraco durante períodos de forte contenção de estado, por isso queremos explorar a mudança entre a execução serial e paralela dependendo da forma da carga de trabalho, bem como prever estaticamente quais slots de armazenamento serão acedidos para melhorar a qualidade do paralelismo. Veja um PoC de uma equipa terceiraaqui.

Com base na nossa análise histórica, cerca de 80% das ranhuras de armazenamento do Ethereum são acedidas de forma independente, o que significa que o paralelismo poderia resultar numa melhoria de até 5x na execução do EVM.

Melhorar o Compromisso do Estado

Nós recentemente escreveu sobreo impacto da raiz do estado no desempenho e as diferenças entre o modelo de banco de dados Reth de outros clientes, bem como por que é importante.

No modelo Reth, calcular a raiz do estado é um processo separado da execução de transações (ver nossa código) permitindo o uso de lojas KV padrão que não precisam saber nada sobre o trie. Isso atualmente leva >75% do tempo de ponta a ponta para selar um bloco, e é uma área muito emocionante para otimizar.

Identificamos os seguintes 2 “ganhos fáceis” que podem nos dar 2-3x no desempenho da raiz do estado, sem quaisquer alterações no protocolo:

1. Raiz de Estado Totalmente Paralelizada: Neste momento, apenas recalculamos a árvore de armazenamento para contas alteradas em paralelo, mas podemos ir mais longe e também calcular a árvore de contas em paralelo, enquanto os trabalhos de raiz de armazenamento são concluídos em segundo plano.
2. Raiz de Estado em Pipeline: Pré-busque nós de árvore intermediários do disco durante a execução, notificando o serviço de raiz de estado sobre os slots de armazenamento e contas tocadas.

Indo além disso, vemos algumas opções avançadas ao divergir do comportamento do estado raiz do Ethereum L1:

1. Raiz do Estado menos frequente: Em vez de calcular a raiz do estado a cada bloco, calcule-a a cada T blocos. Isso reduz o % geral do tempo gasto na raiz do estado em todo o sistema e pode ser a solução mais fácil e eficaz.
2. Raiz de Estado Trailing: Em vez de ter que calcular a raiz do estado no mesmo bloco, deixe-a atrasar-se alguns blocos. Isso permite que a execução avance sem bloquear o cálculo da raiz do estado.
3. Substitua o Codificador RLP & Keccak256: Em vez de codificar com RLP, pode ser mais barato apenas concatenar os bytes e usar uma função de hash mais rápida como o Blake3.
4. Árvore mais larga: Aumente a n-aridade da árvore, para reduzir a amplificação de E/S devido à profundidade logN da árvore trie.

Existem algumas perguntas aqui:

1. Quais são os efeitos de segunda ordem das alterações acima nos clientes leves, L2s, pontes, coprocessadores e outros protocolos que dependem de provas frequentes de conta e armazenamento?
2. Podemos otimizar o compromisso de estado tanto para a prova SNARK quanto para a velocidade de execução nativa?
3. Qual é o compromisso estadual mais amplo que podemos obter com as ferramentas que temos disponíveis? Quais são os efeitos de segunda ordem em torno do tamanho da testemunha?

Roteiro de escalonamento horizontal da Reth

Vamos executar em vários dos pontos acima ao longo de 2024 e atingir nossa meta de 1gigagas/seg.

No entanto, a escalabilidade vertical encontra, em última instância, limites físicos e práticos. Nenhuma máquina única pode lidar com as necessidades computacionais do mundo. Pensamos que existem 2 caminhos a seguir aqui, que nos permitem escalar introduzindo mais caixas à medida que mais carga chega:

Multi-Rollup Reth

As pilhas L2 de hoje requerem a execução de vários serviços para seguir a cadeia: L1 CL, L1 EL, a função de derivação L1 -> L2 (que pode estar incluída com o L2 EL) e o L2 EL. Embora seja ótimo para modularidade, isso se torna complicado ao executar várias pilhas de nós. Imagine ter que executar 100 rollups!

Queremos permitir o lançamento de rollups no mesmo processo que o Reth e reduzir o custo operacional de executar milhares de rollups para quase zero.

Já estamos a trabalhar nisto com o nosso Projetos de Extensões de Execução([1], [2]) mais nas próximas semanas aqui.

Reth nativo na nuvem

Os sequenciadores de alto desempenho podem ter demanda suficiente em uma única cadeia que precisam escalar para além de uma única máquina. Isso não é possível nas implementações de nó monolíticas de hoje.

Queremos permitir a execução de nós Reth nativos da Cloud, implementados como um conjunto de serviços que podem ajustar automaticamente à procura de computação e utilizar o armazenamento de objetos na nuvem aparentemente infinito para persistência. Esta é uma arquitetura comum em projetos de bases de dados serverless como NeonDB, CockroachDB ou Amazon Aurora.

Verpensamentos iniciaisda nossa equipa sobre algumas formas como poderíamos abordar este problema.

Perspectiva

Pretendemos implementar este roteiro incrementalmente para todos os utilizadores do Reth. A nossa missão é dar a todos acesso a 1 gigagas/s e além. Vamos testar as nossas otimizações no Reth AlphaNet e esperamos que as pessoas construam nós de alto desempenho modificados usando o Reth como um SDK.

Existem algumas perguntas para as quais ainda não encontramos respostas.

• Como pode o Reth ajudar a melhorar o desempenho em todo o ecossistema L2?
• Como medimos adequadamente cenários de pior caso quando algumas de nossas otimizações podem ser para o caso médio?
• Como gerimos a tensão entre o L1 e o L2 potencialmente a divergir?

Não temos respostas para muitas destas perguntas, mas temos pistas iniciais promissoras suficientes para nos manter ocupados por um tempo e esperamos que esses esforços tragam frutos nos próximos meses.

Aviso legal：

1. Este artigo é reproduzido a partir de [Gateparadigma], Todos os direitos de autor pertencem ao autor original [Georgios Konstantopoulos]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.