Синтез универсальной изолированной криптовалютной сети

Главная > Статьи >Синтез универсальной изолированной криптовалютной сети
Статьи

УДК 004.6.056: 004.75

СИНТЕЗ УНИВЕРСАЛЬНОЙ ИЗОЛИРОВАННОЙ КРИПОВАЛЮТНОЙ СЕТИ

@ Авторы 2017

Ó ЗАО «Издательство «Радиотехника»», 2017

А.В.Домашев – начальник отдела ФГУП НТЦ «Атлас»

А.Ю.Щербаков  – д.т.н., профессор, главный научный сотрудник ФИЦ ИУ РАН

________________________________

Предложено понятие изолированной криптовалютной сети, изложены принципы и подходы к cинтезу универсальной архитектуры и протокола изолированной криптовалютной сети.

Ключевые слова: криптовалюта (КВ), электронная подпись (ЭП), удостоверяющий центр (УЦ), криптовалютный кошелек (КВК), криптовалютная сеть, изолированная криптовалютная сеть (ИКВС)

Proposed the concept of an isolated cryptocurrency network, the principles and approaches to the synthesis of a generic architecture and protocol of the isolated cryptocurrency network.

Keywords: cryptocurrency (CC), digital signature (DS), certification authority (CA), cryptocurrency wallet (CCW), cryptocurrency network, isolated cryptocurrency network (ICCN)

Введение

Возрастающее влияние криптовалют (КВ) и связанных с ними технологий (в частности, блокчейна) в национальных экономиках ставят актуальную задачу синтеза решений, одинаково приемлемых как для бизнеса, так и для государственных структур и регуляторов экономики [1, 2, 3, 8].

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

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

В настоящей статье рассматривается технология, позволяющая реализовать в рамках практически любой криптовалютной среды изолированную сеть (Изолированная КриптоВалютная Сеть - ИКВС) в которой гарантируется циркуляция транзакций только в рамках централизованно регулируемой клиентской базы.

Терминология

Перед тем как перейти к подробному рассмотрению протокола ИКВС зафиксируем общие и специальные используемые термины и сокращения.

Таблица 1. Общие термины и сокращения

ЭП

Электронная подпись

HSM

Hardware Security Module

УЦ

Удостоверяющий центр

БД

База данных

 

Таблица 2. Специальные термины и сокращения

ИКВС

Изолированная криптовалютная сеть

ГУЦ

Головной УЦ

КВ

Криптовалюта

КВК

Криптовалютный кошелек

ОКВК

Оператор Криптовалютного кошелька (КВК)

ОИКВС

Оператор ИКВС

УЦ УК

УЦ управления клиентами

КВС

Криптовалютная сеть

АВ КВК

Агент восстановления КВК

БД АВ КВК

База данных Агента восстановления КВК

 

Концепция ИКВС

Одним из главных условий практической значимости реализации ИКВС является независимость функционирования данной среды от особенностей реализации протоколов и форматов конкретной криповалюты. На практике это означает, что при реализации не должны использоваться например возможности смарт-контрактов, реализованных в среде Ethereum или multisignature сценариев Bitcoin. Технология изолированности среды должна быть реализована полностью «наложенными» средствами.

Для того, чтобы реализовать концепцию изолированности клиентов ИКВС введем промежуточное звено (назовем его оператором КВК) между клиентом и криптовалютной средой в которой он намерен осуществлять операции. Данное промежуточное звено должно осуществлять следующие основные операции:

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

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

Необходимым условием, дающим клиенту возможность обращаться к оператору КВК, примем получение клиентом сертификата у специального оператора, управляющего допуском к ИКВС (назовем его оператором ИКВС). Использование сертификатов позволяет построить схему регистрации и работы операторов и клиентов на стандартных компонентах и протоколах, которыми являются удостоверяющие центры и программное обеспечение, поддерживающее работу с ними.

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

В общем случае два этих оператора могут управляться одним и тем же органом. Однако разделение данных операторов безусловно рекомендуется.

Предложения по реализации ИКВК

В данном разделе представлена концепция реализации ИКВС. Разумеется описание в этом разделе представляет собой описание подхода к решению данной задачи и не учитывает многие вопросы практической реализации, которые рассмотрены в следующих разделах.

