Paralelização EVM: A chave para melhorar o desempenho do Ethereum

robot
Geração de resumo em curso

EVM Paralelização: A chave para resolver o gargalo de desempenho do Ethereum

O EVM, como motor de execução da Ethereum e ambiente de execução de contratos inteligentes, é um dos componentes mais centrais. Para garantir que os contratos inteligentes obtenham os mesmos resultados em diferentes nós, atendendo aos requisitos de consistência, a tecnologia de máquina virtual tornou-se a melhor escolha. O EVM pode executar contratos inteligentes da mesma forma em diferentes sistemas operacionais e dispositivos, garantindo a compatibilidade entre plataformas.

Os contratos inteligentes são compilados em bytecode EVM antes de serem colocados na blockchain. Quando a EVM executa o contrato, lê esses bytecodes em sequência, com cada instrução tendo um custo de Gas correspondente. A EVM rastreia o consumo de Gas durante a execução de cada instrução, e a quantidade consumida depende da complexidade da operação.

Como motor de execução central, o EVM processa transações de forma sequencial, com todas as transações enfileiradas em uma única fila e executadas em uma ordem determinada. Este design é simples e fácil de manter, mas à medida que a base de usuários cresce e a tecnologia avança, seus gargalos de desempenho se tornam cada vez mais evidentes, especialmente no Layer2.

Para o componente chave de Layer2, o Sequencer, se a eficiência dos módulos complementares for suficientemente alta, o gargalo final dependerá da eficiência do próprio Sequencer. Algumas equipas otimizaram ao máximo, permitindo que o Sequencer execute cerca de 2000 transações ERC-20 por segundo. No entanto, para transações mais complexas, o TPS inevitavelmente diminuirá drasticamente. Assim, a paralelização do processamento de transações torna-se uma tendência inevitável para o futuro.

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

Componente central da execução de transações Ethereum

Além do EVM, outro componente central intimamente relacionado à execução de transações é o stateDB, que gerencia o estado das contas e o armazenamento de dados do Ethereum. O Ethereum utiliza a estrutura em árvore Merkle Patricia Trie como índice de banco de dados. Cada execução de transação altera certos dados no stateDB, e essas mudanças são refletidas na árvore de estado global.

O stateDB é responsável por manter o estado de todas as contas Ethereum, incluindo contas EOA e contas de contratos, armazenando saldos de contas, códigos de contratos inteligentes e outros dados. Durante a execução da transação, o stateDB lê e grava os dados das contas correspondentes. Após a conclusão da execução da transação, o stateDB submete o novo estado ao banco de dados subjacente para persistência.

Em geral, o EVM é responsável por interpretar e executar instruções de contratos inteligentes, alterando o estado da blockchain com base nos resultados dos cálculos, enquanto o stateDB atua como um armazenamento de estado global, gerenciando todas as mudanças de estado das contas e contratos. Ambos colaboram na construção do ambiente de execução de transações do Ethereum.

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

Limitações da execução serial

As transações no Ethereum são divididas em duas categorias: Transferências EOA e Transações de Contratos. As transferências EOA são o tipo de transação mais simples, com alta velocidade de processamento e baixas taxas de gas. Já as transações de contratos envolvem a chamada e execução de contratos inteligentes, onde a EVM precisa interpretar e executar linha por linha as instruções em bytecode do contrato, apresentando maior complexidade e consumo de recursos.

No modo de execução em série, as transações dentro do bloco são processadas uma a uma, na ordem em que ocorrem. Cada transação tem uma instância EVM independente, mas todas as transações compartilham o mesmo stateDB. Durante o processo de execução, a EVM precisa interagir continuamente com o stateDB, lendo dados e escrevendo os resultados alterados.

O gargalo deste modo de execução serial é evidente: as transações devem ser executadas em fila, e se houver uma transação de contrato inteligente que demore muito, outras transações só podem esperar, não conseguindo aproveitar adequadamente os recursos de hardware, resultando em uma eficiência bastante limitada.

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

Otimização de paralelismo multithread do EVM

