Otimização de paralelização EVM: superando o gargalo de execução serial para melhorar o desempenho do Layer2

O gargalo da execução serial do EVM e a exploração da otimização em paralelo

É bem conhecido que o EVM é o núcleo do motor de execução do Ethereum e o ambiente de execução de contratos inteligentes, sendo um dos componentes mais críticos do Ethereum. Em uma rede de blockchain pública composta por numerosos nós, a tecnologia de máquinas virtuais desempenha um papel crucial para garantir que os contratos inteligentes obtenham resultados de execução consistentes em diferentes nós.

O EVM pode executar contratos inteligentes de forma unificada em diversos sistemas operacionais e dispositivos, garantindo que cada nó obtenha resultados consistentes após a execução do contrato. Isso é semelhante ao funcionamento da máquina virtual Java (JVM).

Normalmente, os contratos inteligentes são primeiro compilados em bytecode EVM e, em seguida, armazenados na blockchain. Ao executar o contrato, a EVM lê esses bytecodes em ordem, onde cada instrução corresponde a um custo específico de Gas. A EVM rastreia o consumo de Gas durante a execução de cada instrução, e a quantidade específica consumida depende da complexidade da operação.

Como o núcleo do motor de execução do Ethereum, o EVM processa transações de forma sequencial, com todas as transações enfileiradas em uma única fila e executadas na ordem em que foram confirmadas. A escolha pela abordagem sequencial em vez da paralela é para atender rigorosamente aos requisitos de consistência da blockchain, garantindo que um lote de transações seja processado na mesma ordem em todos os nós.

Entre 2014 e 2015, a equipe fundadora da Ethereum, devido à pressão do tempo, optou por um modo de execução serial simples e fácil de manter. No entanto, com o desenvolvimento da tecnologia blockchain e a expansão da base de usuários, as exigências em relação ao TPS e à capacidade de processamento aumentaram continuamente. Especialmente após a maturação da tecnologia Rollup, o gargalo de desempenho causado pela execução serial do EVM tornou-se ainda mais evidente na rede de segunda camada da Ethereum.

Como um componente chave do Layer2, o Sequencer assume todas as tarefas de computação na forma de um único servidor. Se os módulos externos que trabalham com o Sequencer forem suficientemente eficientes, o gargalo final dependerá da própria eficiência do Sequencer, e a execução em série se tornará um grande obstáculo.

Uma equipe otimizou ao máximo a camada DA e o módulo de leitura e gravação de dados, permitindo que o Sequencer execute mais de 2000 transferências ERC-20 por segundo. Esse número parece alto, mas para transações mais complexas, o valor de TPS inevitavelmente diminuirá. Portanto, a paralelização do processamento de transações será uma tendência inevitável no futuro.

Usando Reddio como exemplo, descrevendo o caminho de otimização do EVM paralelo

Dois componentes principais da execução de transações Ethereum

Além do EVM, outro componente central relacionado à execução de transações é o stateDB, que é utilizado para gerenciar o estado das contas e o armazenamento de dados no Ethereum. O Ethereum utiliza a estrutura de árvore Merkle Patricia Trie como índice do banco de dados, e a cada execução de transação, o EVM altera alguns dados no stateDB, e essas alterações, por fim, se refletirão na árvore de estado global.

stateDB é responsável por manter o estado de todas as contas Ethereum, incluindo contas EOA e contas de contrato, armazenando dados como saldo de conta, código de contrato inteligente, entre outros. Durante o processo de execução da transação, o stateDB irá ler e escrever os dados da conta correspondente. Após a conclusão da execução da transação, o stateDB precisa submeter o novo estado ao banco de dados subjacente para processamento de persistência.

De um modo geral, o EVM é responsável por interpretar e executar instruções de contratos inteligentes, alterando o estado da blockchain com base nos resultados do cálculo, enquanto o stateDB atua como um armazenamento de estado global, gerenciando todas as mudanças de estado de contas e contratos. Juntos, eles constroem o ambiente de execução de transações do Ethereum.

Usando Reddio como exemplo, descrevendo o caminho de otimização do EVM paralelo

O processo específico de execução serial

