É amplamente reconhecido que a EVM é um dos componentes centrais mais importantes do Ethereum, desempenhando um papel crucial como "motor de execução" e "ambiente de execução de contratos inteligentes". Na rede de blockchain pública composta por milhares de nós, a presença da máquina virtual permite que os contratos inteligentes sejam executados da mesma forma em nós com diferentes configurações de hardware, garantindo a consistência dos resultados. Essa compatibilidade entre plataformas é bastante semelhante à da máquina virtual Java (JVM).
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 ordem, e cada instrução tem um custo de Gas correspondente. A EVM rastreia o consumo de Gas durante a execução das instruções, e a quantidade consumida depende da complexidade da operação.
Como o motor de execução central do Ethereum, o EVM processa transações de forma serial. Todas as transações são enfileiradas em uma única fila e executadas na ordem em que são confirmadas. Este design é simples e fácil de manter, mas à medida que a base de usuários se expande e a tecnologia evolui, seus gargalos de desempenho se tornam cada vez mais evidentes, especialmente após a maturação da tecnologia Rollup, que se manifesta de forma particularmente notável nas redes de segunda camada do Ethereum.
O Sequencer, como um componente chave do Layer2, assume todas as tarefas computacionais na forma de um único servidor. Se os módulos externos complementares forem suficientemente eficientes, o gargalo final dependerá da eficiência do próprio 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 escrita de dados, permitindo que o Sequencer execute até cerca de 2000 transações ERC-20 por segundo. Este número pode parecer alto, mas para transações complexas, o valor TPS certamente ficará muito aquém. Portanto, a paralelização do processamento de transações será uma tendência inevitável no futuro.
Dois componentes centrais da execução de transações Ethereum
Além do EVM, outro componente central relacionado à execução de transações no go-ethereum é o stateDB, que é usado para gerenciar o estado das contas e o armazenamento de dados no Ethereum. O Ethereum utiliza uma estrutura de árvore Merkle Patricia Trie como índice de banco de dados, e a cada execução de transação, o EVM altera certos dados no stateDB, essas alterações são, por fim, refletidas na árvore de estado global.
stateDB é responsável por manter o estado de todas as contas do Ethereum, incluindo contas EOA e contas de contrato, os dados armazenados incluem saldo de conta, código de contrato inteligente, entre outros. Durante o processo de execução da transação, o stateDB realiza operações de leitura e escrita nos dados das contas correspondentes. 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 as instruções dos contratos inteligentes, alterando o estado da blockchain de acordo com os resultados do cálculo, enquanto o stateDB atua como armazenamento de estado global, gerenciando as mudanças de estado de todas as contas e contratos. Juntos, eles colaboram para construir o ambiente de execução de transações da Ethereum.
Processo específico de execução em série
Os tipos de transações do Ethereum são divididos em transferências EOA e transações de contrato. As transferências EOA são o tipo de transação mais simples, ou seja, transferências de ETH entre contas comuns, que não envolvem chamadas de contrato, processadas rapidamente e com taxas de gas extremamente baixas.
A negociação de contratos envolve a chamada e execução de contratos inteligentes. O EVM, ao processar negociações de contratos, precisa interpretar e executar linha por linha as instruções em bytecode dentro dos contratos inteligentes. 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 é aproximadamente o dobro do tempo de uma transferência EOA, enquanto operações de contratos inteligentes mais complexos, como transações em um DEX, podem levar dezenas de vezes mais do que uma transferência EOA. Isso se deve ao fato de que os protocolos DeFi precisam lidar com pools de liquidez, cálculos de preços, trocas de tokens e outras lógicas complexas durante as transações, o que requer cálculos muito complexos.
No modo de execução em série, o processo de colaboração entre o EVM e o stateDB é o seguinte:
As transações dentro do bloco são processadas sequencialmente, com cada transação tendo uma instância independente que executa 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 stateDB.
Durante o processo de execução da transação, o EVM precisa interagir continuamente com o stateDB, ler os dados relevantes e escrever os dados alterados de volta no stateDB.
Após a conclusão de todas as transações, os dados no stateDB serão enviados para a árvore de estado global e uma nova raiz de estado será gerada.
O modo de execução em série do EVM apresenta um gargalo evidente: as transações devem ser executadas em fila, na ordem, e se houver uma transação de contrato inteligente que demore muito tempo, as outras transações só podem esperar, não conseguindo utilizar plenamente os recursos de hardware, limitando assim a eficiência.
Solução de otimização em paralelo de múltiplas threads para EVM
O EVM paralelo é semelhante a um banco com múltiplos balcões, onde é possível abrir várias threads para processar várias transações ao mesmo tempo, o que pode aumentar a eficiência em várias vezes. Mas o problema complicado é o conflito de estados, que precisa ser tratado de forma coordenada.
A abordagem de otimização paralela do projeto ZKRollup para EVM é a seguinte:
Execução de transações em paralelo com múltiplas threads: configurar várias threads para processar diferentes transações ao mesmo tempo, sem interferência entre elas, podendo aumentar a velocidade de processamento das transações várias vezes.
Atribuir um banco de dados de estado temporário para cada thread: cada thread é atribuída um banco de dados de estado temporário independente (pending-stateDB). Quando as threads executam transações, não modificam diretamente o stateDB global, mas registram temporariamente os resultados das alterações de estado no pending-stateDB.
Sincronização das alterações de estado: Após a execução de todas as transações dentro de 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 ocorrerem conflitos de estado durante a execução de transações diferentes, os registros no pending-stateDB podem ser mesclados com sucesso no stateDB global.
O projeto otimizou o tratamento de operações de leitura e escrita, 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 existirem, são lidos diretamente do pending-stateDB. Se o par chave-valor correspondente não for encontrado no ReadSet, os dados do estado histórico são lidos do stateDB global do bloco anterior.
Operações de escrita: todas as operações de escrita não são gravadas diretamente na stateDB global, mas primeiro registradas no WriteSet do estado pendente. Após a conclusão da execução da transação, tenta-se mesclar os resultados das alterações de estado na stateDB global após a detecção de conflitos.
Para resolver o problema de conflitos de estado, foi introduzido um mecanismo de detecção de conflitos:
Detecção de conflitos: O EVM monitora o ReadSet e o WriteSet de diferentes transações. Se detectar que várias transações tentam 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 transações, os registros de alteração em vários stateDB em estado pendente serão mesclados no stateDB global. Se a mesclagem for bem-sucedida, a EVM irá submeter o estado final na árvore de estado global e gerar uma nova raiz de estado.
A otimização de paralelismo multithread melhora significativamente o desempenho, especialmente ao lidar com transações de contratos inteligentes complexos. Pesquisas mostram que, em cargas de trabalho de baixo conflito, o TPS de testes de referência aumentou 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 técnicas de otimização forem aplicadas, pode-se alcançar até 60 vezes de melhoria.
Resumo
A solução de otimização de paralelismo multithread EVM melhora significativamente a capacidade de processamento de transações da EVM, atribuindo uma biblioteca de estado temporário a 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, a blockchain pública EVM consegue alcançar uma grande paralelização de transações, garantindo a consistência do estado e resolvendo o gargalo de desempenho trazido pelo modelo de execução serial tradicional. Isso estabelece uma base importante para o desenvolvimento futuro do Rollup da Ethereum.
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.
Otimização EVM: Aumento da eficiência de processamento de transações através de paralelismo multi-thread.
O caminho da otimização da paralelização do EVM
É amplamente reconhecido que a EVM é um dos componentes centrais mais importantes do Ethereum, desempenhando um papel crucial como "motor de execução" e "ambiente de execução de contratos inteligentes". Na rede de blockchain pública composta por milhares de nós, a presença da máquina virtual permite que os contratos inteligentes sejam executados da mesma forma em nós com diferentes configurações de hardware, garantindo a consistência dos resultados. Essa compatibilidade entre plataformas é bastante semelhante à da máquina virtual Java (JVM).
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 ordem, e cada instrução tem um custo de Gas correspondente. A EVM rastreia o consumo de Gas durante a execução das instruções, e a quantidade consumida depende da complexidade da operação.
Como o motor de execução central do Ethereum, o EVM processa transações de forma serial. Todas as transações são enfileiradas em uma única fila e executadas na ordem em que são confirmadas. Este design é simples e fácil de manter, mas à medida que a base de usuários se expande e a tecnologia evolui, seus gargalos de desempenho se tornam cada vez mais evidentes, especialmente após a maturação da tecnologia Rollup, que se manifesta de forma particularmente notável nas redes de segunda camada do Ethereum.
O Sequencer, como um componente chave do Layer2, assume todas as tarefas computacionais na forma de um único servidor. Se os módulos externos complementares forem suficientemente eficientes, o gargalo final dependerá da eficiência do próprio 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 escrita de dados, permitindo que o Sequencer execute até cerca de 2000 transações ERC-20 por segundo. Este número pode parecer alto, mas para transações complexas, o valor TPS certamente ficará muito aquém. Portanto, a paralelização do processamento de transações será uma tendência inevitável no futuro.
Dois componentes centrais da execução de transações Ethereum
Além do EVM, outro componente central relacionado à execução de transações no go-ethereum é o stateDB, que é usado para gerenciar o estado das contas e o armazenamento de dados no Ethereum. O Ethereum utiliza uma estrutura de árvore Merkle Patricia Trie como índice de banco de dados, e a cada execução de transação, o EVM altera certos dados no stateDB, essas alterações são, por fim, refletidas na árvore de estado global.
stateDB é responsável por manter o estado de todas as contas do Ethereum, incluindo contas EOA e contas de contrato, os dados armazenados incluem saldo de conta, código de contrato inteligente, entre outros. Durante o processo de execução da transação, o stateDB realiza operações de leitura e escrita nos dados das contas correspondentes. 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 as instruções dos contratos inteligentes, alterando o estado da blockchain de acordo com os resultados do cálculo, enquanto o stateDB atua como armazenamento de estado global, gerenciando as mudanças de estado de todas as contas e contratos. Juntos, eles colaboram para construir o ambiente de execução de transações da Ethereum.
Processo específico de execução em série
Os tipos de transações do Ethereum são divididos em transferências EOA e transações de contrato. As transferências EOA são o tipo de transação mais simples, ou seja, transferências de ETH entre contas comuns, que não envolvem chamadas de contrato, processadas rapidamente e com taxas de gas extremamente baixas.
A negociação de contratos envolve a chamada e execução de contratos inteligentes. O EVM, ao processar negociações de contratos, precisa interpretar e executar linha por linha as instruções em bytecode dentro dos contratos inteligentes. 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 é aproximadamente o dobro do tempo de uma transferência EOA, enquanto operações de contratos inteligentes mais complexos, como transações em um DEX, podem levar dezenas de vezes mais do que uma transferência EOA. Isso se deve ao fato de que os protocolos DeFi precisam lidar com pools de liquidez, cálculos de preços, trocas de tokens e outras lógicas complexas durante as transações, o que requer cálculos muito complexos.
No modo de execução em série, o processo de colaboração entre o EVM e o stateDB é o seguinte:
O modo de execução em série do EVM apresenta um gargalo evidente: as transações devem ser executadas em fila, na ordem, e se houver uma transação de contrato inteligente que demore muito tempo, as outras transações só podem esperar, não conseguindo utilizar plenamente os recursos de hardware, limitando assim a eficiência.
Solução de otimização em paralelo de múltiplas threads para EVM
O EVM paralelo é semelhante a um banco com múltiplos balcões, onde é possível abrir várias threads para processar várias transações ao mesmo tempo, o que pode aumentar a eficiência em várias vezes. Mas o problema complicado é o conflito de estados, que precisa ser tratado de forma coordenada.
A abordagem de otimização paralela do projeto ZKRollup para EVM é a seguinte:
Execução de transações em paralelo com múltiplas threads: configurar várias threads para processar diferentes transações ao mesmo tempo, sem interferência entre elas, podendo aumentar a velocidade de processamento das transações várias vezes.
Atribuir um banco de dados de estado temporário para cada thread: cada thread é atribuída um banco de dados de estado temporário independente (pending-stateDB). Quando as threads executam transações, não modificam diretamente o stateDB global, mas registram temporariamente os resultados das alterações de estado no pending-stateDB.
Sincronização das alterações de estado: Após a execução de todas as transações dentro de 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 ocorrerem conflitos de estado durante a execução de transações diferentes, os registros no pending-stateDB podem ser mesclados com sucesso no stateDB global.
O projeto otimizou o tratamento de operações de leitura e escrita, 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 existirem, são lidos diretamente do pending-stateDB. Se o par chave-valor correspondente não for encontrado no ReadSet, os dados do estado histórico são lidos do stateDB global do bloco anterior.
Operações de escrita: todas as operações de escrita não são gravadas diretamente na stateDB global, mas primeiro registradas no WriteSet do estado pendente. Após a conclusão da execução da transação, tenta-se mesclar os resultados das alterações de estado na stateDB global após a detecção de conflitos.
Para resolver o problema de conflitos de estado, foi introduzido um mecanismo de detecção de conflitos:
Após a conclusão de todas as transações, os registros de alteração em vários stateDB em estado pendente serão mesclados no stateDB global. Se a mesclagem for bem-sucedida, a EVM irá submeter o estado final na árvore de estado global e gerar uma nova raiz de estado.
A otimização de paralelismo multithread melhora significativamente o desempenho, especialmente ao lidar com transações de contratos inteligentes complexos. Pesquisas mostram que, em cargas de trabalho de baixo conflito, o TPS de testes de referência aumentou 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 técnicas de otimização forem aplicadas, pode-se alcançar até 60 vezes de melhoria.
Resumo
A solução de otimização de paralelismo multithread EVM melhora significativamente a capacidade de processamento de transações da EVM, atribuindo uma biblioteca de estado temporário a 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, a blockchain pública EVM consegue alcançar uma grande paralelização de transações, garantindo a consistência do estado e resolvendo o gargalo de desempenho trazido pelo modelo de execução serial tradicional. Isso estabelece uma base importante para o desenvolvimento futuro do Rollup da Ethereum.