Para superar as limitações da execução sequencial, a indústria propôs uma solução de otimização paralela de múltiplas threads para o EVM. Esta solução é semelhante a um banco onde vários balcões atendem ao mesmo tempo, podendo processar várias transações simultaneamente, aumentando significativamente a eficiência. No entanto, o principal desafio da execução paralela é o problema de conflitos de estado, que requer medidas especiais para ser enfrentado.

A abordagem de otimização em paralelo do EVM de um determinado projeto é a seguinte:

  1. Configurar múltiplas threads para processar transações diferentes simultaneamente, sem interferência entre as threads.

  2. Atribuir a cada thread uma base de dados de estado temporário independente (pending-stateDB). Ao executar transações, cada thread regista temporariamente as alterações de estado na pending-stateDB, em vez de modificar diretamente a stateDB global.

  3. Após a execução de todas as transações no bloco, as alterações de estado em cada pending-stateDB serão sincronizadas sequencialmente com a global stateDB. Se não houver conflitos, os registros poderão ser mesclados com sucesso.

Com o Reddio como exemplo, elucidando o caminho de otimização do EVM paralelo

O plano otimizou as operações de leitura e escrita:

  • Operação de leitura: primeiro verificar o ReadSet do estado Pendentes, se os dados necessários estiverem disponíveis, leia-os diretamente; caso contrário, leia o estado histórico do stateDB global do bloco anterior.

  • Operação de escrita: todas as modificações são primeiro registadas no WriteSet de estado pendente, e após a execução da transação, tentam ser integradas à stateDB global.

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

Para resolver o problema de conflitos de estado, foi introduzido um mecanismo de deteção de conflitos:

  • Monitorar o ReadSet e WriteSet de diferentes transações, considerando como conflito quando várias transações tentam ler e escrever o mesmo item de estado.
  • Marcar transações em conflito como necessitando de reexecução.

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

Após a conclusão de todas as transações, os registros de alterações em vários stateDB pendentes são mesclados no stateDB global. Após a mesclagem bem-sucedida, o estado final é submetido à árvore de estado global, gerando uma nova raiz de estado.

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

Estudos mostram que, em cargas de trabalho de baixo conflito, a execução paralela de TPS é 3 a 5 vezes mais rápida do que a execução tradicional em série. Em cargas de trabalho de alto conflito, teoricamente, após uma otimização completa, pode até alcançar um aumento de 60 vezes.

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

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

Resumo

A solução de otimização de paralelismo multithread do EVM melhora significativamente a capacidade de processamento de transações, alocando uma biblioteca de estado temporário para cada transação e executando-as em paralelo em diferentes threads. Ao otimizar as operações de leitura e escrita e introduzir um mecanismo de detecção de conflitos, foi possível alcançar uma paralelização em larga escala das transações, garantindo a consistência do estado e resolvendo o gargalo de desempenho do modelo de execução serial tradicional. Isso estabelece uma base importante para o futuro desenvolvimento do Rollup do Ethereum.

No futuro, ainda se pode explorar como otimizar a eficiência de armazenamento, lidar com situações de alto conflito, bem como utilizar GPU para otimização, a fim de melhorar ainda mais o desempenho do EVM.

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

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

Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Recompensa
  • 6
  • Partilhar
Comentar
0/400
down_only_larryvip
· 7h atrás
subir lá Vitalik Buterin finalmente entendeu
Ver originalResponder0
BlockTalkvip
· 7h atrás
Ame ver ou não, de qualquer forma, o tps subiu.
Ver originalResponder0
LiquidityOraclevip
· 7h atrás
Mais uma vez, provocando os céus.
Ver originalResponder0
All-InQueenvip
· 8h atrás
Ou seja, as transferências estão mais rápidas?
Ver originalResponder0
ProveMyZKvip
· 8h atrás
Esta onda de otimização de desempenho é de nível máximo.
Ver originalResponder0
SmartContractPlumbervip
· 8h atrás
Ver diretamente o risco de escalabilidade. O design do mecanismo de bloqueio é muito ingênuo.
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)