Что такое блокчейн: как устроены блоки, транзакции и проверка данных

Блокчейн — это способ вести историю записей, объединяя их в блоки со ссылками на предыдущие блоки. В работающей сети узлы проверяют новые записи по общим правилам и согласуют, какую историю принимать. Хеши помогают обнаружить подмену данных, подписи — проверить, каким ключом разрешено действие, а механизм консенсуса — выбрать допустимое продолжение цепочки. Из этого не следует, что любое записанное сообщение правдиво: строка «груз принят» сама по себе не доказывает, что груз доехал.

Зачем нужны хеши и подписи

Представим учебную систему: отправитель, перевозчик и склад ведут общий журнал движения груза. У каждого есть своя копия записей, и никому не хочется принимать исправленную задним числом версию только со слов другого участника. Можно договориться объединять очередные записи в блок и включать в него хеш предыдущего блока. Так появляется связь между частями истории. Пока мы описали структуру данных; кто вправе добавлять блоки и как разрешать разногласия, ещё предстоит определить.

Хеш — результат вычисления над точными входными данными. Для SHA-256 это 256 бит, обычно записанных как 64 шестнадцатеричных символа. Одни и те же байты всегда дают один результат. Изменение пробела, знака препинания или кодировки может дать совсем другой хеш. Удобная аналогия — короткий цифровой отпечаток, но с оговоркой: это не уникальный номер, который кто-то выдал и хранит в общей базе. Его заново вычисляют по самим данным.

Проверим на двух строках. «Груз принят.» в UTF-8 без перевода строки даёт хеш, начинающийся с 84eb94e8. Для «Груз принят!» начало уже 994e6fc3. Здесь показаны только первые восемь символов из 64. Замена точки на восклицательный знак меняет один байт; повторный расчёт для исходной строки возвращает прежний результат. Мы сверили полные значения в Python и PowerShell. Это небольшой опыт с хешированием, а не испытание сети или доказательство доставки.

Хеширование не скрывает исходное сообщение. Если человек предполагает, что записано «принят» или «не принят», он может посчитать оба варианта и сравнить результат. Хеш также не является сжатым архивом: из него нельзя восстановить произвольный исходный документ. У криптографической функции требуется стойкость к поиску подходящих совпадений, но фраза «разные данные математически никогда не дают одинаковый хеш» неверна. Выход имеет фиксированную длину, а возможных входов гораздо больше.

В Bitcoin заголовок блока содержит отдельно хеш предыдущего заголовка и корень дерева Меркла, связанный с транзакциями текущего блока. Это две разные связи. Первая связывает блоки во времени, вторая позволяет проверить включение конкретной транзакции через цепочку промежуточных хешей. Поэтому схема из трёх прямоугольников передаёт только часть устройства: у блока есть ещё собственное содержимое и правила его проверки.

Если изменить старую запись, изменятся связанные с ней вычисляемые значения. Можно пересчитать и последующие хеши, получив другую, внутренне согласованную цепочку. Одни хеши этому не мешают. Вопрос в том, почему другие участники должны принять такую версию. Ответ появляется только вместе с правилами допустимости блоков и консенсусом. Именно этот шаг часто теряется в объяснении «каждый блок ссылается на предыдущий, поэтому ничего изменить невозможно».

Цифровая подпись решает другую задачу. Закрытым ключом создают подпись сообщения, а соответствующим открытым ключом проверяют её. Это не следует объяснять как «шифрование наоборот»: у подписи собственные алгоритмы и условия проверки. В нашей учебной системе подпись склада показывает, что сообщение подписано ключом, который правила системы связывают со складом. Саму связь ключа с организацией устанавливают отдельно.

Как транзакция становится частью истории

Транзакция в блокчейне — оформленная по правилам сети операция. Она может передавать единицы цифрового актива, вызывать программу или менять запись прикладного реестра. В учебном примере склад отправляет операцию «принять груз №42». Это ещё намерение изменить состояние. Получение сообщения одним сервером не означает, что остальные участники его проверили и сохранили.

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

