Otimização de paralelização EVM: explorando o caminho para a melhoria de desempenho com o Reddio

É amplamente conhecido que o EVM é um dos componentes mais centrais do Ethereum, desempenhando um papel importante como "motor de execução" e "ambiente de execução de contratos inteligentes". Em uma rede aberta de blockchain composta por milhares de nós, as configurações de hardware de diferentes nós podem variar bastante. Para garantir que os contratos inteligentes possam ser executados com resultados consistentes em todos os nós, a tecnologia de máquina virtual tornou-se a solução ideal.

O EVM pode executar contratos inteligentes da mesma forma em diferentes sistemas operacionais e dispositivos, e essa compatibilidade multiplataforma garante que cada nó obtenha resultados consistentes após a execução do contrato. Isso é semelhante ao princípio da máquina virtual Java (JVM).

Os contratos inteligentes que vemos no explorador de blockchain são primeiro compilados em bytecode EVM e, em seguida, armazenados na cadeia. Quando a EVM executa um contrato, lê essas instruções bytecode em ordem, 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 o mecanismo de execução central do Ethereum, o EVM processa transações de forma serial, com todas as transações enfileiradas em uma única fila e executadas em ordem determinada. A razão pela qual não é adotado um método de paralelização é que a blockchain precisa garantir rigorosamente a consistência; o mesmo lote de transações deve ser processado na mesma ordem em todos os nós. Se o processamento de transações for paralelizado, será difícil prever com precisão a ordem das transações, a menos que algoritmos de escalonamento complexos sejam introduzidos.

Entre 2014 e 2015, a equipe fundadora do Ethereum, devido à urgência de tempo, escolheu um modo de execução serial que era simples e fácil de manter. No entanto, com a iteração da tecnologia blockchain e a expansão da base de usuários, as exigências em relação ao TPS e à capacidade de processamento estão aumentando cada vez mais. Com o surgimento e a maturação da tecnologia Rollup, os gargalos de desempenho causados pela execução serial do EVM já se tornaram evidentes na rede de segunda camada do Ethereum.

O Sequencer, como um componente chave do Layer2, assume todas as tarefas de computação na forma de um único servidor. Se os módulos externos que trabalham em conjunto com o Sequencer forem suficientemente eficientes, o gargalo final dependerá da eficiência do próprio Sequencer, e nesse caso, 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 até cerca de 2000 transferências ERC-20 por segundo. Esse número parece muito alto, mas se as transações a serem processadas forem muito mais complexas do que as transferências ERC-20, o valor TPS certamente cairá drasticamente. Portanto, a paralelização do processamento de transações será uma tendência inevitável no futuro.

Dois componentes principais 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 chamada Merkle Patricia Trie como índice de banco de dados. A cada execução de transação, o EVM altera alguns dados armazenados no stateDB, e essas alterações acabam refletindo 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, armazenando dados como saldo de conta, código de contrato inteligente, entre outros. Durante o processo de execução da transação, o stateDB realiza leituras e gravações 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.

No geral, o EVM é responsável por interpretar e executar as instruções dos contratos inteligentes, alterando o estado na 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 das contas e contratos. Juntos, eles colaboram para construir o ambiente de execução de transações do Ethereum.

Processo específico de execução em série

Os tipos de transação do Ethereum são divididos em transferências EOA e transações de contrato. A transferência EOA é o tipo de transação mais simples, que se refere à transferência de ETH entre contas comuns, sem envolvimento de chamadas de contrato, com uma velocidade de processamento muito rápida e taxas de gás muito baixas.

A negociação de contratos envolve a chamada e execução de contratos inteligentes. Quando a EVM processa negociações de contratos, precisa interpretar e executar, uma a 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 é aproximadamente o dobro do de uma transferência EOA, enquanto operações de contratos inteligentes mais complexos, como transações em um DEX, podem levar várias vezes mais do que uma transferência EOA. Isso ocorre porque os protocolos DeFi precisam lidar com lógica complexa como pools de liquidez, cálculo de preços, troca de tokens, entre outros, o que requer uma quantidade significativa de cálculos.

No modo de execução em série, o processo de colaboração entre o EVM e o stateDB para processar transações é o seguinte:

