Эта статья не о криптовалюте, а о блокчейне и совокупности технологий и идей, которые, на мой взгляд, помогут создать быстрый, масштабируемый и безопасный распределенный реестр (DLT). Простые DLT могут быть созданы с использованием возможностей смарт‑контрактов блокчейнов второго или третьего поколения, но более сложные реестры могут потребовать альтернативных решений. Примером достаточно сложного и специфического DLT может быть децентрализованная платежная система общего пользования, совместимая с государственной денежно‑кредитной политикой, то есть платформа для «цифровых денег». Реализация такого проекта на смарт‑контрактах едва ли возможна. Поэтому в статье предлагаю рассмотреть для этой роли AppChain — гибридную платформу приложения и блокчейна.

AppChain имеет ряд преимуществ перед смарт‑контрактами. Во‑первых, AppChain позволяет реализовать сложную и специфическую бизнес‑логику, что может быть трудно или невозможно сделать на смарт‑контрактах. Здесь же в вашем распоряжении будет вся мощь вашего любимого языка программирования. Во‑вторых, AppChain обеспечивает более высокую производительность и масштабируемость, поскольку приложения работают в среде операционной системы, а не в среде исполнения смарт‑контрактов блокчейна. В‑третьих, AppChain может предоставить более высокий уровень безопасности, чем смарт‑контракты при одинаково качественной реализации, поскольку он будет менее зависеть от уязвимостей в среде исполнения.

Приложение в этой комбинации является специфичным для области и, вероятно, потребует разработки с нуля. Блокчейн не является обычным, такой класс программного обеспечения называется «Application specific blockchain». Есть несколько хорошо известных проектов, которые можно использовать в качестве основы. Наиболее известным, вероятно, является Hyperledger Fabric. Но Tendermint показался мне более интересным с точки зрения интерфейса приложения и возможности расширения его функциональности.

Tendermint

Tendermint известен тем, что является основой для Cosmos SDK, с помощью которого создается одноименная блокчейн‑экосистема (монета ATOM) третьего поколения. Нижеприведенные рисунки иллюстрируют архитектуру фреймворка Cosmos SDK и AppChain. Они были взяты из статьи, в которой хорошо раскрыта тема экосистемы Cosmos.

Зеленым цветом выделен Tendermint. Другим цветом в первом случае — Cosmos SDK, во втором — AppChain.

Глядя на эти иллюстрации, возникает вопрос: а почему бы не использовать Cosmos SDK? Cosmos SDK — это уже смарт‑контракты, а нам нужен уровень пониже. Наше приложение будет взаимодействовать с Tendermint непосредственно по протоколу ABCI (Application BlockChain Interface). Физическая реализация этого протокола позволяет реализовать приложение разными методами. Оно может быть в виде модуля на Golang, который слинкуется с кодом Tendermint в один исполняемый файл. Либо это будет отдельное приложение, написанное на любом распространенном языке программирования, взаимодействующее с блокчейн‑нодой Tendermint через несколько сетевых подключений.

Tendermint предоставляет базовые возможности блокчейна, но они максимально обобщены и не накладывают на приложение ряд серьезных ограничений. Например, транзакция не специфицирована и может быть представлена любым байтовым массивом, структуру которого определяет логика приложения. Кроме того, механизм достижения консенсуса является очень гибким, и достигается через протокол Byzantine Fault Tolerant (BFT), с ограниченным списком валидаторов, заданным в генезис‑блоке и может быть изменен приложением.

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

Идентификация, Аутентификация, Авторизация

Существует серьезная причина, по которой биткоин и другие классические блокчейны не станут полноценными платежными системами. Торговля и оказание услуг контролируются государством для обеспечения взимания налогов. Чтобы определить, сколько каждый человек должен внести в казну, необходимо идентифицировать плательщиков и получателей, продавцов и покупателей, работодателей и работников. Другими словами, необходима идентификация для однозначной связи транзакций и записей распределенного реестра с налогоплательщиками. И где есть идентификация, там есть аутентификация.

Для классических блокчейнов это пытаются сделать через контроль бирж и обменников, внедряя KYC и AML. Это решает проблему налога на прибыль при обмене криптовалюты на традиционные деньги, но не проблему налога на оборот. Или сделать это будет очень сложно. Можно проанализировать цепочки транзакций дилера шелкового пути, но отследить транзакции крупной розничной сети практически невозможно.

Кроме того, необходимо реализовать банковскую тайну, где только те, кому положено, могут видеть чужие транзакции. И это только часть таких задач. Следовательно, необходима аутентификация.

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

Для идентификации хорошо подходят отличительные имена (distinguished name), например: CN=Василий,STREET=Ферма Василия,L=Нижние Бубенцы,ST=Залесье,С=Наша страна.  Думаю, многие сталкивались с ними в LDAP и в сертификатах x.509. Кстати, сертификаты - это один из механизмов, используемых для аутентификации отличительных имен. Учитывая, что стандарт x.509 третьей версии (Extended Key Usage) позволяет хранить в теле сертификата произвольные объекты, вопрос с простым решением для авторизации будет решен. Для чего-то более сложного можно будет задействовать атрибутные сертификаты.

