Данный концепт с использование цепочки блоков - неизменных записей, хранящихся всеми узлами сети, было предложено Сатоши Накамото в 2008 году и уже была реализована в 2009 году. Его первой реализацией, где он играл роль главного общего реестра для всех операций, был - биткоин - цифровая валюта. (Часто термин Blockchain, путают с Bitcoin. Разъясним, Bitcoin является реализацией базовой технологии Blockchain и служит для оперативного перечисления денежных средств.)

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

Рис. 2 Процесс перевода средств с использованием технологии блокчейн

Особенности технологии Blockchain.

Блокчейн сеть представляют собой - Peer to Peer, P2P - одноранговые Одноранговая сеть (децентрализомванная, или пимринговая сеть) (от англ. peer-to-peer, P2P -- равный к равному) - это оверлейная (логическая сеть, создаваемая поверх другой сети) компьютерная сеть, где все узлы сети равноправны. Часто в такой сети отсутствуют выделенные серверы, а каждый узел (peer) является как клиентом, так и выполняет функции сервера. В отличие от архитектуры клиент-сервера, такая организация позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов.сети, в которой имеются некоторое количество узлов, и каждый из узлов могут держать связь и обмениваться информацией друг с другом. Каждый из узлов может делать запросы другим узлам и выступать в роли клиента. Выступая же в роли сервера, отвечать на запросы. Узлы могут присутствовать в сети не постоянное время, могут отключаться и подключаться. Данный вид сетей не является совсем новым изобретением, до появления технологии блокчейн, была изобретена технология хеш-таблиц (Distributed Hash Tables, DHT) - гибридная, частично децентрализованная сеть, использующаяся в BitTorrent. В DHT есть особенность, что любой узел координирует работу только с несколькими узлами в системе, тогда как в сетях блокчейн все узлы могут связываться между собой. Также, в DHT имеются сервера, служащие для координации работы, поиска и предоставления информации о существующих узлах в сети и их статусы. В основном сервера хранят ip адреса, входящие порты клиентов, и идентификаторы объектов - хеш-суммы. Данная инфраструктура используется для систем мгновенных сообщений, служб DNS, распределенных файлов систем, пирингового распространения файлов.

Рис. 3 Отключение одного узла не влияет на работоспособность децентрализованной сети

1. Свойство - отсутствие точки отказа. Безопасность.

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

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

Асимметричное шифрование. Процесс подписания транзакций.

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



Рис. 4 Процесс подписи транзакции и подтверждение установленных требований подписи

2. Свойство - децентрализованный консенсус.

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

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

Процесс создания и подтверждения транзакции

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

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

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

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

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

Теоретически есть вероятность, что кто-то из злоумышленников может изменить историю цепи блоков на своем узле и отправить ее в сеть, но благодаря механизму доказательства выполнения работы, это практически невозможно. Все потому, что цепочка блоков может быть признана действительной если только 51% или более узлов всей сети признают, что она верна, только тогда история будет применена всем узлам сети, а т.к. на данный момент вычислительная мощность сети гораздо превосходит по мощности все суперкомпьютеры в мире, у мошенников нет возможности обладать такой вычислительной мощности, чтобы заполучить 51% узлов сети. Данный механизм является способом предотвращения атак Сибиллы(Sybil), при которой мошенники незаконно получают данные, путем контроля большего количества узлов сети. А также подмена блока в цепи невозможно, потому что повторимся, в блоках имеются ссылки на предыдущие блоки, и для взлома определенного блока, будет необходимо взломать и все предшествующие блоки, изменять историю журналов сети (рис.5).

Рис. 5 Цепочка блоков

Схематично, общий процесс отправки транзакции на примере биткоина представлен на рис.5. (стр.32)

Итак, главные свойства технологии блокчейн:

1. Хранение всех действий пользователей в сети блокчейн (каждая созданная транзакция)

2. Включение в блоки только проверенных транзакций

3. Каждый блок имеет ссылку на предыдущий

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

Технология распределенного реестра (distributed ledger technology, DLT) может найти свое применение и привнести много полезного в разные области. Кроме финансово-технических проектов и банков, есть другие сферы, заинтересованные в возможностях, которые откроет DLT. Рядом примеров, когда блокчейн находит себе применение вне финансовой сферы, это патентное право, торговля, поставки, управление данными, индустрия драгоценных металлов, аутентификация и авторизация, энергетика, электронный сбор голосов, видеоигры, управление в государственном и частном секторе, интернет вещей, а также есть все предпосылки о том, что в скором времени, технология заявит о себе в области медицины.

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



