В нашем корпоративном блоге мы описали, как решили перейти от биллнговой системы на Excel и разработали собственное решение на базе платформы ServiceNow. Дальнейшее развитие проекта привело к использованию технологии блокчейн, об этом мы решили рассказать читателям Компьютерры.
Зачем блокчейн в биллинге?
Мы используем блокчейн для защиты данных биллинга. Он позволяет вести прозрачный учет без возможности его изменения.
Многие знают как устроены таблицы (справочники) в ServiceNow и других подобных системах, какие у них есть особенности и как они работают. Также известны различные способы защиты этих справочников от несанкционированного доступа. Как и многое в системе, биллинг является тем самым набором подобных справочников.
Один из самых популярных способов защиты подобных списков – это защитить их от пользователя и администратора, используя разделение обязанностей. Это хорошо работает, но имеет большой минус так как требует привлечение дополнительного пользователя с привилегиями администратора. Кроме того, мы не можем гарантировать, что не произойдет какого-либо изменения справочника (в нашем случае – биллинга) этим администратором.
Мы думали об этом некоторое время и параллельно изучали блокчейн. И пришли к выводу, что блокчейн может решить вопрос защиты данных биллинга, без необходимости такого дополнительного ответственного администратора.
Давайте разберемся, что такое блокчейн
Но для начала уточним, что блокчейн – это не биткоин. Биткоин – это система для обмена ценностями на основе технологии блокчейн (одноразовая электронная система наличных денег).
Итак, по данным Википедии:
Блокчейн – выстроенная по определенным правилам непрерывная последовательная цепочка блоков (связный список), содержащих информацию, представляет собой постоянно растущий список записей, называемых блоками, которые связаны и защищены с помощью криптографии. Каждый блок обычно содержит криптографический хеш предыдущего блока, метку времени и данные транзакции. По дизайну блокчейн по своей природе устойчив к изменению данных.
Блокчейн – это способ безопасного хранения данных, так как каждый новый элемент данных полагается на своего предшественника для проверки самого себя.
Теперь давайте посмотрим, как мы будем внедрять блокчейн в биллинг. Во-первых, мы предположим, что мы берем всю запись данных биллинга в нынешнем виде и конвертируем ее в JSON, формат пар «имя – значение», если он еще не в этом формате.
{
«key»: «value»,
«key»: «value»,
«key»: «value»,
«key»: «value»,
«key»: «value»
}
JSON выбран, потому что с ним легче работать и его можно рассматривать как строку полезной нагрузки (payload) для блока в блокчейне.
Далее определимся, какие нужны данные для каждого блока в цепочке.
- **Index** (Индекс) – обозначает положение блока в блочной цепочке. Каждая новая цепочка начинается с Genesis-блока с индексом 0. Обычно он не содержит важной информации и является жестко запрограммированным, тогда как все остальные блоки создаются во время выполнения.
- **Timestamp** (Временная метка) – записывается при создании блока. Это может быть важно, поскольку блокчейн может использоваться для хранения данных временных рядов.
- **Hash** (Хеш) – является хеш-значением всего блока, после того как он прошел через хеширующий алгоритм, обычно это, как и в нашем случае, SHA256.
- **Previous Has** (Предыдущий хеш) – это поле относится к хеш-значению, сохраненному в предыдущем блоке.
- **Nonce** (число, которое может быть использовано один раз) – представляет собой поле, значение которого задано так, чтобы хеш блока содержал последовательность ведущих нулей. Используется для обозначения доказательства работы (сложности алгоритма), подробнее об этом поговорим немного позже.
- **Data/Payload** (Данные / полезная нагрузка) – в нашем случае это запись биллинга в формате JSON, описанная выше.
На приведенной ниже диаграмме проиллюстрировано то, как именно устроена цепь в блокчейне. Если каждый блок зависит от хеш-значения в предыдущем блоке, становится невозможно изменить блок, не изменив каждый последующий.
На следующем рисунке подробнее показана схема, используемая в нашем биллинге.
На схеме видно, что, кроме описанной выше последовательности данных, которые связаны между собой и составляют блокчейн (горизонтальный блокчейн), который используется для обеспечения безопасного биллинга отдельной позиции. Предусмотрен и «вертикальный блокчейн», в который собираются данные по всему биллингу в заданный промежуток времени. Это не только обеспечивает невозможность изменения какой-либо отдельной единицы, но и защищает от непроизвольного добавления или удаления подобных сущностей.
Дерево хешей
Поскольку данных для биллинга с каждым разом становится все больше, для вертикального хеширования используется дерево Меркла.
Хеш-деревом, деревом Меркла (англ. Merkle tree) называют полное двоичное дерево, в листовые вершины которого помещены хеши от блоков данных, а внутренние вершины содержат хеши от сложения значений в дочерних вершинах. Корневой узел дерева содержит хеш от всего набора данных, то есть хеш-дерево является однонаправленной хеш-функцией.
В контексте нашего биллинга листовыми вершинами являются хеши отдельно взятых данных биллинга, которые мы рассматривали ранее. А корневой узел, полученный в результате расчета, вместе в дополнительными данными блока используется для цепочки вертикального блокчейна.
Итак, у нас реализован биллинг, который легко настраивается под практически любой вид деятельности. Каждый его элемент защищен от какого-либо вмешательства, также реализована защита от несанкционированного введения новых или выведения старых данных из биллинга. Для второго уровня защиты необходимо, чтобы актуальные данные собирались и рассчитывались единовременно по всем сущностям. Для этого необходимо настроить расписание. Это может быть любой интервал, все зависит от необходимости периодичности сбора данных.
Так как данных может быть очень много и данный процесс занимает некоторое время, мы предусмотрели еще одну ключевую особенность. Суть ее в том, что при необходимости актуализации конкретных данных на текущий момент времени это можно легко сделать, не нарушив при этом блокчейн и не запуская пересчет всего биллинга для получения нового блока вертикального блокчейна. Эту функциональность мы назвали Lightning Network. Термин придуман не нами, он применяется в криптовалютах.
Lightning Network – это платежный протокол, который оперирует над блокчейнами (обычно используется биткоин). Он позволяет проводить моментальные транзакции между участвующими нодами и предлагается как решение проблемы масштабирования биткоина.
Проще говоря, применение в блокчейне протокола Lightning Network позволяет установить связь между двумя участниками сети и проводить транзакции в обход основного блока, фиксируя при этом транзакции. После закрытия данной сессии конечные суммы попадают в основной блокчейн.
Подобное реализовано и у нас. Между запланированными сборами данных со всего биллинга можно в любой момент получить самые актуальные данные по интересующим объектам. При этом новые записи (блоки горизонтального блокчейна) будут формироваться в ту же единую неразрывную цепочку. А когда придет время очередного запланированного события (расчет хеш-дерева Меркла), будут использоваться всегда последние актуальные данные.
Итоги
Таким образом, мы не просто разработали собственный биллинг на платформе ServiceNow, позволяющий легко и быстро интегрироваться с множеством бизнес-процессов в компании, но и получили абсолютно защищенный инструмент, который теперь можно применить почти для чего угодно. Он разработан таким образом, чтобы в будущем его можно было легко усовершенствовать и без каких-либо препятствий поддерживать в текущем состоянии.
В планах у нас еще много интересных идей, которыми мы обязательно поделимся с вами. А пока можно уверенно сказать, что работа проделана не зря и имеет колоссальный успех.