Кроме того, в представленной схеме аутентификация и авторизация конечных пользователей базируется исключительно на сертификатах и разрешениях, которые соответствующий УЦ включит в них. Данная модель является статической в том смысле, что не позволяет в динамике управлять разрешениями конечных пользователей и поэтому на практике может быть не достаточной. Более гибкие модели управления разрешениями в среде ИКВС также рассмотрены в следующих разделах.

В процессе описания схемы работы ИКВС будут рассмотрены подходы к тому, известен ли конечному пользователю его реальный адрес в среде криптовалюты. Первый заключается в том, что несмотря на то, что он не может воспользоваться самостоятельно секретных ключом КВК, реальный адрес КВК конечному пользователю известен (по сути ему известен открытый ключ КВК). Второй подход, как понятно, заключается в том, что конечному пользователю не известен и открытый ключ КВК, то есть он не знает и адреса КВК, которым он управляет. Выбор того или иного подхода определяется исключительно характеристиками деятельности, которую хочет организовать оператор ИКВС. Однако очевидно, что знание пользователем его реального адреса оказывает прямое влияние на характеристики анонимности в среде ИКВС.

Общая схема предлагаемой ИКВК приведена на Рис. 1. Рассмотрим основные этапы инициализации и работы ИКВС.

Этап A. Инициализация ГУЦ ИКВС.

Инициализация головного УЦ ИКВС. Вопрос как и откуда ГУЦ ИКВС получит свой сертификат (iccn_head_ca_cert) очевидно не относится к концепции ИКВС и зависит от задач, поставленных перед конкретной реализацией ИКВС. В зависимости от целей создаваемой системы ГУЦ ИКВС для своей инициализации может обратиться для получения сертификата к УЦ национального (наднационального), регионального или корпоративного уровня, обладающего необходимыми компетенциями.

Этап B. Инициализация ОКВК.

Инициализация оператора КВК начинается с получения его головным УЦ сертификата (ccw_op_head_ca_cert) у ГУЦ ИКВС (шаг B.1). Шаг B.1 является регистрацией нового ОКВК в системе.

Оператор КВК (см. Рис. 1), состоит из двух основных элементов: головного УЦ и HSM. Для завершения инициализации ОКВК HSM генерирует секретный ключ (ccw_op_hsm_private_key) и получает сертификат (ccw_op_hsm_cert) открытого ключа у своего ГУЦ (шаг B.2).

Этап 3. Инициализация ОИКВС.

Инициализация оператора ИКВС, как и оператора КВК, начинается с получения его головным УЦ сертификата (iccn_op_head_ca_cert) у ГУЦ ИКВС (шаг C.1). Шаг C.1 является регистрацией нового ОИКВС в системе.

Оператор КВК (см. Рис. 1), состоит из четырех основных элементов: головного УЦ, УЦ УК, УЦ КВК и БД АВ КВК. Для завершения инициализации УЦ УК и УЦ КВК запрашивают сертификаты открытых ключей (iccn_op_end_user_ca_cert и iccn_op_ccw_ca_cert), необходимых для их активации (шаг C.2 и шаг C.3 соответственно).

После активации всех УЦ инициализируется БД операторов восстановления. Для этого оператор (операторы) восстановления генерируют секретные ключи и запрашивают сертификаты открытых ключей у своего головного УЦ (шаг C.4).

Этап D. Регистрация клиента у оператора ИКВС.

Этап регистрации, как и остальных случаях, представляет собой запрос и получение сертификата (end_user_iccn_cert) у соответствующего оператора ИКВС. Обработку этих запросов в рамках оператора ИКВС ведет УЦ УК (см. Рис. 1). Таким образом, клиент получает сертификат открытого ключа с включенными в него разрешениями (end_user_iccn_perms), который в дальнейшем он будет использовать для аутентификации при обращении к сервисам ИКВС.

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

Этап E. Получение сертификата КВК.

К настоящему моменту клиент, зарегистрировавшись у оператора ИКВС и получив соответствующий сертификат, имеет возможность обращаться к сервисам ИКВС.

Поскольку в изолированной среде клиент по работает с КВК посредством ОКВК и не владеет секретным ключом кошелька, то для идентификации КВК предлагается использовать специальный сертификат, к которому оператор КВК и будет привязывать реальный КВК и на котором будет производиться шифрование и ЭП информации, связанной с этим кошельком. Кроме того, использование для каждого КВК отдельного сертификата позволит оператору ИКВС проводить в случае необходимости целевую блокировку кошелька просто путем отзыва соответствующего сертификата.