Механизм консенсуса

Как уже упоминалось, Tendermint использует протокол Byzantine Fault Tolerant (BFT). Однако, для достижения консенсуса и определения состояния блокчейна, приложение должно определить список валидаторов, которые будут участвовать в этом процессе. Соответственно и алгоритм, используемый для составления этого списка, реализуется в приложении. 

В нашем случае это алгоритм PoA (Proof of Authority). Вкратце, в PoA транзакции подтверждаются теми, кому это положено, а не тем, кто расходует больше вычислительной мощности (PoW) или у кого больше монет (PoS). Для определения того, кому именно положено, мы будем использовать сертификаты, анализируя в них отличительное имя и/или дополнительные атрибуты.

Инфраструктура открытого ключа

Уже понятно, что сертификаты X.509 могут упростить решение задачи. Однако, для их использования необходима инфраструктура открытого ключа (PKI). В основе PKI лежит криптографическая система с открытым ключом. А что лежит в основе безопасности блокчейна? Аналогичная криптографическая система с открытым ключом. Это означает, что пользователи, использующие распределенный реестр, будут иметь пару ключей. Остается только связать публичный ключ пользователя с его отличительным именем через выдачу сертификата. После чего, все его транзакции и записи в распределенном реестре, будут однозначно с ним связаны..

Минимально необходимыми компонентами PKI являются Центр Сертификации (CA) и репозиторий, хранящий два списка: "Выданные сертификаты" и "Отозванные сертификаты". Репозитории будут храниться в записях нашего распределенного реестра. Функции CA будет выполнять соответствующая подсистема в нашем приложении. На узлах, где будет присутствовать сертификат удостоверяющего центра, эта подсистема будет работать в режиме CA server, а на всех остальных - в режиме CA client. Таким образом, мы получим распределенную инфраструктуру открытого ключа (DPKI).

Иерархии

Отличительные имена могут состоять из компонентов нескольких иерархий. Чаще всего это:

• Иерархия местоположения, представленная атрибутами "C" (страна), "ST" (регион) и "L" (город).

• Иерархия организации, представленная атрибутами "O" (организация) и "OU" (организационная единица).

• Иерархия сети, представленная атрибутом "DC" (компонент домена).

Рассмотрим отличительное имя: CN=First Wonderland CA+DC=node01,OU=Data center,L=Cheshire,C=WN+DC=wn,O=The Corporation+DC=thecorp. Оно достаточно однозначно, можно выделить все три иерархии:

• CN=First Wonderland CA,L=Cheshire,C=WN

• CN=First Wonderland CA,OU=Data center,O=The Corporation

• DC=node01,DC=wn,DC=thecorp - легко преобразовывается в FQDN node01.wn.thecorp

Они не только однозначно идентифицируют объект, но и дают представление о принадлежности объекта, его местоположении и сетевом адресе.

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

Сегментация сети

Проблемой блокчейнов первого и второго поколений было и остается отсутствие масштабируемости, что негативно сказывается на скорости обработки транзакций и размерах хранилищ. Однако, в блокчейнах третьего поколения эта проблема частично решается путем использования вариаций на тему "sidechain". Сайдчейны - это проблемно-ориентированный блокчейн, имеющий канал взаимодействия с одним из базовых блокчейнов. Хорошим примером может быть блокчейн, используемый для хранения состояния сетевой игры. Большинство транзакций, определяющих изменения игрового мира, обслуживаются в его собственной сети. Лишь небольшая часть транзакций, отвечающих за ввод/вывод финансовых активов (например, ETH), попадают в сеть mainchain (Ethereum) и обслуживаются там.

Думаю, многие помнят игру Cryptokitties, которая на пике популярности чуть не прикончила сеть Ethereum. В этой игре все игровые действия обслуживались смарт-контрактами Ethereum и генерировали большое количество транзакций в сети эфира. А если бы это было реализовано на sidechain, как описано выше, никто бы даже не заметил бы активности любителей цифровых котиков.

Таким образом, введение sidechain может решить проблему масштабируемости блокчейна и сделать его более эффективным при обработке транзакций. Иерархические сайдчейны могут дать более эффективное решение этой проблемы.

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

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

Видно, что для фиксации транзакции от Василия нет никаких препятствий. В столичном сегменте эта информация не нужна никому, и она туда не попадает. А вот в сегменте, где находится отделение банка, эта транзакция должна попасть, и валидаторы этого сегмента должны ее подтвердить.

Вторая транзакция же зависнет на уровне OU=Залесский филиал, ST=Залесье, O=Банк, С=Наша страна. Если связь будет восстановлена раньше, чем истечет таймаут обработки транзакций, транзакция будет проведена с опозданием. В противном случае возникнет ошибка, которую приложение должно будет обработать по соответствующим  алгоритмам.

То есть в случае физических аварий сегменты ниже места разрыва будут штатно работать с транзакциями, чей маршрут исполнения не проходит через аварийный участок.

Сохранение работоспособности в отсутствии сети