No design do Ethereum, as transações dentro de um bloco são processadas uma a uma na ordem em que foram recebidas, cada transação tem uma instância independente que executa operações específicas. Embora cada transação use 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, lendo dados relevantes do stateDB e gravando os dados alterados de volta no stateDB.

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

O modo de execução em série do EVM apresenta um gargalo evidente: as transações devem ser executadas em ordem de fila, e se houver uma transação de contrato inteligente que demore muito, as outras transações só podem esperar até que esta seja concluída. Isso claramente impede a utilização plena dos recursos de hardware, como a CPU, limitando bastante a eficiência.

Solução de otimização paralela multithreaded do EVM

A execução serial e a execução paralela podem ser comparadas a um banco com apenas um balcão e a um banco com vários balcões. No modo paralelo, é possível abrir várias threads para processar várias transações ao mesmo tempo, aumentando a eficiência em várias vezes, mas o problema complicado é o conflito de estado.

Se várias transações declararem a intenção de modificar os dados de uma determinada conta, ocorrerá um conflito quando forem processadas simultaneamente. Por exemplo, se um NFT só pode ser cunhado uma vez e tanto a transação 1 quanto a transação 2 declararem a intenção de cunhar esse NFT, se ambos os pedidos forem atendidos, certamente ocorrerá um erro. Na prática, conflitos de estado ocorrem com mais frequência, portanto, a paralelização do processamento de transações deve ter medidas para lidar com conflitos de estado.

Princípios de otimização paralela do Reddio para EVM

Um projeto de ZKRollup tem a abordagem de otimização paralela para o EVM, alocando uma transação para cada thread e fornecendo 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, sem interferência entre elas. Isso pode aumentar a velocidade de processamento de 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 independente para cada thread (pending-stateDB). 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 dentro de um bloco, a EVM irá sincronizar, uma a uma, os resultados das alterações de estado registrados em cada pending-stateDB para o stateDB global. Se diferentes transações não ocorrerem conflitos de estado durante a execução, os registros no pending-stateDB poderão ser mesclados com sucesso no stateDB global.

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 o ReadSet contiver os dados necessários, eles são lidos diretamente do pending-stateDB. Se a chave-valor correspondente não for encontrada no ReadSet, os dados históricos do estado são lidos do stateDB global do bloco anterior.

• Operações de escrita: Todas as operações de escrita (, ou seja, as modificações de estado ), não serão escritas diretamente no stateDB global, mas primeiro serão registradas no WriteSet do estado pendente. Após a execução da transação, será feita uma verificação de conflitos antes de tentar fundir os resultados da alteração de estado no stateDB global.

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

• Detecção de conflitos: Durante a execução das transações, a EVM monitoriza os ReadSet e 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, as alterações registradas em vários stateDB em estado pendente serão mescladas no stateDB global. Se a mesclagem for bem-sucedida, o EVM enviará o estado final para a árvore de estado global e gerará uma nova raiz de estado.

A otimização de paralelismo com múltiplas threads apresenta um aumento significativo no desempenho, especialmente ao lidar com transações complexas de contratos inteligentes. Estudos mostram que, em um pool de transações com baixa carga de conflitos (, onde há menos contradições ou transações que ocupam os mesmos recursos ), o TPS em testes de referência aumentou cerca de 3 a 5 vezes em comparação com a execução sequencial tradicional. Em cargas de trabalho de alta concorrência, teoricamente, se todas as técnicas de otimização forem aplicadas, é possível alcançar um aumento de até 60 vezes.

Resumo

A solução de otimização de paralelismo multithread EVM deste projeto, atribuindo uma biblioteca de estado temporária a cada transação e executando transações em paralelo em diferentes threads, aumentou significativamente a capacidade de processamento de transações do EVM. Ao otimizar operações de leitura e escrita e introduzir um mecanismo de detecção de conflitos, a blockchain pública EVM consegue realizar a paralelização em larga escala das transações, garantindo a consistência do estado, resolvendo o gargalo de desempenho trazido pelo modo de execução serial tradicional. Isso estabelece uma base importante para o desenvolvimento futuro do Rollup do Ethereum.