Блокчейн Ethereum похож на блокчейн Bitcoin во многом, но не во всем. В первую очередь их архитектуры различаются тем, что в Ethereum, в отличие от Bitcoin, блоки содержат копию не только списка транзакций, но и последнего состояния системы. Также в них хранится еще два значения: номер блока и его сложность. Базовый алгоритм валидации блока в Ethereum выглядит так.

1. Убедиться, что блок, который определяется как предыдущий, существует и валиден.

2. Убедиться, что временная метка создающегося блока больше, чем у предыдущего, но не более чем на 15 минут.

3. Проверить валидность номера блока, его сложности, лимита газа, корень транзакции, корень анкла (различные низкоуровневые значения, специфичные для Ethereum).

4. Проверить валидность proof-of-work.

5. Пусть S[0] – состояние на конец предыдущего блока.

6. Пусть TX – список транзакций в блоке, а всего транзакций n. Для всех 0…n–1 установим S[i+1] = APPLY(S[i],TX[i]). Если при применении некоторых транзакций возникает ошибка или если общее количество потребленного газа к этому моменту превышает GASLIMIT, выдать ошибку.

7. Пусть S_FINAL будет S[n], но с выплатой майнеру награды за нахождение блока.

8. Проверить, совпадает ли корень дерева Меркла состояния S_FINAL с корнем финального состояния из заголовка блока. Если да, блок валиден; в противном случае – нет.

На первый взгляд такой подход может показаться крайне неэффективным, поскольку предполагает хранение текущего состояния в каждом блоке, но на самом деле его эффективность сопоставима с эффективностью Bitcoin. Причина в том, что состояния хранятся в древовидной структуре и с нахождением нового блока изменяется лишь малая часть дерева. Два смежных блока имеют по большей части одинаковые деревья, а значит, данные можно записать один раз, а потом на них ссылаться (например, через хеши поддеревьев). Для этого используется особая модификация дерева Меркла – «дерево Патрисии», которое позволяет эффективно добавлять и удалять ноды, а не просто менять их. Наконец, поскольку вся информация о состояниях содержится в последнем блоке, нет необходимости хранить всю историю блокчейна – в Bitcoin такая стратегия помогла бы сохранить в 5–20 раз больше пространства.

Часто возникает вопрос о том, «где» выполняется код контракта с точки зрения физического оборудования. На это есть простой ответ: процесс выполнения кода контракта – часть определения функции перехода состояния, которая, в свою очередь, является частью алгоритма валидации блока. Поэтому, если транзакция добавлена в блок B, выполнение кода, порожденного этой транзакцией, будет выполняться всеми нодами (и сейчас, и в будущем) при загрузке и валидации блока B.