Таким образом на этом этапе клиент обращается к УЦ КВК, проходит аутентификацию и запрашивает сертификат КВК (end_user_ccw_cert). Аутентификация может быть проведена по протоколу TLS с использованием штатной возможности клиентской аутентификации. При обращении за сертификатом КВК клиент может указать разрешения (end_user_ccw_perms), которые он хотел бы получить. Например, тип криптовалюты, максимальный объем кошелька, возможность обращение к внешним шлюзам ИКВС (рассматриваются далее) и др. Конкретный перечень разрешений сертификата и требования к его получению определяются политикой конкретного оператора ИКВС.

После успешного получения сертификата КВК клиент может обращаться с запросами к оператору КВК.

Этап F. Подключение реального КВК к сертификату клиента.

На этом этапе клиент обращается к соответствующему оператору КВК для создания для него КВК. Запрос подписывается на сертификате, полученном от ОИКВС на этапе F. Таким образом, ОКВК имеет возможность проверить полномочия клиента для создания КВК.

После проверки валидности запроса HSM оператора создает (или использует уже созданную) ключевую пару КВК (ccw_private_key и ccw_public_key). Из открытого ключа формируется токен открытого ключа (ccw_public_key_token), а из секретного ключа токен секретного ключа (ccw_private_key_token).

Токен ccw_private_key_token получается путем шифрования и подписи ccw_private_key на сертификате оператора КВК сcw_op_hsm_cert, полученном на этапе B (шаг B.2). В состав токена также входит идентификатор сертификата конечно пользователя end_user_ccw_cert_id. Включение идентификатора необходимо, чтобы оператор КВК мог при обращении проверить соответствие идентификатора сертификата конечного пользователя, который к нему обратился и идентификатора сертификата из токена.

Токен ccw_public_key_token также может быть получен путем шифрования и подписи на сертификате оператора КВК сcw_op_hsm_cert, если есть необходимость в скрытии от клиента реального адреса КВК. В противном случае достаточно только подписи. В состав ccw_public_key_token также входит идентификатор сертификата end_user_ccw_cert_id.

После этого оба токена (ccw_private_key_tokenиccw_public_key_token) направляются клиенту в ответ на его запрос.

Таким образом после этого шага клиент владеет всей необходимой информацией для осуществления криптовалютных транзакций в рамках ИКВС.

Этап G. Проведение транзакции для КВК.

Теперь для проведения транзакции клиенту необходимо сформировать параметры транзакции и подписать запрос сертификатом end_user_ccw_cert, полученным на этапе E.

Для формирования транзакции конечный пользователь должен по соответствующим канал получить целевые адреса в виде токенов ccw_public_key_token. Получить он их может как в результате непосредственно взаимодействия с другими пользователями (например, по электронной почте) или оператор ИКВС может предусмотреть какой любо общедоступный каталог для размещения такой информации (например, непосредственно в свойствах сертификатов в каталоге УЦ КВК).

Получив запрос, оператор КВК проводит следующие действия (шаг G.2):

  1. Проверяет валидность подписи запроса.
  2. Расшифровывает (если необходимо) ccw_public_key_token отправителя транзакции.
  3. Проверяет подпись ccw_public_key_token отправителя транзакции.
  4. Расшифровывает ccw_private_key_token отправителя транзакции и получает секретный ключ КВК ccw_private_key.
  5. Проверяет подпись ccw_private_key_token отправителя транзакции.
  6. Расшифровывает (если необходимо) ccw_public_key_token получателей транзакции.
  7. Проверяет подпись ccw_public_key_token получателей транзакции.
  8. Проверяет валидность сертификатов end_user_ccw_cert получателей транзакции.
  9. Проверяет валидность сертификатов end_user_iccn_cert получателей транзакции.
  10. Формирует и подписывает запрашиваемую транзакцию на ключе ccw_private_key отправителя транзакции.
  11. Отправляет транзакцию с сеть соответствующей криптовалюты.
  12. Отправляет конечному пользователю подписанное подтверждение проведения транзакции.

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