Дальнейшая последовательность зависит от системы. В Ethereum предложенный блок включает операции, исполнение которых проверяется по правилам сети. В Hyperledger Fabric сначала можно получить результаты симуляции и требуемые подписи одобрения, затем сервис упорядочивания соберёт блок, а узлы проверят операции перед обновлением текущего состояния. Переставлять эти этапы в одну универсальную схему «сначала все одобрили, потом записали» нельзя.

У Fabric есть показательный случай. Две операции подготовлены, когда груз ещё имеет статус «в пути». Первая меняет его состояние. При последующей проверке второй операции обнаруживается, что прочитанная ею версия записи устарела. Такая операция может остаться в сохранённом блоке с отметкой недействительности, но её изменения не будут применены к текущему состоянию. Наличие операции в истории и выполнение её замысла — разные результаты.

В Ethereum включённая транзакция тоже может завершиться неуспешным выполнением. Например, программа отклоняет вызов из-за невыполненного условия. В квитанции исполнения это отражается статусом. Сам факт включения сохраняется, а предусмотренные правилами последствия, включая учёт затраченных вычислительных ресурсов, не сводятся к фразе «ничего не произошло». Поэтому подпись, включение и успешное выполнение стоит проверять как отдельные свойства.

Таблица объясняет смысл этапов, а не названия кнопок: обозреватели показывают их по-разному. Один сервис может задержаться с обновлением, другой — смотреть на иной узел. Для технического разбора полезны точная сеть, идентификатор операции, хеш блока и результат исполнения. Скриншота с зелёной галочкой без этих сведений мало, чтобы понять, что именно подтверждено.

Смарт-контракт — программа, которая определяет допустимые действия и работает с состоянием. В нашем примере она могла бы разрешить приёмку только назначенному складу и только для груза, который ещё в пути. Программа проверит заданные условия, но сама не осмотрит коробки. Чтобы использовать сведения от датчика или человека, системе нужен отдельный способ получения этих сведений.

Как узлы выбирают одну цепочку

Даже корректные участники получают сообщения в разное время. В Bitcoin два майнера могут почти одновременно предложить допустимые блоки с одним предшественником. На короткое время появятся конкурирующие продолжения: часть узлов увидит один блок раньше, часть — другой. Это само по себе не означает взлом. Нужен способ выбрать продолжение, на котором участники смогут снова сойтись.

Bitcoin использует доказательство работы, Proof of Work. Подбирается заголовок, хеш которого соответствует целевому ограничению; поиск требует повторных вычислений, а проверка найденного результата существенно проще. Среди цепей, удовлетворяющих правилам, узел выбирает цепь с наибольшей накопленной работой. Здесь важно слово «допустимых»: большой объём вычислений не делает неправильную подпись правильной.

Выражение «самая длинная цепь» удобно как первое приближение, но число блоков не равно накопленной работе. Это разные характеристики, они отдельно представлены и в интерфейсе Bitcoin Core. Правило также не является голосованием всех подключённых компьютеров: создание множества сетевых адресов само по себе не даёт соответствующую долю работы.

Когда предпочтительная ветвь меняется, узел может перестроить последние принятые блоки — это называют реорганизацией. Операция из прежней ветви не обязательно исчезает навсегда: она может попасть в другое продолжение, если остаётся допустимой. Но её прежнее место уже нельзя считать неизменным. Число следующих блоков показывает глубину в конкретной цепи, а не абсолютную гарантию, действующую при любых условиях.

В Ethereum после перехода на Proof of Stake производство блоков и согласование истории устроены иначе. Валидаторы предлагают блоки и подписывают сообщения о своём видении цепи; имеют значение правила протокола и вес голосов, связанный со стейком. Выбор текущей вершины и финализация контрольных точек решают связанные, но разные задачи. Переносить сюда объяснение Bitcoin про соревнование майнеров было бы ошибкой.

Финальность означает, что по правилам данного протокола для принятой части истории выполнены условия, препятствующие обычному переключению на конфликтующую версию. Это сильное свойство внутри заданной модели, но у модели есть предположения о поведении участников и работоспособности сети. Слово «финально» не обещает безошибочного программного обеспечения или невозможности любого чрезвычайного сбоя.