Рис. 6 Процесс отправки транзакции

3.1 Смарт - контракты

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

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

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

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

Объекты смарт-контракта:

· Подписанты - стороны смарт-контракта

· Предмет договора - объект в среде существования умного контракта, к которому смарт-контракт может получить доступ без помощи человека

· Условия - запрограммированное описание логики исполнения пунктов договора

Обязательными атрибутами смарт-контрактов, являются:

· использование методов электронной подписи на основе публичных и приватных ключей, имеющихся у двух или более сторон соглашения (в смарт-контрактах на платформе Ethereum используется асимметричное шифрование);

· наличие децентрализованной среды исполнения (например, Ethereum), в которую записываются смарт-контракты

· предмет договора и необходимые для его исполнения инструментов (криптовалютных расчетных счетов и т. д.);

· точно описанные условия его исполнения, которые участники договора подтверждают подписью, а также достоверность источника цифровых данных.

Типы смарт-контрактов

В зависимости от степени автоматизации смарт-контракты могут быть:

· полностью автоматизированными

· с наличием копии на бумажном носителе

· преимущественно на бумажном носителе, при этом часть положений перенесена в программный код (например, когда автоматизированы только платежи)

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

Как работают смарт-контракты

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

Преимущества смарт-контрактов

Основными преимуществами смарт-контрактов выделяют:

· независимость (для заключения и подтверждения сделок не нужны третьи лица в лице банков, нотариальных контор и т.д.)

· надежность, безопасность (смарт-контракты хранятся в зашифрованном виде на множестве узлов сети блокчейна без возможности изменения и редактирования)

· уменьшения затрат на посредников в виде нотариальных контор

· скорость подписания договоров

· уменьшение количества ошибок, возникающих при ручной работе по заключению договоров

При помощи смарт-контрактов будет возможность полностью или частично автоматизировать процессы заключения договоров

Недостатки смарт-контрактов

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

· нормативно-правовое регулирование

· отсутствие связи цифрового и нецифрового мира для предоставления входных данных смарт-контрактам

· отсутствие возможности изменить внесенные данные, что будет требовать точности при внесении информации - зависимость от человеческого фактора

· банки и крупные компании не пользуются открытыми распределенными реестрами

· присутствуют проблемы скорости в технологии блокчейн (см. пункт описания недостатков блокчейна)

Сфера использования смарт-контрактов

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

На рис. 7 представлен процесс выполнения смарт-контракта.



Рис. 7 Процесс выполнения смарт-контракта

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

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

3.2 Платформы для децентрализованных приложений

Выбор блокчейн платформы для работы со смарт-контрактами

Выбор платформы для работы со смарт-контрактами в первую очередь зависит от целей и нужд каждого проекта. Однако, в любом случае для оценки потенциальной платформы стоит рассмотреть ряд аспектов, в том числе наличие SDK SDK (о англ. software development kit) -- набор средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, необходимой документации и выбор предложенных инструментов.

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

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

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

1. Ethereum

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

Преимущества Ethereum

· доступный порог вхождения (публичная сеть)

· широкое распространение, использование и поддержка сети майнерами

Недостатки Ethereum

· за отправку транзакций необходимо производить оплату (награда майнерам)

· большие нагрузки на сеть

2. Hyperledger Fabric

Hyperledger - платформа для разработки и управления решениями на базе блокчейна в приватной сети, проект появился в 2016 году при поддержке компании IBM.

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

Преимущества Hyperledger

· Создание приватной сети для корпоративного сегмента

Недостатки Hyperledger

· Большой порог вхождения для разработчиков, системных архитекторов, системный администратор (подготавливает среду для развертки)

· Плата за приобретение (как стандартное программное обеспечение). 28 марта 2017 года Сбербанк заключил договор с IBM для создания модуля blockchain на базе Hyperledger стоимостью 15,761 млн рублей. [47]

Кроме Ethereum и Hyperledger имеются ряд других платформ, но они ещё находятся в стадии разработки, это iOlite, Cardano и другие. Так как, на данный момент имеется две работающие платформы для создания блокчейн сети, и одна из них является платной и приватной, в данной работе будет использоваться платформа Ethereum, а для написания смарт-контрактов, язык Solidity.

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

3.3 Варианты хранения информации

Рассмотрим варианты хранения информации:

1 Вариант. Хранение данных в цепочке блоков блокчейна.

