Инженерный взгляд на блокчейн: почему это просто реплицируемый append-only лог

Автор планомерно сдирает маркетинговый слой и показывает инженерную подложку — реплицированный append-only лог, где состояние есть проекция, а запись стоит денег. Для аудитории, у которой при слове «блокчейн» дёргается глаз от «революций» и «цифрового золота», это редкий случай, когда протокол объясняют на языке продакшн-систем, а не whitepaper-поэзии.

Append-only как объединяющая абстракция

Автор выстраивает три параллели, и они рабочие. Write-ahead log в Postgres: перед изменением страницы данных изменение сначала пишется в конец лога, без правок задним числом; упал сервер — состояние восстанавливается проигрыванием WAL, таблицы — производное. Топик в Kafka: продюсеры дописывают сообщения в конец партиции, оффсеты только растут, прошлое неизменяемо до срабатывания retention. Коммит в git: каждый коммит несёт хеш родителя, подмена трёхлетней давности ломает всю последующую цепочку, потому что каждый следующий коммит ссылается на несуществующий хеш.

Блокчейн собран из этих трёх деталей. Единица записи — не коммит и не сообщение, а блок: пачка транзакций плюс служебные данные. В Ethereum новый блок появляется примерно раз в 12 секунд, и каждый блок несёт хеш предыдущего — ровно как коммит в git несёт хеш родителя. Kafka-подобный лог + git-подобная цепочка хешей + репликация на тысячи узлов. Никакой магии — тривиальная комбинация проверенных паттернов.

Состояние как fold, а не ячейка

Второй тезис сильнее ломает интуицию. «Баланс кошелька» — это не ячейка, в которой лежит число. Когда вы видите «на адресе 1.5 ETH», нигде нет записи balance=1.5, которую кто-то обновляет. Есть только лог всех транзакций с начала времён, а баланс — результат его проигрывания: пришло +2, ушло −0.5, итого 1.5. Состояние вычисляется из истории, а не хранится вместо неё.

Это event sourcing в чистом виде. Истина — история событий; текущее состояние — свёртка (fold) по этой истории; снести состояние и пересчитать с нуля можно в любой момент, получив байт в байт то же самое. Ноды, конечно, кешируют вычисленное состояние — пересчитывать миллиарды транзакций на каждый запрос никто не станет. Но это именно кеш, materialized view поверх журнала. Сравните с обычной базой: удалите таблицу без бэкапа — данные потеряны, потому что таблица и была истиной. Здесь истина — лог.

Где аналогия ломается

Автор обещает в финале подключение к реальной сети из десяти строк на TypeScript — это правильный подход к аудиту протокола: прежде чем читать whitepaper, прогоните запросы к ноде и посмотрите на сырой лог транзакций. Если вы до сих пор воспринимаете блокчейн как «распределённую магию» — откройте обозреватель, экспортируйте список транзакций любого контракта и сверните балансы самостоятельно. Десять строк кода заменяют десять часов чтения маркетинговых материалов.

Но у редукции есть цена. Разбор ни слова не говорит об overhead консенсуса, об экономической модели безопасности и о том, почему append-only лог в Postgres нельзя просто так вынести на тысячу недоверяющих друг другу нод. Аналогия прячет именно тот слой, где живёт основная инженерная сложность протокола — слой adversarial game theory между валидаторами. Без него вы понимаете WAL, но не понимаете блокчейн. Используйте материал как вводную, но не путайте педагогическое упрощение с полной архитектурной картиной.