Otimização da paralelização EVM: Aumentar a eficiência do processamento de transações do Ethereum
O EVM, como o motor de execução central do Ethereum, é posicionado como um "ambiente de execução de contratos inteligentes". Para garantir que os contratos inteligentes obtenham resultados consistentes em diferentes nós, o EVM fornece um ambiente de máquina virtual multiplataforma, semelhante à máquina virtual Java (JVM).
Os contratos inteligentes são compilados em bytecode EVM e armazenados na blockchain no momento da sua implantação. Quando o EVM executa o contrato, lê esse bytecode sequencialmente, e cada instrução tem um custo de Gas correspondente. O EVM rastreia o consumo de Gas durante a execução das instruções, e a quantidade consumida depende da complexidade da operação.
O EVM tradicional processa transações de forma serial, onde todas as transações são executadas em uma única fila em uma ordem determinada. Este design é simples e fácil de manter, mas à medida que a escala de usuários cresce e a tecnologia Rollup é aplicada, o gargalo de desempenho da execução serial torna-se cada vez mais evidente.
Na arquitetura Rollup, o Sequencer, como componente-chave do Layer2, assume todas as tarefas de computação. Se outros módulos externos forem suficientemente eficientes, a execução serial do Sequencer se tornará o maior gargalo. Algumas equipes, através de otimizações extremas, conseguiram fazer com que o Sequencer pudesse executar mais de 2000 transferências ERC-20 por segundo, mas para transações mais complexas, o TPS ainda diminuirá significativamente. Assim, a paralelização do processamento de transações torna-se uma tendência de desenvolvimento futuro.
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. O Ethereum utiliza a estrutura de árvore Merkle Patricia Trie como índice de banco de dados, e a cada execução de transação, o EVM altera os dados no stateDB, refletindo finalmente na árvore de estado global.
stateDB é responsável por manter o estado de todas as contas Ethereum, incluindo saldo de contas, códigos de contratos inteligentes, entre outros. Durante a execução da transação, o stateDB realiza leitura e escrita nos dados da conta correspondente, e após a execução, o novo estado é submetido à base de dados subjacente para persistência.
A EVM e o stateDB colaboram na construção do ambiente de execução de transações do Ethereum. A EVM é responsável por interpretar e executar as instruções dos contratos inteligentes, alterando o estado da blockchain com base nos resultados computacionais, enquanto o stateDB atua como um armazenamento de estado global, gerenciando todas as mudanças de estado das contas e contratos.
No modo de execução sequencial, as transações dentro de um bloco são processadas uma a uma em ordem. Cada transação utiliza uma instância EVM independente, mas todas as transações compartilham o mesmo stateDB. Durante a execução, a EVM precisa interagir constantemente com o stateDB, lendo dados relevantes e escrevendo os resultados das alterações.
Após a execução de todas as transações dentro do bloco, os dados no stateDB serão submetidos à árvore de estado global, gerando uma nova raiz de estado. O principal gargalo deste modo de execução em série é que as transações devem ser processadas em fila, não conseguindo aproveitar plenamente os recursos de hardware, especialmente quando se trata de transações complexas de contratos inteligentes, onde a eficiência é relativamente baixa.
Para melhorar a eficiência do processamento de transações, alguns projetos começaram a tentar a otimização em paralelo com múltiplas threads do EVM. Isto é semelhante a um banco abrir múltimos balcões para atender clientes ao mesmo tempo, podendo aumentar a velocidade de processamento várias vezes, mas é necessário resolver os problemas de conflitos de estado que podem surgir.
Um projeto ZKRollup tem a abordagem de otimização paralela para EVM, que consiste em atribuir um banco de dados de estado temporário para cada thread (pending-stateDB). A implementação específica inclui:
Execução de transações em paralelo com múltiplas threads, sem interferência mútua.
Cada thread tem um pending-stateDB independente, e as mudanças de estado são registradas aqui antes da execução da transação.
Após a execução de todas as transações, as alterações no pending-stateDB devem ser sincronizadas com o stateDB global.
Esta solução otimiza as operações de leitura e escrita:
Ao realizar uma operação de leitura, verifique primeiro o ReadSet do pending-stateDB; se os dados necessários estiverem presentes, leia-os diretamente; caso contrário, leia o estado histórico do stateDB global.
As operações de escrita não são escritas diretamente no stateDB global, mas são primeiro registradas no WriteSet do pending-stateDB.
Para lidar com conflitos de estado, foi introduzido um mecanismo de deteção de conflitos:
Monitorizar o ReadSet e WriteSet de diferentes transações, considerando como conflito quando várias transações leem e escrevem os mesmos itens de estado.
Transações em conflito serão marcadas como necessitando de reexecução.
Após a execução de todas as transações, os registos de alteração em múltiplos pending-stateDB serão fundidos na stateDB global, e após o sucesso, serão submetidos à árvore de estado global e gerarão uma nova raiz de estado.
Estudos mostram que, em cargas de trabalho com baixo conflito, o TPS do EVM paralelo é 3 a 5 vezes superior ao da execução serial tradicional. Em cargas de trabalho com alto conflito, teoricamente pode chegar a uma melhoria de até 60 vezes.
Esta solução de otimização paralela multithread, através de um repositório de estado temporário e execução paralela, melhorou significativamente a capacidade de processamento de transações do EVM. A otimização das operações de leitura e escrita e a introdução de mecanismos de deteção de conflitos permitem a paralelização em larga escala das transações, garantindo a consistência do estado, resolvendo o gargalo de desempenho da execução serial e estabelecendo as bases para o futuro desenvolvimento do Ethereum Rollup.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
7 gostos
Recompensa
7
5
Partilhar
Comentar
0/400
AirdropHunterZhang
· 07-29 02:07
Não vai acontecer. Todos os dias 60 vezes. A pizza ainda está a este preço.
Ver originalResponder0
GateUser-afe07a92
· 07-28 22:11
é apenas um pequeno aumento no TPS
Ver originalResponder0
ZKProofEnthusiast
· 07-28 22:09
Mestre, como é que o tps é tão rápido e ainda consegue manter a privacidade na cadeia?
Ver originalResponder0
¯\_(ツ)_/¯
· 07-28 21:56
Continue a Mineração assim.
Ver originalResponder0
GateUser-aa7df71e
· 07-28 21:48
entrar numa posição咯 irmãos TPS Grande subida vai chegar
Otimização paralela do EVM: Aumentar a eficiência do processamento de transações do Ethereum em 5 a 60 vezes
Otimização da paralelização EVM: Aumentar a eficiência do processamento de transações do Ethereum
O EVM, como o motor de execução central do Ethereum, é posicionado como um "ambiente de execução de contratos inteligentes". Para garantir que os contratos inteligentes obtenham resultados consistentes em diferentes nós, o EVM fornece um ambiente de máquina virtual multiplataforma, semelhante à máquina virtual Java (JVM).
Os contratos inteligentes são compilados em bytecode EVM e armazenados na blockchain no momento da sua implantação. Quando o EVM executa o contrato, lê esse bytecode sequencialmente, e cada instrução tem um custo de Gas correspondente. O EVM rastreia o consumo de Gas durante a execução das instruções, e a quantidade consumida depende da complexidade da operação.
O EVM tradicional processa transações de forma serial, onde todas as transações são executadas em uma única fila em uma ordem determinada. Este design é simples e fácil de manter, mas à medida que a escala de usuários cresce e a tecnologia Rollup é aplicada, o gargalo de desempenho da execução serial torna-se cada vez mais evidente.
Na arquitetura Rollup, o Sequencer, como componente-chave do Layer2, assume todas as tarefas de computação. Se outros módulos externos forem suficientemente eficientes, a execução serial do Sequencer se tornará o maior gargalo. Algumas equipes, através de otimizações extremas, conseguiram fazer com que o Sequencer pudesse executar mais de 2000 transferências ERC-20 por segundo, mas para transações mais complexas, o TPS ainda diminuirá significativamente. Assim, a paralelização do processamento de transações torna-se uma tendência de desenvolvimento futuro.
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. O Ethereum utiliza a estrutura de árvore Merkle Patricia Trie como índice de banco de dados, e a cada execução de transação, o EVM altera os dados no stateDB, refletindo finalmente na árvore de estado global.
stateDB é responsável por manter o estado de todas as contas Ethereum, incluindo saldo de contas, códigos de contratos inteligentes, entre outros. Durante a execução da transação, o stateDB realiza leitura e escrita nos dados da conta correspondente, e após a execução, o novo estado é submetido à base de dados subjacente para persistência.
A EVM e o stateDB colaboram na construção do ambiente de execução de transações do Ethereum. A EVM é responsável por interpretar e executar as instruções dos contratos inteligentes, alterando o estado da blockchain com base nos resultados computacionais, enquanto o stateDB atua como um armazenamento de estado global, gerenciando todas as mudanças de estado das contas e contratos.
No modo de execução sequencial, as transações dentro de um bloco são processadas uma a uma em ordem. Cada transação utiliza uma instância EVM independente, mas todas as transações compartilham o mesmo stateDB. Durante a execução, a EVM precisa interagir constantemente com o stateDB, lendo dados relevantes e escrevendo os resultados das alterações.
Após a execução de todas as transações dentro do bloco, os dados no stateDB serão submetidos à árvore de estado global, gerando uma nova raiz de estado. O principal gargalo deste modo de execução em série é que as transações devem ser processadas em fila, não conseguindo aproveitar plenamente os recursos de hardware, especialmente quando se trata de transações complexas de contratos inteligentes, onde a eficiência é relativamente baixa.
Para melhorar a eficiência do processamento de transações, alguns projetos começaram a tentar a otimização em paralelo com múltiplas threads do EVM. Isto é semelhante a um banco abrir múltimos balcões para atender clientes ao mesmo tempo, podendo aumentar a velocidade de processamento várias vezes, mas é necessário resolver os problemas de conflitos de estado que podem surgir.
Um projeto ZKRollup tem a abordagem de otimização paralela para EVM, que consiste em atribuir um banco de dados de estado temporário para cada thread (pending-stateDB). A implementação específica inclui:
Execução de transações em paralelo com múltiplas threads, sem interferência mútua.
Cada thread tem um pending-stateDB independente, e as mudanças de estado são registradas aqui antes da execução da transação.
Após a execução de todas as transações, as alterações no pending-stateDB devem ser sincronizadas com o stateDB global.
Esta solução otimiza as operações de leitura e escrita:
Ao realizar uma operação de leitura, verifique primeiro o ReadSet do pending-stateDB; se os dados necessários estiverem presentes, leia-os diretamente; caso contrário, leia o estado histórico do stateDB global.
As operações de escrita não são escritas diretamente no stateDB global, mas são primeiro registradas no WriteSet do pending-stateDB.
Para lidar com conflitos de estado, foi introduzido um mecanismo de deteção de conflitos:
Monitorizar o ReadSet e WriteSet de diferentes transações, considerando como conflito quando várias transações leem e escrevem os mesmos itens de estado.
Transações em conflito serão marcadas como necessitando de reexecução.
Após a execução de todas as transações, os registos de alteração em múltiplos pending-stateDB serão fundidos na stateDB global, e após o sucesso, serão submetidos à árvore de estado global e gerarão uma nova raiz de estado.
Estudos mostram que, em cargas de trabalho com baixo conflito, o TPS do EVM paralelo é 3 a 5 vezes superior ao da execução serial tradicional. Em cargas de trabalho com alto conflito, teoricamente pode chegar a uma melhoria de até 60 vezes.
Esta solução de otimização paralela multithread, através de um repositório de estado temporário e execução paralela, melhorou significativamente a capacidade de processamento de transações do EVM. A otimização das operações de leitura e escrita e a introdução de mecanismos de deteção de conflitos permitem a paralelização em larga escala das transações, garantindo a consistência do estado, resolvendo o gargalo de desempenho da execução serial e estabelecendo as bases para o futuro desenvolvimento do Ethereum Rollup.