Данный подход решает проблему с безопасностью данных, храня их децентрализовано, исключается возможность нарушения целостности данных, сохраняя доступность и достоверность информации. А для сохранения конфиденциальности данных будут использоваться смарт-контракты, с применением алгоритма SHA-256, чтобы при децентрализованном хранении ваших данных на множестве узлов, только вы имели бы к ним доступ при помощи закрытого ключа. Однако, цепочка блоков изначально была предназначена для хранения списка транзакций, а не для большого объема данных, с которым мы столкнемся в телемедицине. За последние годы, в сети Биткоин, в которой хранятся только транзакции, достигла размеров в более чем 40 Гбайт памяти. Для майнеров, выгрузка такой большой цепочки данных занимает несколько дней, увеличивая их расходы, тем самым делая поддержание сети для них невыгодным делом. Для разработчиков, большая цепочка блоков с плохой масштабируемостью, тоже приводит к проблемам. Также, есть очень важный момент, в контексте нашей темы работы, мы ищем решения в области телемедицины, где будем осуществлять передачу большого объема данных, таких как медицинские карты пациентов, при этом ранее уже упоминалось, что

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

Комиссии в сети Ethereum

1. Оплата майнерам

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

2. Защита сети

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

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

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

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

2 Вариант. Хранение данных в распределенной хеш-таблице.

Ранее уже упоминались хеш-таблиц DHT (англ. distributed hash table -- «распределённая хэш-таблица») -- децентрализованная распределённая система поисковой службы, работающая подобно хэш-таблице. Как структура данных, хэш-таблица представляет собой ассоциативный массив, содержащий пары (ключ-значение)- технология которая распределяет копии данных и функции индексирования, для обеспечения поиска и гаранта надежности данных. Впервые технология была реализована в действующем проекте BitTorrent, и до сих пор пользуется огромной популярностью. Удобен для раздачи файлов больших размеров, таких как, аудио-, видеофайлы. Однако, остаются централизованные серверы (трекеры), хранящие IP адреса, входящие порты клиентов и хеш файлов, участвующих в закачках, для того, чтобы пользователи могли найти друг друга. Трекер может периодически отключается, т.е. постоянный доступ к данным не гарантирован. (Хотя в последних версиях, тоже начали пользоваться DHT таблицами.)

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

IPFS (Interplanetary File System, [48]) - межпланетная файловая система. IPFS представляет собой контентно-адресуемую Контентно-адресуемая сеть (от англ. Content-addressable storage (CAS)) - архитектура хранения, при которой адресация осуществляется образом хранимых данных. Образ данных хэшируется и хэш используется для его нахождения на устройствах или системах хранения.(данные находятся по их хэшу), децентрализованную гипермедийную Гипермедийный - технологией структурирования информации и произвольного доступа к её элементам с помощью гиперсвязей.файловую систему. IPFS является проектом с открытым исходным кодом, разработанным Protocol Labs при содействии open-source сообщества.

То есть, IPFS - это распределенная файловая система с контентной адресацией.

· Под распределённостью понимается P2P файлообмен, где пользователь, скачав файл, становится источником данного файла для других пользователей.

· Под файловой системой понимается, что, скачав клиент IPFS, можно видеть файлы, загруженные в IPFS в файловой системе на своем компьютере по адресу «/ipfs/хэш_файла».

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

Итак, IPFS:

· Сеть дает возможность хранить данные с неограниченным сроком без центрального сервера. Если в случае сети Интернет, основанный на IP адресах, данные перестанут быть доступными при сбое в работе сервера имен, то в контентно-адресуемой сети IPFS, без центральных серверов, такая ситуация невозможна. Соответственно поиск по имени файла, как и в BitTorrent - невозможен.

· Для хранения данных используются распределенные хеш-таблицы DHT. Для начала работы с IPFS нужно скачать его клиент, загрузить данные и получить мультихэш, по которому данные будут доступны. Мультихеш состоит из трёх частей: ID хеш функции, размер хеша в байтах, хеш. Мультихеш является 46-байтным хешом, который служит уникальным цифровым идентификатором файла. Так гарантируется, что один и тот же файл не будет закачан в сеть дважды. С развитием проекта предполагается переход на другие стойкие хеш функции.

· Загруженные данные формируются в блоки (по сети данные передаются в виде блоков) и копируются на некоторое количество узлов

· Для того, чтобы через Интернет получить файл загруженный в IPFS, нужно взять хэш файла полученный при загрузке данных через клиент IPFS, и записать перед хэш-ссылкой «https://ipfs.io».

