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 animados em compartilhar o caminho da Reth para 1 gigagás por segundo em L2 em 2024, e nosso roteiro de longo prazo para ir além disso.

Convidamos o ecossistema a colaborar conosco enquanto avançamos a fronteira de desempenho e benchmarking rigoroso em criptomoedas.

Estamos escalados ainda?

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

Como você mede o desempenho? 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 sutil e talvez precisa é "gás por segundo". Essa 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 de gás por segundo como uma métrica de desempenho permite uma compreensão mais clara da capacidade e eficiência de um blockchain. Também ajuda a avaliar as implicações de custo no sistema, protegendo contra possíveis ataques de Negação de Serviço (DOS) que poderiam explorar medições menos sutis. Essa métrica ajuda a comparar o desempenho em diferentes cadeias compatíveis com a Máquina Virtual Ethereum (EVM).

Propomos à comunidade EVM adotar gás por segundo como uma métrica padrão, juntamente com a incorporação outras dimensões de precificação de 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 de transferência atual de gás por segundo e latência em várias cadeias EVM L1s e L2s (não é exaustivo):

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

Estamos trabalhando em um conjunto de benchmarks contínuos para Reth replicando carga de trabalho real, se você deseja colaborar nisso, por favor entre em contato. Precisamos de um Benchmarks do TPCpara nós.

Como o Reth chegará a 1 gigagas por segundo? E além disso?

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

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

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

• Escalonamento Vertical: Nosso objetivo aqui é maximizar o uso de cada “caixa” ao seu máximo potencial. Ao otimizar como cada sistema individual lida com transações e dados, podemos melhorar significativamente o desempenho geral, tornando-o mais eficiente para os operadores individuais de nós.
• Escalonamento Horizontal: Apesar das otimizações, o volume de transações em escala web ultrapassa o que qualquer servidor único pode lidar. Para lidar com 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 explorando aqui não envolvem a resoluçãocrescimento do estado, que estamos pesquisando 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.

Roteiro de escalonamento vertical da Reth

Nosso objetivo aqui é maximizar o desempenho e a eficiência de um único servidor ou laptop executando Reth.

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

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

A compilação Just-In-Time (JIT) aborda isso convertendo o bytecode para código de máquina nativo logo antes da execução, melhorando assim o desempenho ao ignorar o processo interpretativo da VM. Essa 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ódigos maliciosos projetados 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 mais exigidos 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 trabalhado em um compilador JIT/AOT para Revm, atualmente em integração com Reth. Vamos tornar isso open source nas próximas semanas, assim que nossos testes de referência estiverem concluídos. Cerca de 50% do tempo de execução é gasto em média no interpretador EVM, então isso deve fornecer uma melhoria de execução do EVM de ~2x, embora em alguns casos mais intensivos em computação possa ser ainda mais impactante. Compartilharemos nossos testes de referência e a integração de nosso próprio JIT EVM em Reth nas próximas semanas.

EVM paralelo

O conceito de uma Máquina Virtual Ethereum Paralela (EVM Paralela) permite o processamento de transações simultâneas, divergindo do modelo de execução serial tradicional da EVM. Temos 2 caminhos adiante aqui:

1. Sincronização Histórica: 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óricos. Veja nossa tentativa inicial disso em um ramo antigo em Github.
2. Sincronização ao Vivo: Para sincronização ao vivo, podemos usar Bloco STM-like técnicas para executar especulativamente sem nenhuma informação adicional como listas de acesso. Este algoritmo tem baixo desempenho durante períodos de alta contenção de estado, então queremos explorar a alternância entre execução serial e paralela, dependendo do formato da carga de trabalho, bem como prever estaticamente quais slots de armazenamento serão acessados para melhorar a qualidade do paralelismo. Veja uma prova de conceito feita por uma equipe de terceirosaqui.

Com base em nossa análise histórica, cerca de 80% dos slots de armazenamento do Ethereum são acessados independentemente, o que significa que o paralelismo poderia resultar em um aumento de até 5 vezes na execução do EVM.

Melhorando 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çõesver nossos código) possibilitando o uso de lojas KV padrão que não precisam saber nada sobre a trie. Atualmente, isso leva mais de 75% do tempo de ponta a ponta para selar um bloco e é uma área muito emocionante para otimizar.

Identificamos as seguintes 2 “vitórias fáceis” que podem nos dar 2-3x no desempenho da raiz de estado, sem quaisquer alterações no protocolo:

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

Indo além disso, vemos alguns caminhos à frente ao divergir do comportamento da raiz do estado do Ethereum L1:

1. Raiz de Estado menos frequente: Em vez de calcular a raiz de estado a cada bloco, calcule-a a cada T blocos. Isso reduz a porcentagem geral do tempo gasto na raiz de estado em todo o sistema e pode ser a solução mais fácil e eficaz.
2. Raiz do Estado de Rastreamento: Em vez de ter que calcular a raiz do estado no mesmo bloco, permita que ela fique alguns blocos atrás. Isso permite que a execução avance sem bloquear no 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 Blake3.
4. Trie mais amplo: aumentar a aridade N da árvore, para reduzir a amplificação de E/S devido à profundidade logN da trie.

Há algumas perguntas aqui:

1. Quais são os efeitos de segunda ordem das mudanças acima nos clientes leves, L2s, pontes, coprocessadores e outros protocolos que dependem de provas frequentes de conta e armazenamento?
2. Podemos otimizar tanto o compromisso de estado 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 de computação do mundo. Achamos que há 2 caminhos adiante aqui, que nos permitem escalar introduzindo mais caixas à medida que mais carga chega:

Multi-Rollup Reth

As pilhas de L2 de hoje exigem a execução de múltiplos serviços para seguir a cadeia: L1 CL, L1 EL, a função de derivação L1 -> L2 (que pode estar agrupada 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 em andamento com isso com nossoProjetos de Extensões de Execução([1], [2]), mais nas próximas semanas aqui.

Reth nativo na nuvem

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

Queremos permitir a execução de nós Reth nativos da nuvem, implantados como um conjunto de serviços que podem dimensionar automaticamente com a demanda de computação e usar o armazenamento de objetos em nuvem aparentemente infinito para persistência. Esta é uma arquitetura comum em projetos de banco de dados serverless, como NeonDB, CockroachDB ou Amazon Aurora.

Ver pensamentos iniciaisda nossa equipe sobre algumas formas como poderíamos abordar este problema.

Perspectiva

Temos a intenção de implementar este roteiro incrementalmente para todos os usuários do Reth. Nossa missão é dar a todos acesso a 1 gigagás/s e além. Estaremos testando 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 o Reth pode 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 gerenciamos a tensão entre L1 e L2 potencialmente divergentes?

Não temos respostas para muitas dessas perguntas, mas temos pistas iniciais promissoras o suficiente para nos manter ocupados por um tempo e esperamos ver esses esforços darem frutos nos próximos meses.

Aviso Legal：

1. Este artigo é reproduzido a partir de [paradigma], Todos os direitos autorais pertencem ao autor original [Georgios Konstantopoulos]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões e pontos de vista expressos 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 equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.