Министерство науки и высшего образования Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Сибирский государственный автомобильно-дорожный университет
(СибАДИ)»
Институт магистратуры и аспирантуры
Направление 09.04.01 Информатика и вычислительная техника
Магистерская программа «Архитектура предприятия и управление
информационными процессами»
Кафедра «Прикладная информатика»
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к магистерской диссертации
Обозначение магистерской диссертации МД-02068982-09.04.01-09-21
Тема магистерской диссертации: «Автоматизация процесса заключения
биржевых сделок на рынке нефтепродуктов с использованием технологии
блокчейн»
Студент Эрбах Константин Михайлович
Магистерская диссертация допущена к защите в ГЭК
Заведующий кафедрой, канд. экон. наук, доц.
__________ Л.И. Остринская
«___»___________2021 г.
Руководитель магистерской программы
декан фак. ИСУ, зав. каф. ПИ,
канд. экон. наук, доц.
__________ Л.И. Остринская
Руководитель магистерской диссертации
декан фак. ИСУ, зав. каф. ПИ,
канд. экон. наук, доц.
__________ Л.И. Остринская
Нормоконтроль
доц. каф. ПИ, канд. пед. наук
____________ С.Ю. Пестова
Омск 2021
Министерство науки и высшего образования Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Сибирский государственный автомобильно-дорожный университет
(СибАДИ)»
Кафедра «Прикладная информатика»
УТВЕРЖДАЮ
Зав. кафедрой
_____________ Л.И. Остринская
«__»_________ 2020 г
Задание
к магистерской диссертации студента Эрбах Константина Михайловича
1
Тема МД: «Автоматизация процесса заключения биржевых сделок на
рынке нефтепродуктов с использованием технологии блокчейн».
2
Исходные данные к МД: законодательные и нормативные акты, устав
компании, статьи, электронные ресурсы, интернет-источники.
3
Содержание пояснительной записки:
1) Введение
2) Анализ объекта автоматизации и предметной области
3) Задачи предметной области. Формирование и анализ бизнес-процессов
4) Разработка программного решения для предложенной архитектуры
проекта
5) Внедрение программного решения предложенной архитектуры проекта
6) Заключение
7) Список использованной литературы
8) Приложения
4
Перечень демонстрационного материала для сопровождения докладов в
ГЭК
1) Презентация
2) Раздаточный материал к научному докладу
5
Назначенный кафедрой рецензент МД: ведущий бизнес-аналитик
ООО «Диджитал Девелопмент» Яснова Ирина Ивановна
Задание выдано «___» ____________ 2020 г.
Руководитель МД ______________________ / Л.И. Остринская
подпись
Задание к исполнению принял «___» ____________ 2020 г.
Студент _________________ / К.М. Эрбах
(подпись)
2
Аннотация
Пояснительная записка 78 с., 28 рис., 8 табл., 32 источн., 4 прил.
ТОВАРНО-СЫРЬЕВАЯ
БИРЖА,
БИРЖЕВАЯ
СДЕЛКА,
ТЕХНОЛОГИЯ БЛОКЧЕЙН, АВТОМАТИЗАЦИЯ, ИНТЕРФЕЙС.
Результаты данной работы представлены в пояснительной записке. В
ходе работы изучен объект автоматизации, которым является компания ООО
«Петролеум Трейдинг», когда как процессом автоматизации является процесс
заключения сделок на Санкт-Петербургской международной товарносырьевой бирже. Рассмотрены и описаны бизнес-процессы, выполнено
построение
основных
моделей
предметной
области,
спроектирован
интерфейс, предложено и обосновано техническое решение по автоматизации
процесса заключения сделок, разработан модуль заключения сделок,
выполнены работы по автоматизации данного процесса.
Степень внедрения – основные результаты исследования доложены на
IV международной научно-технической конференции в СибАДИ (2019)
«Архитектурно-строительный
и
дорожно-транспортный
комплексы:
проблемы, перспективы, инновации».
COMMODITY
EXCHANGE,
EXCHANGE
TRANSACTION,
BLOCKCHAIN TECHNOLOGY, AUTOMATION, INTERFACE.
The results of this work are presented in the explanatory note. In the course
of the work, the automation object was studied, which is the process of concluding
transactions at the St. Petersburg International Commodity Exchange for the supply
of petroleum products or liquefied hydrocarbon gases. Business processes were
considered and described, the main models of the subject area were built, an
interface was designed, a technical solution was proposed and justified to automate
the process of concluding transactions, and a design solution was implemented.
The degree of implementation - the main results of the study were reported
at the IV international scientific and technical conference in SibADI (2019)
"Architectural and construction and road transport complexes: problems, prospects,
innovations."
3
Список условных обозначений и сокращений
ООО
Общество с ограниченной ответственностью
СУГ
Сжиженные углеводородные газы
СПБМТСБ Санкт-Петербургская международная товарно-сырьевая биржа
ИНН
Индивидуальный налоговый номер
КПП
Код причины постановки на учет
ОГРН
Основной государственный регистрационный номер
БИК
Банковский идентификационный код
ОЗУ
Оперативное запоминающее устройство
ICO
Initial Coin Offering (первичное размещение токенов)
DEX
Decentralized Exchange (децентрализованная биржа)
PoF
Proof-of-Face (доказательство на лицо)
PoS
Proof-of-Stake (доказательство доли)
KYC
Know Your Customer (знай своего клиента)
UI
User Interface (пользовательский интерфейс)
API
Application Programming Interface (программный интерфейс
приложения)
CA
Certificate Authorities (менеджер сертификатов)
CLI
Command Line Interface (интерфейс командной строки)
4
Содержание
Введение ............................................................................................................... 7
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ ......................................................... 9
1.1 Характеристика объекта автоматизации.................................................... 9
1.2 Основные понятия области биржевых сделок ........................................ 12
1.3 Нормативно-правовая база предметной области .................................... 13
1.4 Формализация существующего процесса обработки данных ................ 18
1.5 Модели предметной области .................................................................... 23
1.5.1 Концептуальная модель .................................................................... 23
1.5.2 Функциональная модель ................................................................... 26
1.5.3 Техническая и программная модели ................................................ 28
1.5.4 Технологическая модель ................................................................... 29
1.6 Анализ проблем предметной области ...................................................... 31
2 АНАЛИЗ И ВЫБОР ПРОЕКТНЫХ РЕШЕНИЙ ..................................... 33
2.1 Анализ технологии блокчейн, обоснование внедрения .......................... 33
2.2 Анализ и обоснование выбора вида блокчейн-платформы .................... 35
2.3 Анализ и выбор платформы для проекта ................................................. 36
3 ПРОЕКТИРОВАНИЕ БЛОКЧЕЙН-ПЛАТФОРМЫ............................... 39
3.1 Постановка задачи и требования по проекту .......................................... 39
3.2 Характеристика входной и выходной информации ................................ 42
3.3 Предлагаемая модель процесса обработки данных ................................ 44
3.4 Проектирование базы данных .................................................................. 48
3.5 Проектирование интерфейса .................................................................... 52
3.6 Проектирование топологической модели ................................................ 55
5
3.7 Архитектура сервиса на платформе ......................................................... 59
4 РАЗРАБОТКА МОДУЛЯ ЗАКЛЮЧЕНИЯ СДЕЛОК ............................. 61
4.1 Разработка модуля заключения сделок .................................................... 61
4.2 Описание ролей и прав доступа к платформе ......................................... 63
4.3 Формирование запросов к базе данных ................................................... 66
4.4 Разработка механизмов защиты информации ......................................... 69
Заключение ....................................................................................................... 72
Библиографический список............................................................................ 74
Приложение А Список используемых терминов и определений .............. 79
Приложение Б Бизнес-процесс предметной области (AS-IS) ..................... 82
Приложение В Блокчейн-платформы ........................................................... 83
Приложение Г Архитектура базы данных проектируемой блокчейнплатформы PROLEUM ................................................................................... 84
6
Введение
В настоящее время многие организации переходят на систему
электронного документооборота со своими клиентами с целью упрощения
работы
сотрудников
компании
и
целых
отделов,
занимающихся
сопроводительными документами по деятельности компании, а также
снижения статей расходов на обмен юридическими документами. Не
исключением является компания ООО «Петролеум Трейдинг», занимающаяся
брокерскими услугами и заключением биржевых сделок на СанктПетербургской международной товарно-сырьевой бирже.
При работе с конечными покупателями нефтепродуктов или сжиженных
углеводородных газов компания сталкивалась и продолжает встречаться со
следующими проблемами, такие как: ведение многими покупателями или
поставщиками бумажного документооборота, длительный по времени процесс
подписания договора о поставке нефтепродуктов или СУГ и приложения к
контракту с покупателем (в качестве юридического документа, который
фиксирует факт заключения сделки о поставке нефтепродуктов или СУГ),
нарушение покупателями или поставщиками обязательств перед брокером
(неуплата или несвоевременная уплата по расходам компании, нарушение
условий и сроков поставки нефтепродуктов или СУГ и иные обязательства,
прописанные в договорах и других документах). Прийти к решению проблем,
связанных с документооборотом и невыполнением обязательств по договорам
путем разработки и внедрения блокчейн-платформы.
Актуальность работы состоит в том, что блокчейн, как технология,
является новой и динамично развивающейся. В западных странах она
получает всё большее и большее распространение в различных сферах
жизнедеятельности общества, в том числе при выполнении коммерческих
операций.
Объект автоматизации – компания ООО «Петролеум Трейдинг».
7
Предмет автоматизации – процесс заключения сделок.
Цель работы – автоматизировать процесс заключения сделок и
избавиться от бумажного документооборота, применив технологию блокчейн.
Для достижения заданной цели были поставлены следующие задачи:
1)
Выполнить анализ, дать характеристику задачи предметной
области со стороны деятельности организации.
2)
Проанализировать существующие технологии с целью выбора
проектных решений.
3)
Выполнить
проектирование
блокчейн-платформы
предлагаемого модуля заключения сделок.
4)
Разработать модуль заключения сделок.
8
и
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Характеристика объекта автоматизации
Объектом автоматизации является процесс заключения биржевых
сделок на Санкт-Петербургской международной товарно-сырьевой бирже
(СПбМТСБ)
в
компании
ООО
«Петролеум
Трейдинг»,
сферами
специализации которой согласно уставу организации являются:
–
оптовая торговля топливом;
–
оптовая торговля через агентов (за вознаграждение или на
договорной основе);
–
деятельность автомобильного грузового транспорта;
–
деятельность автомобильного грузового специализированного
транспорта;
–
транспортная обработка грузов и хранение;
–
хранение и складирование;
–
прочая вспомогательная транспортная деятельность;
–
организация перевозок грузов;
–
брокерская деятельность;
–
аренда легковых автомобилей;
–
аренда прочих транспортных средств и оборудования;
–
аренда прочих машин и оборудования;
–
рекламная деятельность;
–
предоставление различных видов услуг;
–
оказание транспортно-экспедиционных и агентских услуг по
организации внутрироссийских и международных перевозок грузов всеми
видами транспорта для предприятий, организаций и граждан;
–
осуществление грузовых перевозок привлеченным транспортом, в
том числе железнодорожным, автомобильным, морским и авиационным;
9
–
услуги по погрузке, разгрузке, креплению, сепарированию грузов
в соответствии с требованиями различных видов перевозок, а также
разработка схем и проведение расчетов по погрузке и креплению грузов;
–
услуги по логистике, а также информационные услуги, включая
консультирование по грузовым и иным перевозкам;
–
иная
деятельность,
не
запрещенная
действующим
законодательством Российской Федерации [33].
В компании существует несколько отделов, которые так или иначе
принимают участие в заключении и сопровождении сделок на всех её этапах.
На рисунке 1 представлена организационная структура компании:
–
отдел продаж и отдел тендерных продаж – данные отделы
непосредственный закуп нефтепродуктов или сжиженных углеводородных
газов на Санкт-Петербургской международной товарно-сырьевой бирже,
производят
аналитику
товарно-сырьевой
биржи,
выбирают
лучшие
предложения и покупают самый дешёвый нефтепродукт или сжиженный
углеводородный газ для осуществления поставки покупателю, а также
подготавливают предварительный перечень документов для заключения
сделок;
–
отдел
нефтепродуктов
логистики
или
–
отвечает
сжиженных
за
осуществление
углеводородных
газов
поставки
со
станции
отправления от поставщика до станции назначения к покупателю, отправляют
претензии покупателям или поставщикам, а также рекламации покупателям
или поставщикам в случаях нарушения сроков загрузки / отгрузки
нефтепродуктов или сжиженных углеводородных газов на станциях
отправления / назначения;
–
отдел бухгалтерии – данный отдел отвечает за отслеживание
движений денежных средств (оплата поставщикам за нефтепродукт или
сжиженный углеводородный газ и получение оплаты от покупателя);
10
11
Рисунок 1 – Организационная структура компании
–
отдел сопровождения сделок и операционного сопровождения
сделок – отвечают за документацию по нестандартным условиям поставки
покупателям
и
согласуют
её
для
отдела
продаж,
контролируют
документооборот в компании с покупателями и поставщиками, оперативно
реагируют на различные спорные и иные ситуации, связанные с поставкой
нефтепродуктов или СУГ в части документации, вносят скан-копии
документов в систему 1С:Документооборот;
–
претензионно-договорной отдел – данный отдел занимается
возникшими спорными ситуациями, связанными с нарушениями условий
действующего контракта между компанией и контрагентом (покупателем или
поставщиком) и/или нарушений условий сделки;
–
отдел финансового планирования – данный отдел отвечает за
планирование бюджета компании на следующие временные периоды,
планируемые доходы и расходы;
–
отдел рисков – данный отдел производит оценку контрагентов на
финансовую составляющую (включая их кредито- и платежеспособность).
1.2 Основные понятия области биржевых сделок
Основными
Трейдинг»
на
видами
деятельности
СПбМТСБ
являются:
компании
стандартные
ООО
«Петролеум
биржевые
сделки
приобретения нефтепродуктов или СУГ (приносят более половины доходов
компании), оказание брокерских услуг от своего имени или от имени клиента
на международной товарно-сырьевой бирже, заключение спекулятивных и
фьючерсных сделок.
Биржевая
сделка
–
стандартная
сделка,
которая
заключается
участниками биржевой торговли в отношении биржевого товара в ходе
биржевых торгов, а порядок регистрации и оформления биржевых сделок
устанавливается биржей [13, с. 156].
Спекулятивные сделки – такие сделки купли-продажи, которые
осуществляются в рамках биржи (ситуация на бирже, когда брокер по одной
12
цене приобретает товар, который остается у поставщика, а в будущем уже
самостоятельно перепродает этот товар на бирже по более выгодной и
высокой цене, нежели цена покупки) [19, с. 92].
Фьючерсные сделки – такие сделки купли-продажи, при заключении
которой стороны (в нашем случае, поставщик как продавец и компания как
покупатель) договариваются только об уровне цены и сроке поставки товара,
когда как другие параметры товара (количество, качество, маркировка и т.п.)
оговорены заранее в спецификации биржевого контракта и являются
стандартными для данной торговой площадки (устанавливаются правилами
торговой площадки), при этом стороны несут обязательство перед биржей
вплоть до исполнения фьючерсной сделки [22, с. 229].
Прежде чем перейти к вопросу об автоматизации заключения сделок
обратимся к нормативно-правовой базе с целью анализа возможности и
законности применения технологии блокчейн.
1.3 Нормативно-правовая база предметной области
Для решения вопроса по реализации блокчейн-платформы на товарносырьевой бирже на территории Российской Федерации с целью покупки
нефтегазопродуктов и сжиженных углеводородов необходимо обратиться к
российскому законодательству с целью его анализа на предмет легальности
использования блокчейн-платформы как таковой, а также криптовалют для
осуществления
расчётов
между
участниками
блокчейн-платформы
и
электронных подписей для формирования документов о заключении сделки,
имеющих такую же юридическую силу, что и их бумажные носители.
Вышеупомянутые специфические аспекты взаимодействия на блокчейнплатформе в российском законодательстве рассматривают и регулируют
следующие федеральный законы Российской Федерации:
1)
Федеральный закон №149-ФЗ от 27.07.2006 «Об информации,
информационных технологиях и о защите информации»;
13
2)
Федеральный закон №63-ФЗ от 06.04.2011 «Об электронной
подписи»;
3)
Федеральный закон №402-ФЗ от 06.12.2011 «О бухгалтерском
учете»;
4)
Федеральный закон №259-ФЗ от 31.07.2020 «О цифровых
финансовых активах, цифровой валюте и о внесении изменений в отдельные
законодательные акты Российской Федерации».
Федеральный закон №149-ФЗ от 27.07.2006 «Об информации,
информационных
технологиях
и
о
защите
информации»
является
основополагающим законом в области информационных технологий и
информации – он регулирует не только защиту информации, но и отношения,
возникающие
при
осуществлении
её
поиска,
получения,
передачи,
производства и распространения, а также устанавливает определение
электронного
документа,
как
документированную
информацию,
представленную в электронной форме, то есть в виде, пригодном для
восприятия человеком с использованием электронных вычислительных
машин, а также для передачи по информационно-телекоммуникационным
сетям или обработки в информационных системах» (данное определение
введено федеральным законом №227-ФЗ от 27.07.2010 «О внесении
изменений в отдельные законодательные акты Российской Федерации в связи
с принятием Федерального закона «Об организации предоставления
государственных и муниципальных услуг») [6].
Федеральный закон №63-ФЗ от 06.04.2011 «Об электронной подписи»
устанавливает следующие определения основных понятий, связанных с
электронным документооборотом, а именно:
1)
электронная подпись – информация в электронной форме, которая
присоединена к другой информации в электронной форме (подписываемой
информации) или иным образом связана с такой информацией и которая
используется для определения лица, подписывающего информацию;
14
2)
ключ электронной подписи – уникальная последовательность
символов, предназначенная для создания электронной подписи;
3)
ключ
проверки
электронной
подписи
–
уникальная
последовательность символов, однозначно связанная с ключом электронной
подписи и предназначенная для проверки подлинности электронной подписи.
Также в данном законе подробно расписаны и обозначены виды
электронных
подписей,
такие
как:
усиленная
неквалифицированная
электронная подпись (иными словами, неквалифицированная электронная
подпись)
и
усиленная
квалифицированная
электронная
подпись
(квалифицированная электронная подпись).
Согласно действующего федерального закона, неквалифицированной
электронной подписью является электронная подпись, которая:
1)
получена в результате криптографического преобразования
информации с использованием ключа электронной подписи;
2)
позволяет определить лицо, подписавшее электронный документ;
3)
позволяет обнаружить факт внесения изменений в электронный
документ после момента его подписания;
4)
создается с использованием средств электронной подписи.
Когда как квалифицированной электронной подписью является
электронная
подпись,
которая
соответствует
всем
признакам
неквалифицированной электронной подписи и следующим дополнительным
признакам:
1)
ключ
проверки
электронной
подписи
указан
в
квалифицированном сертификате;
2)
для создания и проверки электронной подписи используются
средства электронной подписи, имеющие подтверждение соответствия
требованиям,
установленным
в
соответствии
с
вышеупомянутым
Федеральным законом.
Информация в электронной форме, подписанная квалифицированной
электронной подписью, признается электронным документом, равнозначным
15
документу
на
бумажном
носителе,
подписанному
собственноручной
подписью, и может применяться в любых правоотношениях в соответствии с
законодательством Российской Федерации, кроме случая, если федеральными
законами или принимаемыми в соответствии с ними нормативными
правовыми актами установлено требование о необходимости составления
документа исключительно на бумажном носителе.
Также законом №63-ФЗ устанавливается признание иностранной
электронной подписи, которая соответствует не только законам того
иностранного государства, где была сделана данная подпись, но и
международным нормативно-правовым актам и российским законам [8].
Федеральный закон №402-ФЗ от 06.12.2011 «О бухгалтерском учете»
говорит о том, что первичный учетный документ составляется на бумажном
носителе и (или) в виде электронного документа, подписанного электронной
подписью, то есть данным отдельным законом разрешается ведение
бухгалтерских документов с применением электронных подписей и
технологий электронного документооборота [1].
Долгое время на территории Российской Федерации было запрещено
использование криптовалюты как таковой в виде денежных средств и
совершение с ними соответствующих операций [10, с. 40]. Только в 2020 году
был подписан и обнародован федеральный закон №259-ФЗ от 31.07.2020 «О
цифровых финансовых активах, цифровой валюте и о внесении изменений в
отдельные
законодательные
акты
Российской
Федерации»,
который
официально разрешил и легализовал криптовалюту как платежное средство.
Помимо
этого,
нормативно-правовой
акт
регулирует
отношения,
возникающие при выпуске, учете и обращении цифровых финансовых
активов, при обороте цифровой валюты на территории России [5].
Согласно
признаются
новому
цифровые
закону
цифровыми
права,
включающие
финансовыми
денежные
активами
требования,
возможность осуществления прав по эмиссионным ценным бумагам, права
участия в капитале непубличного акционерного общества, право требовать
16
передачи эмиссионных ценных бумаг, которые предусмотрены решением о
выпуске цифровых финансовых активов в порядке, установленном настоящим
Федеральным законом, выпуск, учет и обращение которых возможны только
путем внесения (изменения) записей в информационную систему на основе
распределенного реестра, а также в иные информационные системы.
Вышеупомянутым нормативно-правовым актом цифровой валютой
признается совокупность электронных данных (цифрового кода или
обозначения),
содержащихся
в
информационной
системе,
которые
предлагаются и (или) могут быть приняты в качестве средства платежа, не
являющегося денежной единицей Российской Федерации, денежной единицей
иностранного государства и (или) международной денежной или расчетной
единицей, и (или) в качестве инвестиций и в отношении которых отсутствует
лицо, обязанное перед каждым обладателем таких электронных данных, за
исключением оператора и (или) узлов информационной системы, обязанных
только обеспечивать соответствие порядка выпуска этих электронных данных
и осуществления в их отношении действий по внесению (изменению) записей
в такую информационную систему ее правилам. Выпуск, учет и обращение
эмиссионных ценных бумаг, возможность осуществления прав по которым
удостоверяется
цифровыми
финансовыми
активами,
регулируются
Федеральным законом от 22 апреля 1996 года № 39-ФЗ «О рынке ценных
бумаг» с учетом тех особенностей, которые предусмотрены федеральным
законом о цифровой валюте.
Суммируя всё вышесказанное, приходим к выводу о том, что с 1 января
2021 года (когда федеральный закон №259-ФЗ от 31.07.2020 «О цифровых
финансовых активах, цифровой валюте и о внесении изменений в отдельные
законодательные акты Российской Федерации» вступает в силу) в Российской
Федерации официально разрешено использование криптовалюты в качестве
платежного средства и её выпуск, что позволяет в полной мере реализовать
блокчейн-платформу на базе товарно-сырьевой биржи [12, с. 15]. Помимо
этого, все документы, заключенные на блокчейн-платформе и подписанные
17
всеми сторонами сделки с помощью электронных подписей, имеют
юридическую силу [23, с. 47].
Применяемая терминология в области блокчейн представлена в
приложении А.
1.4 Формализация существующего процесса обработки данных
Основной целью компании ООО «Петролеум Трейдинг», как брокера на
рынке нефтепродуктов и СУГ, является заключение биржевых сделок с целью
получения прибыли. Несмотря на возможное отсутствие покупателя,
трейдеры ежедневно заключают десятки сделок на товарно-сырьевой бирже.
Часть нефтепродуктов или СУГ приобретаются по фьючерсным контрактам,
чтобы в дальнейшем быть отправленными потенциальному покупателю,
другие – для совершения спекулятивных сделок, третьи – для текущей
поставки нефтепродуктов или СУГ покупателям.
На рисунке 2 представлена схема процесса взаимодействия брокера с
СПбМТСБ.
Ежедневно (в рабочие дни товарно-сырьевой биржи: с понедельника по
пятницу) трейдеры проводят анализ котировок на бирже и мониторят
ситуацию во время проведения торгов с целью поиска и выбора наилучшего и
наиболее выгодного ценового предложения для компании. При этом
необязательно наличие покупателя на нефтепродукты или СУГ – трейдеры
приобретают нефтепродукты или СУГ на бирже с целью получения выгоды и
прибыли, которая может быть получена не только в ситуациях с заключением
классических биржевых сделок, но и фьючерсных и спекулятивных сделок,
которые могут принести значительный единовременный доход компании.
После осуществления покупки нефтепродуктов или СУГ заключаются и
подписываются биржевые документы между брокером и поставщиком,
которые подтверждают факт совершенной сделки и передают право
собственности от поставщика брокеру.
18
Рисунок 2 – Схема процесса взаимодействия брокера с СПбМТСБ
Одним из главных процессов в компании, схема которого представлена
на рисунке 3, является заключение биржевых сделок с контрагентами
(покупателями) на поставку нефтепродуктов или СУГ.
Покупателем может выступать юридическое лицо или индивидуальный
предприниматель, заинтересованные в приобретении нефтепродуктов или
СУГ, когда как брокером является компания ООО «Петролеум Трейдинг».
Есть два развития событий при заключении сделки с контрагентом.
1)
Если у контрагента ранее был заключен с поставщиком
(компанией) договор на поставку нефтепродуктов или СУГ и он является
действующим на момент заключения сделки, тогда с контрагентом
подписывается приложение к контракту с покупателем на поставку
нефтепродуктов или СУГ.
19
Рисунок 3 – Схема процесса взаимодействия покупателя и брокера
2)
Если у контрагента нет заключенного с компанией договора на
поставку нефтепродуктов или СУГ или он не является действующим на
момент заключения сделки, тогда с контрагентом заключается новый договор.
Данная процедура состоит из подписания стандартного договора (текст
договора с его условиями, включая условия поставки, разработан компанией)
или подписания нестандартного договора (текст договора, к которому
добавлены определенные условия, связанные со спецификой работы
контрагента и компании). После подписания договора происходит подписание
приложения к контракту с покупателем на поставку нефтепродуктов или СУГ.
После подписания приложения к контракту с покупателем компания
осуществляет процесс поставки нефтепродуктов или СУГ – она (компания)
производит покупку сырья у поставщика, отгрузку и доставку до пункта
назначения, обозначенного в приложении к контракту с покупателем.
20
После поставки нефтепродуктов или СУГ (когда покупатель получает
нефтепродукты или СУГ и юридически становится его владельцем) могут
возникнуть обоюдные претензии по осуществлению сделки. Например,
период простоя ж/д вагонов (если поставка нефтепродуктов или СУГ
осуществлялась железнодорожным транспортом) – все расходы за простой,
фактически, несёт компания (поскольку именно она обратилась и заказала
услугу поставки нефтепродуктов или СУГ от станции поставщика к станции
покупателя), и в то же самое время они включены в стоимость сделки. Другим
примером может послужить качество поставленного нефтепродукта или СУГ
и/или его количество – также ответственность перед покупателем несёт
компания, которая, в свою очередь, предъявляет претензии к поставщику
нефтепродуктов или СУГ. И таких ситуаций может быть много: срыв сроков
поставки, срыв поставки как таковой и тому подобное.
Рассмотрим возникающие в процессе работы компании проблемы:
1)
Оплата. Одним из важных и главных вопросов является оплата за
нефтепродукты или СУГ. В данном случае риски несут как покупатель, так и
компания. При предоплате (оплата за нефтепродукты или СУГ при
заключении сделки и подписании договора) наибольшие риски несет
покупатель – он может получить некачественный нефтепродукт или СУГ или
в меньшем
объеме.
При фактической оплате
(в момент отгрузки
нефтепродуктов или СУГ, к примеру, на станции покупателя) наибольшие
риски несет компания – она может не получить оплату или получить сумму,
меньше оговоренной в подписанном договоре. Чаще всего, как показывает
российская практика, данные вопросы решаются в судебном порядке (сами
судебные процессы могут затянуться на долгие месяцы или даже годы). В
данной ситуации технология блокчейн (в идеальном варианте реализации и
работы; схема процесса представлена на рисунке 3) снизила бы риски,
описанные выше, и поступила бы следующим образом: в момент заключения
сделки и подписания договора со счета покупателя списалась бы
21
криптовалюта в определенном объеме, и в это же время произошла бы
отгрузка нефтепродуктов или СУГ покупателю.
Доставка договора. Процедура подписания договора с обоих
2)
сторон
выглядит
следующим
образом.
После
обсуждения
всех
дополнительных условий к договору и формирования итоговой его редакции,
с каждой из сторон происходит подписание данного договора и отправка
подписанного экземпляра (с подписью и печатью) другой стороне – у каждой
из сторон должен быть оригинал подписанного документа, который имеет
юридическую силу. Чаще всего, компании прибегают к услугам курьерских
служб для быстрой доставки корреспонденции. Однако могут возникнуть
форс-мажорные ситуации, при которых сроки доставки документов были бы
увеличены.
При
законодательство,
этом,
как
компании
требует
должны
того
российское
предоставлять
налоговое
подтверждающие
документы в отчетные периоды (квартал / год). Поэтому, если документы не
попали в данный отчетный период, то они должны быть в следующем, при
этом обязательно должен быть предоставлен конверт «Почты России» с
печатью (о дате отправки и дате доставки). Данная процедура также
упрощается при применении технологии блокчейн – при заключении и
подписании договора ставятся электронные подписи и печати сторон, при
этом каждый из экземпляров хранится у сторон.
3)
Уникальные условия заключаемого договора. При заключении
договора о поставке нефтепродуктов или СУГ стороны предварительно
обсуждают дополнительные условия (отражающие специфику покупателя или
брокера), после чего происходит подписание или отказ от заключения сделки.
В условиях меняющихся цен на товарно-сырьевой бирже, вопрос о
заключении договора и обсуждении дополнительных условий к нему может
затянуться на несколько дней, недель или месяцев, что может привести к
убыткам со стороны брокера или к увеличению цены для покупателя. В
данном случае, при применении технологии блокчейн может быть реализован
искусственный интеллект и применение smart-контракта, который упростит и
22
ускорить процедуру составления индивидуальных условий и подписания
договора.
1.5 Модели предметной области
1.5.1 Концептуальная модель
На основании ранее представленных данных о процессе заключения
сделок на товарно-сырьевой бирже была составлена концептуальная модель,
представленная на рисунке 4.
Рисунок 4 – Концептуальная модель системы
На входе получаем следующие данные:
1)
заявка от покупателя на определенный нефтепродукт или СУГ (его
наименование и количество) и сведения для заключения контрактов
(покупателя или поставщика), такие как:
23
–
полное наименование контрагента (согласно Устава организации
или иного документа, на основании которого действует организация);
–
руководитель организации (должность, фамилия, имя и отчество
руководителя или иного ответственного лица контрагента; если указано
ответственное лицо контрагента – номер и дата доверенности или иного
документа, на основании которого данное лицо действует от имени
организации);
–
регион базирования контрагента (его местонахождение для
определения ближайших ж/д станций);
–
юридический адрес и адрес для корреспонденции;
–
ИНН, КПП, ОГРН;
–
расчетный счет контрагента и наименование банка, где находится
данный расчетный счет (с указанием БИК и корреспондентского счёта);
–
телефон контрагента или руководителя, или ответственного лица;
–
адрес электронной почты контрагента или руководителя, или
ответственного лица;
–
наличие или отсутствие кредитного лимита для покупателя и его
размер.
2)
нормативно-правовые акты, то есть законы, в рамках которых
происходят все операции на СПбМТСБ, а именно:
–
№135-ФЗ от 26.07.2006 «О защите конкуренции» [3];
–
№325-ФЗ от 21.11.2011 «Об организованных торгах» [7];
–
№224-ФЗ от 27.07.2010 «О противодействии неправомерному
использованию инсайдерской информации и манипулированию рынком и о
внесении изменений в отдельные законодательные акты Российской
Федерации» [4];
–
№129-ФЗ
от
08.08.2001
«О
государственной
регистрации
юридических лиц и индивидуальных предпринимателей», а также иные
документы, регулирующие операции на бирже [2].
24
3)
в качестве пользователей выступают сотрудники следующих
отделов:
–
отдел продаж;
–
отдел тендерных продаж;
–
отдел операционного сопровождения сделок;
–
отдел сопровождения сделок;
–
отдел логистики.
4)
выходными данными будут:
–
контракты (с покупателем и/или поставщиком), которые будут
отражать основные принципы и условия взаимодействия между брокером и
контрагентом (включая предоставление кредитного лимита и установленный
его размер);
–
приложение к контракту покупателя, в котором перечислены все
условия проведения сделки, а именно:
а)
полная сумма сделки с учетом всех расходов на нефтепродукт или
СУГ, его доставку и иные расходы, предусмотренные контрактами брокера
(как с покупателем, так и с поставщиком);
б)
стоимость ж/д тарифа за тонну нефтепродукта или СУГ и полная
сумма ж/д тарифа по сделке;
в)
условие поставки нефтепродукта или СУГ (с упоминанием
момента, в какой момент происходит передача прав собственности от брокера
к покупателю на нефтепродукт или СУГ);
г)
форма оплаты (факт / предоплата);
д)
станция
назначения
(покупателя)
и
станция
отправления
(поставщика);
е)
отсрочка по оплате за нефтепродукт или СУГ (в днях, если таковая
имеется);
ж)
наличие таможни при транспортировке нефтепродуктов или СУГ
от станции отправления к станции назначения (с указанием юридического
лица, кто будет нести таможенные расходы по товару);
25
–
комплект биржевых документов, который включает следующие
документы [31, 32]:
а)
генеральное соглашение между брокером и поставщиком (если
ранее не было заключено);
б)
дополнительное соглашение к Генеральному соглашению;
в)
договор поставки (если это необходимо);
г)
договор купли-продажи товара с передачей прав собственности.
Перечень документов, получаемых на выходе при заключении биржевой
сделки между покупателем и поставщиком при посредничестве брокера и
непосредственно участвующих в бизнес-процессе, представлен в таблице 1.
Таблица 1 – Перечень документов, участвующих в бизнес-процессе
Выходной документ
Контракты
Наименование документа
Контракт с покупателем
Тип документа
Бумажный / электронный
документ
Контракт с поставщиком
Бумажный / электронный
документ
Приложение
с Приложение к контракту с Бумажный / электронный
покупателем
покупателем
документ
Комплект документов Генеральное соглашение
Бумажный / электронный
биржи
документ
Дополнительное соглашение к Бумажный / электронный
Генеральному соглашению
документ
Договор поставки
Бумажный / электронный
документ
Договор купли-продажи
Бумажный / электронный
документ
1.5.2 Функциональная модель
На рисунке 5 представлен бизнес-процесс (AS-IS) предметной области
(бизнес-процесс AS-IS с раскрытием процессов подписания документов
представлен в приложении Б), который более подробно раскрывает
информационную модель и отображает процессы заключения договоров
между сторонами сделки (между покупателем и брокером, между брокером и
поставщиком), а также заключения и подписания приложения к контракту с
покупателем.
26
27
Рисунок 5 – Бизнес-процесс предметной области (AS-IS)
Процесс заключения договора (или подписания приложения к контракту
с покупателем о заключении сделки) состоит в следующем: покупателю или
поставщику предлагается для подписания стандартная форма договора,
разработанная юристами компании ООО «Петролеум Трейдинг». В случаях,
когда у покупателя или поставщика есть уникальные условия взаимодействия
с компанией-брокером, тогда происходит процедура согласования новой,
уникальной для данного покупателя или поставщика формы договора, которая
в дальнейшем будет подписана (или не подписана, если данные пункты будут
противоречить политике компании ООО «Петролеум Трейдинг»). Если же
уникальных условий нет, тогда подписывается стандартная форма договора.
При осуществлении покупки нефтепродуктов или СУГ на бирже
оформляется пакет документов, содержащий:
1)
генеральное соглашение между брокером и поставщиком (если
ранее не было заключено);
2)
дополнительное соглашение к Генеральному соглашению;
3)
договор поставки (если это необходимо);
4)
договор купли-продажи товара с передачей прав собственности.
Представленная на рисунке 5 и в приложении Б модель не отображает
факта
осуществления
документооборота
между
компаниями
–
подразумевается, что весь документооборот осуществляется через курьерские
службы или Почтой России (в последнем случае – тогда и только тогда, когда
необходимо получение конверта с датой отправки и доставки в место
назначения для отчетности перед Федеральной налоговой службой или
аудиторами).
1.5.3 Техническая и программная модели
Техническая модель, представленная в таблице 2, была составлена на
основании ключевых отделов компании ООО «Петролеум Трейдинг»,
задействованных в биржевых сделках.
28
Таблица 2 – Техническая модель
Компьютерная
техника
Персональный
компьютер
Монитор
МФУ
Сервер
3)
Технические характеристики
Операционная система: Windows 10 Professional
Видеокарта: AMD Radeon Vega 8
Процессор: Ryzen 3 PRO 3200G
Оперативная память (ОЗУ): 8GB
Привод: DVD-RW
Режим экрана: 1366x768 (16:9)
Модель: HP V214a
Модель: HP LaserJet Enterprise M725dn
Операционная система: Microsoft SQL 2016
Количество
единиц
техники
41
82
8
1
1С:Документооборот – система, в которой хранятся скан-копии
подписанных договоров с покупателем или поставщиком, а также приложения
к контракту с покупателями, и осуществляется учет и анализ имеющихся
юридических документов;
4)
корпоративный антивирус Kaspersky – программный продукт,
отвечающий за безопасность данных компании;
5)
операционная система Windows 10 Professional;
6)
Power BI – построение аналитической отчетности по сделкам, по
эффективности работы трейдеров (по доходностям их сделок) и иные отчеты,
предоставляющие картину в разрезе определенных данных и параметров;
7)
Business Studio – для создания и редактирования бизнес-процессов
компании (для выявления узких мест специалистами отделов и их
автоматизации).
1.5.4 Технологическая модель
На рисунке 6 представлена технологическая модель предметной
области, кратко иллюстрирующая процесс заключения сделки и поставки
нефтепродуктов и СУГ.
29
Рисунок 6 – Технологическая модель предметной области
Запрос на поставку нефтепродуктов или СУГ от покупателя получает
трейдер из отдела продаж (через телефонный звонок или по электронной
почте) или из отдела тендерных закупок (по результатам проведения тендера).
Трейдер же осуществляет закуп нефтепродуктов или СУГ на СПбМТСБ,
заключая простой договор купли-продажи по форме, установленной биржей.
В случаях необходимости и заинтересованности сторон, между брокером и
поставщиком заключается долгосрочный договор поставки. Документальное
сопровождение сделок после предварительного заключения контракта между
брокером и покупателем переходит отделам сопровождения сделок и
операционного сопровождения сделок. Также они осуществляют полный
контроль всех этапов сделки: подписания соответствующих документов и
получение их оригиналов (с дальнейшим занесением скан-копий в систему
1С:Документооборот), отслеживание соблюдения всех пунктов договоров,
заключенных как с поставщиком, так и с покупателем, включая сроки отгрузки
/ разгрузки нефтепродуктов или СУГ, сроков поставки нефтепродуктов или
СУГ (совместно с отделом логистики в рамках поставки нефтепродуктов или
СУГ от станции отправления поставщика до станции назначения покупателя),
сроков и размеров оплаты от покупателя (включая расходы за сам
30
нефтепродукт или СУГ, транспортные расходы, агентское вознаграждение
брокера и иные расходы по сделке) и поставщику от брокера.
Сделка считается закрытой тогда, когда каждая из сторон получила все
оригиналы документов, были произведены все выплаты по всем понесенным
расходам и каждая из сторон не имеет никаких претензий по проведенной
сделке (ни к нефтепродуктам или СУГ, ни к качеству оказания услуг).
1.6 Анализ проблем предметной области
При заключении сделок в компании периодически возникает ряд
проблем, связанных с поставкой юридических документов курьерскими
службами (всегда есть риск потери данных документов). Кроме того, если с
покупателем или поставщиком планируется подписание договора (или
приложения к контракту с покупателем), в котором будут уникальные для
данных сторон условия, то согласование текста договора (или приложения к
контракту с покупателем) может также существенно затянуть процесс
подписания контракта и в дальнейшем сделки на поставку нефтепродуктов
или СУГ. Также очень часто возникают споры с покупателями и
поставщиками по оплате за нефтепродукт или СУГ и иные расходы,
понесенные во время проведения сделки не по вине брокера – в таких случаях,
чаще всего, решение вопроса возможно только в судебном порядке, что только
откладывает получение денежных средств и приносит хоть и несущественный,
но финансовый урон. Помимо этого, возникают спорные моменты, связанные
с поставкой самого нефтепродукта или СУГ и его качества – данные вопросы
тоже решаются в судебном порядке.
Выявленные «узкие места» представлены в таблице 3 и основаны на
бизнес-процессе AS-IS, отображенным в приложении Б, они в своей
перспективе могут привести к большим финансовым потерям со стороны
брокера, а также к потере репутации и контрагентов (как поставщиков, так и
покупателей).
31
Таблица 3 – Перечень «узких мест» предметной области и возможных
рисков
Проблема предметной области
Риски
Преимущественно
бумажный 1) потеря документов в процессе доставки
документооборот
курьерской службой или «Почтой России»;
2) необходимость отправлять документы
конвертом «Почтой России», если важные
финансово-отчетные документы попали
после
завершения
бухгалтерского
отчетного периода;
3)
денежные
траты
на
отправку
документов;
4) без подписанных обеими сторонами
юридических документов о заключении
сделки невозможно быстрое совершение
поставки нефтепродуктов или СУГ, что, в
конечном итоге, может привести к
увеличению цены на приобретаемый
биржевой товар и к расходам (со стороны
брокера или конечного покупателя).
Уникальные
условия
поставки долгий процесс переговоров (в виде
нефтепродуктов или СУГ
переписки и/или телефонных разговоров),
прежде чем обеими сторонами сделки
будет утверждена форма контракта (или
приложения к контракту с покупателем).
Оплата за поставленные нефтепродукты 1)
нарушение
сроков
оплаты
за
или СУГ и нарушение иных обязательств поставленные нефтепродукты или СУГ (в
сторонами
данном случае брокер может решить
проблему с оплатой путем достижения
соглашения с задолжником или в судебном
порядке);
2)
нарушение
сроков
поставки
нефтепродуктов или СУГ.
32
2 АНАЛИЗ И ВЫБОР ПРОЕКТНЫХ РЕШЕНИЙ
2.1 Анализ технологии блокчейн, обоснование внедрения
Для решения и ликвидации «узких мест» в процессе заключения
биржевых сделок и осуществления поставки нефтепродуктов и СУГ
обратимся к анализу современной и молодой технологии блокчейн, которая в
последнее время только набирает популярность в различных сферах
жизнедеятельности человека и общества в целом [15, с. 56].
Технология блокчейн имеет ряд преимуществ:
1)
высокая прозрачность совершаемых сделок на платформе за счёт
открытости баз данных;
2)
децентрализованная система базы данных, что с большей долей
вероятности исключает возможность взлома системы, потому что для
намеренного изменения данных нужно изменить их у каждого участника
платформы;
3)
существует возможность создания и использования внутренней
валюты для совершения сделок на платформе;
4)
технология smart-контракта, которая позволяет формировать
между сторонами сделки документы, имеющие юридическую силу [26, с. 38].
На рисунке 7 представлен перечень вопросов, ответы на которые
позволят определиться с решением поставленной задачи – поможет ли
технология блокчейн осуществить оптимизацию заключения биржевых
сделок на товарно-сырьевой бирже и избавиться от узких мест процесса AS-IS
[17].
«Нужно ли избавиться от посредников?» – да, в данном случае
необходимо избавиться от брокера, как от посредника между поставщиком и
конечным покупателем, поскольку наличие брокера в цепочке поставки
нефтепродуктов и СУГ увеличивает стоимость биржевого товара.
33
34
Рисунок 7 – Последовательность вопросов для определения необходимости внедрения блокчейна
«Работа с цифровыми активами?» – да, цифровые активы позволят
избежать проблемы просрочки оплаты за поставку нефтепродуктов и СУГ.
«Ведется ли учет этого цифрового актива?» – да, учет будет вестись с
той целью, чтобы отслеживать, у кого из участников цепи находится
большинство актива
«Нужна ли высокая скорость транзакции?» – нет, высокая скорость
транзакции не нужна.
«Решает ли проблему хранение нетранзакционных данных?» – нет, это
не решит всех перечисленных проблем, выявленных в текущем бизнеспроцессе компании.
«Нужен ли контроль трех сторон?» – нет, контроль не нужен; он будет
осуществляться программными алгоритмами и технологией smart-контракта.
«Работа происходит с договорами или с обменом валюты?» – да, работа
происходит с договорами, которые регулируют отношения между брокером и
покупателем, брокером и поставщиком (в рамках биржи и за её пределами).
«Необходим ли общий доступ для записи?» – да, каждый из участников
блокчейн-платформы должен иметь право на внесение транзакционной
записи.
«Доверяют ли контрагенты друг другу?» – нет, на российском рынке
сложилась культура недоверия между сторонами сделок.
«Нужно ли влиять на правила участия в блокчейне?» – да, не каждый
поставщик или покупатель может стать участником блокчейн-платформы.
Ответив на все вопросы, приходим к выводу, что внедрение в ООО
«Петролеум Трейдинг» блокчейн-платформы для достижения поставленных
целей будет целесообразным.
2.2 Анализ и обоснование выбора вида блокчейн-платформы
Существует несколько классификаций блокчейн-платформ, которые
ниже будут подробно рассмотрены. Обратимся к видам платформ, а именно
35
проанализируем различия публичных и частных блокчейн-сетей, которые
отражены в таблице 4 [18].
Таблица 4 – Виды блокчейн-платформ
Публичная платформа
Частная платформа
Открытая платформа, любой может стать Ограниченный доступ к платформе,
участником цепи.
требующий права доступа к ней; новый
участник присоединяется к сети по
приглашению от уже действующего
участника цепи.
Каждый узел сети (нода) имеет равную Только определенные узлы сети могут
мощность передачи информации.
создавать
и
подтверждать
новые
транзакции.
Низкая скорость выполнения транзакции.
Высокая скорость выполнения транзакции.
Высокая стоимость каждой совершенной Сравнительно низкая стоимость каждой
транзакции.
транзакции.
PoF и PoS консенсусы протоколов при Предварительно одобренные участники
добавлении новых блоков.
платформы добавляют новый блок.
Не нужно подтверждение всех участников Каждый участник платформы должен
при формировании транзакционного блока. уникальным идентификационным ключом
подтвердить
новый
формируемый
транзакционный блок.
Высокое потребление энергии.
Низкое потребление энергии.
Компании ООО «Петролеум Трейдинг» необходима такая платформа,
которая позволит проводить транзакции на достаточно большой скорости с
низким потреблением энергии, а также ограничить круг лиц, имеющих доступ
к платформе. Данным требованиям отвечает частный вид блокчейнплатформы [9, с. 10].
2.3 Анализ и выбор платформы для проекта
В настоящее время в мире существует огромное количество блокчейнплатформ, получивших широкое распространение в мире в различных
отраслях экономики [11][24]. Перечень наиболее подходящих платформ после
проведенного анализа представлен в таблице 5 (более подробный список
проанализированных платформ описан в приложении В).
36
Таблица 5 – Блокчейн-платформы
Характеристики
Ethereum
Cardana
платформы
Консенсус
PoW
PoS
Основные языки
JavaScript,
JavaScript,
программирования
C++, Python THoskell
ICO
+
+
(предварительная
продажа токенов)
DEX
(децентрализованная
биржа)
Создание токенов
+
+
Создание
независимого
блокчейна
Функции
конфиденциальности
Smart-контракт
+
+
Язык
Solidity
Solidity
программирования
контракта
Ardor
+
Hyperledger
Fabric
PBFT
C ++, JavaScript,
Python, Java
+
+
+
+
-
+
+
+
+
+
+
Java, Go
PoS
Java, Shell
Java
Исходя из перечисленных функций осуществляем выбор платформы
Hyperledger Fabric по ряду причин [27, 28, 30]:
1)
имеется аппаратный модуль безопасности, который повышает
безопасность цифровых ключей платформы для таких чувствительных
случаев использования, как управление идентификацией пользователей
блокчейн-платформы;
2)
позволяет
создать
приватную
блокчейн-платформу
и
собственными инструментами произвести настройку прав доступа к сети;
3)
гибкая настройка приватности и доступности информации внутри
сети: существует возможность предоставлять определенный массив данных
конкретному участнику платформы;
4)
гибкий механизм создания и разработки smart-контрактов и их
вариативности.
37
2.4 Обоснование рекомендуемого проектного решения
В результате проведенного анализа существующих блокчейн-платформ
и потребностей компании «Петролеум Трейдинг» для автоматизации
заключения биржевых сделок на СПбМТСБ была выбрана приватная
технология блокчейн и платформа Hyperledger Fabric по следующим
причинам:
1)
компании ООО «Петролеум Трейдинг» необходима закрытая (то
есть, приватная) платформа, чтобы сохранять данные о заключенных
биржевых сделках втайне от других участников биржевых торгов,
потенциальных покупателей и поставщиков нефтепродуктов и СУГ;
2)
необходима платформа, которая позволит не только заключать
договоры по технологии smart-контрактов, но и разрешит моделировать
различные тексты договоров в зависимости от индивидуальных условий
поставки или полноценного сотрудничества между сторонами сделки;
3)
в самой платформе должна быть доступной настройка прав и
доступа участников блокчейн-платформы к информации.
38
3 ПРОЕКТИРОВАНИЕ БЛОКЧЕЙН-ПЛАТФОРМЫ
3.1 Постановка задачи и требования по проекту
Так
как
блокчейн-платформа
представляет
собой
масштабное
программное решение, то будет рассмотрен только модуль, отвечающий за
создание и подписание smart-контрактов между покупателем и поставщиком
о поставке нефтепродуктов и СУГ.
Термины и определения, связанные с технологией блокчейн и ранее
описанные в главе 1, представлены в приложении А.
Внешний вид будущей блокчейн-платформы PROLEUM со всеми
встроенными модулями представлен на рисунке 8.
Рисунок 8 – Внешний вид платформы PROLEUM
Предполагаемый состав модулей платформы PROLEUM включает в
себя следующие сервисы:
39
1)
KYC – модуль, отвечающий за оценку контрагентов (покупателей
и поставщиков) с целью оценки финансовых рисков для брокера при
заключении с ними сделок на поставку нефтепродуктов и СУГ;
2)
алгоритм прогноза будущих цен – модуль, отвечающий за
прогнозирование изменения цены на тот или иной вид нефтепродукта или
СУГ;
3)
алгоритм подбора лучшей цены – модуль, который на основании
данных товарно-сырьевой биржи и иных площадок, где поставщики
выставляют нефтепродукты и СУГ по установленной ими или торгами на
бирже цене, отбирает лучшие предложения рынка на текущий момент
времени;
4)
реального
блок логистики (Rail Locator) – модуль, позволяющий в режиме
времени
отслеживать
вагоны,
в
которых
осуществляется
транспортировка и доставка нефтепродуктов и СУГ от станции отправления
поставщика до станции назначения покупателя
5)
модуль заключения биржевых сделок и работы с клиентами по
контрактам – основополагающий модуль блокчейн- платформы, отвечающий
за процесс заключения сделок между контрагентами и подписания всех
необходимых сопроводительных документов по сделке.
Для реализации внедрения блокчейн- платформы и модуля заключения
биржевых сделок оформим техническое задание (согласно ГОСТ 34.602-89
«Информационная технология. Комплекс стандартов на автоматизированные
системы. Техническое задание на создание автоматизированной системы»).
Наименование платформы: PROLEUM (PRO).
Наименование предприятия-заказчика: ООО «Петролеум Трейдинг».
Наименование
предприятия-исполнителя:
ООО
Девелопмент».
Цель разработки и внедрения платформы:
1)
увеличить скорость заключения биржевых сделок;
40
«Диджитал
2)
сократить расходы, связанные с издержками при заключении
биржевых сделок;
3)
обеспечить прозрачность и надежность заключаемых сделок,
снизить риски, связанные с выполнением обязательств по заключенному
договору о поставке нефтепродукта или СУГ;
4)
обеспечить электронный документооборот между сторонами
сделки, который позволит создавать электронные документы, имеющие такую
же юридическую силу, что и их бумажные носители (благодаря внедрению
модуля заключения сделок).
Требования к системе и модулю:
1)
языки программирования: Java, NodeJS, Javascript, HTML, CSS,
2)
базы данных: CouchDB, PostgresSQL;
3)
блокчейн: Hyperledger Fabric;
4)
компании-владельцу обеспечить контрольный процент (51%) от
1С;
общего размера платформы во избежание несанкционированного изменения
информации в системе;
5)
использовать механизм консенсуса RAFT, то есть ноды сами
выбирают лидера в автоматическом режиме; при отключении любой из нод
лидер выбирается заново;
6)
обеспечить подтверждение транзакции в системе в том случае,
когда получено подтверждение от 2 организаций, которые участвуют в
консенсусе, или от одной из нод «PROLEUM» и одной из нод «Petroleum
Trading». После того, как на платформу добавляется новая организация, она
также участвуют в консенсусе;
7)
осуществить
анализ
по
внедрению
криптовалюты
осуществления сделок на платформе с целью автоматизации платежей;
8)
прописать виды пользователей и установить их права;
41
для
9)
позволить
создавать
электронные
документы
с
помощью
технологии smart-контракта, а именно контракт о поставке нефтепродуктов
или СУГ между покупателем и поставщиком через товарно-сырьевую биржу;
10)
позволить
регистрироваться
организациям
на
платформе
PROLEUM, регистрировать им пользователей, подписывать и расторгать
документы о заключении сделки;
11)
обеспечить хранение информации о действиях пользователей на
платформе, а также проводить версионирование документов;
12)
обеспечить резервное копирование информации, хранящейся на
платформе;
13)
рассмотреть
и
прописать
регламент
работ
организаций,
присоединившихся к работе на платформе PROLEUM, которые разместили у
себя ноды и которые не разместили у себя ноды;
14)
документирование: написание следующих инструкций для:
а)
пользователя платформы PROLEUM;
б)
разработчика;
в)
организации (для разработчиков или IT-отдела), которая в
будущем будет устанавливать и размещать ноды.
3.2 Характеристика входной и выходной информации
Определим входную информацию, необходимую для заключения
сделки с применением модуля блокчейн-платформы по заключению сделок.
Любая сделка, заключенная между двумя сторонами, подтверждается
соответствующим документом в двух экземплярах. В нашем случае, таким
документом является приложение. Однако при этом между сторонами должен
быть подписан другой документ – договор, который связывает покупателя и
поставщика и прописывает основные моменты при заключении сделок в
будущем.
42
При заключении договора на блокчейн-платформе между покупателем
и поставщиком входной информацией, достаточной для подписания договора,
будет являться:
–
ID организации (уникальный идентификатор, присваиваемый при
регистрации на платформе PROLEUM);
–
название организации (согласно Устава организации или иного
документа, на основании которого действует организация);
–
ИНН организации;
–
КПП организации;
–
баланс токенов (криптовалюты) у организации;
–
наличие ноды у организации;
–
статус блокировки организации;
–
дата и время создания организации;
–
фактический адрес организации;
–
юридический адрес организации.
На выходе при заключении договора будет получен сформированный
(то есть подписанный двумя сторонами) между покупателем и поставщиком
договор, основанный на ранее разработанном алгоритме (технология smartконтрактов), или новый подписанный договор, в котором изменились условия
поставки или иные условия, влияющие на дальнейшее заключение сделок и
формирование текста приложений и отменяющий предыдущий договор,
заключенный между покупателем и поставщиком.
На выходе при заключении сделки будет получено подписанное
приложение между покупателем и поставщиком о поставке нефтепродуктов
или СУГ, в котором прописаны уникальные для данной сделки условия с
перечислением нефтепродукта или СУГ и его стоимости, а также размером ж/д
тарифа за тонну нефтепродукта или СУГ и за общее количество
нефтепродукта или СУГ, и сумму сделки, и наличие (или отсутствие) расходов
на таможне при транспортировке нефтепродуктов или СУГ до станции
назначения (или от станции отправления).
43
В дальнейшем по одному из уникальных вышеперечисленных
параметров (например, ИНН контрагента), можно будет получить имеющуюся
информацию о контрагенте (как общую, так и частную, например,
информацию о договорах, о совершённых сделках и иные аналитические
данные).
3.3 Предлагаемая модель процесса обработки данных
Как говорилось ранее, основным процессом автоматизации является
процесс заключения сделок о поставке нефтепродуктов и СУГ. Неотъемлемой
частью сделки является подписанный контракт. В рамках внедрения
платформы PROLEUM и модуля заключения сделок между контрагентами
возможно две ситуации: у клиента размещена и развернута нода и у клиента
отсутствует развернутая нода.
В таблице 6 описана информация, связанная со статусами различных
документов в платформе PROLEUM при работе с модулем заключения сделок.
Таблица 6 – Статусы документов
Статус
Когда появляется
Проект
Документ создан, но не подписан ни одним из участников.
Ожидает подписи
Документ подписан как минимум одной стороной документа и
ожидает подписи остальных участников.
Подписан
Документ подписан всеми участниками документа.
Ожидает
расторжения
Документ расторгнут как минимум одной стороной документа и
ожидает расторжения остальных участников.
Расторгнут
Документ расторгнут всеми участниками документа.
Аннулирован
Истекло время, отведенное на подписание документа.
В таблице 7 представлена информация, касающаяся основных действий
с документами на платформе PROLEUM и с действиями, которые разрешено
совершать с тем или иным видом документа (например, нельзя расторгнуть
44
соглашение о расторжении ранее заключенного договора) во время работы с
модулем заключения сделок, который предлагается разрабатывать на базе
продукта 1С.
Таблица 7 – Действия с документами
Действие
PARENT
(родительский
документ)
CORRECT
(корректировка)
TERMINATION
(соглашение о
расторжении)
Создавать
+
+
+
Отклонять
+
+
+
Расторгать
+
+
-
Корректировать
+
-
-
Аннулировать
+
+
+
Все действия, совершаемые на блокчейн-платформе её пользователями,
фиксируются и составляют поток event-событий. Данные действия было
решено фиксировать с помощью программного продукта 1С по ряду причин:
1)
в компании ООО «Петролеум Трейдинг» многие жизненно
важные сервисы для функционирования организации и её безотказной работы
разработаны и внедрены на базе продуктов 1С, такие как 1С:Аналитика,
1С:Документооборот, сервисные модули по анализу лучших предложений, по
отслеживанию вагонов (Rail Locator), по ж/д тарифам;
2)
IT-отдел компании непосредственно занимался разработкой
вышеперечисленных модулей под нужды компании, их технической
поддержкой и консультациями пользователей, среди которых большинством
являются трейдеры.
Поэтому с помощью программного продукта 1С планируется не только
фиксировать поток event-событий и обрабатывать их для дальнейшей
аналитики сотрудниками компании, но и производить запись в базу данных и
получение информации из неё.
45
Первоначально рассмотрим процесс подписания и расторжения
контракта (бизнес-процесс TO-BE) с клиентом, у которого отсутствует
размещенная и развернутая нода. На рисунке 9 показан процесс заключения
договора с клиентом без ноды с использованием модуля заключения сделок.
В случае заключения контракта клиентом без размещенной нод процесс
инициируется оператором ноды, размещенной в компании ООО «Петролеум
Трейдинг». При подписании контракта (или любого иного документа на
платформе) происходит проверка документов, имеющихся в блокчейнплатформе – у клиента одновременно может существовать только один
документ, имеющий статус «Проект», «Ожидает подписи» или «Ожидает
расторжения». В противном случае система не позволит создавать новые
документы.
Рисунок 9 – Процесс заключения договора с клиентом без ноды
Перед созданием контракта платформа проверяет наличие клиента, как
зарегистрированную компанию, в блокчейне. Если такой контрагент уже
46
имеется в системе, то новый клиент создаваться не будет – в противном
случае, платформа создаст нового клиента.
При создании заключаемого контракта в его тексте будет прописано
особое условие, что он подписывается компанией ООО «Петролеум
Трейдинг» от имени клиента.
Так как у клиента нет размещенной и развернутой ноды, то договор
формируется оператором ноды компании «Петролеум Трейдинг» для его
дальнейшего заключения. Технически договор будет подписан двумя нодами:
нодой компании ООО «Петролеум Трейдинг» и нодой PROLEUM.
На рисунке 10 представлен процесс расторжения договора с клиентом, у
которого отсутствует развернутая нода с использованием модуля заключения
сделок. Аналогично заключению договора, процесс расторжения документа
инициируется оператором ноды компании ООО «Петролеум Трейдинг». В
самом документе будет прописано, что он расторгается компанией от имени
клиента.
Рисунок 10 – Процесс расторжения договора с клиентом без ноды
47
На рисунке 11 представлен процесс заключения договора между
клиентами (бизнес-процесс TO-BE), имеющих собственные развернутые ноды
(а значит, зарегистрированных уже на блокчейн-платформе) с использованием
модуля заключения сделок.
Один из клиентов инициирует подписание договора (или иного
документа) с другим клиентом. При этом ни у кого из них на момент
подписания договора не должно быть документов, имеющих статус «Новый»,
«Ожидание подписания» или «Ожидание расторжения» - в противном случае,
платформа не позволит создать новый документ.
Запрос на подписание договора, имеющего подпись первого клиента,
приходит второму клиенту и ожидает реакции от него: договор может быть
подписан и может быть отклонен от подписания. При выборе любого из
сценариев, договор остается в платформе с соответствующим статусом.
Рисунок 11 – Процесс заключения договора между клиентами,
имеющих собственные ноды
3.4 Проектирование базы данных
Так как предполагается внедрение нескольких сервисных модулей
(включая модуль заключения сделок) и широкий спектр алгоритмов выбора
48
текста контракта и иных документов, свидетельствующих о заключении
сделки, то будет представлена общая схема предполагаемой базы данных. Так
как многие сервисные модули разработаны на продукте 1С, то и действия,
совершаемые с базой данных (внесение информации, её изменение и
удаление), будет тоже совершаться продуктом на базе 1С.
Архитектура базы данных платформы представлена в приложении Г.
Каждый модуль, в том числе модуль блокчейн-платформы по
заключению сделок, имеет связь с другим модулем базы данных через
уникальный
идентификатор,
присваиваемый
при
обработке
данных
программным продуктом 1С.
При создании нового соглашения с контрагентом к действующему
договору записываются следующие данные в базу данных:
1) timestamp – время заключения соглашения;
2) Id – ID созданного соглашения, присваивается автоматически
системой регистрации документа (1С);
3) contractId – ID контракта с клиентом;
4) number – номер созданного соглашения, присваивается автоматически
системой регистрации документа (1С) по установленному шаблону;
5) date – дата соглашения;
6) status – статус соглашения;
7) dateStart – дата начала действия соглашения;
8) dateEnd – дата окончания действия соглашения.
При создании контракта с контрагентом записываются следующие
параметры в базу данных:
1) timestamp – время заключения соглашения;
2) Id – ID созданного контракта, присваивается автоматически системой
регистрации документа (1С);
3) number – номер созданного контракта, присваивается автоматически
системой регистрации документа (1С) по установленному шаблону;
4) date – дата контракта;
49
5) status – статус контракта;
6) orgs – информация по организации;
7) dateStart – дата начала действия контракта;
8) dateEnd – дата окончания действия контракта.
При заключении сделки с контрагентом о поставке нефтепродукта или
СУГ записывается следующая структура данных:
1) timestamp – время заключения сделки;
2) items:
– timestamp – время;
– id
–
ID
документа,
присваивается
автоматически
системой
регистрации документа (1С);
– dealId – ID созданной сделки, присваивается автоматически системой
регистрации документа (1С);
– instrumentCode – код инструмента нефтепродукта или СУГ;
– price – цена нефтепродукта или СУГ;
– amount – количество нефтепродукта или СУГ.
При создании документа (прикрепляется в дальнейшем к заключаемой
сделке с покупателем о поставке нефтепродукта или СУГ) формируется и
записывается в базу данных следующая структура:
1) timestamp – время создания документа;
2) operationType – тип операции (parent, correct, termination);
3) parentId – ID владельца документа, присваивается автоматически
системой регистрации документа (1С);
4) documentId – ID документа, присваивается автоматически системой
регистрации документа (1С);
5) orgs – информация по организации;
6) kindId – вид документа;
7) termValidity – дата актуальности документа;
8) params:
50
– contractId – ID договора, присваивается автоматически системой
регистрации документа (1С);
– managerId – ID менеджера сделки, присваивается автоматически
системой регистрации документа (1С);
– agreementId – ID дополнительного соглашения, присваивается
автоматически системой регистрации документа (1С);
– delay – количество дней просрочки;
– productId – ID нефтепродукта или СУГ, присваивается автоматически
системой регистрации документа (1С);
– plantId
–
ID
завода,
присваивается
автоматически
системой
регистрации документа (1С);
– shipmentBasisId – ID базиса отгрузки (станции отправления),
присваивается автоматически системой регистрации документа (1С);
– stationDestinationId
–
ID
станции
назначения,
присваивается
автоматически системой регистрации документа (1С);
– consigneeId – ID получателя нефтепродукта или СУГ, присваивается
автоматически системой регистрации документа (1С);
– amount – количество нефтепродуктов или СУГ;
– price – цена нефтепродукта или СУГ.
При подписании документа формируется и записывается в базу данных
следующая структура:
1) timestamp – время подписания документа;
2) documentId
–
ID
подписанного
документа,
присваивается
автоматически системой регистрации документа (1С);
3) orgId – ID организации, присваивается автоматически системой
регистрации документа (1С);
4) userId – ID пользователя, подписавшего документ, присваивается
автоматически системой регистрации документа (1С).
При расторжении документа сохраняются в базе данных следующие
параметры:
51
1) timestamp – время расторжения документа;
2) documentId
–
ID
расторгаемого
документа,
присваивается
автоматически системой регистрации документа (1С);
3) orgId – ID организации, присваивается автоматически системой
регистрации документа (1С);
4) userId – ID пользователя, расторгнувшего документ, присваивается
автоматически системой регистрации документа (1С);
5) reason – причина расторжения документа.
3.5 Проектирование интерфейса
При
проектировании
интерфейса
модуля
заключения
сделок
необходимо опираться на требования технического задания и потребности
компании ООО «Петролеум Трейдинг». Так как блокчейн-платформа должна
автоматизировать процесс заключения биржевых сделок между клиентами, то
модуль должен отражать заключенные договоры и иные документы в удобной
для пользователей формы.
На рисунке 12 представлен макет интерфейса окна модуля «Создание
договора» (подписываемого договора о поставке нефтепродуктов или СУГ
или иного юридического документа между клиентами, у которых размещены
и развернуты ноды). Как показано на рисунке, должна быть соответствующая
кнопка, которая бы позволила предварительно ознакомиться с текстом
подписываемого договора и его условиями.
При создании договора вся информация, отображенная в интерфейсе,
будет занесена в базу данных с помощью продукта 1С.
52
Рисунок 12 – Интерфейс окна модуля «Создание договора»
На рисунке 13 отображен макет интерфейса окна модуля для отражения
списка договоров или иных документов, заключенных клиентом с другими
контрагентами. В представленном списке должны отражаться только те
договоры и иные документы, где одной из сторон является авторизованный
клиент. Для информативности в списке должны отражаться следующие
данные:
–
тип документа;
–
номер
документа
(присваивается
автоматически
блокчейн-
платформой);
–
статус документа;
–
дата создания документа, его подписания и расторжения.
53
Информация по контракту будет передана в интерфейс с помощью
продукта 1С, который осуществит запрос к базе данных и передаст
полученную информацию в интерфейс пользователя на платформе.
Рисунок 13 – Интерфейс окна модуля для отражения списка договоров
На рисунке 14 представлен макет интерфейса окна модуля для
отображения текста договора или иного юридического документа, который
отражает основные данные договора или другого документа и его параметры.
В самом договоре или ином документе должна быть предусмотрена кнопка о
расторжении документа, а также вывести документ на печать или сохранить
его в удобном для пользователя формате pdf.
В представленном примере указана следующая информация по
договору:
–
стороны сделки и их электронные подписи в виде уникальных
идентификаторов;
–
предмет сделки (наименование нефтепродукта или СУГ, его вес,
стоимость за тонну, общая стоимость);
–
станция отправления;
–
станция назначения;
–
порядок оплаты за нефтепродукт или СУГ.
54
Информация по контракту будет передана в интерфейс с помощью
продукта 1С, который осуществит запрос к базе данных и передаст
полученную информацию в интерфейс пользователя на платформе.
Рисунок 14 – Интерфейс окна модуля для отображения текста договора
3.6 Проектирование топологической модели
С точки зрения архитектурного решения все пользователи блокчейнплатформы будут делиться на две основные категории: клиенты, имеющие
установленные и развернутые ноды и клиенты, не имеющие установленных и
развернутых нод. В зависимости от вида клиента будет выбрано то или иное
взаимодействие с платформой PROLEUM.
Рассмотрим взаимодействие пользователей с платформой пользователей
с собственными нодами, представленную на рисунке 15.
55
56
Рисунок 15 – Взаимодействие пользователей с платформой пользователей с собственными нодами
При наличии собственной развернутой ноды клиент действует через
локальный web-интерфейс собственных компьютеров (или иных устройств) и
через собственную ноду. Нода клиента, в свою очередь, в рамках блокчейнплатформы, будет взаимодействовать с другими нодами и с нодами компании
ООО «Петролеум Трейдинг». Вся информация об имеющихся документах и
заключенных сделках будет храниться на ноде клиента и на нодах PROLEUM.
На рисунке 16 представлен процесс взаимодействия пользователей с
платформой пользователей с собственными нодами и без нод.
Те клиенты, которые не имеют своей ноды, доверяют платформе
PROLEUM и участникам сети, могут заключать, подписывать, расторгать и
смотреть документы, которые хранятся на нодах других участников и своей
копии не держат. Взаимодействие с нодами участников сети они
осуществляют от своего имени через веб-интерфейс, а запись в блокчейн будет
идти от имени платформы с указанием пользователя, который инициировал
эту запись.
При записи от имени пользователя принципиально учитывать тот
момент, что используется не публичный блокчейн (в котором все участники
равны и одинаковы), а приватный (в котором определенные организации
могут брать на себя определенные роли и определенные функции). В данном
случае платформа PROLEUM может взять на себя функцию записи данных от
имени всех пользователей, у которых нет своих нод.
В этом случае запись в блокчейн будет идти от имени платформы
PROLEUM с использованием сертификата ноды платформы PROLEUM, а
текст смарт-контракта может содержать формулировку, что подписано через
платформу PROLEUM.
57
58
Рисунок 16 – Взаимодействие пользователей с платформой пользователей с собственными нодами и без нод
3.7 Архитектура сервиса на платформе
В рамках реализации блокчейн-платформы и модуля заключения сделок
также планируется внедрить очередь сообщений, которая позволит решить
следующие задачи:
1)
синхронизация паролей между локальными нодами организаций и
глобальной нодой платформы PROLEUM;
2)
гарантированная отправки события на платформе. Сообщение
попадает в очередь, специальный сервис отправляет это сообщение из
очереди, и если сообщение не доставлено, то через некоторое время сервис
отправит его снова;
3)
фиксация произошедших на платформе событий, их
структуризация и анализ с целью получения определенной статистики и
принятия решений по дальнейшему совершенствованию работы платформы.
В рамках реализации блокчейн-платформы предполагается следующая
классификация нод:
–
обычные c сервисом упорядочивания транзакций - ноды, на
которых размещаются дополнительные сервисы упорядочивания транзакций;
–
обычные без сервиса упорядочивания транзакций;
–
мастер-ноды – ноды, на которых размещаются дополнительные
сервисы для работоспособности платформы.
Архитектура сервиса очереди на платформе представлена на рисунке 17,
где:
–
CA – менеджер сертификатов;
–
СLI – командная строка для управления инфраструктурой
Hyperledger;
–
Global-web – web-интерфейс организации PROLEUM;
–
Local-web – локальный web-интерфейс организации;
–
Peer – узел сети;
–
Orderer (Ordering service) – сервис упорядочивания транзакций;
–
Reserved (web\API) – это дополнительная копия web и API, на
случай если первый сервер выйдет из строя.
Сервис очереди и файловое хранилище развернуты на всех мастернодах. На данной схеме это 2 ноды PROLEUM. Также будет происходить
переключение между нодами одной организации будет происходить
автоматически для обеспечения балансировки нагрузки.
59
60
Рисунок 17 – Архитектура сервиса очереди на платформе
4 РАЗРАБОТКА МОДУЛЯ ЗАКЛЮЧЕНИЯ СДЕЛОК
4.1 Разработка модуля заключения сделок
В результате внедрения блокчейн-платформы в компании ООО
«Петролеум Трейдинг» был разработан web-интерфейс, позволяющий в
полной мере пользоваться возможностями модуля заключения сделок.
На рисунке 18 отображен интерфейс окна модуля заключения сделок
«Документы», в котором отражены все документы авторизированного
пользователя по его организации.
Рисунок 18 – Интерфейс окна модуля «Документы».
На рисунке 19 отображен интерфейс окна модуля «Информация о
контракте» по подписанному контракту или иному юридическому документу,
заключенному на блокчейн-платформе. В документе указаны следующие
данные:
1)
поставщик нефтепродуктов или СУГ;
2)
покупатель;
3)
наименование приобретаемого нефтепродукта или СУГ;
4)
количество (в тоннах);
61
5)
стоимость нефтепродукта или СУГ за тонну;
6)
общая сумма сделки;
7)
станция отправления;
8)
станция назначения.
Рисунок 19 – Интерфейс окна модуля «Информация о контракте»
На рисунке 20 представлена иерархия связанных документов у
конкретного
покупателя
через
интерфейс
окна
модуля
«Связанные
документы». Как видно на рисунке, иерархия представляет собой сеть
документов, которые подчинены главному документу – дополнительному
соглашению с контрагентом. Благодаря подобной иерархии и выводимой для
пользователя информации по заключенным в системе документам можно
проследить историю подписания документов, заключения сделок между
покупателем и поставщиком, а также развитие бизнес-отношений между
сторонами.
62
Рисунок 20 – Интерфейс окна модуля «Связанные документы»
4.2 Описание ролей и прав доступа к платформе
Для обеспечения безопасности данных и предотвращения их утечки
изнутри платформы была рассмотрена и проанализирована возможность
создания ролей в платформе и установка ограничений для каждой из них.
Роли в рамках платформы PROLEUM:
–
Владелец
платформы
(Owner)
–
основатели
платформы,
пользователи, которые имеют наибольшие полномочия на платформе, в том
числе и эмиссию бонусных токенов.
–
Администратор (Admin) – пользователь платформы, который
имеет права для настройки сети и распоряжение бонусными токенами;
–
Владелец организации (Organisation_Owner) – участник сети,
который создается автоматически при создании организации и имеет право к
управлению функциями организации.
63
–
Пользователь (User) – представитель любой из организаций -
клиент, участник сети, взаимодействующий с Организацией PROLEUM.
В таблице 8 представлена информация по ролям и по доступным
действиям для каждой из них.
Таблица 8 – Виды пользователей платформы и их права
Метод
Owner
Admin
Organisation
_Owner
User
Авторизация
+
+
+
+
Смена пароля (самому себе)
+
+
+
+
Установка пароля (самому себе)
+
+
+
+
Создание организации
+
+
-
-
Получение списка всех
организаций
+
+
-
-
Просмотр данных об
организации по ID
+
+
-
-
Обновление данных об
организации
+
+
-
-
Блокировать организацию
+
+
-
-
Разблокировать организацию
+
+
-
-
Создать пользователя
+
+
-
-
Обновить данные о
пользователе
+
+
-
-
Удалить пользователя
+
+
-
-
Получение списка всех
документов
+
+
-
-
Получение списка своих
документов
+
+
+
+
Создание документа
+
+
+
+
64
Продолжение таблицы 8
Owner
Admin
Organisation
_Owner
User
Получение документа по ID
+
+
+
+
Отклонение документа,
подписантом которого является
организация пользователя
+
+
+
+
Отклонение/отмена документа
по ID пользователя через ноду
PROLEUM
+
+
-
-
Получить историю документа
по ID
+
+
+
+
Подписание документа,
подписантом которого является
организация пользователя
+
+
+
+
Подписание документа по ID
пользователя через ноду
PROLEUM
+
+
-
-
Загрузить файл
+
+
-
-
Получить список версий
чейнкода
+
+
+
+
Загрузить новую версию
чейнкода
+
+
-
-
Получить список последних
версий чейнкода
+
+
+
+
Просмотр баланса любой
организации по ID
+
+
-
-
Просмотр баланса своей
организации по ID
+
+
+
-
Дополнительная эмиссия
+
-
-
-
Подтверждение запроса на
увеличение эмиссии
+
-
-
-
Метод
65
Окончание таблицы 8
Owner
Admin
Organisation
_Owner
User
Отклонение запроса на
увеличение эмиссии
+
-
-
-
Получение списка запросов на
увеличение эмиссии
+
-
-
-
Просмотр размера общей
эмиссии
+
-
-
-
Распределение
токенов(бонусов) – перевод
организациям
+
+
-
-
Метод
4.3 Формирование запросов к базе данных
Так как было решено использовать 1С для работы с базой данных
(внесение информации о документах и заключаемых сделках, её получение,
изменение и удаление), то будет осуществлена разработка кода и
программных алгоритмов для работы с базой данных.
На рисунке 21 представлен фрагмент кода по получению данных о
документе из базы данных для отображения информации по сделке или иному
юридическому документу через
пользовательский
интерфейс
модуля
заключения сделок.
Рисунок 21 – Код получения информации по документу (сделке)
66
На рисунке 22 представлен фрагмент кода, отображающего алгоритм
подписания или отклонения документа (включая договор) пользователем
блокчейн-платформы в модуле заключения сделок.
Рисунок 22 – Код алгоритма подписания или отклонения документа
На рисунке 23 отображена структура данных, получаемых программным
продуктом на базе 1С из базы данных блокчейн-платформы по ранее
подписанному договору или иному юридическому документу. Полученная
информация используется модулем заключения сделок для отображения в
пользовательском интерфейсе.
На рисунке 24 отображена структура данных, получаемых программным
продуктом на базе 1С из базы данных блокчейн-платформы по ранее
расторгнутому договору или иному юридическому документу. Полученная
информация используется модулем заключения сделок для отображения в
пользовательском интерфейсе.
67
Рисунок 23 – Структура данных в базе данных по подписанному
договору
Рисунок 24 – Структура данных в базе данных по расторгнутому
договору
На рисунке 25 представлен фрагмент кода, описывающего алгоритм
создания и заполнения сделки о поставке нефтепродуктов или СУГ модулем
заключения сделки. Алгоритм модуля настроен таким образом, что
68
анализирует ранее подписанные документы, имеющиеся у сторон сделки для
получения информации по условиям их работы и поставки нефтепродуктов
или СУГ (тип оплаты, срок отсрочки платежа и иные параметры,
прописываемые в договоре и иных юридических документах).
Рисунок 25 – Код алгоритма создания и заполнения сделки
4.4 Разработка механизмов защиты информации
В платформе разработано и реализовано несколько механизмов защиты
информации:
1)
была разработана система ролей и их прав на платформе
PROLEUM (подробно описано в п.4.3);
2)
платформа PROLEUM была создана на базе Hyperledger Fabric,
которая является закрытой (частной) блокчейн-платформой, соответственно,
стать её участником можно только по приглашению со стороны создателя
платформы;
3)
обеспечение для компании-владельца контрольного процента
(51%) от общего размера платформы позволит в будущем избежать
несанкционированного
изменения
информации
69
в
системе,
а
также
предотвратить возможный сговор участников платформы для внесения какихлибо изменений;
4)
на рисунке 27 представлено окно авторизации пользователя – без
пройденной авторизации никто не сможет получить доступ к блокчейнплатформе;
Рисунок 27 – Интерфейс окна «Авторизация пользователя»
5)
на рисунке 28 представлен интерфейс окна, всплывающего при
совершении того или иного действия с любым документом на платформе
PROLEUM. Для подписания или расторжения того или иного документа
необходимо подтвердить это действие не только электронной подписью
клиента, но и SMS кодом, который приходит ответственному лицу компании.
Рисунок 28 – Интерфейс окна «Подтверждение расторжения
контракта»
70
6)
само понятие децентрализованной системы данных не позволит
быстро взломать блокчейн-платформу и внести серьезные изменения в данные
– для этого необходимо взломать каждый компьютер каждого участника сети,
что только усложняет задачу для преднамеренного изменения данных;
7)
использование квалифицированных электронных подписей;
8)
процедура криптографического хэширования данных при их
передаче между участниками платформы;
9)
резервное копирование данных платформы;
10)
для защиты серверов использовать следующие средства защиты:
–
специализированные системы обнаружения и предотвращения
вторжений (IDS/IPS);
–
разрешение удаленного доступа к серверам определенному списку
IP-адресов по VPN, а также настройка шифрования данных SSL;
–
установка аутентификации по ключам SSH;
–
периодический мониторинг и проверки защищенности серверов
службой безопасности платформы с целью предотвращения возможных
утечек, выявления и устранения уязвимых мест серверов.
71
Заключение
В рамках выполнения магистерской диссертации в компании ООО
«Петролеум Трейдинг» представлена его архитектура в различных аспектах, а
также описана реализация архитектуры проекта в рамках автоматизации
процесса заключения биржевых сделок на рынке нефтепродуктов с
использованием технологии блокчейн в ООО «Петролеум Трейдинг».
В первой главе были рассмотрены основные сферы деятельности
компании ООО «Петролеум Трейдинг» согласно Устава организации. Также
представлена структура компании с выделением ключевых отделов,
непосредственно задействованных в процессе заключения биржевых сделок.
Приведены основные понятия и термины в области биржевых сделок.
Рассмотрены основные законы, регулирующие электронный документооборот
и его использование как равнозначного бумажному документообороту
юридических
документов;
законы,
регулирующие
использование
электронных цифровых подписей и их юридическую равнозначность
физически поставленными подписями и печатями; законы, регулирующие
использование блокчейн-платформ и законность использования криптовалют
как платежных средств на территории Российской Федерации. Рассмотрены и
проанализированы процессы взаимодействия брокера (компании ООО
«Петролеум Трейдинг») с Санкт-Петербургской международной товарносырьевой биржей (с учетом нормативно-правовых актов о бирже и правил
торгов, установленных СПбМТСБ) и с непосредственными покупателями
нефтепродуктов и сжиженных углеводородных газов. В ходе проведенного
анализа процесса заключения сделок была составлена модель AS-IS и были
выявлены проблемные места и обозначены возможные риски для компании.
Во второй главе рассмотрены теоретические аспекты предметной
области, а именно:
72
-
был проведен анализ и обоснование целесообразности и
необходимости внедрения технологии блокчейн;
-
было
приведено обоснование
выбранного
вида
блокчейн-
платформы, как частной закрытой системы;
-
был проведен анализ существующих блокчейн-платформ и
выбрана та платформа, которая удовлетворяет требованиям компании для
автоматизации процесса заключения сделок.
В третьей главе были четко поставлены и описаны основные
требования к платформе и её ключевому модулю заключения сделок. Была
описана предлагаемая модель процесса заключения сделок, в рамках которой
были описаны процессы заключения или расторжения договора или иного
юридического документа между сторонами сделки в зависимости от того,
размещена ли у контрагента нода или нет. Также была представлена и описана
спроектированная
структура
базы
данных платформы через
модуль
заключения сделок и архитектура сервиса очередей событий. Помимо этого,
был рассмотрен и предложен интерфейс основного модуля платформы –
модуля заключения сделок.
В четвертой главе представлен интерфейс разработанного модуля
заключения сделок на блокчейн-платформе и фрагменты кодов модуля к базе
данных с целью получения (или внесения/изменения) информации по
договорам и иным документам контрагента. Также была создана система
ролей в рамках платформы с описанием их прав доступа к тем или иным
сервисам блокчейн-платформы. Помимо этого, были предложены механизмы
защиты информации как внутри платформы, так и на стороне каждого из её
участников.
Результаты магистерской диссертации полностью соответствуют
решению поставленных задач и достижению цели.
73
Библиографический список
О бухгалтерском учете: Федеральный закон № 402-ФЗ : [принят
1
Государственной Думой 22 ноября 2011 года] // ИПО ГАРАНТ-Максимум /
НПП «ГАРАНТ-СЕРВИС-УНИВЕРСИТЕТ.» – Дата обновления: 26.07.2019.
О
2
государственной
регистрации
юридических
лиц
и
индивидуальных предпринимателей: Федеральный закон № 129-ФЗ : [принят
Государственной Думой 13 июля 2001 года] // ИПО ГАРАНТ-Максимум /
НПП «ГАРАНТ-СЕРВИС-УНИВЕРСИТЕТ.» – Дата обновления: 27.10.2020.
О защите конкуренции: Федеральный закон № 135-ФЗ : [принят
3
Государственной Думой 8 июля 2006 года] // ИПО ГАРАНТ-Максимум / НПП
«ГАРАНТ-СЕРВИС-УНИВЕРСИТЕТ.» – Дата обновления: 22.12.2020.
О
4
противодействии
неправомерному
использованию
инсайдерской информации и манипулированию рынком и о внесении
изменений в отдельные законодательные акты Российской Федерации:
Федеральный закон № 224-ФЗ : [принят Государственной Думой 2 июля 2010
года]
//
ИПО
ГАРАНТ-Максимум
/
НПП
«ГАРАНТ-СЕРВИС-
УНИВЕРСИТЕТ.» – Дата обновления: 01.04.2020.
О цифровых финансовых активах, цифровой валюте и о внесении
5
изменений в отдельные законодательные акты Российской Федерации:
Федеральный закон № 259-ФЗ : [принят Государственной Думой 22 июля 2020
года]
//
ИПО
ГАРАНТ-Максимум
/
НПП
«ГАРАНТ-СЕРВИС-
УНИВЕРСИТЕТ.» – Дата обновления: 22.07.2020.
6
Об информации, информационных технологиях и о защите
информации: Федеральный закон № 149-ФЗ : [принят Государственной Думой
8 июля 2006 года] // ИПО ГАРАНТ-Максимум / НПП «ГАРАНТ-СЕРВИСУНИВЕРСИТЕТ.» – Дата обновления: 30.12.2020.
7
Об организованных торгах: Федеральный закон № 325-ФЗ :
[принят Государственной Думой 2 ноября 2011 года] // ИПО ГАРАНТ-
74
Максимум / НПП «ГАРАНТ-СЕРВИС-УНИВЕРСИТЕТ.» – Дата обновления:
31.07.2020.
8
Об электронной подписи: Федеральный закон № 63-ФЗ : [принят
Государственной Думой 25 марта 2011 года] // ИПО ГАРАНТ-Максимум /
НПП «ГАРАНТ-СЕРВИС-УНИВЕРСИТЕТ.» – Дата обновления: 23.07.2020.
9
Аверин, А.С., Аверина, О.С. Особенности и перспективы развития
приватных блокчейн систем / А.С. Аверин, О.С. Аверина // Наука настоящего
и будущего. – СПб, 2019. – С. 9-12.
10
Антипина, Н.И. Особенности применения технологии блокчейн в
России: отраслевой и региональный аспекты / Н.И. Антипина // Управление
социально-экономическими системами. – Кострома, 2019. – № 1. – С. 39-41.
11
Бакибаев, Т.И., Абешев, К.Ш. Blockchain для транспортных
средств на базе платформы Exonum / Т.И. Бакибаев, К.Ш. Абешев,
Н.А.Жумадил,
С.М.
Нарбаева,
К.А.
Шубенкова
//
T-COMM:
Телекоммуникации и транспорт. – Москва, 2019. – № 12. – С. 36-42.
12
Белянцев, С.С. Развитие информационных и блокчейн технологий
в российских компаниях / С.С. Белянцев // Электронный научный журнал. –
Люберцы, 2020. – № 1 (30). – С. 14-17.
13
Вильданова, М.М. О биржевых посредниках в России / М.М.
Вильданова // Право и практика. – Москва, 2019. – № 2. – С. 154-160.
14
Годин, В.В., Терехова, А.Е. Блокчейн: философия, технология,
приложения и риски / В.В. Годин, А.Е. Терехова // Вестник университета. –
Москва, 2019. – № 9. – С. 54-61.
15
Ёлохова, И.В., Ахметова, М.И. Подходы к определению правового
статуса криптовалют в ведущих странах мира / И.В. Ёлохова, М.И. Ахметова,
А.В. Крутова,
А.В. Тетенова // Вестник Пермского национального
исследовательского
политехнического
университета.
Социально-
экономические науки. – Пермь, 2019. – № 1. – С. 201-209.
16
Ефремов, В.С., Пилишвили, А.С. Перспективы сотрудничества
финансовой корпорации и компаний, работающих в сфере цифровых
75
технологий / В.С. Ефремов, А.С. Пилишвили // Управление. – Москва, 2019. –
№ 2. – С. 57-64.
17
Как внедрить блокчейн в цепочку поставок: 7 обязательных шагов
[Электронный
ресурс].
Режим
доступа:
URL.:
https://merehead.com/ru/blog/how-to-implement-blockchain-in-the-supply-chain/,
свободный (дата обращения 10.11.2020)
18
Как работает, применение и использование блокчейн в логистике
[Электронный
ресурс].
Режим
доступа:
URL.:
https://merehead.com/ru/blog/logistic-companies-that-use-blockchain/, свободный
(дата обращения 10.11.2020)
19
Крохичева, Г.Е., Архипов, Э.Л. Спекуляция и ее роль в экономике
/ Г.Е. Крохичева, Архипов Э.Л., В.В. Троценко, М.А. Жилякова // Экономика
и бизнес: теория и практика. – Новосибирск, 2020. – № 3-1 (61) – С. 92-94.
20
Маргацкая, Г.С., Маргацкий, Р.В. Технологии блокчейн на
фондовом рынке / Г.С. Маргацкая, Р.В. Маргацкий // Вестник университета
Туран. – Алматы, 2019. – № 1 (81). – С. 87-92.
21
Остринская,
Л.И.,
Эрбах,
К.М.
Основные
проблемы
взаимодействия брокера на товарно-сырьевой бирже с покупателем и их
решение с помощью технологии блокчейн / Л.И. Остринская, К.М. Эрбах //
Архитектурно-строительный
и
дорожно-транспортный
комплексы:
проблемы, перспективы, инновации. – Омск, 2019. – С. 506-509.
22
Павлова, Е.В. Инновационный фьючерсный контракт, как
инструмент снижения финансовых рисков / Е.В. Павлова // Вестник
Казанского технологического университета. – Казань, 2011. – № 8. – С. 229238.
23
Пескова, О.Ю., Половко, И.Ю., Захарченко, А.Д. Применение
блокчейн-технологий в системах электронного документооборота: анализ и
программная реализация / О.Ю. Пескова, И.Ю. Половко, А.Д. Захарченко //
Инженерный вестник Дона. – Ростов-на-Дону, 2019. – № 3 (54). – С. 42-58.
76
24
Садчиков,
регулирования
и
М.Н.,
Курбатов,
обеспечения
Н.М.
К
вопросу
информационной
правового
безопасности
при
использовании технологии блокчейн в банковском секторе экономики
Российской Федерации / М.Н. Садчиков, Н.М. Курбатов // Вестник
Саратовской государственной юридической академии. – Саратов, 2020. – № 1
(132). – С. 219-229.
25
Сидорова, Л.Г., Фурадеева, Ю.В. Основы функционирования и
взаимодействия блокчейн-технологий и криптоактивов / Л.Г. Сидорова, Ю.В.
Фурадеева
//
Рынок
транспортных
услуг
(проблемы
повышения
эффективности). – Гомель, 2019. – № 1 (12). – С. 320-328.
26
Уржумов, А.В. Эффективность применения блокчейна для
осуществления государственных тендеров / А.В. Уржумов // Госзаказ:
управление, размещение, обеспечение. – Москва, 2019. – № 57. – С. 38-47.
27
Хряпова, Т.К. Перспективы использования набора инструментов
Hyperledger
Fabric
для
создания
надежной
бизнес-управляемой
информационной структуры блокчейн / Т.К. Хряпова // Актуальные научные
исследования в современном мире. – Переяслав-Хмельницкий, 2019. – № 12-4
(56). – С. 103-106.
28
Чистяков,
М.А.
Hyperledger
Fabric:
особенности,
сферы
применения / М.А. Чистяков // Аллея науки. – Томск, 2018. – № 2 (18). – С.
776-779.
29
Чистяков, М.А. Изменение данных в распределенном реестре
посредством замены блоков / М.А. Чистяков // E-SCIO. – Саранск, 2019. – № 6
(33). – С. 31-35.
30
Что такое Hyperledger Fabric платформа: преимущества и примеры
[Электронный
ресурс].
Режим
доступа:
URL.:
https://merehead.com/ru/blog/benefits-of-blockchain-hyperledger-fabric/,
свободный (дата обращения 10.11.2020)
31
Правила
допуска
к
участию
в
организованных
торгах
Акционерного общества «СанктПетербургская Международная Товарно77
сырьевая Биржа». Утверждены Протоколом №150 Советом директоров
Акционерного общества «Санкт-Петербургская Международная Товарносырьевая Биржа» от 5 декабря 2019 года [электронный ресурс] // Сайт АО
«Санкт-Петербургская Международная Товарно-сырьевая Биржа». Режим
доступа: URL.: https://spimex.com/upload/iblock/cda/cda92d9d8e868cfe521cfd18
fb926667.pdf, свободный (дата обращения 10.11.2020)
32
Правила
«Нефтепродукты»
проведения
организованных
Акционерного
общества
торгов
в
Секции
«Санкт-Петербургская
Международная Товарно-сырьевая Биржа». Утверждены Протоколом №153
Советом
директоров
Акционерного
общества
«Санкт-Петербургская
Международная Товарно-сырьевая Биржа» от 10 апреля 2020 года
[электронный ресурс] // Сайт АО «Санкт-Петербургская Международная
Товарно-сырьевая Биржа». Режим доступа: https://spimex.com/upload/iblock/
903/903df4b62b1ed30def74255c3908c386.pdf, свободный (дата обращения
10.11.2020)
33
Устав общества с ограниченной ответственностью «Петролеум
Трейдинг». Утвержден Протоколом №1 общего собрания учредителей ООО
«Петролеум Трейдинг» от 13 февраля 2013 года (ред. от 09.12.2019)
[электронный ресурс] // Сайт компании ООО «Петролеум Трейдинг». Режим
доступа: https://ptomsk.ru/upload/iblock/60b/Ustav-obnovlennyy.pdf, свободный
(дата обращения 10.11.2020)
78
Приложение А
Список используемых терминов и определений
Администратор
пользователь, который имеет права для настройки сети
Блокчейн
структура данных, представляющая собой выстроенную
по
определённым
правилам
непрерывную
последовательную цепочку блоков (связный список),
содержащих информацию
Логи
это записи о действиях (вызовах API)
Механизм
алгоритм, который проверяет, что соблюдаются правила
консенсуса
протокола блокчейна, и гарантирует, что все транзакции
происходят доверенным способом
Оператор
участник сети, работающий от имени Организации
PROLEUM
Пользователь
клиент,
участник
сети,
взаимодействующий
с
Организацией PROLEUM и её операторами
Приложение
существующее решение для работы операторов с API
Участник сети
любое лицо, имеющее доступ к сети "PROLEUM",
аналог в терминологии Hyperledger Fabric – Организация
(Organisation)
Ядро
бэкэнд на стороне PROLEUM
API
решение
для
любого
взаимодействия
с
сетью
«PROLEUM» и его чейн-кодами
Chaincode (смарт- программа,
загруженная
контракт,
Fabric
чейн- Hyperledger
и
в
приватный
позволяющая
код)
выполнять операции с данными блокчейна
Creator MSP
нода-создатель транзакции
Endorser
ноды, которые подтвердили транзакцию
(эндорсер)
79
блокчейн
участникам
уведомление о событии в блокчейне, которое блокчейн
Event
посылает в ядро
Global-web
глобальный web-интерфейс (для всех пользователей)
Global API
API для взаимодействия с глобальным интерфейсом
платформы PROLEUM
компьютер, подключенный к сети. Компьютер обладает
Host (хост)
достаточными вычислительной способностью чтоб
поддерживать работу ноды, API, хранилищ данных и
другой инфраструктуры сети. Хост может быть как
отдельным
прибором
(ноутбук,
сервер),
так
и
виртуальным контейнером.
Hyperledger
приватный open-source блокчейн
Local-web
локальный web-интерфейс (только для пользователей с
нодой)
Local API
API для взаимодействия с локальными интерфейсом
Membership
это CA (Certificate Authority) для выдачи identity и
Services Provider назначения
ролей.
Для
создания
ноды
нужно
(MSP)
провзаимодействовать с MSP
Node (нода)
узел блокчейна, где хранится копия истории блокчейна
и позволяющий подключаться и работать с сетью
блокчейна
Ordering
(Orderer)
Service cервис упорядочивания транзакций принимает на вход
подписанные
транзакции
распространение
транзакций
и
по
обеспечивает
узлам
сети
в
правильном порядке. Orderer не запускает смартконтракты и не содержит цепь блоков и состояние цепи
блоков
Peer
узел сети. Поддерживает свою версию цепи блоков и
состояния цепи блоков, а также обеспечивает среду для
запуска чейнкодов. На уровне ПО узла сети текущее
80
состояние цепи блоков (world state) может хранится в
LevelDB или в CouchDB. Преимуществом CouchDB
является поддержка расширенных запросов (rich query),
использующих синтаксис MongoDB
RAFT
новый механизм консенсуса версии 1.4.1, в соответствии
с
которым
ноды
сами
выбирают
лидера
в
автоматическом режиме
Web-
решение
для
высокоуровневого
взаимодействия
интерфейс
пользователей с сетью (например, отображения данных
документов), использующее API и хранящееся на том же
хосте, что и нода
81
Приложение Б
Бизнес-процесс предметной
области (AS-IS)
82
dPoW
Komodo
83
-
-
+
Создание независимого
блокчейна
Функции
конфиденциальности
Smart-контракт
Язык программирования Solidity
контракта
+
-
DEX
(децентрализованная
биржа)
Создание токенов
+
+
-
-
+
+
+
JavaScript,
Typescript,
Shel, C
LPoS
Waves
UXTO
Ride
CryptoConditio
ns
+
+
+
+
+
+
JavaScript, JavaScript,
C++,
C++, C
Python
PoW
Ethereum
ICO
(предварительная
продажа токенов)
Основные языки
программирования
Консенсус
Характеристика
платформы
C, C++
+
-
-
+
-
+
JavaScript,
Typescript,
Shel, C++
DPoS
EOS
Solidity
+
-
-
+
-
+
JavaScript,
THoskell
PoS
Cardana
PoS
Qtum
PBFT
Hyperledger
Fabric
Java
+
+
-
+
+
+
Solicity
+
-
-
+
-
+
Java, Go
+
+
+
+
+
+
Java, JavaScript,
C
++,
Shell C++,
C, JavaScript,
TypeScript
Python, Java
PoS
Ardor
Приложение В
Блокчейн-платформы
Приложение Г
Архитектура базы данных
проектируемой блокчейнплатформы PROLEUM
84
Отзывы:
Авторизуйтесь, чтобы оставить отзыв