Например: «https://ipfs.io/ipfs/QmcXx6mTREAc7tCWLq84Hn8PLxWfBdZpvogJk3tFRESFiv»

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

· Данные распространяются через протокол основанный на протоколе BitTorrent, и каждый пользователь поддерживает доставку контента другим пользователям сети, при его просмотре.

· Структурирование системы данных, для возможности просмотра пользователями историю изменения доступных им данных, заимствовано от модели управления версиями из Git.

· Уникальная веб технология для хранения веб-ресурсов как файлы и объекты, пока данные кому-либо необходимы и к нему обращаются. Когда обращение к файлам прекращается, через некоторое время клиент IPFS отчищает загруженные данные на узлах.

· Основанные на IPFS сайты защищены от DDoS атаки - атака, которая выполняется одновременно с большого числа компьютеров, говорят о DDoS-атаке (от англ. Distributed Denial of Service, распределённая атака типа «отказ в обслуживании»).

· В первую половину 2016 года проект находился в альфа-тестировании и пока майнеры хранят данные бесплатно и операции выполняются без оплаты. При дальнейшем развитии проекта, для оплаты будет использоваться протокол Filecoin[49].

На рис.8 представлен схематично процесс загрузки файла на IPFS.

Рис. 8 Загрузка данных на IPFS

На рис. 9 представлен поиск файла по хэшу. Когда файл найден и отдан пользователю, IPFS нода 2 так же кэширует файл себе.



Рис. 9 Поиск файла по хэшу

На рис.10 представлен клиент IPFS.

Рис. 10 Клиент IPFS

Безопасность

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

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

Также, технология IPFS удачно используется в реальных функционирующих проектах. Например, для хранения профиля пользователей в ChronoBank (Хроно Банк)[52] во избежание наличия back-end и централизованной базы данных для хранения данных пользователей.

На рис.7,8,9 изображен процесс выдачи ключей и алгоритм асимметричного шифрования.

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



Рис. 11 Генерация пары ключей

Рис. 12 Асимметричное шифрование сообщения

Рис. 13 Процесс расшифровывания сообщения

Рис. 14 Асимметричное шифрование в разрабатываемом комплексе

Вывод

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

· Технология блокчейн на платформе Ethereum для хранения истории взаимодействия врача и пациента без возможности изменения.

· Смарт-контракты на языке программирования Solidity платформы Ethereum для осуществления переписки врача и пациента с сохранением конфиденциальности переданной информации.

· Технология IPFS для безопасного хранения и быстрого доступа к информации.

4. Проектирование информационной системы. Программная реализация

4.1 Определение входных и выходных данных

В рамках поставленной задачи, входными данными будут являться:

1. Email (google аккаунт) регистрирующегося пользователя на платформу

2. Сведения о физическом состоянии (пульс) в формате json

Выходными данными будут являться:

1. Заключение, результаты консультации от медицинского специалиста (врача).

4.2 Проектирование информационной системы

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

На диаграмме А-0 (Приложение 1.) содержится наиболее общее описание объекта моделирования, на диаграммах А0 (рис.15), А1(рис.16) и А2 (рис.17) произведена декомпозиция и рассматривается более подробное описание модели ИТ-процесса.

На рис. 12 изображена схема взаимодействия компонентов платформы.

Рис. 15 Диаграмма А0. Обеспечение обмена и хранения персональных медицинских данных между пользователями платформы

Рис. 16 Диаграмма А1 Получение данных пациента из google fit

Рис. 17 Диаграмма А2 Получение назначение врача

4.3 Интеграция с платформой мониторинга сердечного ритма

1. В работе автора 2017 года «Исследование и разработка системы сбора и обработки информации для мониторинга сердечного ритма» схема взаимодействия компонентов разработанной системы выглядел следующим образом: (см. рис. 18.)

Рис. 18 Схема взаимодействия компонентов системы сбора и обработки информации для мониторинга сердечного ритма

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

2. Платформа синхронизируется с Google Fit через google аккаунт пользователя. Для этого пользователь перенаправляется на сервис Google Oauth и авторизуется при помощи своего google аккаунта. Авторизация на платформе осуществлялась при помощи Google Oauth Oauth -- открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. . Данный протокол позволяет пользователям не передавать логин и пароль от защищенных ресурсов третьей стороне - приложению через которую происходит авторизация, что исключает несанкционированные доступы к персональным данным. При успешной авторизации на back-end возвращается временны токен пользователя - access_token, для произведения авторизованных запросов при помощи специального rest api (набор спецификаций для работы с ресурсом через определенные запросы, протоколы, параметры и т.д.) к Google Fit в течении 24 часов.

