Full Text

Одной из основных проблем, стоящих перед системами здравоохранения во всем мире, является предоставление большого объема медицинских данных большому кругу заинтересованных сторон и обеспечение при этом целостности и конфиденциальности данных. Сегодня медицинские записи фрагментированы и хранятся разрозненно в многочисленных медицинских организациях - частных и государственных. Хранение и управление медицинскими данными в современном мире характеризуются рядом проблем. Так, существует проблема целостности данных, когда медицинские данные хранятся разрозненно. Каждая медицинская организация имеет собственную базу данных, но она чаще всего ограничена определенным учреждением. Медицинские записи пациентов в государственных медицинских организациях и вовсе чаще всего хранятся на бумажных носителях в единственном экземпляре. Для того чтобы собрать все медицинские записи воедино, пациенту придется пройти долгий путь, и на определенных этапах с большой долей вероятности окажется, что часть данных утеряна и не подлежит восстановлению. Отсюда возникает проблема утраты данных. Нередки случаи, когда истории болезни были утеряны, либо утрачены в связи с форс-мажорными обстоятельствами, что существенно влияло на качество лечения. Если человек часто переезжает с места на место и не проходит регулярных осмотров, вероятнее всего, при следующем обращении в клинику на него будет заведена новая карта без какой-либо информации о предыдущем периоде лечения. Проблема доступа к личным медицинским данным - последняя в нашем списке, но не последняя по значимости. В существующей системе медицинские записи хранятся открыто в рамках учреждения на бумажных носителях или в базах данных, пациент не может регулировать доступ к ним. Децентрализация относится к распределению управления фактическими серверами и устройствами, хранящими данные среди множества отдельных автономных узлов, что помогает гарантировать безопасность данных в связи с отсутствием единой точки отказа [1, с. 40]. Обеспечение точного и полного происхождения записей является важной целью в здравоохранении. Когда пациент получает копию собственной медицинской карты или врач получает медицинскую запись, адресат хотел бы убедиться, что данная запись является полной и правильной. Пациенты хотят быть уверенными в том, что никакая часть истории болезни не была несанкционированно изменена или неверно зафиксирована. Любая система, которая управляет электронными записями здравоохранения, должна обеспечивать механизм, посредством которого изменения в данной записи могут отслеживаться и проверяться кем-либо, у кого есть возможность прочитать запись. Аудитор, который может быть пациентом или врачом, должен иметь возможность определить, когда было создано определенное значение для определенного атрибута, а также какие данные были зафиксированы до этого, при условии любого полезного и разумного ограничения конфиденциальности, которое может установить владелец данных - пациент. Благодаря надежному механизму отслеживания изменений получатели данных могут быть уверены, что данные, которыми они оперируют, являются продуктом разумного процесса ведения документации, и если наблюдаемое изменение истории находится в большом противоречии с ранее наблюдаемой историей или иным образом указывает на поведение вне разумных ожиданий, то получатель данных имеет право требовать пояснений от предыдущих врачей. Любая система без надежного отслеживания изменений не может обеспечить это ключевое свойство, поскольку получателю данных становится намного сложнее установить аутентичность любых данных, особенно когда они не соответствуют ожиданиям [2]. Таким образом, мы не рассматриваем системы, не имеющие возможности отслеживания изменения данных, что позволило нам представить указанные ниже. 1. Традиционная, централизованная структура данных. Полностью централизованная модель предполагает, что пользователи доверяют единому централизованному органу, который выполняет всю аутентификацию, авторизацию, обработку данных, Проблема в том, что здравоохранение - это система, в которой часто добавляются данные и запрашивается доступ к уже существующим. Таким образом, естественная эволюция использования традиционной централизованной структуры данных привела к сегодняшнему состоянию, когда многие медицинские учреждения поддерживают собственные базы данных, основанные на ограниченной информации. В этих организациях нет доступа к единому пулу данных, а пациенты должны прилагать усилия, чтобы согласовать, объединить и унифицировать данные медицинских карт в случае смены медицинского учреждения [3]. 2. Распределенная база данных с отслеживанием изменений. Необходимо реализовать безопасную распределенную систему управления версиями, которая позволяет устанавливать режимы доступа для чтения и для записи. Запись должна быть безопасной и конфиденциальной, чтобы различные заинтересованные организации могли получать статистические данные о медицинских записях без доступа к исходным данным [4]. Можно представить себе распределенную систему серверов, которая отслеживает большой объем данных с течением времени и способна откатываться назад в любое предыдущее состояние. Изменения записи должны быть представлены в виде наборов изменений предыдущего состояния системы. Системы управления версиями могут служить полезным инструментарием для понимания использования описанного механизма. Предположим, имеется главная ветвь, в которой содержатся все актуальные записи относительно пациента и его истории болезни, к которой получает доступ врач. В процессе диагностики и лечения пациента врач может изменить локальную ветку, а затем представить изменения в главную ветку, когда диагноз был поставлен. Здесь встает важный вопрос: кто физически контролирует данные? В качестве управляющего данными органа могут выступать государственные органы, сами пациенты, неправительственные трастовые сети серверов (аналогичная Bitcoin минус Proof-of-work) и прочие. Любой из этих вариантов может быть жизнеспособным [5, с. 48]. 3. Частные блокчейны. Частные блокчейны лишены преимуществ децентрализованной сети, способной к бесконтрольным транзакциям и надежному консенсусу. В этом случае блокчейн и весь майнинг-пул управляется одним субъектом, который превращается в традиционную централизованную систему. Вероятнее всего, данный стандарт должен быть санкционирован государством или местными органами самоуправления, поэтому лучше просто назначить стандартный формат данных для обычных записей. 4. Частично открытые блокчейны. Частично открытый блокчейн состоит из нескольких доверенных узлов, которые совместно создают публичный блокчейн и пытаются заменить распределенную сеть добровольных майнеров собственными компьютерами, обрабатывающими транзакции [6]. В области здравоохранения такая группа, вероятно, будет включать регуляторы, поставщиков медицинских услуг и плательщиков. Такая система более безопасна, чем полностью публичный блокчейн, поскольку организации могут агрегировать вычислительные мощности для обеспечения работы системы. Кроме того, данные реплицируются на каждый узел, в результате чего в системе отсутствует единая точка отказа. Осуществление действий внутри блокчейна также становится более дешевым в сравнении с публичной сетью, поскольку требуется менее «расточительное» доказательство работы (Proof-of-work) [7]. Но удаление пациентов как равноправных участников взаимодействия делает систему менее гибкой. 5. Публичные, открытые блокчейны. Несомненно, нежелательно размещать медицинские записи в открытом виде непосредственно в таком блокчейне, поскольку любая информация, передаваемая публичному блокчейну, доступна каждому, кто имеет доступ в интернет, что создает проблему конфиденциальности для пациента. Кроме того, при использовании такого блокчейна, как Bitcoin, должны быть соблюдены ограничения на хранение данных. Для Bitcoin это ограничение составляет байт данных, которые могут быть переданы вместе с транзакцией, поэтому полная медицинская документация не может быть легко сохранена напрямую [8]. Однако если используется вторичный механизм хранения данных, например распределенная хеш-таблица с механизмом открытого доступа и пользовательского контроля доступа, тогда появляются необходимые инструменты для создания разумной конфиденциальности, соответствующей электронной медицинской системе. Правильно созданная архитектура подобного рода дает пациенту доступ и контроль над своими полными медицинскими записями, не налагая особой нагрузки на ее хранение или передачу [9]. В настоящее время разработки в данной области ведутся Массачусетским технологическим институтом (MIT, проект «MedRec»), эстонским фондом E-HEALTH (Estonian eHealth Foundation), компанией Phillips (проект «Gem»), компанией IBM. Технология блокчейн должна быть хорошо понята разработчиками программного обеспечения, поскольку использование данной концепции приведет к изменению алгоритма написания программных продуктов в будущем [10]. Чаще всего блокчейн (blockchain, буквально - цепь блоков) определяют как учетную книгу или журнал, как распределенную базу данных или реестр записей (транзакций), объединенных в блоки (страницы, если использовать аналогию с книгой или журналом). Также блокчейн (от англ. block и chain) - это цепочка блоков, или, точнее, распределенная база данных; блокчейн - это журнал с фактами, реплицируемый на несколько компьютеров, объединенных в сеть равноправных узлов (P2P) [11]. Другие исследователи считают, что блокчейн представляет собой распределенную учетную книгу записей о событиях в цифровом мире. Ключевой составляющей блокчейна является журнал транзакций, а сами транзакции - это единственный способ изменить состояние реестра. Таким образом, блокчейн представляет собой распределенную базу данных, журнал или книгу, для которой многие компьютеры поддерживают одинаковые копии и соглашаются на упорядочение информации, не доверяя друг другу или какой-либо третьей стороне [12]. Важной особенностью журнала транзакций в блокчейне является его неизменность. Это свойство означает, что нельзя незаметно удалить транзакцию из журнала или добавить новую в его середину. Факты, хранящиеся в блокчейне, не могут быть утеряны. Они остаются там навсегда, реплицируясь на каждый узел. Более того, блокчейн не просто хранит конечное состояние, он хранит и все предыдущие состояния. Поэтому каждый может проверить правильность, пересчитывая факты с самого начала. Как было отмечено выше, блокчейн является неизменной линейной последовательной цепочкой из блоков. Блоки могут содержать транзакции, файлы или любые другие данные. Новые блоки всегда добавляются строго в конец цепочки [13]. Из сказанного выше можно сделать вывод, что технология, основанная на блокчейне, является жизнеспособным выбором для хранения медицинских данных пациентов и управления ими. Децентрализация может стать благоприятной, минимизировав требуемые доверительные отношения. Слабые стороны, которые в настоящее время присущи технологии блокчейн, такие как отсутствие обработки больших объемов данных и трудности обработки частных данных, можно все чаще компенсировать с привлечением других технологий и уделить значительное внимание разработчиков блокчейна устранению текущих недостатков [14]. Основным языком написания приложения является JavaScript (ES2015) [15]. Данный язык позволяет писать код и для клиентской, и для серверной части веб-приложения. JavaScript поддерживает как функциональный, так и объектно-ориентированный стили при разработке приложения, что может оказаться удобным при написании клиентского и серверного кода. В качестве среды, в которой выполняется приложение, был выбран Electron - библиотека с открытым исходным кодом для создания кросс-платформенных приложений с помощью HTML, CSS и JavaScript, разработанная GitHub [16]. Главная причина, по которой было принято решение использовать Electron, а не создавать браузерное приложение, - избежание передачи приватных ключей между сервером и клиентом [17]. Идея состоит в том, чтобы создавать криптографическую пару ключей на стороне клиента и хранить их в этом же месте, чтобы не произошло утечки приватного ключа пользователя и его личные медицинские данные не были скомпрометированы. Electron достаточно прост в освоении, и разработка на нем практически не отличается от разработки в браузере [18]. В качестве библиотеки для разработки интерфейса был выбран React. В React используется компонентный подход, ведь компоненты - это своего рода строительные единицы, из которых собирается интерфейс. Для управления состоянием была выбрана библиотека Redux. Redux является предсказуемым контейнером состояния для приложений JavaScript и подходит для одностраничных приложений, в которых управление состоянием со временем может становиться сложным. Redux отлично работает в связке с React [19]. В качестве UI библиотеки была выбрана библиотека MaterialUI. Библиотека представляет собой необходимый набор основных компонентов с соответствующей логикой для разработки пользовательских интерфейсов на React. Данную библиотеку особенно удобно использовать при создании прототипов систем, поскольку готовые элементы интерфейса позволяют вести разработку быстро и качественно. В качестве сборки JavaScrip-модулей и каскадных таблиц стилей был использован Webpack. Webpack удобен для работы с одностраничными приложениями, воспринимает как require- так и import-синтаксисы модуля, позволяет осуществлять продвинутое разделение кода, имеет Hot Reload для более быстрой разработки с помощью React, Vue.js и подобных фреймворков. Для серверной части приложения, которая выступает скорее в качестве API для взаимодействия с базой данных, был выбран Node.js и фреймворк Express. Node.js хорош для создания быстрых масштабируемых сетевых приложений, поскольку позволяет одновременно обрабатывать огромное количество соединений с большой пропускной способностью, что равноценно высокой масштабируемости. Node.js имеет пакетный менеджер и менеджер зависимостей NPM, позволяющий легко загружать необходимые для разработки модули прямо из сети [20]. Предполагается, что серверная часть разрабатываемого прототипа не должна выполнять сложных вычислений, нагружающих процессор, поскольку практически все энергозатратные операции (генерация криптографических ключей, кодирование и декодирование данных) производятся на клиентской стороне. В качестве базы данных была выбрана MongoDB. MongoDB - это документоориентированная система управления базами данных (СУБД), ключевой особенностью которой является хранение JSON-данных, сгруппированных в «коллекции». В таком формате можно хранить любые JSON-документы и удобно категоризировать их по коллекциям [21]. Содержащийся в MongoDB JSON-документ называется двоичным JSON или BSON и является неструктурированным, как любой другой документ этого формата. Поэтому, в отличие от традиционных СУБД, в коллекциях можно сохранять любые виды данных, и эта гибкость сочетается с горизонтальной масштабируемостью базы данных. Данные, сохраненные в формате JSON, позволяют Node.js функционировать без потери соответствия и без преобразования данных [22]. Зачастую необходимо отслеживать некоторые изменения в приложении в режиме реального времени. Например, когда Врач отправляет Пациенту запрос на доступ, Пациент, находящийся в сети, должен иметь возможность сразу же его получить и отреагировать или проигнорировать. Для данной цели при разработке прототипа была использована технология WebSocket. Соединение постоянно держится открытым, но не передает лишних HTTP-заголовков. При этом в веб-сокетах нет ограничений на количество соединений. В качестве блокчейна был выбран протокол Ethereum. Ethereum разрабатывался для создания децентрализованных приложений на основе блокчейн. В блокчейне Ethereum возможно совершать транзакции с нулевым полем value; это означает, что мы можем передавать, сохраняя в сети блокчейн, некоторые данные, переданные с транзакцией. Каждый блок в цепочке идентифицируется хешем, сгенерированным с использованием алгоритма криптографического хеширования SHA 256 в заголовке блока. Каждый блок также ссылается на предыдущий блок, известный как родительский блок, через поле previous block hash в заголовке блока. Последовательность хешей, связывающих каждый блок с его родителем, создает цепочку, возвращающуюся полностью к первому блоку, когда-либо созданному, известному как блок генезиса. Блок генезиса является общим предком всех блоков в цепочке, а это означает, что если начать с любого блока и следовать по цепочке вверх, в конечном итоге мы прибудем к блоку генезиса. Каждый узел всегда «знает» хеш и структуру блока генезиса, фиксированное время его создания и даже одну транзакцию внутри. Таким образом, каждый узел имеет начальную точку для блок-цепи - защищенный «корень», из которого создается надежная блок-цепочка [23]. Каждый блок в цепи имеет только одного родителя, он может временно иметь несколько дочерних элементов. Каждый из дочерних блоков относится к тому же блоку, что и его родительский элемент, и содержит тот же (родительский) хеш в поле previous block hash. Несколько дочерних элементов возникают во время «разветвления» цепочки (fork). Это временная ситуация, возникающая, когда разные блоки обнаруживаются почти одновременно разными способами. В итоге только один дочерний блок становится частью блок-цепи, и «вилка» разрешена. Даже если блок может иметь более одного дочернего элемента, он всегда имеет только одного родителя [24]. Поле previous block hash находится внутри заголовка блока и тем самым влияет на хеш текущего блока. Когда родительский блок каким-либо образом изменяется, то изменяется его хеш, следовательно, изменяются все хеши его дочерних блоков до самого нижнего (последнего) блока. Этот каскадный эффект гарантирует: когда блок будет иметь много поколений после него, блок нельзя изменить без принудительного пересчета всех последующих блоков, поскольку такой перерасчет потребует огромных вычислений. Существование длинной цепочки блоков делает историю блокчейна неизменной, что является ключевой особенностью безопасности сети [25]. Блок представляет собой некий контейнер, объединяющий транзакции для включения в публичный реестр - блокчейн. Блок состоит из заголовка, содержащего метаданные, и тела из списка транзакций. Заголовок блока состоит из трех наборов метаданных. Во-первых, это ссылка на предыдущий хеш блока, который соединяет этот блок с предыдущим блоком в цепочке блоков [26]. Второй набор метаданных - сложность, временная метка и некое случайное число (nonce), заполняемые майнерами. Третьей частью метаданных является корень дерева Меркла - структура данных, используемая для эффективного суммирования всех транзакций в блок. Дерево Меркла, известное также как двоичное хеш-дерево, представляет собой структуру данных, используемую для эффективного обобщения и проверки целостности больших наборов данных. Деревья Меркла - это двоичные деревья, содержащие криптографические хеши [27]. Термин «дерево» используется в информатике для описания структуры ветвящихся данных, но эти деревья обычно отображаются с «корнем» вверху и «листьями» внизу диаграммы. Деревья Меркла используются в блокчейне для суммирования всех транзакций в блоке, создавая общий цифровой отпечаток всего набора транзакций, обеспечивая очень эффективный процесс проверки того, включена ли транзакция в блок. Дерево Меркла создается рекурсивно хеширующими парами узлов, пока не останется только один хеш, называемый корнем или корнем Меркла. Несмотря на то что блокчейн и является распределенной системой, а формировать транзакции может каждый узел, это не означает, что все участники блокчейн-сети равноправны: почти в любой реализации этой технологии введено распределение ролей на майнеров (участников, пишущих транзакции в журнал), аудиторов и легких клиентов. Такое разделение справедливо не только для приватных блокчейнов, но и для открытых блокчейнов, например Bitcoin. Легкие клиенты не имеют полной версии блокчейна и содержат лишь данные, которые важны для узла. Второй тип - узлы аудита не участвуют в процессе консенсуса, однако имеют у себя полную копию блокчейна. «Аудиторы» регулярно проверяют работу майнеров и занимаются распределением нагрузки по сети, выполняя функцию своеобразной сети доставки контента (Content Distribution Network, CDN) для данных блокчейна. Третий тип - майнеры, или узлы консенсуса. Майнеры активно участвуют в формировании блокчейна, постоянно группируя входящие транзакции в блоки и распространяя их по сети. Процесс поиска блоков называется майнингом [28]. Майнер должен в течение короткого промежутка времени решить действительно трудную вычислительную головоломку. Этот механизм, известный как «доказательство работы» (Proof of Work), был создан для обеспечения того, чтобы никто не обладал монопольной властью над возможностью писать в журнал и не смог таким образом манипулировать его содержанием или подвергать цензуре включенную в него информацию. Любой, у кого достаточно вычислительных ресурсов для решения задачи, может добавлять блоки к цепочке. Частым явлением может стать ветвление цепи, когда одновременно формируется несколько новых блоков, каждый из которых имеет один и тот же блок в качестве родительского. Ветвление прекратится, как только будет найден новый блок, который продолжит любую из ветвей. Все узлы переключатся на ту цепь, которая имеет самую длинную версию, и продолжат работать над ее удлинением. Для создания нового блока майнеру необходимо решить на своем оборудовании задачу, которую выдает сеть. У каждого блока есть свое уникальное решение, которое также записывается в заголовок блока. Эта задача сложна для решения и занимает большое количество времени, но как только один из пользователей (майнеров) решает задачу, остальная сеть очень быстро подтверждает, что решение верно. Существует несколько решений для каждого блока, достаточно найти хотя бы одно из них. Транзакции транслируются на всю сеть отправителем, узлы собирают информацию о них и, руководствуясь определенными условиями, включают их в найденный блок. Время генерации управляемого блока достигается добавлением значений сложности внутри блока. В блокчейне Bitcoin хеш блока должен быть строго меньше заданного значения, которое должно быть принято. Данное значение изменяется в зависимости от общей вычислительной мощности сети. Чем мощнее сеть, тем меньше заданное значение и тем сложнее создать блок. Сложность задачи регулируется сетью таким образом, чтобы в среднем находилось определенное количество блоков, для Bitcoin это шесть блоков в час (один блок в 10 мин). В настоящий момент принято выделять два типа блокчейнов: публичные (например, блокчейн Bitcoin и Ethereum), доступные для любого человека в мире, и приватные или частные - с ограниченным членством [29]. Публичный блокчейн - это блокчейн, который может прочитать любой человек в мире, любой человек в мире может отправлять транзакции и ожидать их включения, если они действительны, и любой человек в мире может участвовать в процессе консенсуса - процессе для определения, какие блоки добавляются в цепочку и каково текущее состояние всей цепи. В качестве замены централизованного или квазицентрального доверия публичные блокчейны защищены криптоэкономикой - сочетанием экономических стимулов и криптографической проверки с использованием таких механизмов, как доказательство работы или доказательство заинтересованности, в соответствии с общим принципом, согласно которому степень, влияние в процессе консенсуса пропорционально количеству экономических ресурсов, которые они могут принести. Эти блокчейны обычно считаются «полностью децентрализованными». Хотя эта избыточность делает публичный блокчейн чрезвычайно безопасным, она также делает его медленным и расточительным. Расход электроэнергии, необходимый для выполнения каждой транзакции, увеличивается с каждым дополнительным узлом и в итоге может стать непомерно большим. Преимущество заключается в том, что каждая транзакция является общедоступной и пользователи могут поддерживать анонимность. Полную версию блокчейна может скачать любой желающий, с учетом того что блокчейн развивается уже не только для транзакций, но и в качестве реестра различных событий, и также дает возможность работы различных приложений [30]. Децентрализованный, открытый и криптографический характер блокчейна позволяет людям доверять друг другу и взаимодействовать друг с другом, что делает ненужным использование посредников. Это также обеспечивает беспрецедентные преимущества в плане безопасности. Например, если кто-то захотел взломать конкретный блок в блок-цепочке, хакеру понадобится взломать не только этот конкретный блок, но и все последующие блоки, которые возвратят историю этой блок-цепи. Помимо прочего, злоумышленник должен будет внести изменения в каждый экземпляр блокчейна внутри сети, которая в свою очередь может состоять из миллиона, но одновременно. Ethereum блокчейн - платформа для создания DApp. Определение понятия DApp - Decentralized Application, или децентрализованное приложение. Децентрализованное приложение может быть реализовано с использованием разных технологий, но среди них есть и блокчейн со смарт-контрактами. Можно сказать, что на данный момент DApp - это логика на смарт-контрактах, объединенная с пользовательским интерфейсом. Хранение больших объемов данных и обмен сообщениями в идеальном DApp тоже должны быть децентрализованными, однако эти технологии только начинают появляться. С помощью DApp пользователь может получить доступ к блокчейну напрямую на своем компьютере, установив специальное программное обеспечение (ПО). Блокчейн также может использоваться для отдельных операций на стороне сервера привычных нам мобильных и веб-приложений. Упрощенный вариант DApp можно представить в следующем виде: фронтенд и бэкенд в данном случае - классические элементы приложения, а функциональность с задействованием блокчейна выполняется на виртуальной машине EVM. Ethereum - это блокчейн, основанный на идеях Bitcoin. Данный протокол считается блокчейном нового поколения, блокчейном версии 2.0, обеспечивает возможность быстрого и простого создания децентрализованных приложений на основе блокчейн-технологии. Как и Bitcoin, Ethereum децентрализован: никто не регулирует, не владеет им, у него есть своя криптовалюта под названием «эфир». Тем не менее у Ethereum есть несколько нововведений, которые стоит отметить. Первое из них - это «умные контракты», второе - собственная виртуальная машина, которая управляет памятью и приложениями в сети. В первоначальной форме умные контракты присутствуют и в Bitcoin, но создатель криптовалюты Сатоши Накамото намеренно ограничил их возможности. Для описания условий сделок в Bitcoin встроен язык программирования под названием Script. Он напоминает Forth, но не позволяет устраивать циклы, не сохраняет состояние между вызовами и лишен доступа к данным транзакции или блокчейна. Этого хватает только на самые простые задачи. Тьюринг-полные языки программирования Ethereum, такие как Solidity (схож с Javascript) и Serpent (схож с Python), напротив, позволяют реализовать практически любую идею. Вместо того чтобы предоставлять пользователям набор предопределенных операций, таких как транзакции Bitcoin, Ethereum позволяет пользователям разрабатывать собственные операции с уровнем сложности, который отвечает их потребностям. В Ethereum контракты чаще всего описывают на полноценном объектно ориентированном динамическом языке, который напоминает JavaScript. Код контракта исполняется при получении сообщений от пользователя или другого контракта. Он может принимать и отправлять деньги и работать с данными в постоянном хранилище, которое прилагается к каждой транзакции. В финале скрипт возвращает вычисленный результат отправителю сообщения. Глобальное «общее состояние» Ethereum состоит из множества небольших объектов («учетных записей»), которые могут взаимодействовать друг с другом через инфраструктуру передачи сообщений. У каждой учетной записи есть связанное с ней состояние и 20-байтовый адрес. Адрес в Ethereum - это 160-битный идентификатор, который используется для идентификации любой учетной записи. Существуют два типа учетных записей: внешние учетные записи, которые контролируются закрытыми ключами и не имеют никакого кода, связанного с ними, и контрактные учетные записи, которые контролируются кодом контракта, загруженным в него. Важно понимать фундаментальное различие между внешними учетными записями и контрактными. Внешняя учетная запись может отправлять сообщения другим внешним счетам или другим учетным записям, создавая и подписывая транзакцию с использованием своего закрытого ключа. Сообщение из внешней учетной записи на контрактную учетную запись активирует код учетной записи контракта, позволяя ему выполнять различные действия (создавать и переносить токены, записывать во внутреннее хранилище, выполнять некоторые вычисления, создавать новые контракты и т. д.). Любое действие, которое происходит на блокчейне Ethereum, всегда приводится в действие транзакциями, запущенными из внешних контролируемых учетных записей. Каждое вычисление, которое происходит в результате транзакции в сети Ethereum, берет плату (gas). При каждой транзакции отправитель устанавливает лимит газа и цену на газ. В случае если отправитель не предоставляет необходимый газ для совершения транзакции, транзакция запускается «без газа» (gas free) и считается недействительной. В случае прерывания обработки транзакций любые изменения состояния, которые произошли, изменяются таким образом, что блокчейн возвращается в состояние до транзакции. Одним из важных аспектов работы Ethereum является то, что каждая операция, выполняемая сетью, одновременно выполняется каждым полным узлом. Однако вычисления на виртуальной машине Ethereum очень дороги. Таким образом, умные контракты Ethereum лучше всего использовать для простых задач, таких как запуск простой бизнес-логики или проверка подписей и других криптографических объектов, а не более сложных, как, например, хранение файлов, электронная почта или машинное обучение, что может вызвать нагрузку на сеть. Для выполнения транзакции должны соответствовать первоначальному набору требований. Транзакция должна быть правильно отформатированной в RLP-формат. RLP означает «рекурсивный префикс длины» и представляет собой формат данных, используемый для кодирования вложенных массивов двоичных данных. На балансе счета отправителя должно быть достаточно эфира для покрытия «авансовых» расходов на газ, которые отправитель должен заплатить. Если рассматривать Ethereum как платформу для гарантированных вычислений, то по сравнению с традиционными системами у него есть следующие плюсы: -авторизация пользователя через криптографические подписи; -полностью настраиваемая логика транзакции и изменения состояний; -устойчивость к DDoS-атакам; -нет единой точки отказа сети; -история всех действий сети хранится в открытом доступе в децентрализованной распределенной базе данных (блокчейне). Таким образом, основное внимание было уделено платформе Ethereum, поскольку данный протокол блокчейн имеет на текущий момент ряд преимуществ среди прочих. Одним из преимуществ является то, что Ethereum разрабатывался в качестве платформы для создания децентрализованных приложений, поэтому в Ethereum предусмотрено создание и запуск «умных контрактов», для их написания предложены Тьюринг-полные языки - Solidity и Serpent. Промежутки подтверждения блоков в сети Ethereum составляют примерно 14 с, что гораздо быстрее в сравнении с тем же Bitcoin, где для этого требуется 10 мин. Транзакции в сети Etherium возможно отправлять с нулевым value, т. е. передавать с транзакцией исключительно данные, не передавая при этом активы. Это как раз то, что нам необходимо, ведь одной из главных задач прототипа является фиксирование медицинских данных в блокчейне. Основным минусом использования публичной сети Ethereum является то, что каждое вычисление, которое происходит в результате транзакции в сети Ethereum, берет плату (gas), но данная проблема не специфична именно для Ethereum: в любой блочной сети, где существуют майнеры, существуют и комиссии за транзакции. В ходе изучения проблем хранения медицинских данных и вариантов решения этих проблем удалось выявить главные факторы, которым должны соответствовать разработки в области хранения медицинских данных. В первую очередь это обеспечение целостности данных. При обработке данных исследований или результатов испытаний, чья целостность может напрямую влиять на здоровье людей, необходима уверенность, что эти данные не были подделаны с момента создания. Таким образом, существует заинтересованность любого лица в проверке того, что данные исследований защищены твердой цепочкой поставок с момента появления. Вторым фактором является обеспечение безопасности данных. Записи не должны быть получены людьми, у которых нет прав на их просмотр, но доступны всем сторонам, у которых такое право имеется. Третий фактор - обеспечение сохранности данных, невозможности их удаления или изменения. Для преодоления вышеописанных проблем система управления данными должна отвечать следующим требованиям: возможность отслеживания изменений, децентрализация и репликация данных. Для того чтобы определиться, какая модель хранения данных наилучшим образом подходит для нашего случая и помогает преодолеть вышеописанные проблемы, рассмотрены несколько структур данных, а именно: структуры данных без отслеживания изменений, традиционная, централизованная структура данных, распределенная база данных с отслеживанием изменений, приватный блокчейн, частично публичный блокчейн и публичный блокчейн. В ходе анализа вышеназванных структур данных выявлено, что публичный блокчейн наиболее соответствует выдвинутым требованиям, которым должна соответствовать модель хранения медицинских данных. Правильно созданная архитектура подобного рода дает пациенту доступ и контроль над своими полными медицинским записями, не налагая особой нагрузки на хранение или передачу данных. А при использовании вторичного механизма хранения данных, например распределенной хеш-таблицы, мы решим проблему ограничения на хранение данных в блокчейне. Среди требований к хранилищам данных для децентрализованных приложений мы выделили распределенность, поддержку шардинга, скорость работы, структурированность, неизменяемость. Среди рассмотренных вариантов была выбрана технология, наиболее соответствующая вышеуказанным критериям, созданная на основе технологии блокчейн и распределенных баз данных BigchainDB. Поскольку наш прототип будет использовать для хранения данных публичный блокчейн, необходимо подумать о том, как защитить персональные данные. В качестве защиты было выбрано шифрование данных, при этом было принято решение применять как симметричный, так и асимметричный алгоритмы шифрования. При разработке прототипа были обозначены основные требования. 1. В прототипе должна быть предусмотрена авторизация для двух типов пользователей: Пациента и Врача. 2. Должны быть реализованы панели управления для Врача и Пациента. 3. Врач должен иметь возможность найти Пациента с помощью функции поиска. 4. Врач должен иметь возможность отправлять запросы на доступ к медицинским данным Пациента и просматривать медицинские записи, если такой доступ был одобрен. 5. Врач должен иметь возможность добавлять записи в медицинскую карту конкретного Пациента. 6. Пациент должен иметь возможность подтверждать или отклонять запросы доступа, поступающие от Врачей, а также удалять из списков доступа тех Врачей, в доступе которых он больше не заинтересован. Удаление из списков доступа должно полностью лишать Врача возможности обращения к медицинской карте Пациента. 7. Каждая запись в медицинской карте Пациента должна быть неизменной и должна храниться в зашифрованном виде. Шифр медицинской карты может расшифровать только владелец данной карты, имеющий приватный ключ. 8. Все криптографические операции должны осуществляться на стороне клиента, а не на стороне сервера, приватные ключи также должны храниться на клиентской стороне. Для разработки использовались технологии JavaScript, Electron, Node.js, Express и MongoDB, React, Redux и Webpack, WebSoket, Ethereum Blockchain и BigchainDB. Таким образом, в ходе разработки прототипа были реализованы: 1. Авторизация и регистрация для Пациента и Врача. 2. Панель управления Пациента, включающая его персональную информацию, список из последних четырех запросов доступа и четырех последних одобренных Врачей с возможностью просмотра полных списков. 3. Возможность для Пациента отклонять или подтверждать запросы доступа к личным медицинским данным, а также возможность удалять Врачей с лишением доступа к личным медицинским данным Пациента. 4. Шифрование публичным ключом Врача медицинских данных Пациента, который одобрил доступ конкретного Врача, и сохранение медицинской карты в базе данных приложения с возможностью последующего удаления данных Пациентом из базы данных приложения. Таким образом, все данные сохраняются исключительно в зашифрованном виде. 5. Возможность Пациента просматривать свои личные медицинские записи. 6. Панель управления Врача с возможностью просмотра всех доступных Пациентов и перехода к медицинской карте конкретного Пациента. 7. Возможность Врача осуществлять поиск по Пациентам и отправлять запросы на доступ к медицинским данным. 8. Возможность просматривать медицинские данные доступных Пациентов и добавлять в медицинскую карту новые медицинские записи. 9. Шифрование каждой новой медицинской записи (осуществляемой Врачом) публичным ключом данного конкретного Пациента, за счет чего обеспечивается защищенность медицинских данных Пациента. 10. Осуществление криптографических операций на стороне клиента, что уменьшает возможность хищения приватного ключа и компрометации личных медицинских данных Пациента. 11. Фиксация каждой медицинской записи внутри блокчейн, что обеспечивает иммутабельность данных и их целостность, т. е. данные не могут быть изменены, перезаписаны или стерты. Благодаря тому что данные реплицируются на несколько узлов, мы избавляемся от единой точки отказа системы, что также позволяет обеспечить целостность данных и агрегирование их в одном месте, а не во множестве разрозненных баз данных множества медицинских организаций. Исследование не имело спонсорской поддержки. Авторы заявляют об отсутствии конфликта интересов.

About the authors

A. V. Polyanin

The Federal State Budget Educational Institution of Higher Education “The Russian Academy of National Economy and Governmental Service under the President of the Russian Federation”, the Central Russian Institute of Management-the Branch

I. A. Dokukina

The Federal State Budget Educational Institution of Higher Education “The Russian Academy of National Economy and Governmental Service under the President of the Russian Federation”, the Central Russian Institute of Management-the Branch

Email: irenalks@mail.ru

References

Statistics