Os tipos de transações no Ethereum são divididos em transferências EOA e transações de contrato. A transferência EOA é o tipo de transação mais simples, ou seja, a transferência de ETH entre contas normais, sem envolvimento de chamadas de contrato, com uma velocidade de processamento muito rápida e taxas de gas extremamente baixas.

Em comparação, a negociação de contratos envolve a chamada e a execução de contratos inteligentes. O EVM, ao processar negociações de contratos, precisa interpretar e executar, uma por uma, as instruções de bytecode contidas no contrato inteligente; quanto mais complexa for a lógica do contrato, mais instruções estarão envolvidas e mais recursos serão consumidos.

Por exemplo, o tempo de processamento de uma transferência ERC-20 é cerca de 2 vezes o de uma transferência EOA, enquanto operações de contratos inteligentes mais complexas, como as transações em um DEX, podem levar mais de dez vezes o tempo de uma transferência EOA. Isso se deve ao fato de que os protocolos DeFi precisam lidar com lógica complexa, como pools de liquidez, cálculo de preços e troca de tokens durante as transações, exigindo muitos cálculos.

No modo de execução sequencial, o processo em que os componentes EVM e stateDB colaboram para processar transações é o seguinte:

No design do Ethereum, as transações em um bloco são processadas sequencialmente, uma por uma, e cada transação possui uma instância independente para executar operações específicas. Embora cada transação utilize uma instância EVM diferente, todas as transações compartilham o mesmo banco de dados de estado, o stateDB.

Durante o processo de execução de transações, o EVM precisa interagir continuamente com o stateDB, lendo dados relevantes do stateDB e escrevendo os dados alterados de volta no stateDB.

Quando todas as transações em um bloco forem concluídas, os dados no stateDB serão submetidos à árvore de estado global, gerando uma nova raiz de estado. A raiz de estado é um parâmetro importante em cada bloco, que registra o "resultado comprimido" do novo estado global após a execução do bloco.

É evidente que o modo de execução serial do EVM apresenta um gargalo significativo: as transações devem ser executadas em fila, na ordem em que foram recebidas. Se uma transação de contrato inteligente demorar muito, as outras transações ficam à espera, não podendo aproveitar adequadamente os recursos de hardware, o que limita bastante a eficiência.

Usando Reddio como exemplo, descrevendo o caminho de otimização do EVM paralelo

Solução de otimização de paralelismo de múltiplas threads para EVM

Se usarmos um exemplo da vida cotidiana para fazer uma analogia, a execução serial é como um banco com apenas um balcão, enquanto o EVM paralelo é semelhante a um banco com vários balcões. No modo paralelo, é possível abrir várias threads para processar várias transações simultaneamente, o que pode aumentar a eficiência em várias vezes, mas é necessário resolver o problema de conflitos de estado.

Se várias transações declararem a necessidade de modificar os dados de uma determinada conta, isso poderá resultar em conflitos durante o processamento. Por exemplo, um NFT só pode ser cunhado uma vez, e se a transação 1 e a transação 2 ambas declararem a intenção de cunhar esse NFT, é evidente que haverá um erro se ambas as solicitações forem atendidas. Conflitos de estado em operações reais ocorrem com muito mais frequência, portanto, o processamento paralelo deve ter medidas para lidar com conflitos de estado.

Usando Reddio como exemplo, explicando o caminho de otimização do EVM paralelo

Princípio de otimização paralela de EVM para determinado projeto

Um projeto ZKRollup tem a abordagem de otimização paralela para EVM de alocar uma transação para cada thread e fornecer um banco de dados de estado temporário em cada thread, chamado de pending-stateDB. Os detalhes específicos são os seguintes:

  1. Execução de transações em paralelo com múltiplas threads: configurar várias threads para processar diferentes transações simultaneamente, onde as threads não se interferem, podendo aumentar a velocidade de processamento das transações em várias vezes.

  2. Atribuir um banco de dados de estado temporário para cada thread: atribuir um banco de dados de estado temporário (pending-stateDB) independente para cada thread. Cada thread, ao executar transações, não modifica diretamente o stateDB global, mas registra temporariamente os resultados das mudanças de estado no pending-stateDB.

  3. Sincronização das alterações de estado: Após a execução de todas as transações em um bloco, o EVM sincroniza sequencialmente os resultados das alterações de estado registrados em cada pending-stateDB para o stateDB global. Se não houver conflitos de estado durante a execução de transações diferentes, os registros do pending-stateDB podem ser mesclados com sucesso no stateDB global.

