O EVM atual processa contratos inteligentes sequencialmente devido à sua arquitetura de interpretador baseada em pilha, e honestamente, este design traz overhead real. O interpretador gasta recursos consideráveis a gerir a estrutura de dados da pilha — empurrar, popar, gerir memória — em vez de fazer o trabalho de computação real.

Aqui está uma forma prática de visualizá-lo: imagine uma pilha de pratos numa cantina. Cada vez que precisa de um prato, deve removê-lo do topo. Se estiver a montar uma refeição com múltiplos ingredientes, está constantemente a empilhar e desempilhar pratos só para aceder ao que precisa. Quanto mais complexa for a sua operação, mais tempo é gasto a gerir a pilha em vez de preparar a comida. Isso é essencialmente o que acontece com o EVM — o overhead de manter a pilha cresce, e a eficiência da execução sofre. Esta restrição arquitetural tem provocado discussões contínuas na comunidade de desenvolvedores sobre possibilidades de otimização e melhorias futuras potenciais na forma como a VM lida com a execução de contratos.