Архитектура блокчейн систем весьма интересна и не смотря на свою кажущуюся сложность на самом деле состоит из довольно простых элементов, которые широко используются не только в блокчейн системах но и в разработке программ в индустрии в целом. Да, все довольно сложно и просто одновременно. Парадокс? Предлагаю разобраться и попробовать выделить ключевые элементы из которых состоят все блокчейн системы и распределенные реестры.
Event Store
Итак, начнем с начала. Пользователи взаимодействуют с блокчейнами отправляя транзакции. Не будем углубляться в подробности про подпись транзакций ключем пользователя и хотя вся эта криптография весьма интересна она в данном случае обеспечивает только один из этапов валидации. Так вот, транзакции, которые являются запросами на выполнение функций в системе, отправляются пользователем на вход в систему, проверяются на валидность, выстраиваются в очередь и сохраняются в этой очереди навсегда. Все это наводит на мысль об использовании паттерна Event Sourcing. Это значит что всегда есть возможность обработав всю последовательность событий получить состояние актуальное системы. А так как события храняться бесконечно и в строгой последовательности, то блокчейны представляют собой разновидность хранилищ событий (Event Store). Одним из вариантов такого хранилища при традиционной разработке программ является Kafka.
Валидатор
Следующим этапом обработки запросов (транзакций) в блокчейн системах является валидация. Проверяется та самая подпись пользователя и ряд других параметров. Важной функцией валидатора является лимитирование пользовательской активности, для предотвращения перегрузки сети и оганичения особо активных пользователей. Как будет работать валидатор и что именно проверяется зависит от самого валидатора и его конфигурации. Есть системы с настраиваемыми валидаторами, например Ethereum. Да, те самые умные контракты позволяют конфигурировать валидатор, определяя какие запросы бедут обработаны системой а какие нет. И конечно валидатор может иметь состояние, на которое влияют обрабатываемые системой запросы, но хранение этого состояния не является важным, так как его всегда можно восстановить обработав всю последовательность запросов заново.
Консенсус
Любые рапределенные системы, а все блокчены являются распределнными систмами, требуют использования некоторого алгоритма консенсуса. Задача алгоритма консенсуса обеспечить синхронизацию данных между узлами сети. Одним из наиболее широко распространенных традиционных алгоритмов консенсуса является Raft. Однако блокчейн системах он не применим из-за возможного наличия в сети недобросовестных узлов. Вместо него используются разновидности алгоритмов устойчивых к византийским ошибкам (BFT). И да, конечно придется придумать некоторый способ определения доверенных узлов, которым будет позволено принять участие в голосовании в процессе выработки консенсуса.
Консенсус хоть и идет тертьим в списке, является самой важной и сложной частью системы, ведь от него зависит насколько сеть будет устойчива к различного вида техническим сбоям, сетевым проблемам и злонамеренным атакам.
И кое что еще
Да, приведенные выше три элемента являются ключевыми для реализации любой блокчейн системы. Конечно желательно еще хранить текущее состояние и добавить индексов для поиска по транзакциям, но все это лишь вспомогательные элементы которые обеспечивают удобство работы с системой, хотя большенство существующих блокчейнов не особо балуют пользователей удобством.