Otimização de paralelização do EVM: A chave para melhorar o desempenho do Blockchain
O EVM, como o motor de execução central do Ethereum, sempre processou transações de forma sequencial. Embora esse método seja simples e fácil de manter, com a expansão da base de usuários e o avanço técnico, seus gargalos de desempenho tornaram-se cada vez mais evidentes. Especialmente na era em que a tecnologia Rollup é amplamente utilizada, a execução sequencial do EVM tornou-se um fator importante que limita o desenvolvimento das redes de camada dois.
O Sequencer, como componente central do Layer2, assume todas as tarefas de computação na forma de um único servidor. Quando outros módulos têm eficiência suficiente, a capacidade de processamento do Sequencer torna-se o gargalo final. Algumas equipes otimizaram a camada DA e os módulos de leitura e escrita de dados, permitindo que o Sequencer execute cerca de 2000 transferências ERC-20 por segundo. Esse número pode parecer considerável, mas, quando confrontado com transações mais complexas, o TPS inevitavelmente diminuirá drasticamente. Portanto, a paralelização do processamento de transações torna-se uma tendência inevitável para o desenvolvimento futuro.
Na estrutura de código do Ethereum, além do EVM, o stateDB também é um componente central intimamente relacionado à execução de transações. Ele é responsável por gerenciar o estado das contas e o armazenamento de dados do Ethereum. Cada vez que o EVM executa uma transação, ele altera certos dados no stateDB, e essas alterações acabam refletidas na árvore de estado global.
stateDB mantém principalmente o estado de todas as contas Ethereum, incluindo contas comuns e contas de contrato, armazenando informações como saldo da conta, código do contrato inteligente, entre outros. Durante o processo de execução da transação, o stateDB realiza operações de leitura e escrita nos dados da conta correspondente, e após a conclusão da execução, o novo estado é enviado para ser salvo permanentemente na base de dados subjacente.
No modo de execução serial tradicional, as transações dentro de um bloco são processadas uma a uma, na ordem. Cada transação tem uma instância independente do EVM que executa operações específicas, mas todas as transações compartilham a mesma stateDB. O EVM precisa interagir frequentemente com a stateDB durante a execução, lendo e escrevendo dados relevantes.
A deficiência deste modo de execução sequencial é bastante evidente: as transações devem ser colocadas em fila para serem executadas, e se uma transação de contrato complexo demorar muito tempo, as transações subsequentes são forçadas a esperar, não conseguindo aproveitar plenamente os recursos de hardware, limitando severamente a eficiência do processamento.
Para superar esse gargalo, a indústria propôs uma solução de otimização paralela multithread para o EVM. A ideia central é abrir várias threads para processar várias transações simultaneamente, aumentando significativamente a eficiência. No entanto, o principal desafio da execução paralela é como lidar com o problema de conflitos de estado.
Um projeto de otimização paralela para EVM merece atenção. Eles alocam uma transação e uma base de dados de estado temporário (pending-stateDB) para cada thread. Os passos específicos são os seguintes:
Execução de transações em paralelo com múltiplas threads, onde as threads não interferem umas nas outras.
Cada thread tem um estado pendente de base de dados independente, e a execução das transações não modifica diretamente a base de dados de estado global, mas sim armazena temporariamente as alterações de estado na base de dados de estado pendente.
Após a execução de todas as transações dentro do bloco, o EVM sincroniza, uma a uma, as alterações de estado dos pending-stateDB para o stateDB global.
O projeto também otimizou as operações de leitura e escrita:
Durante a operação de leitura, o EVM primeiro verifica o ReadSet do estado pendente. Se houver os dados necessários, eles são lidos diretamente do pending-stateDB; caso contrário, são lidos do estado histórico do stateDB do bloco anterior.
A operação de escrita não é gravada diretamente no stateDB global, mas primeiro é registrada no WriteSet do estado pendente. Após a execução da transação, tenta-se mesclar no stateDB global através da detecção de conflitos.
Para resolver o problema de conflito de estado, o projeto introduziu um mecanismo de deteção de conflitos:
Monitorizar o ReadSet e WriteSet de diferentes transações durante o processo de execução, considerando como conflito quando múltiplas transações leem e escrevem o mesmo item de estado.
Marcar transações em conflito como necessitando de reexecução.
Após a execução de todas as transações, várias alterações de registro do estado pendente do stateDB são mescladas no stateDB global. Após a mesclagem bem-sucedida, o estado final é enviado para a árvore de estado global, gerando uma nova raiz de estado.
A otimização de paralelismo com múltiplas threads melhorou significativamente o desempenho, especialmente ao lidar com transações complexas de contratos inteligentes. Estudos mostram que, sob cargas de trabalho de baixa colisão, o TPS dos testes de benchmark melhorou de 3 a 5 vezes em comparação com a execução serial tradicional. Em cargas de trabalho de alta colisão, teoricamente, a adoção de todos os meios de otimização pode até alcançar um aumento de 60 vezes.
Esta solução de otimização de paralelismo multithread EVM melhora significativamente a capacidade de processamento de transações da EVM, alocando uma biblioteca de estado temporária 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, alcançou uma paralelização em larga escala das transações, garantindo a consistência de estado, resolvendo efetivamente o gargalo de desempenho do modelo de execução serial tradicional. Isso estabelece uma base importante para a futura expansão do ecossistema Ethereum.
As direções futuras de pesquisa podem incluir a otimização adicional da eficiência de armazenamento, a melhoria das soluções de processamento em casos de alta conflitualidade, bem como a exploração da utilização de GPU para otimização. Esses avanços fornecerão um novo impulso para o desenvolvimento contínuo da tecnologia Blockchain.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
14 Curtidas
Recompensa
14
7
Repostar
Compartilhar
Comentário
0/400
MEVVictimAlliance
· 5h atrás
A concorrência está a apressar-se, está a travar-me!
Ver originalResponder0
MelonField
· 5h atrás
Ainda a falar do evm, a aparência está má.
Ver originalResponder0
MetaDreamer
· 5h atrás
Aumento de desempenho de 60 vezes? O gm tem que fazer mais um negócio.
Ver originalResponder0
TestnetScholar
· 5h atrás
Este cartão, otimize-o rapidamente.
Ver originalResponder0
faded_wojak.eth
· 5h atrás
卡啦 Até à lua啊
Ver originalResponder0
BugBountyHunter
· 5h atrás
Se ficar preso, tem que ser em paralelo! Vamos nos envolver!
Ver originalResponder0
DefiPlaybook
· 5h atrás
Esta limitação está apenas à espera de ser explorada. Os bots de corrida estão em êxtase.
Otimização paralela EVM: a tecnologia chave para aumentar o desempenho do Blockchain em 60 vezes
Otimização de paralelização do EVM: A chave para melhorar o desempenho do Blockchain
O EVM, como o motor de execução central do Ethereum, sempre processou transações de forma sequencial. Embora esse método seja simples e fácil de manter, com a expansão da base de usuários e o avanço técnico, seus gargalos de desempenho tornaram-se cada vez mais evidentes. Especialmente na era em que a tecnologia Rollup é amplamente utilizada, a execução sequencial do EVM tornou-se um fator importante que limita o desenvolvimento das redes de camada dois.
O Sequencer, como componente central do Layer2, assume todas as tarefas de computação na forma de um único servidor. Quando outros módulos têm eficiência suficiente, a capacidade de processamento do Sequencer torna-se o gargalo final. Algumas equipes otimizaram a camada DA e os módulos de leitura e escrita de dados, permitindo que o Sequencer execute cerca de 2000 transferências ERC-20 por segundo. Esse número pode parecer considerável, mas, quando confrontado com transações mais complexas, o TPS inevitavelmente diminuirá drasticamente. Portanto, a paralelização do processamento de transações torna-se uma tendência inevitável para o desenvolvimento futuro.
Na estrutura de código do Ethereum, além do EVM, o stateDB também é um componente central intimamente relacionado à execução de transações. Ele é responsável por gerenciar o estado das contas e o armazenamento de dados do Ethereum. Cada vez que o EVM executa uma transação, ele altera certos dados no stateDB, e essas alterações acabam refletidas na árvore de estado global.
stateDB mantém principalmente o estado de todas as contas Ethereum, incluindo contas comuns e contas de contrato, armazenando informações como saldo da conta, código do contrato inteligente, entre outros. Durante o processo de execução da transação, o stateDB realiza operações de leitura e escrita nos dados da conta correspondente, e após a conclusão da execução, o novo estado é enviado para ser salvo permanentemente na base de dados subjacente.
No modo de execução serial tradicional, as transações dentro de um bloco são processadas uma a uma, na ordem. Cada transação tem uma instância independente do EVM que executa operações específicas, mas todas as transações compartilham a mesma stateDB. O EVM precisa interagir frequentemente com a stateDB durante a execução, lendo e escrevendo dados relevantes.
A deficiência deste modo de execução sequencial é bastante evidente: as transações devem ser colocadas em fila para serem executadas, e se uma transação de contrato complexo demorar muito tempo, as transações subsequentes são forçadas a esperar, não conseguindo aproveitar plenamente os recursos de hardware, limitando severamente a eficiência do processamento.
Para superar esse gargalo, a indústria propôs uma solução de otimização paralela multithread para o EVM. A ideia central é abrir várias threads para processar várias transações simultaneamente, aumentando significativamente a eficiência. No entanto, o principal desafio da execução paralela é como lidar com o problema de conflitos de estado.
Um projeto de otimização paralela para EVM merece atenção. Eles alocam uma transação e uma base de dados de estado temporário (pending-stateDB) para cada thread. Os passos específicos são os seguintes:
Execução de transações em paralelo com múltiplas threads, onde as threads não interferem umas nas outras.
Cada thread tem um estado pendente de base de dados independente, e a execução das transações não modifica diretamente a base de dados de estado global, mas sim armazena temporariamente as alterações de estado na base de dados de estado pendente.
Após a execução de todas as transações dentro do bloco, o EVM sincroniza, uma a uma, as alterações de estado dos pending-stateDB para o stateDB global.
O projeto também otimizou as operações de leitura e escrita:
Durante a operação de leitura, o EVM primeiro verifica o ReadSet do estado pendente. Se houver os dados necessários, eles são lidos diretamente do pending-stateDB; caso contrário, são lidos do estado histórico do stateDB do bloco anterior.
A operação de escrita não é gravada diretamente no stateDB global, mas primeiro é registrada no WriteSet do estado pendente. Após a execução da transação, tenta-se mesclar no stateDB global através da detecção de conflitos.
Para resolver o problema de conflito de estado, o projeto introduziu um mecanismo de deteção de conflitos:
Monitorizar o ReadSet e WriteSet de diferentes transações durante o processo de execução, considerando como conflito quando múltiplas transações leem e escrevem o mesmo item de estado.
Marcar transações em conflito como necessitando de reexecução.
Após a execução de todas as transações, várias alterações de registro do estado pendente do stateDB são mescladas no stateDB global. Após a mesclagem bem-sucedida, o estado final é enviado para a árvore de estado global, gerando uma nova raiz de estado.
A otimização de paralelismo com múltiplas threads melhorou significativamente o desempenho, especialmente ao lidar com transações complexas de contratos inteligentes. Estudos mostram que, sob cargas de trabalho de baixa colisão, o TPS dos testes de benchmark melhorou de 3 a 5 vezes em comparação com a execução serial tradicional. Em cargas de trabalho de alta colisão, teoricamente, a adoção de todos os meios de otimização pode até alcançar um aumento de 60 vezes.
Esta solução de otimização de paralelismo multithread EVM melhora significativamente a capacidade de processamento de transações da EVM, alocando uma biblioteca de estado temporária 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, alcançou uma paralelização em larga escala das transações, garantindo a consistência de estado, resolvendo efetivamente o gargalo de desempenho do modelo de execução serial tradicional. Isso estabelece uma base importante para a futura expansão do ecossistema Ethereum.
As direções futuras de pesquisa podem incluir a otimização adicional da eficiência de armazenamento, a melhoria das soluções de processamento em casos de alta conflitualidade, bem como a exploração da utilização de GPU para otimização. Esses avanços fornecerão um novo impulso para o desenvolvimento contínuo da tecnologia Blockchain.