Эта статья не о криптовалюте, а о блокчейне и совокупности технологий и идей, которые, на мой взгляд, помогут создать быстрый, масштабируемый и безопасный распределенный реестр (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. Однако, кое-что мною уже сделано. Не уверен, что этим можно похвастаться, но ссылки на репозитории приведу. Возможно это поможет заинтересовать этой темой кого-то ещё:

Комментарии (11)


  1. ivankudryavtsev
    00.00.0000 00:00

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


    1. Alesh Автор
      00.00.0000 00:00

      Представите себе смарт-контракт и виртуальную машину EVM как единое целое. Это будет примерно соответствовать ABCI приложению Tendermint.


  1. Number571
    00.00.0000 00:00

    Не знаю, может ли это помочь хоть как-то, но схожие задачи в своё время я пытался решать. Одной из таковых стало переписывание ядра Tendermint на ГОСТ криптографию. В конечном итоге, я написал пакет на go, который использовал криптопровайдер КриптоПРО и импортировал его в tendermint, заменив все криптографические пакеты.

    ГОСТ tendermint: https://github.com/number571/tendermint

    Пакет go-cryptopro: https://github.com/number571/go-cryptopro

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


  1. ibashevv
    00.00.0000 00:00

    Идея просто отличная.

    Но моими скудными знаниями в программировании я даже не смогу что ли добавить ????????‍♂️.

    А так удачи вам в реализации ❤️


  1. VVitaly
    00.00.0000 00:00
    +2

    Остался вопрос. Зачем тут блокчейн?
    У покупателя свой публичный ключ подписанный его банком и единым центром сертификации. У продавца услуг свой. Offline (если нет Online) транзакция подписывается с двух сторон. Что еще необходимо? Для получения средств на свой банковский счет продавец ее "предъявляет" (когда Online появится) своему банку, банк продавца предъявляет банку покупателя и выполняют взаиморасчет. Все.
    В случае нехватки средств у покупателя (по разным причинам, поскольку Online проверок не было) его банк кредитует его и "дерет %" (все довольны). Сознательных нарушителей/махинаторов/закредированных лишают подписанных сертификатов (причем централизованно).
    И где тут блокчейн?


    1. Alesh Автор
      00.00.0000 00:00

      Прошу прощение что не сразу ответил. Когда в хабр залили гиктаймс, я не сразу “просек фишку”. В общем, усомнился в комментария, что Маск великий инженер. За это теперь писать комменты, даже к своей статье, могу не больше раза в день :))

      Я честно говоря не уловил в каком конкретном моменте и в связи с чем возник вопрос “И где тут блокчейн?” Но у меня три версии :)

      1. Да пока Геннадий и фермы офлайн, то блокчейна нет, есть только формирование транзакций. Блокчейн появится, когда появится связь. Транзакции будут переданы в сеть и отрабатываются блокчейном для формирования нового его состояния.

      2. Если эта была отсылка к тому что и обычное банковское ПО справится. Да, справится. А 100 лет назад с этим прекрасно справлялась обычная бумажная чековая книжка. Но речь шла о национальной платежной системе. Общенациональной, распределенной. На последней схеме я показывал, что она может и без “связи с центром” работать. Речь не об платежной системе конкретного банка. Я использовал термин банк, но не в том смысле, что это красивый зеленый, синий или красный дом. А как институт, обеспечивающий “банковскую тайну” и соответствие государственной кредитно-денежной политике. Как необходимый посредник удостоверяющий владение гражданином заявляемых активов. В тексте кстати написано, что эту функцию могла бы выполнить и налоговая. Банк, просто потому что сейчас именно банк выполняет эту функцию. 

      3. Или вы в принципе не понимаете нафига в этой схеме блокчейн? Обсуждается архитектура Распределенного Реестра. 

        1. Распределенного - значит БД распределенная, а значит нужен механизм репликации данных между узлами. А для этого нужен P2P сетевой уровень. 

        2. Реестр - по русски понятие не такое четкое, а вот ledger уже четче. Это бухгалтерская книга, прошитые листы. То есть то что гарантирует неизменность записанных данных.

      Какой класс ПО обладает всеми этими свойствами? Блокчейн. Потому и есть смысл использовать его в качестве платформы для таких решений. 

      Я ответил на вопрос? Если нет, переформулируйте. Завтра попробую еще раз.


      1. VVitaly
        00.00.0000 00:00

        А вам встречный вопрос. :-)
        Кому нужна (кто заинтересован) в распределенной транзакционной системе? Государство (налоговая, ЦБ и т.п.) явно нет. На это указывают все действия государственных органов, которые в явном виде (они это не скрывают) хотят управлять и контролировать все безналичные расчеты внутри страны (собственно так же как они контролируют по возможности выпуск и оборот наличной государственной валюты). Примеры (типа ЕБС, НСПК и СБП) надеюсь приводить не нужно.
        Т.е. на уровне государства нужна единая централизованная система безналичных расчетов. Тогда кто "пойдет против" и главное "с какой целью"? :-)
        Это ответ на ваш вопрос? Или что-то не понятно?


        1. Alesh Автор
          00.00.0000 00:00

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

          У меня два варианта, почему вы не нашли эти ответы:)

          1.  Вы прочитали первые два абзаца и сразу перешли к комментариям.

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

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

          Я полагаю, что технических вопросов по статье у вас больше не будет, а политические вопросы я на Хабре не обсуждаю. Всего хорошего.


          1. VVitaly
            00.00.0000 00:00

            :-) У вас есть вопросы о необходимости использования блокчейна с технической стороны для реализации централизованно управляемой транзакционной системы?
            Разве вам (как техническому специалисту по блокчейну и транзакционным системам) нужно объяснять про разницу в потребляемых серверных вычислительных ресурсах между блочейн системой и обычной транзакционной реализации? Или разницу в стоимости поддержки и эксплуатации таких систем?
            Вот и пришли к моему вопросу. Так зачем тут блокчейн? "Стильно, модно, молодежно"? Или потратить больше ресурсов на реализацию и эксплуатацию? Поскольку функционально/технически мы от блокчейна для централизованно управляемой транзакционной системы ничего не выигрываем и не получаем....
            Как то так...


  1. olaf_art
    00.00.0000 00:00

    спасибо, полезно


  1. Woosim
    00.00.0000 00:00

    Идея неплоха. Если появятся результаты по внедрению или MVP, по возможности опубликуйте Часть 2.