Приветствую, Хабр! Моя предыдущая статья была посвящена формализованным критериям выбора базовой технологии хранения и обработки данных, совокупность которых позволяла ответить на вопрос, использовать ли в конкретной системе блокчейн-технологии или ограничиться хорошо изученными СУБД. При этом ответ на данный вопрос при использовании формализованных методов выбора мог быть получен именно на основе технических факторов, не принимая во внимание различные «политические» аспекты выбора, такие как, например, повышенный информационный шум, продолжающийся вокруг блокчейна.

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

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

Введение

Поговорим немного про историю блокчейна. Краткая история спрятана под катом, на случай если читателю эта тема хорошо известна или не интересна.

Одна из достаточно явно прослеживаемых современных тенденций состоит в усилении роли блокчейн-технологий в системах хранения и обработки идентификационных данных граждан. На текущий момент известно уже несколько реализаций на государственном уровне информационных систем, построенных на основе блокчейн-технологий и предназначенных для управления идентификационными данными граждан. В качестве примеров можно привести системы электронных удостоверений личности, развернутые в Бразилии и Эстонии [4, 5].

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

Паспортные данные – частный случай идентификационных данных

Паспортные данные в РФ представляют собой совокупность следующих данных для каждого гражданина [6]:

• фамилия, имя, отчество, пол, дата рождения и место рождения;

• сведения о регистрации гражданина по месту жительства и снятии его с регистрационного учета;

• отметки об отношении к воинской обязанности граждан, достигших 18-летнего возраста;

• отметки о регистрации и расторжении брака (указанные здесь и далее сведения могут отсутствовать в паспорте, поскольку вносятся по желанию его владельца [6]);

• сведения о детях (гражданах Российской Федерации, не достигших 14-летнего возраста);

• отметки о ранее выданных паспортах;

• отметки о выданных действительных основных документах, удостоверяющих личность гражданина Российской Федерации за пределами территории Российской Федерации;

• сведения о группе крови и резус-факторе;

• сведения об идентификационном номере налогоплательщика.

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

Дополнительными атрибутами паспорта являются следующие данные:

• машиночитаемая запись, содержащая основные сведения о владельце паспорта и самом паспорте;

• серия и номер паспорта, наименование и код подразделения, выдавшего паспорт, а также дата выдачи паспорта;

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

Хранение паспортных данных в традиционной базе данных

Рассмотрим паспортные данные с точки зрения их хранения в информационной системе с использованием традиционных БД. Запись всей совокупности паспортных данных может иметь структуру, крайне упрощенный вариант которой показан на рис. 1 (хочу сразу оговориться, что я не являюсь экспертом по базам данных, проектированием БД занимался только на практически любительском уровне, поэтому прошу не судить строго. Структуры БД приведены далее не более чем для иллюстрации).

В приведенном примере информация, представляющая собой паспортные данные каждого гражданина, может храниться в БД в виде записи в основной таблице (назовем ее «Гражданин»), связанной с записями в других таблицах такой БД.

Поскольку практически все поля записи о паспортных данных гражданина могут меняться с течением времени, для идентификации записи необходимо наличие некоего уникального номера (это может быть справедливо и для других таблиц), для чего в таблице присутствует поле «Идентификационный номер», которое может быть использовано для ссылок на запись таблицы из других таблиц и БД связанных информационных систем. В качестве еще одного примера использования идентификационного номера на рисунке выше можно привести связь через данное поле в таблице «Брак» (поле «Идентификационный номер супруга», которое ссылается на поле «Идентификационный номер» записи о супруге в основной таблице). 

Если предположить, что подобная БД является основой некоторой совокупности государственных информационных систем, то можно также предположить, что информация из такой таблицы будет запрашиваться связанными информационными системами достаточно активно. При этом выборка информации может производиться по значениям или диапазонам значений практически всех полей приведенных таблиц: поиск граждан может осуществляться, например, по ФИО или только фамилии, номеру и дате выдачи паспорта (диапазону номеров/дат), подразделению, выдавшему паспорт, дате и месту рождения и т. д. Для ускорения подобных выборок содержимое БД индексируется по всем полям, по которым предполагается поиск, что увеличивает объем хранимых данных, но также значительно увеличивает быстродействие, практически обеспечивая независимость времени поиска от количества записей.

Далее, поскольку разнообразные потребители такой БД (например, различные ведомства РФ) могут иметь различающиеся права на доступ к разным столбцам таблиц, приведенная выше таблица «Гражданин» может быть по факту представлена совокупностью таблиц, связанных через идентификационный номер гражданина, каждая из которых содержит подмножество данных с одинаковыми правилами доступа к ним (см. рис. 2, связи на рисунке не приведены).

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

Хранение паспортных данных в блокчейне

Если поставить целью использование именно блокчейн-технологий для хранения и обработки паспортных данных, то гипотетически стоит рассмотреть, как хранить такие данные непосредственно в блокчейне. Пример подобной структуры приведен на рис. 3.

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

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

• паспортные данные представляют собой конфиденциальную информацию (в РФ паспортные данные относятся к персональным данным, причем совокупность паспортных данных более 100 000 граждан предусматривает их отнесение к одной из максимально защищаемых категорий персональных данных [7]); при их хранении в блокчейне выглядит крайне сложным организовать надлежащее разграничение доступа к ним;

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

• хранение данных в традиционных БД позволяет использовать все их преимущества.