3. Данные с Google Fit скачиваются в формате JSON JSON (англ. JavaScript Object Notation, обычно произносится как /?d?e?s?n/ JAY-s?n) -- текстовый формат обмена данными, основанный на JavaScript. по стратегии map-reduce MapReduce - это представленная компанией Google модель распределённых вычислений, а также её реализации, используемые для параллельной обработки больших объёмов информации. которая производит промежуточный подсчет данных и их фильтрацию, для получения только новых данных, не скачанных ранее, а также, у массива данных производиться расчет промежуточных значение, для уменьшения размеров хранимых данных, которые хранились в базе данных и времени на подсчет среднего значения при добавлении новых данных. И предсказывали возможные значения пульса на коротком промежутке времени при помощи линейной регрессии Линейная регрессия (англ. Linear regression) --регрессионная модель зависимости одной переменной y от другой или нескольких других переменных (факторов, регрессоров, независимых переменных) x с линейной функцией зависимости..

2.

Рассмотрим схему взаимодействия компонентов новой разрабатываемой системы: (см. рис. 19)

Рис. 19 Схема взаимодействия компонентов разрабатываемой системы

1. В работе автора данной магистерской работы (Абзаловой Л.Р.) 2017 года «Исследование и разработка системы сбора и обработки информации для мониторинга сердечного ритма» было разработано приложение, которое синхронизировалось с сервисом Google Fit для получения данных о здоровье пользователей. Преимуществом данного сервиса по-прежнему остаются обширные инструменты для разработчиков и тот факт, что все смарт-трекеры (пульсометры), как бюджетной, так и более дорогой ценовой категории, кроме Apple Watch, подключаются к сервису Google Fit для отправки снятых данных о здоровье пользователей в облако Google. Именно поэтому, в данной работе, будем продолжать использовать данный сервис.

2. Ранее с Google Fit взаимодействовал back-end и осуществлял хранение скачанных данных в базе данных. Для разрабатываемой системы, реализуем взаимодействие Front-end - клиентской стороны с Google Fit. При котором убираем часть, где осуществляется хранение данных в базе данных и заменяем у Fron-end rest api работы с back-end, на rest api работы с Google fit и взаимодействуем с ним напрямую. Также, оставляем логику работы с Google fit по части сбора и агрегирования данных пользователя (из rest api Google). Т.е. теперь клиентская сторона будет обращаться к Google fit и отображать агрегированные данные в интерфейсе пользователя.

3. Постоянное хранилище будет отсутствовать в связи с выбором децентрализованных технологий, в роли временного хранилища будет IPFS. Front-end взаимодействует с IPFS при помощи специального rest-api. В IPFS будут храниться временные данные пользователя: данные о здоровье пациента для врача, которые выбирает сам пользователь для отправки, сообщения между врачом и пациентом.

4. Внедрение технологии блокчейн при помощи rest-api. Раннее, врач и пациент могли общаться при помощи back-end, теперь взаимодействие пациента и врача будет осуществляться посредством технологии блокчейн, а именно смарт-контрактов.

5. Где же осуществлять хранение профилей пользователей, которые регистрируются на платформе, если отсутствует база данных?

Ранее было определено хранить в смарт-контрактах только хэш-ссылки на сообщения в ipfs, и полный отказ от централизованных баз данных, в связи с чем возник вопрос, где осуществлять хранение профилей пользователей с основной информацией, такой как, ФИО (фамилия, имя, отчество) и дата рождения. Решить данную проблему можно при помощи аккаунта Google с gmail почтой. Аккаунт Google хранит основную информацию пользователей и позволяет их получать сторонним приложениям при аутентификации через Google oauth.

В результате использования аккаунта Google для получения данных о пользователе посредством Google Oauth, для пользователей платформы будет установлена двухфакторная аутентификация. Двухфакторная аутентификация -- это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса данных аутентификации двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного доступа. [33] Пользователям будет необходимо вводить сначала свой приватный ключ (которые имеются у пользователей сети блокчейн, т.к. каждая транзакция подписывается приватными ключами для идентификации пользователей), затем вводить почту gmail и пароль от нее. Благодаря двухфакторной аутентификация будет получен надежный механизм защиты данных.

