O caminho da otimização paralela do EVM

Como é bem conhecido, a EVM é o núcleo do motor de execução do Ethereum e o ambiente de execução de contratos inteligentes. Sendo uma rede aberta que contém um grande número de nós, a blockchain pública enfrenta o desafio de como alcançar uma execução consistente em dispositivos com parâmetros de hardware extremamente diferentes. A tecnologia de máquinas virtuais oferece uma solução potencial para esse problema, permitindo que contratos inteligentes sejam executados de forma idêntica em diferentes sistemas operacionais e dispositivos, garantindo a consistência dos resultados.

Os contratos inteligentes são compilados em bytecode EVM antes de serem colocados na blockchain. Quando a EVM executa o contrato, lê esses bytecodes sequencialmente, e cada instrução tem 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.

Tradicionalmente, o EVM processa transações de forma serial, com todas as transações enfileiradas em uma única fila e executadas em ordem determinada. Este design é simples e fácil de manter, mas à medida que a tecnologia blockchain evolui e a base de usuários cresce, as exigências em relação ao TPS e à capacidade de processamento aumentam constantemente. Com a maturação da tecnologia Rollup, o gargalo de desempenho da execução serial do EVM tornou-se especialmente evidente nas redes de segunda camada da Ethereum.

O Sequencer, como um componente chave do Layer 2, assume todas as tarefas de computação na forma de um único servidor. Se a eficiência dos módulos de apoio for suficientemente alta, o gargalo final dependerá da eficiência do próprio Sequencer, momento em que a execução em série se tornará um grande obstáculo. Assim, a paralelização do processamento de transações torna-se a tendência inevitável do futuro.

O componente central da execução de transações em 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 a estrutura de á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.

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 de transações, o stateDB realiza leituras e gravações dos 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.

De forma geral, o EVM é responsável por interpretar e executar as instruções dos contratos inteligentes, alterando o estado da blockchain com base nos resultados dos cálculos, enquanto o stateDB, como armazenamento de estado global, gerencia 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

As transações de Ethereum são divididas em dois tipos: transferências EOA e transações de contrato. A transferência EOA é o tipo de transação mais simples, ou seja, transferências de ETH entre contas comuns, que não envolvem chamadas de contrato, têm uma velocidade de processamento rápida e taxas de gas baixas.

A negociação de contratos envolve a chamada e execução de contratos inteligentes. Quando o EVM processa transaçõ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 é cerca de 2 vezes o de uma transferência EOA, enquanto operações de contratos inteligentes mais complexas, como as transações na Uniswap, 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, swaps de tokens e outras lógicas complexas durante as transações, o que requer uma quantidade significativa de cálculos.

No modo de execução serial, o processo de colaboração entre a EVM e a stateDB é o seguinte:

1. As transações dentro do bloco são processadas em sequência, uma a uma, com cada transação tendo uma instância independente que executa operações específicas.
2. Todas as transações usam o mesmo banco de dados de estado stateDB.
3. Durante o processo de execução da transação, a EVM interage continuamente com a stateDB, lendo os dados relevantes e escrevendo os dados alterados de volta na stateDB.
4. Após a execução de todas as transações no bloco, os dados no stateDB são submetidos à árvore de estado global, gerando uma nova raiz de estado.

O gargalo deste modo de execução serial é evidente: as transações devem ser executadas em ordem, e se houver uma transação de contrato inteligente que leve muito tempo, as outras transações só podem esperar, não conseguindo aproveitar plenamente os recursos de hardware, limitando assim a eficiência.

Solução de otimização de paralelismo multithread para EVM

O modo de execução paralela pode abrir múltiplas threads para processar várias transações ao mesmo tempo, aumentando a eficiência em várias vezes, mas enfrenta problemas de conflito de estado. Quando várias transações tentam simultaneamente declarar a reescrita dos dados de uma determinada conta, ocorre um conflito que precisa ser tratado de forma coordenada.

Princípios de otimização paralela

Tomando como exemplo a abordagem de otimização paralela do projeto ZKRollup Reddio, as suas principais características incluem:

1. Execução de transações em paralelo com múltiplas threads: configure várias threads para processar transações diferentes simultaneamente, sem interferência entre threads, o que pode aumentar várias vezes a velocidade de processamento das transações.

2. Atribuir um banco de dados de estado temporário para cada thread: cada thread tem um banco de dados de estado temporário independente (pending-stateDB). Durante a execução da transação, os resultados das mudanças de estado são temporariamente registrados no pending-stateDB, sem modificar diretamente o stateDB global.

3. Sincronização de alterações de estado: Após a execução de todas as transações dentro do bloco, os resultados das alterações de estado registrados em cada pending-stateDB são sincronizados sequencialmente no stateDB global.

A Reddio otimizou o tratamento das operações de leitura e escrita:

• Operação de leitura: primeiro verifique o ReadSet do estado pendente. Se os dados necessários existirem, leia diretamente do pending-stateDB; caso contrário, leia os dados de estado histórico do stateDB global correspondente ao bloco anterior.

• Operações de escrita: Todas as operações de escrita são inicialmente registradas no WriteSet do estado pendente e, após a conclusão da execução da transação, são tentadas para mesclar os resultados das alterações de estado no stateDB global após a detecção de conflitos.

Para resolver o problema de conflitos de estado, a Reddio introduziu um mecanismo de deteção de conflitos:

• Detecção de conflitos: Monitorizar o ReadSet e o WriteSet de diferentes transações; se vários transações tentarem ler e escrever o mesmo item de estado, isso é considerado um conflito.

• Tratamento de conflitos: Transações em conflito são marcadas como necessitando de reexecução.

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

A otimização de paralelismo em múltiplas threads melhorou significativamente o desempenho, especialmente ao lidar com transações complexas de contratos inteligentes. Estudos mostram que, em cargas de trabalho de baixo conflito, o TPS nos testes de referência é de 3 a 5 vezes superior à 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.

Resumo

A solução de otimização de paralelismo multithread EVM da Reddio melhora significativamente a capacidade de processamento de transações do 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 pode alcançar a paralelização em larga escala das transações, garantindo a consistência do estado, resolvendo o gargalo de desempenho do modo de execução serial tradicional. Isso estabelece uma base importante para o desenvolvimento futuro do Rollup do Ethereum.

Poderemos discutir mais detalhadamente os detalhes de implementação do Reddio, incluindo como otimizar ainda mais a eficiência de armazenamento, soluções de otimização em situações de alta concorrência, e como utilizar GPU para otimização, entre outros conteúdos.