1.1. Описание субтехнологий систем распределенного реестра 1.1.1. Перечень субтехнологий систем распределенного реестра по состоянию на 2019 год Для определения перечня субтехнологий была разработана методология, в рамках которой были определены следующие понятия и принципы: • Понятие «субтехнология» определено как компонент «сквозной» цифровой технологии, благодаря которому возможно выделение продуктов и решений и их отнесение к данной «сквозной» цифровой технологии; • Каждая субтехнология является уникальной компонентой для технологии распределенного реестра; • Субтехнологии не пересекаются и не включают в себя составляющие друг друга; • Субтехнологии не являются отдельными формами применения «сквозной» цифровой технологии. Представленное определение субтехнологии является основополагающим элементом методологии выявления субтехнологий. Этапы выявления субтехнологий систем распределенного реестра: 1. Анализ и интерпретация научных публикаций; 2. Анализ и интерпретация публикаций стандартизирующих органов, ассоциаций, консорциумов; 3. Анализ и интерпретация публикаций аналитических агентств; 4. Анализ и интерпретация статей профессиональных медиаресурсов; 5. Анализ и интерпретация публикаций ведущих разработчиков и коммун разработчиков; 6. Анализ и интерпретация патентного ландшафта технологии; 7. Семантический и сравнительный анализ выявленных классификаций, архитектур и схем; 8. Построение предварительных версий перечня субтехнологий; 9. Согласование предварительных версий и их редактура совместно с экспертами; 10. Формулировка окончательного перечня субтехнологий и согласование с экспертами отрасли. Исходным ресурсом, определяющим субтехнологии систем распределенного реестра, являлся «Атлас «Сквозных» Цифровых Технологий» Государственной корпорации «Росатом». Субтехнологии Атласа включают объекты технологии распределенного реестра, области применения, функции элементов технологической карты. Все эти элементы были определены как равнозначные субтехнологии. Представленный подход не является консистентным, однако, перечень был использован как базис при определении структуры слоёв субтехнологий. Предварительным результатом этапа семантического анализа стала подборка информационных ресурсов, наиболее полно агрегирующих в своей структуре основные подходы к определению составляющих элементов технологии. К их числу относятся: 10 1. Публикация аналитического агентства Forrester «Прагматичная дорожная карта для блокчейна»1; 2. Предварительный проект стандартов «Блокчейн и Технология распределенного реестра» комитета ISO/TC 3072; 3. Доклад Института инженеров электротехники и электроники «Системы распределенного реестра и блокчейн архитектуры»3; 4. Доклад «Клиентская облачная архитектура блокчейн решений» совета по разработке стандартов облачных технологических решений4; 5. Публикация исследования Института инженеров электротехники и электроники «Виртуализация для технологии распределенного реестра»5; 6. Публикация Национального Университета Сингапура «Блокбенч: Фреймворк анализа приватных систем распределенного реестра»6. Представленные источники по-разному определяют структуру технологической карты систем распределенного реестра, однако все они сходятся в определении иерархии функциональной системы технологии. Функциональные слои систем распределенного реестра представляют собой совокупности технологий и функциональных инструментов, используемых для управления и поддержки работоспособности, создания продуктов и решений. Структурный анализ слоёв систем выявил сходства набора инструментов и технологий в представленных ресурсах. Были выявлены паттерны группировки инструментов и технологий в слоях, обусловленные функциональной связью элементов технологической карты. Представителями экспертного сообщества, вовлечёнными в определение субтехнологий, было предложено объединение паттернов соответствующих слоёв в субтехнологии систем распределенного реестра. Для формулировки определений субтехнологий были использованы соответствующие технологические стандарты, включающие определения глобальных консорциумов, определения, представленные в ГОСТ и методические рекомендации отечественных технологических комитетов. Так в соответствии с этими паттернами были определены следующие субтехнологии7: • Технологии организации и синхронизации данных - совокупность методов и инструментов, направленных на определение, организацию и усовершенствование взаимосвязей между частями и элементами распределённых баз данных, а также на обеспечение их согласованности и приведение к соответствию; • Технологии обеспечения целостности и непротиворечивости данных (консенсус) - совокупность методов и инструментов, направленных на приведение в соответствие имеющихся данных в децентрализованной сети к единой внутренней логике и структуре по заранее определённым правилам, включая порядок добавления и валидации новых данных в распределенном реестре, а также обеспечение синхронизации и согласования данных между узлами децентрализованной сети; • Технологии создания и исполнения децентрализованных приложений и смарт- контрактов - совокупность методов и инструментов, направленных на создание приложений, обеспечивающих взаимодействие неограниченного количества участников распределённой системы, и на разработку, поддержание и выполнение 1 «A Pragmatic Road Map For Blockchain», Чарли Дай. https://www.forrester.com/report/A+Pragmatic+Road+Map+For+Blockchain/-/E-RES137094 2 Blockchain and distributed ledger technologies. https://lists.hyperledger.org/g/perf-and-scale-wg/attachment/439/0/ISO-TC307_N0327_TC307_WG1_report.pdf 3 «DLT/Blockchain architectures and Reference Framework», IEEE Global Blockchain Summit https://blockchain.ieee.org/images/files/pdf/20180917-blockchain-architecture-and-reference- frameworks_-_c-lima.pdf 4 «Cloud Customer Architecture for Blockchain», CSCC. https://www.omg.org/cloud/deliverables/CSCC-Cloud-Customer-Architecture-for-Blockchain.pdf 5 «Virtualization for Distributed Ledger Technology Report», IEEE. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8344824 6 «BLOCKBENCH: A Framework for Analyzing Private Blockchains», NSU, IEEE. https://www.comp.nus.edu.sg/~ooibc/blockbench.pdf 7 Все определения были сформулированы оператором Дорожной карты посредством анализа открытых источников и верифицированы с профильными экспертами 11 компьютерных алгоритмов, предназначенных для автоматизации процессов исполнения контрактов или сохраненных в распределенном реестре процедур. Децентрализованные приложения обладают прозрачной и открытой логикой, обеспечивающей гарантированное исполнение заданных функций в рамках систем распределенного реестра; Блокчейн в рамках Дорожной карты рассматривается в качестве одного из типов субтехнологии организации и синхронизации данных, где данные добавляются в последовательность из блоков, причем каждый блок связан с предыдущим таким образом, что изменение данных в одном блоке требует изменения данных во всех предыдущих блоках, а все полные ноды хранят всю историю изменений данных (либо в рамках всей цепи, либо в рамках шарда при использовании технологии шардинга), что существенно повышает защищенность сети. Вследствие наибольшей защищенности и надежности большинство разработчиков систем распределенного реестра используют блокчейн в качестве технологии организации и синхронизации данных систем распределенного реестра. В тоже время существуют альтернативные методы, такие как направленный ациклический граф, где синхронизация информации организована не в формате блоков, а в формате взаимных сообщений между множеством пользователей сети друг другу. Также существуют различные запатентованные субтехнологии организации и синхронизации данных, являющиеся подвидами направленного ациклического графа. Например, компания Radix разрабатывает технологию Tempo, Swirlds Corporation – HashGraph, однако не существует подтверждения гипотез о более высокой эффективности данных проприетарных технологий. Защищенность от захвата сети и проблемы двойной траты подобных сетей на данный момент не подтверждены. Большинство разработчиков фокусируются на увеличении пропускной способности технологии блокчейн, чем ациклического направленного графа, в связи с более низким уровнем разработанности последнего. В части технологии обеспечения целостности и непротиворечивости данных существуют различные консенсус алгоритмы, которые отличаются между собой как в части используемых математических алгоритмов, обеспечивающих целостность сети распределенного реестра, так и в части типа ресурсов, необходимых для валидации блоков, энергозатрат, требуемых для подтверждения транзакций, и уровня защиты от захвата данных ресурсов. Разработчики систем распределенного реестра экспериментируют с алгоритмами консенсуса, создавая новые. На сегодняшний момент не существует одного идеального алгоритма. Для различных целей используются различные консенсус алгоритмы – в зависимости от потребности в уровне децентрализации, защиты от захвата сети, энергоэффективности и пропускной способности для каждой сети подбирается определенный алгоритм консенсуса. Также существуют системы распределенного реестра с настраиваемым алгоритмом консенсуса. Распространенные на текущий момент алгоритмы консенсуса: • Proof of Work (PoW) - алгоритм достижения консенсуса, в котором вероятность получения права валидации блока зависит от доли вычислительных мощностей сети, принадлежащих ноде; • Proof of Stake (PoS) - алгоритм достижения консенсуса, в котором вероятность получения права валидации блока зависит от доли ресурсов (токенов) сети, принадлежащих ноде; 12 • Proof of Authority (PoA) - алгоритм достижения консенсуса, в котором право валидации блоков предоставлено определенным одобренным аккаунтам – валидаторам; • Practical Byzantine Fault Tolerance (PBFT) – консенсус алгоритм без лидера сети, валидирующего транзакции; каждая нода может обращаться к любой другой ноде сети. В рамках алгоритма предварительно выбранные «доверенные» ноды поддерживают целостность сети; • Paxos/RAFT – консенсус алгоритм, где ноды сети выбирают одного лидера, отвечающего за валидацию транзакций; • Leased/Delegated Proof-of-Stake (LPoS/DPoS) - алгоритм консенсуса, предусматривающий возможность добавления блоков только для держателей определенного количества токенов сети, которые можно передавать другим нодам сети в лизинг или голосовать за определенных валидаторов в соответствии с долей токенов сети, принадлежащих определенной ноде; • Limited Confidence Proof-of-Activity (LCPoA) - модификация алгоритма Proof of Work в части уменьшения расхода вычислительных ресурсов, требуемых для подбора хеша блока, но в качестве дополнительного значения nonce используется текущая метка времени. Технологии синхронизации и организации данных отвечают за организацию распределенных нод в единую сеть с согласованной базой данных. Технологии обеспечения целостности и непротиворечивости данных обеспечивают неизменность и единство данных сети, защищая ее от неавторизованных изменений истории данных и формируя доверительные отношения между участниками сети. Технологии создания и исполнения децентрализованных приложений и смарт-контрактов расширяют функционал систем распределенного реестра и позволяют цифровизировать процессы за счет использования смарт-контрактов в доверенной среде. Вышеуказанные субтехнологии представляют собой совокупность методов и инструментов, формирующих технологию распределенного реестра и обеспечивающих ее функциональность. Они являются уникальными и не пересекаются, но при этом являются неотъемлемой составляющей технологии распределенного реестра. Представленная категоризация не формирует отдельных продуктовых решений, ввиду своей неотъемлемости от технологии, в связи с чем альтернативный подход, разделяющий технологию на приватные, публичные и гибридные системы, является более целесообразным. Продуктовая категоризация по типам систем распределенного реестра позволит провести более детальную оценку технологии с точки зрения уровня ее развития и анализа существующих продуктовых решений. В результате данного решения вводится три дополнительных понятия: публичная система распределённого реестра, приватная система распределённого реестра и гибридная система распределенного реестра, характеризующие все возможные имплементации систем распределенного реестра8. • Публичная система распределённого реестра — открытые сети, допуск к участию в которых не ограничен для широкого круга пользователей, статус оператора не закреплен за определенными участниками, а также отсутствуют централизованные 8 Доклад для Общественных организаций, «Развитие технологии распределенных реестров», декабрь 2017, Москва https://www.cbr.ru/Content/Document/File/50678/Consultation_Paper_171229(2).pdf 13 инстанции, управляющие правилами сети, ее конфигурацией и выпуском криптографических ключей; • Приватная система распределённого реестра — закрытые сети, в которых устанавливаются критерии членства, в соответствии с которыми участники допускаются к управлению узлами и получают доступ к сервисам сети; • Гибридная система распределенного реестра — сети сочетают в себе свойства как открытых, так и закрытых сетей. Консорциумные системы распределенного реестра рассматриваются как подвид приватных, так как применяются только в рамках приватных систем распределенного реестра, однако управление данными системами осуществляется консорциумом, состоящим из множества организаций. В связи с тем, что в рамках Дорожной карты используются понятия как решений в разрезе субтехнологий, так и продуктовых решений по типам систем распределенного реестра необходимо уточнить данные понятия. Под решениями в разрезе субтехнологий понимаются отдельные технические имплементации выявленных субтехнологий, например, Proof of Stake алгоритм консенсуса. Под продуктовыми решения в разрезе типов систем распределенного реестра рассматриваются отдельные продуктовые имплементации технологии, например, публичная система распределенного реестра Ethereum, данные продуктовые решения включают в себя технические имплементации выявленных субтехнологий, которые, в свою очередь, по отдельности не формируют продуктовых решений. Благодаря использованию технологии распределенного реестра, данные приобретают новые свойства – становятся достоверными и неизменными, так как, помещая данные в систему распределенного реестра, любой участник может отследить все изменения, которые были произведены, и ни один участник не может изменить историю изменений. Рассмотренные свойства данных были определены содержанием методических рекомендаций технического комитета 26 за номером МР 26.4.001-2018, который на текущий момент является единственным принятым документом на уровне технического комитета, определяющим ключевые понятия в области технологии распределенного реестра: • Система с реестром с ограничениями на добавление информации — система, в которой только некоторые пользователи могут быть пользователями- регистраторами. Возможно реализовать в приватных системах распределенного реестра, а также в публичных, работающих на базе консенсус алгоритма Proof Of Authority (PoA); • Система с реестром конфиденциальная — система, в которой обеспечивается конфиденциальность внесенной в реестр информации. Возможно реализовать как в публичных, так и приватных системах; • Система с реестром с ограничениями на просмотр — система, использующая реестр, в котором не все пользователи являются пользователями-наблюдателями. Возможно реализовать только в приватных системах; • Система с реестром совместная — система, использующая реестр, в котором все пользователи могут быть пользователями-регистраторами. Возможно реализовать только в рамках публичных систем распределенного реестра; 14 • Система с реестром анонимная (псевдонимная) — система, использующая реестр, в котором обеспечена анонимность (псевдонимность) пользователей. Возможно реализовать только в публичных системах; • Система с реестром иерархическая — система, использующая реестр, в которой обеспечена иерархия пользователей информационной системы (ИС). Возможно реализовать только в рамках приватных систем распределенного реестра. 1.1.2. Уровень готовности субтехнологий На базе анализа патентов в области технологии распределенного реестра в Российской Федерации, открытых источников, например, «Атласа «сквозных» цифровых технологий России», а также консультаций с экспертами в отрасли технологии распределенного реестра была произведена оценка уровня готовности субтехнологий. Также была произведена корректировка в связи с последними обновлениями дорожных карт развития отечественных решений на базе технологии распределенного реестра, а также в соответствии с «белыми книгами» по технологии распределенного реестра. Таблица 1. Уровень готовности субтехнологий в соответствии с ГОСТ Р 57194.1-2016 Субтехнологии Уровень Комментарий готовности технологии (УГТ9) Технологии организации 7 Прототипы отражают планируемую штатную и синхронизации систему или близки к ней данных Технологии обеспечения 8 Технология проверена на работоспособность и целостности и может быть использована в ожидаемых непротиворечивости условиях эксплуатации при незначительных данных доработках Технологии создания и 6 Доказаны реализуемость и эффективность исполнения технологий в реальных или близких к децентрализованных реальным условиях и возможность интеграции приложений и смарт- технологии в административные и бизнес- контрактов процессы, для которых данная технология должна продемонстрировать работоспособность. Однако, переход технологии на следующий уровень требует реализации большего количества пилотов, тестирования как в лабораторных, так и в реальных условиях Ввиду того, что субтехнологии по отдельности не формируют продуктовые решения, в рассматриваемых далее примерах основных существующих отечественных и зарубежных продуктов отражено использование решений на основе каждой субтехнологии. 9 В соответствии с ГОСТ Р 57194.1-2016 15 Таблица 2. Основные решения и продукты на базе технологий организации и синхронизации данных Решение Описание УГТ10 Зарубежные Отечественные продукты продукты Блокчейн Данные добавляются в последовательность из 7 Corda; Waves Platform; блоков, где каждый блок связан с предыдущим таким образом, что изменение данных в одном Ethereum; IZZIO BigNet; блоке требует изменения данных во всех Ripple Vostok Platform предыдущих Направленный Синхронизация информации, организованная не в 4 IoTA; Н/Д ациклический граф формате блоков, а в формате взаимных сообщений между множеством пользователей сети друг другу Byteball Хашграф Гарантированная асинхронная толерантность к 3 Hedera; Н/Д необъяснимым ошибкам, консенсус достигается с вероятностью единица HashGraph Таблица 3. Основные решения и продукты на базе технологий обеспечения целостности и непротиворечивости данных (консенсус) Решение Описание УГТ Зарубежные Отечественные продукты продукты Proof of Work Алгоритм достижения консенсуса, в котором 7 Ethereum; Acryl Platform; вероятность получения права валидации блока зависит от доли вычислительных мощностей сети, Beam Ergo Platform принадлежащих ноде Proof of Stake Алгоритм достижения консенсуса, в котором 6 Cardano; Waves Platform; вероятность получения права валидации блока Ontology; Vostok Platform 10 В соответствии с ГОСТ Р 57194.1-2016 16 Решение Описание УГТ Зарубежные Отечественные продукты продукты зависит от доли ресурсов (токенов) сети, Decred принадлежащих ноде Practical Byzantine Консенсус алгоритм без лидера сети, 8 HyperLedger Exonum Fault Tolerance валидирующего транзакции, каждая нода может Fabric; обращаться к любой другой ноде сети, алгоритм требует валидации как сообщений, так и Zilliqa неизменность и надежность сообщения Proof of Authority Алгоритм достижения консенсуса, в котором право 7 POA Network; Н/Д удостоверения блока проверяется посредством одобренных аккаунтов (валидатору) Tomochain Таблица 4. Основные решения и продукты на базе технологий создания и исполнения децентрализованных приложений и смарт- контрактов Решение Описание УГТ Зарубежные Отечественные продукты продукты Отраслевые решения Доработанные платформы распределенного реестра, 6 TradeLens; «Мастерчейн»; созданные для внедрения в определенные области применения IPChain Децентрализованные Приложения, исполняемые в одноранговой сети, 6 Geon; Button Wallet; приложения состоящей из множества серверов Matic Network Tradingene Смарт-контракты Самоисполняемый в доверительной среде 6 Data Gumbo; NaumovLab; (созданной с использованием технологии блокчейн) контракт, заключенный напрямую между Coinfabrik Digital Forest 17 Решение Описание УГТ Зарубежные Отечественные продукты продукты покупателем и продавцом и записанный в качестве программного кода 18 Также целесообразно рассмотреть уровень готовности технологии и интегрирования по типам систем распределенного реестра. Уровень готовности приватных систем распределенного реестра в соответствии с ГОСТ Р 57194.1-2016 — УГТ 9, то есть была продемонстрирована работа реальной системы в условиях реальной эксплуатации; приватные системы распределенного реестра готовы к промышленной эксплуатации. Данная оценка обусловлена тем, что приватные системы распределенного реестра готовы к внедрению в отрасли экономики в промышленном масштабе как в мире, так и в России. В соответствии с видением рынка и мнением профильных экспертов уровень развития технологии и уровень готовности платформ на основе систем распределённого реестра достаточно высоки, однако для интегрирования решений в бизнес-процессы требуются точечные разработки децентрализованных приложений и смарт-контрактов, создаваемые на основе платформ под определённые задачи заказчика. Разница между показателями уровня готовности системы и уровнем готовности интеграции системы в бизнес-процессы достаточно высока. В результате целевой эффект от проведения мероприятий Дорожной карты лучше прослеживается не в части показателей готовности технологии, а в части готовности систем к интеграции. Таким образом, было определено текущее состояние уровня готовности интеграции типов систем распределенного реестра относительно приоритетных областей применения публичных и приватных платформ. Принимая во внимание реализацию мероприятий, предусмотренных в рамках данной Дорожной карты, был составлен прогноз развития технологии и увеличения уровня готовности интеграции систем. Уровень готовности интеграции приватных систем распределенного реестра в соответствии с ГОСТ Р 57194.1-2016 — УГИ 3, то есть определены процессы эффективного взаимодействия технологии и существующих ИТ-архитектур. Существуют примеры промышленного внедрения технологии, например, в рамках решения по переводу факторинговых операций на технологии распределенного реестра. Данное решение поддерживается консорциумом, созданным в 201711 году, лидер которого - Группа «М.Видео-Эльдорадо», другие участники - АО «Альфа-Банк», ПАО «Сбербанк», ПАО «МДМ Банк», ПАО Банк «ФК Открытие». Решение представляет собой открытую блокчейн-платформу для факторинговых операций, которая делает возможным подключение неограниченного числа банков и факторинговых компаний с сохранением конфиденциальности информации о сделках. Существуют примеры внедрения технологии на иностранном рынке, такие как TradeLens12 (на базе Hyperledger) – отраслевое решение, которое используется больше, чем 100 различными портами и транспортными компаниями в процессах трансграничных морских перевозок, Corda13 – универсальная система распределенного реестра с открытым исходным кодом, сфокусированная на финансовом секторе. Уровень готовности публичных систем распределенного реестра – УГТ 7, то есть прототип системы прошел демонстрацию в эксплуатационных условиях; прототип отражает планируемую штатную систему или близок к ней. На этой стадии компаниями рассматривается вопрос о возможности применения целостной технологии на объекте и 11 М.Видео, Сбербанк Факторинг и Альфа-Банк созадил первый в России коммерческий блокчейн-консорциум – https://alfabank.ru/press/news/2017/10/13/41066.html 12 Цифровизация глобальной цепи поставок – https://www.tradelens.com 13 Официальный сайт Corda – https://www.corda.net 19 целесообразности запуска объекта в серийное производство. Публичные системы распределенного реестра уже готовы для разработки и использования децентрализованных приложений и смарт-контрактов. Однако, ни одна публичная система распределенного реестра не готова к промышленному использованию по причине низких показателей пропускной способности и конфиденциальности транзакций, в связи с чем на текущий момент они преимущественно используются для обмена цифровыми активами. Уровень готовности интеграции публичных систем распределенного реестра в соответствии с ГОСТ Р 57194.1-2016 — УГИ 2, то есть определены основные интерфейсы взаимодействия технологии и существующих ИТ-архитектур и процессов на уровне определения концепции. Таблица 5. Уровень готовности типов систем в соответствии с ГОСТ Р 57194.1-2016 Типы УГТ УГИ14 Примеры отечественных Примеры зарубежных систем вендоров вендоров Приватные 9 3 Vostok – продукт Vostok Linux - продукт Platform; Hyperledger; Bitfury – продукт Exonum; R3 - продукт Corda; IZZZIO – продукт IZZZIO Ripple - продукты Xcurrent, Xrapid, Xvia Публичные 7 2 Waves - продукт Waves Ethereum Foundation – Platform; продукт Ethereum; IZZZIO - продукт IZZZIO NEO Foundation - продукт BigNet; NEO; Acryl - продукт Acryl VeChain - продукт VeChain Platform Продукты на базе систем распределенного реестра можно разделить на платформы, которые включают в себя все ключевые компоненты технологической карты технологии распределенного реестра, а также отраслевые решения, созданные на базе данных платформ. Отраслевые решения являются доработками платформ распределенного реестра, созданными для внедрения в определенные области применения. В связи с тем, что для установления доверительных отношений в цифровой среде требуется, чтобы каждый участник сети мог провести аудит исходного кода системы распределенного реестра, наиболее развитые платформы распределенного реестра распространяются по модели открытого исходного кода. Однако разработчики отраслевых решений, как правило, не раскрывают исходный код и продают как услуги по интеграции, так и сами решения. Отраслевые решения зависят от технических характеристик платформы, на базе которой они построены, так как являются доработкой отдельных элементов и не представляют полностью новую сущность. В связи с этим оценка уровня готовности технологии отраслевых решений не является целесообразной. Примером российского отраслевого решения является «Мастерчейн15», построенная на базе публичной системы 14 В соответствии с ГОСТ Р 57194.1-2016 15 Белая книга «Мастерчейн» - http://fintechru.org/documents/Masterchain_whitepaper_11_08.pdf 20 распределенного реестра Ethereum, открытый код которой был доработан для применения в финансовом секторе Российской Федерации. Таблица 6. Уровень готовности российских решений Тип Решение УГТ Описание системы Публичные Waves 7 Мейннет запущен и используется для запуска смарт- контрактов и токенизации реальных активов, идет доработка отдельных модулей платформы, а также инструментов повышения пропускной способности сети16 IZZZIO 6 Платформа распределенного реестра IZZZIO, BigNet включает в себя инфраструктуру и инструменты для создания смарт-контрактов и децентрализованных бизнес-решений. Мейннет запущен, реализован конструктор смарт-контрактов и идет доработка инфраструктуры системы17 Acryl 5 Данная система является форком российской platform платформы распределенного реестра Waves и платформы NXT. Мейннет запущен, отсутствует применение платформы за пределами «майнинга»18 Приватные Exonum 9 Мейннет запущен и используется в промышленном масштабе как в Российской Федерации, так и в других странах, например, для ведения земельного кадастра Грузии19 Vostok 8 Построено на базе публичной платформы распределённого реестра Waves. Система разработана, идет активное пилотирование в различных областях применения и проверка технических и экономических гипотез в условиях приближенных к реальным20. Уже в 2019 году начнется пилотирование системы в Нижнем Новгороде, Правительство которого будет использовать платформу компании Vostok для распределения городского бюджета и проведения голосования среди населения в части определения направления расходования бюджетных средств21. IZZZIO 8 Платформа готова к использованию и пилотированию. На базе платформы уже реализован 16 Официальный сайт Waves - https://wavesplatform.com/ 17 Официальный сайт IZZZIO BigNet - https://bignet.izzz.io/ 18 Официальный сайт Acryl platform - https://acrylplatform.com/ 19 Официальный сайт Exonum - https://exonum.com/ru/ 20 Официальный сайт Vostok - https://vostok.io/ 21 Официальный сайт ТАСС: https://tass.ru/nacionalnye-proekty/6359487 21 Тип Решение УГТ Описание системы ряд проектов, в том числе приватные сети для крупных компаний (например, PwC), а также, сети с контролем доступа (например, запущена система хранения документов22) Приватные системы распределенного реестра отечественных производителей не отстают с точки зрения технологической готовности от зарубежных. Все ключевые модули и функции, необходимые для использования продуктов, готовы к промышленной эксплуатации на уровне с западными решениями. Отставание отечественных публичных систем распределенного реестра заключается в преобладании неполных по Тьюрингу публичных систем распределенного реестра, которые необходимы для создания полноценных децентрализованных приложений. 22 Официальный сайт IZZZIO - https://izzz.io/ru/ 22 1.1.3. Анализ мирового опыта разработки решений на базе технологии «Системы распределенного реестра» - ключевые этапы и инструменты создания и реализации решений и проектов С целью выявления ключевых шагов для создания лидирующих систем распределенного реестра рассмотрены ключевые особенности и этапы создания международных систем распределенного реестра. Разработка решений на базе технологии распределенного реестра отличается от разработки традиционного ПО более длительным сроком пилотирования тестовой системы (тестнет) перед релизом финального решения (мейннет) в связи с тем, что для внесения изменений в инфраструктурную часть мейннета необходимо согласие большинства участников сети и осуществление разделения сети (хардфорка). Данная особенность в большей степени характерна для публичных систем, в работе которых требуется согласованность более широкого числа стейкхолдеров по сравнению с приватными сетями. Также этапы разработки отличаются в зависимости от объекта. Разработка платформы и приложения/отраслевых решений отличаются с точки зрения ключевых этапов. Платформа – универсальная система распределенного реестра, на базе которой возможно создание различных умных контрактов и децентрализованных приложений, представляющих собой набор программ, расширяющих функционал платформ для конкретных целей и предоставляющих пользовательский интерфейс. 23 Таблица 7. Этапы и инструменты создания решений Тип продукта Описание этапа Описание инструментов Платформа Определение потребностей, которые платформа будет Анализ открытого кода других решений; удовлетворять, определение целевой аудитории. Планирование Опрос потенциальных потребителей; технической архитектуры, функционала и планирование гипотез эффективности решения, формирование бизнес-плана и Привлечение технических и бизнес-консультантов экономической модели, определение модели распространения программного кода. Сравнительный анализ с конкурентами Разработка критических компонентов, документации, Готовые инструменты разработки и развертывания развертывание тестнета и публикация кода программного обеспечения (ПО) в облачной среде Разработка пользовательских интерфейсов, браузера для Анализ открытого кода других решений; мониторинга загрузки сети, API и других инструментов Анализ наиболее востребованных решений и интеграции с внешними системами, разработки смарт- инструментов контрактов и децентрализованных приложений, первичное наполнение экосистемы приложений Закрытое пилотирование сети в тестовой среде, валидация Инструменты развертывания платформы в возможности достижения запланированных операционных облачной среде исполнения показателей, доработка программного кода, внесение изменений в транспортный слой платформы Аудит безопасности Привлечение специализированных на информационной безопасности консалтинговых компаний; Проведение массовых программ поиска неисправностей и ошибок в коде за вознаграждение (bug bounty program) 24 Тип продукта Описание этапа Описание инструментов Открытое пилотирование тестнета на реальных транзакциях, Привлечение потенциальных заказчиков к валидация экономических показателей, доработка программного пилотированию, использование данных и кода всех архитектурных слоев, расширение экосистемы вычислительных мощностей заказчиков для приложений пилотирования; Стимулирование разработчиков к созданию децентрализованных приложений, обучение разработчиков созданию приложений на платформе Запуск мейннета, генерация первоначального блока (genesis Поддержка запуска путем использования нод block) разработчика для валидации транзакций, в случае если были выпущены временные токены на базе другой платформы – обмен данных токенов на токены платформы Приложение Определение потребностей целевой аудитории, которые Исследование рынка; приложение будет решать. Определение технических Опрос потребителей; требований к платформе, на базе которой будет разработано приложение. Формулирование требований к документации и Сравнительный анализ платформ наличию инструментов разработки. Прототипирование пользовательского интерфейса, определение экономической модели и бизнес-плана Пилотирование различных платформ и выбор платформы в Тестнет различных платформ соответствии с требуемыми техническими характеристиками Разработка функционала приложения Инструменты разработки приложений и смарт- контрактов платформ 25 Тип продукта Описание этапа Описание инструментов Пилотирование приложения в тестнете, доработка функционала, Исполнение кода в виртуальной машине, среда исправление критических уязвимостей исполнения Аудит безопасности Привлечение специализированных на информационной безопасности консалтинговых компаний; Проведение массовых программ поиска неисправностей и ошибок в коде за вознаграждение (bug bounty program); Использование автоматизированных инструментов аудита безопасности децентрализованных приложений и смарт-контрактов Разработка API и пользовательского интерфейса Инструменты разработки платформы 26 1.1.4. Критерии успешности развития систем распределенного реестра В связи с тем, что приватные и публичные системы распределенного реестра находятся на различных стадиях готовности и сфокусированы на различных областях применения и рынках, данные два типа систем распределенного реестра обладают различными критериями успешности развития, которые делятся на два основных типа: 1. Технологические – направлены на оценку успешности технической реализации решения; 2. Экономические – направлены на оценку уровня используемости решений. Критерии позволяют комплексно оценить уровень успешности развития приватных систем распределенного реестра как с точки зрения их используемости и ценности для экономики, так и технических характеристик. Приватные системы распределенного реестра позволяют установить доверительные отношения в цифровой среде между установленными и авторизованными участниками, в связи с чем преимущественно используются в B2B- и B2G-сегментах, где есть потребность в доверительных отношениях между установленными нодами. Данный тип систем готов к промышленной эксплуатации, ввиду чего основным критерием успешности развития приватных систем распределенного реестра является количество компаний, использующих различные отраслевые решения на базе данных систем и участвующих в их доработке в рамках функционирования консорциума. Другим важным показателем является количество областей применения, где используются приватные системы распределенного реестра. Данные два показателя должны приводить к формированию дополнительной экономической ценности, выраженной в виде дополнительной выручки и экономии, полученной за счет внедрения решений на базе технологии. Объем экономической ценности является важным показателем успешности развития приватных систем распределенного реестра. Помимо критериев, связанных с внедрением технологии, необходимо также отметить технические критерии успешности приватных систем распределенного реестра: количество поддерживаемых традиционных языков программирования, количество полностью интероперабельных платформ, возможность создания смарт-контрактов на естественном языке, срок и стоимость развертывания и интеграции системы распределенного реестра, наличие сопроводительной технической документации и количество описанных протоколов обращения к внешним данным. Публичные системы распределенного реестра позволяют устанавливать доверительные отношения между неограниченным кругом лиц, так как любое юридическое или физическое лицо обладает правами просмотра, добавления, верификации и валидации данных в систему распределенного реестра. Данный вид систем используется преимущественно в B2C-сегменте, где требуется установление доверительных отношений между большим количеством участников сети. На текущий момент публичные системы распределенного реестра не могут быть использованы в промышленном масштабе из-за «трилеммы» технологии данного типа, в соответствии с которой система не может быть одновременно децентрализованной с точки зрения количества валидирующих нод, безопасной с точки зрения защиты от захвата и быстрой с точки зрения количества обрабатываемых транзакций в секунду. Повышая один из параметров, автоматически 27 ухудшаются два других. Данные три технических критерия успешности публичных систем распределенного реестра являются ключевыми. Дополнительно важными критериями успешности публичных систем являются: ежедневное количество пользователей децентрализованных приложений, количество активных пользовательских адресов, количество транзакций, записываемых в систему в день, количество разработанных децентрализованных приложений, количество исполняемых ежедневно смарт-контрактов. Данные критерии позволяют оценить уровень используемости публичных систем распределенного реестра среди пользователей и разработчиков, что является ключевым при оценке успешности данных решений. Ключевые экономические показатели эффективности отличаются в зависимости от типа распределенной системы, публичная или приватная. Так приватные системы используются преимущественно в B2B-сегменте и нацелены на оптимизацию операционной эффективности в части сокращения затрат в массовых процессах, например, где до сих пор требуется механическая сверка при осуществлении взаиморасчетов, как в случае с межбанковскими транзакциями. Также приватные системы распределенного реестра направлены на достижение дополнительной выручки за счет выхода на новые рынки, обслуживание нового сегмента клиентов за счет сокращения издержек и возможности сокращения стоимости услуги для конечных потребителей. На данный момент возможности систем распределенного реестра в части формирования новых источников прибыли не доказаны на практике. С точки зрения экономической эффективности публичные системы распределенного реестра могут сравниваться по средней стоимости осуществления транзакции и развертывания смарт-контракта, но необходимо учитывать, что чем ниже комиссия, тем ниже уровень безопасности (так как меньший объем вычислительных средств требуется для подтверждения транзакций), а так же повышается централизация (меньшее количество нод участвует в подтверждении транзакций, что приводит к необходимости доверия данным нодам, а не только математическим и криптографическим алгоритмам, формирующим консенсус и устанавливающим доверительные отношения в цифровой среде) системы. Стоимость, как правило, привязана к внутренней валюте (токену) открытой платформы, которая ежедневно меняется в соответствии с курсом на бирже. Для оценки стоимости в долларах США используется средний курс23 внутреннего токена за последние 90 дней от 15.04.2019. 1.1.5. Бенчмарки, включая анализ мирового опыта (описание лучших практик) С целью определения уровня развития мировых лидеров публичных и приватных систем распределенного реестра приведены примеры наиболее развитых решений, подтверждающих уровень развития, включая осуществленные инвестиции в реализацию (или их оценку). 23 Источник курса: Официальный сайт BitInfoCharts - bitinfocharts.com) 28 Таблица 8. Наиболее развитые системы распределенного реестра, подтверждающие уровень готовности технологии Тип системы Решение УГТ Инвестиции24 Критерий Оценка по критерию экономической эффективности Приватные Ripple 9 96.4 Потенциальная От 3.5 долл. США за каждую транзакцию (может млн долл. экономия быть больше в зависимости от объема транзакций США банка). Потенциальная экономия может достигать до 60% от расходов на урегулирование и клиринг транзакций25 Дополнительная Количественная оценка отсутствует, однако за выручка счет более низкой себестоимости транзакций банки получают возможность обслуживания потребителей с низким уровнем дохода, изначально не вовлечённых в банковскую систему (unbanked)26 TradeLens 9 Н/Д Потенциальная До 10% от административных расходов при (на базе экономия морских перевозках за счет автоматизации Hyperledger) механических операций и повышения скорости передачи и валидации транспортных документов27 Дополнительная Количественная оценка отсутствует, однако за выручка счет сокращения времени на передачу и валидацию транспортных документов возможно сокращение времени перевозки и, как следствие, 24 Официальный сайт Crunchbase - https://www.crunchbase.com/ 25 Официальный сайт Ripple - https://ripple.com/ 26 Сравнительный анализ Ethereum, HyperLedgar Fabric and Corda. Франкфуртская Школа. Блокчейн Центр - http://explore-ip.com/2017_Comparison-of-Ethereum-Hyperledger-Corda.pdf 27 Lars_Mikkelgaard-Jensen, TradeLens overview, 2018 - http://bss.au.dk/fileadmin/BSS/Alumner/Digital_2018/Slides_fra_digital_2018/Lars_Mikkelgaard-Jensen.pdf 29 Тип системы Решение УГТ Инвестиции24 Критерий Оценка по критерию экономической эффективности рост количества выполняемых парком судов перевозок Corda 9 112 Потенциальная До 50% расходов на комплаенс при млн долл. экономия осуществлении сделок торгового США финансирования за счет обмена и валидации данных в цифровой среде28 Дополнительная Монетизация данных, предоставляемых в выручка реальном времени, а также привлечение новых клиентов за счет элиминации посредников из цепочки создания ценности Публичные Ethereum 8 18.4 Средняя стоимость 0.113 долл. США млн долл. транзакции за 90 США дней29 Стоимость 0.3 ETH или 40 долл. США развертывания (по среднему курсу 134 долл. США за 1 ETH) контракта30 NEO 8 Стоимость 0 долл. США транзакции31 28 Официальный сайт Corda: https://www.corda.net/ 29 5 лучших Блокчейн платформ для внедрения и что их делает лучшими. https://medium.com/swishlabs/the-5-best-blockchain-platforms-for-enterprises-and-what-makes-them-a-good-fit-1b44a9be59d4 30 Официальный сайт bitinfocharts.com: https://bitinfocharts.com/ 31 Официальный сайт bitinfocharts.com: https://bitinfocharts.com/ 30 Тип системы Решение УГТ Инвестиции24 Критерий Оценка по критерию экономической эффективности 5.1 Стоимость 100 Gas или 253 долл. США млн долл. развертывания США контракта 32 EOS 8 4 000 Стоимость 0 долл. США млн долл. транзакции 33 США Стоимость 120 EOS или 422 долл. США развертывания контракта34 Для развертывания контракта необходимо приобрести внутреннюю валюту платформы на 422 долл. США для резервирования 1 Мб оперативной памяти платформы, однако данные токены можно продать после завершения исполнения процедур по смарт-контракту Итоговый перечень международных бенчмарков состоит из: Ripple (США), TradeLens (США), Corda (США), Ethereum (Швейцария), NEO (Китай), EOS (Южная Корея). 32 Официальный сайт bitinfocharts.com: https://bitinfocharts.com/ 33 Официальный сайт bitinfocharts.com: https://bitinfocharts.com/ 34 Сравнение Ethereum и EOS, NEO, ADA - https://medium.com/alethena/eth-vs-eos-neo-ada-75acf52f6344 31 1.1.6. Технологическая архитектура систем распределенного реестра С целью определения ключевых компонентов технологии распределенного реестра и фокусов развития в рамках Дорожной карты необходимо описать архитектуру технологии распределенного реестра. Архитектура систем распределенного реестра состоит из модулей программного кода, которые не являются отдельными продуктовыми решениями, но в совокупности формируют платформы распределенного реестра. Публичные и приватные системы распределенного реестра отличаются между собой в части отдельных технологических компонент, однако не отличаются на уровне элементов инфраструктуры и слоев (за исключением модуля управления правами доступа и ролями, который используется только в приватных системах распределенного реестра). Для описания архитектуры использовалась сетевая модель OSI, в соответствии с которой были выделены три слоя: транспортный, представления, приложений. Рисунок 1 — Упрощенная архитектура технологии «Системы распределенного реестра»35 Слои и элементы архитектуры систем распределенного реестра можно описать следующим образом: I. Транспортный: • Консенсус - включает в себя инструменты и протоколы, обеспечивающие неизменность и достоверность данных; • Исполнение транзакций - определяет структуру данных, модель транзакций и обеспечивает их распределенное хранение; • Безопасность и приватность - включает в себя инструменты и протоколы шифрования и обеспечения приватности данных. 35 Онтология технологии Блокчейн. Принципы идентификации и классификации. Университетский Колледж Лондона: https://allquantor.at/blockchainbib/pdf/tasca2017ontology.pdf 32 II. Представления: • Кодовая база платформы - включает в себя архитектуру программного обеспечения и используемый язык программирования; • Функциональность платформы - включает инструменты и протоколы интеграции с другими системами распределенного реестра и внешними источниками данных, а также поддержку инструментов сценарного программирования; • Токенизация - включает инструменты выпуска цифровых активов; • Механизмы увеличения пропускной способности - включают различные методы увеличения пропускной способности за счет параллельного добавления транзакций в основную сеть, выполнения части транзакций вне основной сети и другие подходы в части увеличения пропускной способности; • Исполнение скриптов - определяет процессы выполнения смарт-контрактов в вычислительной среде; • Механизмы стимулирования заданного поведения участников сети - включают структуру поощрения различных участников системы к заданному поведению; • Управление правами доступа и ролями - включает инструменты авторизации и аутентификации пользователей, а также определения прав доступа (неприменимо для публичной сети распределенного реестра). III. Слой приложений • Интеграция - определяет механизмы использования данных, находящихся вне сети, для исполнения смарт-контрактов, взаимодействия и обеспечения возможности обмена данными и цифровыми активами между различными платформами; • Создание приложений и смарт-контрактов - включает в себя инструменты разработки, тестирования и интеграции приложений, создаваемых на базе платформы; • Функционирование - включает инструменты мониторинга загрузки и состояния платформы, интерфейсы для отслеживания транзакций, аналитические модули процессов выполнения смарт-контрактов; • Приложения безопасности - включает инструменты обеспечения защиты сети от DDoS-атак, минимизации критических уязвимостей в смарт-контрактах, резервное копирование и восстановление сети. 1.1.7. Ключевые технические характеристики технологии распределенного реестра Технические характеристики необходимы для проведения сравнительного анализа различных систем распределенного реестра, определения решений, отвечающих ключевым запросам приоритетных отраслей, а также формирования целевых показателей развития технологии. Большая часть существующих стандартов в области технологии распределенного реестра направлена на стандартизацию различных субъектов технологии, ввиду чего определение технических характеристик не является целесообразным. Однако, данные стандарты закладывают единое понятийное поле в области технологии распределенного реестра. 33 Таблица 9. Стандарты в области технологии распределенного реестра, использованные в Дорожной карте № Наименование Описание 1 ГОСТ 28147-89 Российский стандарт симметричного блочного шифрования 2 ГОСТ Р 34.10-2012 Российский стандарт, описывающий алгоритмы формирования и проверки электронной цифровой подписи 3 МР 26.4.001-2018 Термины и определения в области технологий цепной записи данных (блокчейн) и распределенных реестров 4 ГОСТ Р 55681-2013 / Информация и документация. Анализ процессов работы с ISO/TR 26122:2008 точки зрения управления документами 5 ГОСТ Р ИСО ТО Финансовые услуги. Рекомендации по информационной 13569-2007 безопасности 6 ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными 7 ГОСТ Р 34.11-2012 Информационная технология. Криптографическая защита информации. Функция хеширования Для каждой субтехнологии определен перечень технических характеристик, по которым возможно сравнение различных решений на базе технологии распределенного реестра. Для каждой технической характеристики определен индикатор, оценивающий состояние технической характеристики. Таблица 10. Список технических характеристик для субтехнологий технологии распределенного реестра Субтехнология Техническая Индикатор Текущий характеристика мейннета описания показатель Технологии Возможность создания Есть/Нет Зависит от организации и публичной распределенной конкретного синхронизации сети решения данных Возможность создания Есть/Нет Зависит от централизованной конкретного приватной (с ограниченным решения числом участников) распределенной сети Конфиденциальность Есть/Нет Зависит от (возможность ограничения конкретного доступа к части решения информации) Возможность использования Есть/Нет Зависит от криптографии по ГОСТ и конкретного УКЭП решения Средний размер блока МБ 0.213 Среднее время, необходимое Минут 8.2 для подтверждения блоков 34 Субтехнология Техническая Индикатор Текущий характеристика мейннета описания показатель Технологии Пропускная способность / Число транзакций в 1-15 обеспечения количество транзакций в секунду тыс./сек целостности и секунду непротиворечивости Безопасность / доля Доля в процентах 33-51% данных (консенсус) вычислительных мощностей сети или нод, которые необходимо скомпрометировать, чтобы захватить сеть Децентрализация / Количество Зависит от количество нод, конкретного участвующих в консенсус решения алгоритме Требования к оборудованию Относительное Зависит от и энергоэффективность описание конкретного требований к решения оборудованию и энергообеспечению конкретного решения Технологии Возможность работы без Есть/Нет Зависит от создания и внутренней валюты конкретного исполнения решения децентрализованных Возможность выпуска Есть/Нет Зависит от приложений и токенов конкретного смарт-контрактов решения Средний срок интеграции Часы 120 ч. системы в бизнес-процессы Средний срок аудита смарт- Минуты 120 мин. контракта Поддерживаемые языки Количество Зависит от программирования поддерживаемых конкретного языков конкретной решения платформы Полнота по Тьюрингу Описание полноты Зависит от и ограничений конкретного решения 35 Необходимость и критичность технологических компонент В связи с тем, что приватные и публичные сети распределенного реестра состоят из различного набора технологических компонент, ниже представлена оценка необходимости в каждом компоненте для формирования приватных и публичных систем. Компонента необходима, если без нее невозможно создание публичной или приватной системы распределенного реестра. Компонента может быть либо необходима для обоих видов систем распределенного реестра, либо только для одной из двух систем (и опциональна для другой), либо компонента может быть необходимой или опциональной для одной системы и неприменимой для другой. Понятия необходимости и критичности различны. Компонента может быть необходима только для одного из двух типов систем, что не делает ее критичной. Критическими компонентами в рамках Дорожной карты являются компоненты, необходимые для создания как приватных, так и публичных сетей, а также компоненты критичные для разрешения ключевого недостатка публичных сетей – низкой пропускной способности. Также в качестве критичных компонентов определены инструменты работы со смарт-контрактами и интеграции с внешними данными, без которых невозможно достижение экономических эффектов приватных распределенных систем. Компоненты, необходимые для создания как приватной, так и публичной сети, формируют платформы распределенного реестра, которые являются ключевой продуктовой категорией, так как приложения или отраслевые решения, построенные на базе платформ, зависят от технических характеристик самих платформ. Механизмы увеличения пропускной способности критичны для любой публичной сети, так как предопределяют ее возможности масштабирования и дальнейшего использования. 36 Таблица 11. Технологическая карта для «сквозной» цифровой технологии «Системы распределенного реестра» Слой Элемент Технологическая компонента Технологическое Необходимость Критичность архитектуры описание компоненты компоненты Транспорт- Консенсус Топология сети консенсуса Децентрализован- Необходимо для Критично для ный ная публичной и приватных и приватной публичных систем Иерархичная систем распределенного реестра Централизованная Обеспечение неизменности и Proof of Work Необходимо для Критично для непротиворечивости консенсуса (PoW) публичной и приватных и приватной публичных систем Proof of Stake (PoS) систем распределенного реестра Proof of Authority (PoA) Гибридный Безконсенсусная модель Другие Передача данных (gossiping) Локальная Необходимо для Критично для публичной и приватных и Глобальная приватной публичных систем систем распределенного реестра 37 Слой Элемент Технологическая компонента Технологическое Необходимость Критичность архитектуры описание компоненты компоненты Достижение Задержка Синхронная / Необходимо для Критично для консенсуса асинхронная публичной и приватных и приватной публичных систем Подтверждение Детерминированно систем распределенного транзакций е / не реестра детерминированное Лимиты По количеству Максимальное Необходимо для масштабирова транзакций количество публичной и ния транзакций в приватной секунду систем По количеству нод Максимальное количество нод По количеству Максимальное пользователей количество пользователей Время подтверждения Детерминированно блока е Вероятностное Исполнение Структура данных блока Дерево Меркла Необходимо для Критично для транзакций публичной и приватных и Дерево Патрисии приватной публичных систем Модель транзакций UTXO систем 38 Слой Элемент Технологическая компонента Технологическое Необходимость Критичность архитектуры описание компоненты компоненты Традиционная распределенного реестра Хранение данных Полные ноды Возможности тонких клиентов Данные блока Транзакции Баланс пользователей Безопасность Шифрование данных SHA-2 (SHA-224, Необходимо для Критично для и SHA-256, SHA-384, публичной и приватных и приватность SHA-512) приватной публичных систем систем распределенного SHA-1 реестра ZK-Snarks Приватность данных Встроенные механизмы обеспечения приватности данных Подключаемые механизмы приватности данных 39 Слой Элемент Технологическая компонента Технологическое Необходимость Критичность архитектуры описание компоненты компоненты Представле Кодовая база Язык программирования Один язык Необходимо для Критично для ния платформы публичной и приватных и Несколько языков приватной публичных систем Лицензирование кода Открытый систем распределенного исходный код реестра (open-source) Закрытый исходный код Архитектура программного Монолитная обеспечения Микросервисная Функциональ Интегрируемость с внешними Внутренняя Необходимо для Критично для ность информационными системами интегрируемость публичной и приватных и приватной публичных систем Интегрируемость с систем распределенного помощью внешних реестра инструментов Неинтегрируемый Интегрируемость с другими системами Внутренняя распределенного реестра интегрируемость Интегрируемость с помощью внешних инструментов 40
Enter the password to open this PDF file:
-
-
-
-
-
-
-
-
-
-
-
-