После приведения описания работы ИКВС более понятным должно стать предложенное ранее деление «полнофункционального» оператора ИКВС (серая область на Рис. 1) на два независимых компонента: собственно оператора ИКВС и оператора КВК. В области оператора КВК собраны компоненты работающие непосредственно с транзакциями конечных пользователей и криптовалютными средами. Организация, заинтересованная в создании для каких-либо целей изолированной криптовалютной среды может и не иметь таких специфических компетенций. Задача «малого» оператора ИКВС это управление подключением конечных пользователей к изолированной среде. Кроме того введение дополнительного независимого оператора безусловно повышает и уровень доверия конечных пользователей к системе в целом.

И еще одно замечание в отношении оператора КВК. Как можно заметить из приведенного описания, оператор КВК не хранит результатов своих операций. Результаты всем проведенных им операций отправляются или конечных пользователям или в криптовалютную сеть. Это очень выгодное свойство с точки зрения простоты реализации HSM и оператора в целом. Однако, конечно возможности такой реализации могут не удовлетворить запросы организатора ИКВС.

В следующих разделах рассматриваются дополнительные компоненты ИКВС, которые позволяют динамически управлять разрешениями конечных пользователей.

Дополнительные компоненты ИКВС

При описании базовых принципов функционирования ИКВС, изложенных в предыдущем разделе, были для упрощения опущены несколько важных компонентов. Этими компонентами являются каталог КВК, а также операторы аудита и управления (см. Рис. 1).

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

В связи с введением новых компонент этап F может быть дополнен шагом H (см. Рис. 1) на котором будут проверены текущие разрешения конечного пользователя на проведение запрошенной транзакции.

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

Ну и наконец организатор ИКВС может быть заинтересован в том, чтобы при необходимости проводить операции с КВК конечных пользователей. Это может быть прежде всего связано с необходимостью обеспечения возможности возвращение средств транзакции, признанной по каким-либо причинам необходимой к отмене. Для этого оператор администрирования КВК должен иметь доступ к секретным ключам КВК. Наиболее очевидная схема реализации данного требования это дополнение этапа F шагом создания токена секретного ключа, зашифрованного на сертификате оператора администрирования КВК, полученном на шаге С.4 (см. Рис. 1). Этот токен может быть, в зависимости от требований оператора, сохранен в каталог КВК или напрямую передан оператору ИКВС для хранения и использования.

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

Варианты реализации функциональности оператора КВК

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

В качестве готового решения специального чипа могут быть использован, например, чипы, реализующие функциональность TPM (Trusted Platform Module). Определенным недостатком такого решения является ограниченная функциональность TP. Модуль TPM реализует только определенный набор базовых криптографических преобразований.

Более функциональным решением может являться реализация функциональности ядра оператора КВК в рамках доверенной среды исполнения (Trusted Execution Environment - TEE). Примером наиболее развитой TEE является технология Intel SGX (Software Guard Extensions). Данная технология дает возможность вынести в изолированную доверенную среду исполнения не только непосредственно работу с ключами, но и полное функциональное ядро оператора КВК.

Кроме того, в настоящее время, крупнейшие операторы облачных сервисов предлагают возможность реализации доверенной среды исполнения в рамках облачной среды. Так компания Microsoft предлагает в рамках сервиса Azure Confidential Computing предлагает сразу два варианта реализации TEE. Кроме варианта на основе технологии Intel SGX, Microsoft предлагает также вариант программной реализации доверенной среды исполнения на основе Virtual Secure Mode [10].

Прямая передача КВК как внутренняя транзакция ИКВС

При всех своих достоинствах сети таким криптовалют как Bitcoin и Ehtereum обладают рядом врожденных недостатков в части проведения транзакций. Это существенное (особенно у Bitcoin) включения в блокчейн и необходимостью платить майнерам за включение в блокчейн. Необходимость платы за включение в блок приобретает большое значение в случае обмена большим количеством малых по стоимости транзакций (микроплатежи), когда плата майнерам может превысить объем перевода.

В настоящее время предложен целый ряд вариантов так называемых протоколов Payment Channel, предлагающих возможность реализовать в недоверенной среде обмен транзакциями без необходимости включения их всех в блок ().

В части решения данной проблемы ИКВС также может предложить оригинальное решение базирующееся на его основополагающем свойстве. Основополагающим свойством ИКВС является то, что конечный пользователь не владеет секретным ключом КВК и оперирует кошельком посредством оператора КВК. Таким образом конечный пользователь имеет непосредственную возможность просто передать посредством оператора КВК свой кошелек другому конечному пользователю.