Usando Reddio como exemplo, explicando o caminho da otimização do EVM paralelo

O projeto otimizou a forma como as operações de leitura e escrita são tratadas, para garantir que as transações possam acessar corretamente os dados de estado e evitar conflitos:

  • Operação de leitura: Quando uma transação precisa ler o estado, o EVM primeiro verifica o ReadSet do estado pendente. Se os dados necessários estiverem presentes no ReadSet, eles são lidos diretamente do pending-stateDB. Se a chave-valor correspondente não for encontrada no ReadSet, os dados de estado históricos são lidos do stateDB global do bloco anterior.

  • Operações de escrita: todas as operações de escrita (ou seja, modificações de estado) não são escritas diretamente no stateDB global, mas são primeiro registradas no WriteSet do estado pendente. Após a execução da transação, tenta-se mesclar os resultados da mudança de estado no stateDB global após a detecção de conflitos.

Usando Reddio como exemplo, explicando o caminho de otimização do EVM paralelo

A questão chave da execução paralela reside em conflitos de estado, que se tornam particularmente evidentes quando várias transações tentam ler e escrever o estado da mesma conta. Para isso, foi introduzido um mecanismo de deteção de conflitos:

  • Detecção de conflitos: Durante o processo de execução da transação, o EVM monitoriza o ReadSet e o WriteSet de diferentes transações. Se várias transações tentarem ler e escrever o mesmo item de estado, isso é considerado um conflito.

  • Tratamento de conflitos: Quando um conflito é detectado, a transação em conflito será marcada como necessitando de reexecução.

Após a conclusão de todas as execuções de transações, várias alterações registradas no pending-stateDB serão mescladas no stateDB global. Se a mesclagem for bem-sucedida, o EVM irá submeter o estado final na árvore de estados global e gerar uma nova raiz de estado.

Usando Reddio como exemplo, descrevendo o caminho de otimização do EVM paralelo

A otimização de paralelismo de múltiplas threads resulta em um aumento significativo no desempenho, especialmente ao lidar com transações complexas de contratos inteligentes. Estudos mostram que, em cargas de trabalho de baixo conflito, o TPS em testes de referência aumenta cerca de 3 a 5 vezes em comparação com a execução serial tradicional. Em cargas de trabalho de alto conflito, teoricamente, se todas as medidas de otimização forem aplicadas, é possível alcançar um aumento de até 60 vezes.

Usando Reddio como exemplo, explicando o caminho de otimização do EVM paralelo

Resumo

A solução de otimização de paralelismo multithread EVM melhora significativamente a capacidade de processamento de transações da EVM, atribuindo um repositório de estado temporário para cada transação e executando-as em paralelo em diferentes threads. Ao otimizar operações de leitura e escrita e introduzir um mecanismo de detecção de conflitos, as blockchains públicas baseadas em EVM conseguem realizar paralelização em larga escala das transações, garantindo a consistência do estado e resolvendo os gargalos de desempenho impostos pelo modelo de execução serial tradicional. Isso estabelece uma base importante para o desenvolvimento futuro do Rollup do Ethereum.

No futuro, também podemos explorar como otimizar a eficiência de armazenamento para melhorar o desempenho, soluções de otimização em situações de alta concorrência, e como utilizar GPUs para otimização, entre outros conteúdos.

Usando Reddio como exemplo, descrevendo o caminho de otimização do EVM paralelo

ETH-4.35%
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
  • Recompensa
  • 3
  • Partilhar
Comentar
0/400
LeverageAddictvip
· 07-20 10:07
Outra pessoa está fazendo paralelismo, igual à minha posição L2, que está travada.
Ver originalResponder0
WenMoonvip
· 07-20 09:51
Ufa, o L2 também precisa de aceleração.
Ver originalResponder0
EntryPositionAnalystvip
· 07-20 09:44
A paralelização L2 já foi compreendida, agora é que estou a seguir o evm.
Ver originalResponder0
  • Pino
Negocie cripto em qualquer lugar e a qualquer hora
qrCode
Digitalizar para transferir a aplicação Gate
Novidades
Português (Portugal)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)