О последней из перечисленных выше причин следует сказать особо. Классические БД позволяют эффективно хранить данные и обеспечивать высокую скорость доступа к ним. Процитируем известную работу [8]: «If your requirements are fulfilled by today’s relational databases, you’d be insane to use a blockchain… Why? Because products like Oracle and MySQL have decades of development behind them. They’ve been deployed on millions of servers running trillions of queries. They contain some of the most thoroughly tested, debugged and optimized code on the planet, processing thousands of transactions per second... And what about blockchains? Well, our product was one of the first to market, and has been available for exactly 5 months, with a few thousand downloads.» («Если ваши требования удовлетворяются современными реляционными базами данных, было бы безумием использовать блокчейн… Почему? Потому что такие продукты, как Oracle и MySQL, имеют за плечами десятилетия разработки. Они были развернуты на миллионах серверов, выполняющих триллионы запросов. Они содержат одни из самых тщательно протестированных, отлаженных и оптимизированных кодов на планете, обрабатывая тысячи транзакций в секунду... А как насчет блокчейнов? Что ж, “наш продукт был одним из первых, вышедших на рынок, и был доступен ровно 5 месяцев, с несколькими тысячами загрузок”.»).

Использование варианта хранения данных, приведенного на рис. 3, является крайне неэффективным с точки зрения поиска требуемых данных. При необходимости выборки требуемых данных при такой «прямой» реализации поиск данных потребуется осуществлять фактически перебором всех записей от более новых к более старым с проходом по всем блокам цепочки и данным всех транзакций каждого блока (при этом нет гарантии, что требуемый для конкретной выборки набор полей найдется в одной транзакции с данными конкретного гражданина – об этом также см. далее). Для ускорения поиска снова потребуется введение индексов, которые не выглядит возможным хранить в блокчейне, – для хранения индексов придется использовать внешнюю по отношению к блокчейну БД.

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

Фиксация записей с помощью блокчейна

Достаточно часто принято противопоставлять друг другу организацию хранения данных в виде блокчейна и в виде БД. Процитируем доклад Академии наук Китая (упоминавшийся мной в предыдущей статье) [9]: «Traditional databases have four classic operations of insert, delete, update, and select... The blockchain technology is equivalent to the databases of giving up deletion and update options, leaving only two manipulation, insertion and selection, through the “block-chain” structure of blocks and linked lists…» («Традиционные базы данных имеют четыре классические операции: вставки, удаления, обновления и выбора... Технология блокчейна эквивалентна базам данных, отказывающимся от возможностей удаления и обновления, оставляя только две манипуляции, вставку и выбор, через структуру цепочки блоков и связанных списков…»).
Тем не менее, ничто не мешает совместному использованию блокчейна и классической БД, например, следующим образом для рассматриваемого применения:

• классическая БД используется для хранения данных;

• записи БД связываются в цепочку с помощью блокчейна: в блокчейне хранятся хеш-коды записей, размещенных в БД.

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

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

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

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

Кроме того, за заполнение различных полей записей отвечают различные ведомства. Вернемся к Постановлению Правительства РФ [6], в котором явным образом перечислено, какие организации отвечают за наполнение паспортных данных:

• Министерство внутренних дел;

• органы регистрационного учета;

• многофункциональные центры предоставления государственных и муниципальных услуг;

• военные комиссариаты;

• органы, осуществляющие государственную регистрацию актов гражданского состояния;

• учреждения здравоохранения;

• налоговые органы.

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

С другой стороны, «append-only» парадигма блокчейн-технологий по отношению к паспортным данным может оказаться единственно верной, поскольку выглядит необходимым не только хранить текущие значения всех полей записей, но также и их предыдущие значения, даты модификации и идентификаторы организаций (должностных лиц), внесших изменения. В частности, поиск и выборка записей могут производиться в случае необходимости и по значениям, актуальным в определенный диапазон прошедших дат.

Другое дело, что даже эту парадигму достаточно эффективно можно организовать с помощью традиционных БД вводом дополнительных полей или дополнительных таблиц, содержащих не только актуальные, но и прошлые значения полей. Это было проиллюстрировано ранее на рис. 1, где приведены дополнительные таблицы (например, «Адрес регистрации»), содержащие совокупность как актуальных, так и бывших актуальными ранее значений вкупе с датами их изменений и прочей дополнительной информацией.

Так нужен ли здесь блокчейн?

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

Применение блокчейна в данном случае не может добавить прозрачности, поскольку все данные хранятся вне блокчейна, доступ к ним ограничен в соответствии, в том числе, с требованиями по защите персональных данных. Следовательно, единственное, что можно проверить с помощью такого блокчейна – факт наличия в БД записи, совокупность полей которой имеет определенное, записанное в блокчейне, хеш-значение, с привязкой ко времени ее добавления или изменения. В приведенной структуре такую проверку может осуществить только обладатель доступа на чтение ко всем полям записи. Есть, правда, альтернативный вариант, подразумевающий хеширование полей по отдельности и последующая фиксация хеш-значением второго уровня – вычисленного от хеш-значений полей. В этом случае по хешу записи можно проверить наличие в ней полей с определенными хеш-значениями (но можно ли это считать «прозрачностью»?). 

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

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

• возможность записи данных в БД различными субъектами системы решается за счет настройки соответствующих прав по доступу к различным сущностям БД;

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

• доступность данных обеспечивается резервированием компонентов системы, включая создание резервных копий БД с репликацией данных в режиме реального времени;

• хранение данных, ставших неактуальными, осуществляется вводом дополнительных связанных таблиц, при этом хранение таких данных никак не увеличивает трудоемкость поиска и выборки данных.

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

А вы как думаете?