С криптографической точки зрения это операция выглядит просто как получение от конечного пользователя, передающего КВК, токена ccw_private_key_token, расшифрование его и зашифрование с новых идентификатором end_user_ccw_cert_id конечного пользователя, получающего КВК. После этого в каталог КВК вносятся соответствующие изменения о владельце КВК и токены открытого и секретного ключей отсылаются новому владельцу.

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

На данном примере видно, что при реализации правильно настроенной схемы динамического управления разрешениями конечных пользователей по доступу к КВК, в рамках ИКВС можно реализовать схему «мгновенных» переводов криптовалютных средств гарантированных оператором ИКВС.

Сценарии и смарт-контракты в среде ИКВС

До настоящего момента изолированность криптовалютной сети рассматривалась только в части отправителя и получателя транзакций. Однако такого понимания изолированности достаточно только если ИКВС ограничивает тип разрешенных транзакций только транзакциями переводящими криптовалютные средства с одного адреса на другой. К таким типах транзакций можно отнести Pay-to-PubKeyHash (P2PKH) транзакцию для сети Bitcoin или Ehtereum транзакция с целевых адресом, являющимся адресом кошелька.

Если такое ограничение типа транзакций устраивает оператора ИКВС, то описанной выше схемы достаточно для выполнения поставленной задачи. Однако если в среде ИКВС предусматривается использование транзакций типа Pay-to-ScriptHash (P2SH) для Bitcoin или создание в сети Ethereum смарт-контрактов (в этом случае целевой адрес не указывается) и вызов функций смарт-контрактов (в этом случае целевой адрес транзакции это адрес контракта), то необходимо расширить понятие изолированной криптовалютной среды.

Расширение понятия изолированной крпитовалютной среды на сценарии и смарт-контракты приводит к тому, что по сути ИКВС становится настоящей замкнутой программной средой, применяемой для защиты информации в универсальных ОС.

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

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

Таким образом ИКВС предоставляет возможность создать в криптовалютной среде настоящую ЗПС. Это особенно актуально, конечно, для среды Ethereum, в которой язык старт-контрактов Solidity предоставляет невероятно огромные возможности и в случае неправильного использования может привести к проблемам и потерям криптовалютных средств.

Выводы

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

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

 

Литература

1. А.Ю.Щербаков. Синтез универсальной архитектуры и протокола криптовалюты в рамках национального проекта/ Системы высокой доступности, № 3, т. 13, 2017 - c. 15-18

2. Централизованные криптовалюты. geektimes.ru/company/waves/blog/289379/

3. Black, F. 1970. Banking and interest rates in a world without money: the effects of uncontrolled banking. Journal of Bank Research, 1 (Autumn): 9–20.

4. Fama, E. F. 1980. Banking in the theory of finance. Journal of Monetary Economics, 6: 39–57.

5. Hall, R. E. 1982. Monetary trends in the United States and the United Kingdom: a review from the perspective of new developments in monetary economics. Journal of Economic Literature, 20: 1552–6.

6. Kareken, J. and Wallace, N. 1981. On the indeterminacy of equilibrium exchange rates. Quarterly Journal of Economics, 96(2): 207–22. doi: 10.2307/1882388

7.Meiklejohn, S., Pomarole, M., Jordan, G., Levchenko, K., McCoy, D., Voelker, G. M. and Savage, S. 2013. A fistful of Bitcoins: characterizing payments among men with no names. Proceedings of the 2013 Conference on Internet Measurement.

8. Nakamoto, S. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System. bitcoin.org. 

9. Wallace, N. 1983. A legal restrictions theory of the demand for ‘money’ and the role of monetary policy. Federal Reserve Bank of Minneapolis Quarterly Review, 7: 1–7.

10. Mark Russinovich. 2017. Introducing Azure confidential computing. https://azure.microsoft.com/ru-ru/blog/introducing-azure-confidential-computing/

SYNTHESIS UNIVERSAL ISOLATED CRYPTOCURRENCY NETWORK

© Authors, 2017

© Radiotekhnika, 2017

A.V. Domashev – the chief of Department STC "Atlas", E-mail: domix@stcnet.ru

A.Yu. Scherbakov – Dr. Sc. (Eng.), Professor, Main Research Scientist,

FRC «Computer Science and Control» RAS (Moscow)

E-mail: x509@ras.ru

Proposed the concept of an isolated cryptocurrency network, the principles and approaches to the synthesis of a generic architecture and protocol of the isolated cryptocurrency network.