У корпоративных сетей могут быть другие механизмы согласования и заранее известные участники. В частности, сервис упорядочивания Fabric 2.5 на Raft рассчитан на определённую модель отказов и не превращается от названия «блокчейн» в защиту от любых злонамеренных действий. Объяснять все сети одним процентом «честных узлов» неверно: различаются роли, веса и допустимые отказы.

Практический смысл консенсуса в нашем примере — согласовать порядок взаимоисключающих действий. Если отправитель пытается отменить отправку в тот момент, когда склад оформляет приёмку, важны согласованный порядок и прикладные правила. Компьютеры не голосуют о том, нравится ли им сообщение; они проверяют формальные условия и участвуют в установленной процедуре.

Почему состояние меняется, хотя история сохраняется

После приёмки у груза меняется статус: раньше он был в пути, теперь находится на складе. Блокчейн не запрещает такое изменение. Нужно различать журнал действий и текущее состояние, которое получилось после их применения. Запись о приёмке остаётся в истории, а запрос приложения «где сейчас груз №42?» возвращает актуальный результат.

В Fabric реестр включает цепочку блоков и базу текущего состояния — world state. Значения в ней можно обновлять по правилам программы; они не обязаны навсегда оставаться такими, какими были при создании. Подобное представление позволяет отвечать на запросы к актуальным данным, не пересчитывая при каждом чтении все действия за прошлые годы. Для проверки и восстановления важна связь этого состояния с историей.

В Ethereum состояние тоже меняется при исполнении допустимых операций. Переменная смарт-контракта может хранить новое значение, хотя история транзакций никуда не «редактируется поверх». При этом размещённая реализация программы и поведение приложения — не всегда одно и то же: приложение с прокси может перенаправлять вызовы к другой реализации, если это предусмотрено его устройством и правами управления. Поэтому лозунг «смарт-контракт нельзя изменить» мало сообщает о конкретном приложении.

Разные узлы хранят разный объём данных. Полная проверка новых блоков не тождественна хранению каждого исторического состояния в форме, удобной для немедленного запроса. Архивный узел нужен, в частности, чтобы получать прошлые состояния без долгого повторного вычисления. В Bitcoin проверяющий узел может удалять старые файлы блоков после обработки; слово «полный» не означает, что он обязан бессрочно раздавать всю историю.

Облегчённый клиент проверяет меньше данных, используя заголовки и доказательства. Какие именно выводы он может сделать, зависит от протокола. Доказательство включения записи не заменяет полную проверку всех правил исполнения. А браузерная страница обозревателя может просто показывать сведения, полученные от своего сервера: наличие таблицы с хешами ещё не делает браузер проверяющим узлом.

Данные могут находиться и вне цепочки. Например, система хранит хеш накладной, а сам файл лежит в отдельном хранилище. По сохранившемуся файлу можно заново вычислить хеш и проверить совпадение. Если файл потерян, запись хеша не вернёт его содержимое. Даже адресация по содержимому в IPFS не означает, что кто-то обязательно продолжает хранить и раздавать нужные байты.

Представим, что в накладной исправили опечатку. Можно зарегистрировать новую версию и связь со старой, сохранив обе записи о событии. Это прикладное решение: нужно определить, кто вправе вносить исправление и какую версию считать действующей. Сам способ хранения не выбирает эти правила за разработчика и не превращает ошибочный документ в правильный.

Кто видит данные и где остаётся доверие

В открытой сети обычно можно самостоятельно получить публичные данные и проверить их по правилам протокола. Однако «открытая», «общедоступная» и «без разрешения на участие» описывают разные свойства. Разработчик может открыть чтение, ограничив запись известными организациями. А внутри сети с доступом по разрешению участникам могут быть доступны разные наборы сведений.

У Fabric есть механизм приватных коллекций данных. Уполномоченные участники получают само содержимое, а другие участники того же канала могут видеть связанные с ним хеши. Это полезный пример того, почему неверна фраза «в блокчейне каждый видит абсолютно всё». Конкретную видимость определяют устройство системы и её настройки. Хеш приватного значения при этом не стоит считать универсальным способом скрыть легко угадываемое содержимое.