Известно, что покупки можно совершать с помощью "цифровых юаней" даже без подключения к интернету. Надеюсь, что этот функционал будет доступен и для "цифрового рубля". Неизвестно, как это реализовали китайцы, но полагаю, что это может быть метод, аналогичный тому, который описан ниже.

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

• Геннадий имеет сертификат, удостоверяющий его личный публичный ключ (аккаунт) в нашей платежной системе, и соответственно, имеет запись в реестре, подтверждающую наличие у него определенного количества "цифровых рублей".

• Согласно положениям о банковской тайне информация зашифрована и доступна только банку, Геннадию и налоговым органам. Банк также имеет сертификат, удостоверяющий его как субъекта платежной системы. В этом случае он выступит посредником, гарантирующим наличие средств на цифровом счете Геннадия. В принципе, в качестве такого посредника могли бы выступать и налоговые органы.

Для возможности оплаты офлайн необходимо выполнить следующие действия онлайн:

• Геннадий должен создать производные ключи и соответствующую запись в реестре на основе своей основной пары ключей. Этот объект/счет будет называться "Чековая книжка Геннадия".

• Затем Геннадий переводит определенную сумму со своего основного счета на этот новый счет.

• Основной счет Геннадия зашифрован, и наличие на нем необходимой суммы может проверить только банк.

• Банк выдает подтверждение в виде сертификата на открытый ключ (адрес) "Чековая книжка Геннадия" с указанием суммы, которая была зачислена на него. Это может быть реализовано как расширение v3 для сертификата..

Таким образом, мы получаем электронный аналог чековой книжки, владелец которой известен и подтвержден сертификатом. Также известна начальная сумма чековой книжки, подтвержденная сертификатом, подписанным банком. При оплате офлайн Геннадий генерирует и подписывает транзакцию на требуемую сумму со счета чековой книжки, присваивает ей порядковый номер и передает ее через QR-код на платежный терминал получателя платежа. Это будет соответствовать передаче заполненного и подписанного чека из чековой книжки. Вероятно, получатель захочет убедиться в корректности чековой книжки. Для этого достаточно передать локально с терминала на терминал (с помощью тех же QR-кодов или иным способом) сертификат Геннадия, сертификат счета чековой книжки и, возможно, информацию о номерах и суммах предыдущих транзакций.

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

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

ГОСТ криптография

Замахнувшись на создание национальной платежной системой важно учитывать следующий фактор. Используемые криптографические алгоритмы должны быть сертифицированы компетентными органами. В России такие алгоритмы определены:

• ГОСТ Р 34.11-2012 - Формирование хеша 256 и 512 бит.

• ГОСТ Р 34.10-2012 - Цифровая подпись на основе эллиптических кривых; размер ключа 256 и 512 бит; функция хеширования ГОСТ Р 34.11-2012.

• ГОСТ Р 34.12-2015 - Блочный шифр “Кузнечик”; размер ключа 256 бит; размер блока 128 бит.

Tendermint использует криптографические алгоритмы: sha256, ed25519. Также заявляется поддержка secp256k1. Все криптографические функции собраны в отдельный пакет. В Tendermint нет хорошо проработанного интерфейса, позволяющего использовать различные алгоритмы, как в Hyper Ledger Fabric. Поэтому его "гостофикация" будет сложнее, чем "гостофикация" HLF, но это вполне осуществимо.

В заключении

Тема очень интересная. Уже довольно продолжительное время, с паузами, но я изучаю это направление. “С паузами”, потому что деньги в семью не приносят себя сами. Можно попробовать совместить приятное с полезным, устроиться на работу в компанию, которая занимается разработкой распределенных реестров. Попробовать можно, но не факт, что её  удастся найти. Компании, которые этим занимаются всерьез и продолжительное время, есть, но техническая информация о проектах практически отсутствует в публичном доступе. То, что удалось выяснить, указывает на то, что они разрабатывают свои распределенные реестры на базе смарт-контрактов на модифицированном Ethereum. Понятно, что если они начинали работу 4-5 лет назад, то и особых вариантов не было. Но это не то, уже не то.

Многие компании с успехом используют Hyperledger Fabric, но они применяют его для решения конкретных задач заказчиков. Но велик соблазн сделать свой Hyperledger Fabric с иерархической сегментацией и DPKI. О компаниях, которые гостофицируют что-то модное и объявляют это - национальной платформой для выпуска токенов и NFT, можно упомянуть только для галочки.

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

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

• Модуль, который упрощает написание приложений ABCI на Python. Содержит асинхронную реализацию ABCI и минималистический фреймворк.

• Прототип распределенной инфраструктуры открытых ключей DPKI, описанный в статье. Это еще не MVP, но уже можно посмотреть. Надеюсь довести до уровня MVP в скором времени.

• Попытка гостофикации Tendermint, пока не полная. Сетевой уровень генерирует производные ключи и работает на ed25519. Уровень консенсуса проходит тесты с ГОСТ ключами, но  решение  не окончательное. Чтобы сделать это правильно, нужно создать хороший интерфейс криптопровайдера, как у HLF. Сейчас все это в Tendermint прибито гвоздями, и моя попытка по сути сводится к подмене этих гвоздей.