Текущий EVM обрабатывает смарт-контракты последовательно из-за своей архитектуры интерпретатора на основе стека, и, честно говоря, такой дизайн сопровождается реальными накладными расходами. Интерпретатор тратит значительные ресурсы на управление структурой данных стек — добавление, удаление, управление памятью — а не на выполнение самой вычислительной работы.

Вот практическое сравнение: представьте себе стопку тарелок в столовой. Каждый раз, когда вам нужна тарелка, вы должны взять ее с вершины. Если вы собираете набор для блюда с несколькими ингредиентами, вы постоянно складываете и распаковываете тарелки, чтобы получить нужное. Чем сложнее ваша операция, тем больше времени уходит на управление стеком, а не на приготовление еды. В этом и заключается суть — накладные расходы на поддержку стека растут, и эффективность выполнения страдает. Эта архитектурная особенность вызвала постоянные обсуждения в сообществе разработчиков о возможностях оптимизации и потенциальных будущих улучшениях в том, как VM обрабатывает выполнение контрактов.