Открытый адрес тоже не равен паспортному имени. Подпись связывает действие с ключом, а сведения о владельце возникают из других данных: регистрации, сертификата, опубликованного адреса, поведения пользователя. Отсутствие имени в поле не доказывает анонимность. Для чтения схемы достаточно разделять ключ, адрес, учётную запись и личность, не объявляя их синонимами.

Программные слова могут вводить в заблуждение. Переменная с видимостью private в смарт-контракте ограничивает доступ средствами языка, но не делает хранящиеся в публичной цепочке байты секретными. Аналогично возможность вызвать контракт не означает, что опубликован его удобочитаемый исходный код или что любому вызову разрешено менять любые данные. Ограничения задаёт сама программа.

Вернёмся к грузу. Датчик отправил сообщение «температура в норме», и система корректно сохранила его. Это подтверждает историю сообщения, но остаются вопросы: где стоял датчик, был ли он исправен, к какому грузу относилось измерение? В исследовательской работе о применимости блокчейна разобран наглядный пример: охлаждать можно место датчика, оставив остальной груз без нужных условий. Ни подпись, ни согласованная цепочка не замечают такую подмену контекста сами.

Средства доставки внешних сведений в программу часто называют оракулами. Они помогают сделать данные доступными для исполнения, но не устраняют вопрос к их происхождению. Несколько поставщиков могут повысить устойчивость сбора, однако простое число поставщиков ещё не доказывает независимость: они способны пользоваться одним исходным каналом. Для нашей учебной системы требуется отдельно описать, кто сообщает о приёмке и что считается достаточным основанием.

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

Чем блокчейн отличается от обычной базы данных

Базы данных давно умеют хранить журнал изменений, делать резервные копии, поддерживать реплики и разрешать одновременные обращения. Например, PostgreSQL использует журнал предзаписи для восстановления после сбоев, а SQLite тоже имеет режим с журналом WAL. Поэтому сравнение «обычная база хранит только последнее значение, блокчейн хранит историю» неточно: история возможна в обоих случаях, хотя цели и правила её ведения различаются.

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

Общий реестр становится предметом обсуждения, когда несколько самостоятельных участников хотят совместно проверять историю и не готовы отдать её одному оператору. Но сначала им всё равно надо договориться о праве записи, проверках, доступе к данным, исправлениях и поведении при отказах. Даже в этом случае блокчейн — вариант решения, который сравнивают с альтернативами, а не обязательный итог слова «несколько».

Это вопросы к устройству системы, а не анкета с автоматическим ответом. По ним можно разобрать и обещание поставщика. Если заявлено «данные невозможно подделать», уточнение звучит так: кто вводит исходные сведения, что именно проверяется и кто способен изменить правила приложения? Если обещана «полная децентрализация», нужны сведения о владельцах узлов, клиентах и внешних сервисах, а не только количество значков на схеме.

Новости о таких проектах тоже стоит разбирать по отдельным утверждениям. Факт запуска пилота, показанный результат испытания и обещание будущего внедрения требуют разных подтверждений. Для работы с сообщением, его датой и первичным контекстом пригодится отдельное руководство по проверке новостей.

Приложение на блокчейне нередко включает обычную базу, сервер, файловое хранилище и веб-интерфейс. В описании R-chain разработчики отдельно рассказывают о базе представления бизнес-процессов и адаптере к компонентам распределённого реестра. Это исторический пример архитектуры, а не подтверждение нынешних характеристик продукта: наличие блокчейна не отменяет остальные программные части.

В учебной истории с грузом границы теперь ясны. Цепочка связывает записи, подписи проверяют действия ключей, прикладные правила ограничивают изменения, а консенсус определяет принимаемый порядок. Проверка состояния коробок и достоверности показаний остаётся отдельной задачей. Чтобы понять любую похожую систему, полезно найти все эти части и выяснить, какая из них отвечает за конкретное обещание.