Итак, выбраны оставшиеся необходимые технологии:

· Google Fit для сбора данных о здоровье пользователей. Подключение к облачному сервису производится при помощи Google oauth. Обеспечение двухфакторной аутентификация: публичные/приватные ключи (асимметричное шифрование) и Google oauth

· Google аккаунт для получения профилей пользователей и их личной информации, для отказа от централизованной базы данных

На рис.20 представлены выбранные технологии, которые позволят учесть критерии к разрабатываемой системе.

Рис. 20 Выбранные технологии для учета критериев к разрабатываемому комплексу

Рис. 21. Схема взаимодействия компонентов платформы

4.4 Требования к техническим и программным средствам

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

Для реализации клиентской части, будет использоваться framework от google - angular. Он позволит быстро и эффективно спроектировать клиентскую логику.

Серверная часть:

· Linux (x86/x64/ARM) / Windows Server Edition 2008+ / MacOS X 10.7+

· Node.js 8.0+

· Geth / Parity (тестовая сеть, максимально приближенная к mainnet), (клиент для Ethereum), (в нашем случае использую - ganache-cli, локальная внутренняя сетка без истории, без блоков)

Клиентская часть:

· Браузер с поддержкой технологий: Html5, CSS3, JavaScript 6+

Стек технологий для разработки платформы (на чем написана платформа):

· Solidity 4

· Truffle 4 (для компиляции смарт-контрактов)

· Web3 (для работы смарт-контракта)

· Angular 5

4.5 Предварительный метод, как связать входные и выходные данные

Входные и выходные данные планируется связать через следующую последовательность шагов:

Регистрация на платформе. Пользователь - Пациент.

1. Пользователь - пациент переходит по ссылке на платформу.

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

3. Для регистрации необходимо использовать google аккаунт (почта - xxx@gmail.com).

4. При помощи протокола аутентификации google oauth, платформа получает доступ к ресурсам пользователя на сервисе google fit.

5. Данные пользователя, а именно его email (часть xxx от xxx@gmail.com (это и будет идентификатор пользователя, для сокращения количества хранимых байт в смарт-контракте) сохраняются в смарт контракте в структуре user и в виде ассоциативного массива ключ(адрес)-значение(пользователь): {Адрес пользователя}-{email пользователя}.

6. При помощи rest запроса до сервисов google, на frontend поступают данные о пульсе пользователя за определенный промежуток времени в формате json.

Полученные данные распарсиваются (преобразуются из строки в объект) для отрисовки на графике.

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

8. Из списка доступных врачей, зарегистрированных на платформе, пациентом выбирается врач и отправляется ссылка на данные пациента.

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

Регистрация на платформе. Пользователь - Врач.

1. Пользователь - врач переходит по ссылке на платформу.

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

3. Для регистрации необходимо использовать google аккаунт (почта - xxx@gmail.com).

4. Данные пользователя, а именно его email (часть xxx от xxx@gmail.com (это и будет идентификатор пользователя, для сокращения количества хранимых байт в смарт-контракте) сохраняются в смарт контракте в структуре user.

5. После получения ссылки на сообщение и данные пациента хранящихся в ipfs, записываются результаты консультации.

6. Данные консультации отправляются в ipfs, а ссылка на данные записывается в смарт-контракт, подписывается приватным ключом врача и отправляются пациенту.

Авторизация на платформе

1. При нажатии кнопки “Authorization” вводится приватный ключ пользователя, выданный при регистрации.

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

3. По адресу, находиться email пользователя, и просим пользователя авторизоваться при помощи google аккаунт через google oauth.

4. В случае успешной аутентификации, пользователь попадает на платформу в личный кабинет.

4.6 Программная реализация

Сценарий регистрации пользователя

1. Нажатие на кнопку Register

2. Выдача пользователю приватного ключа

3. Введение gmail, срабатывает - function isExists() для проверки существования пользователя в системе с таким адресом почты, затем срабатывает function addClient () и пользователь сохраняется в памяти смарт-контракта.

4. Вход в систему

Сценарий авторизации пользователя

1. Введение приватного ключа срабатывает - function isExists() для проверки регистрации пользователя с таким приватным ключом

2. Введение gmail и пароля для аутентификации в окне google oauth, если аутентификация пройдена успешна и от google oauth получена email пользователя, срабатывает - function getMail() и возвращает email пользователя по введенному ранее приватному ключу, далее два полученных email сравниваются, если они равны, то попадам в системы, иначе нет.