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

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

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

При создании такой базы данных предлагается отталкиваться от существующих noSql реализаций, например, Apache Cassandra, но при этом наделить нашу БД следующими свойствами:

• База публичная, идентификация пользователя (клиента) базы осуществляется по его публичному ключу (тот же самый ключ, что в блокчейне) — это ID пользователя.
• Каждый пользователь может слать транзакции в базу, каждая транзакция должна быть подписана этим пользователем.
• Созданная пользователем новая запись запоминает, что он её владелец.
• Изменять запись после создания может только её владелец (или пользователь, для которого установлено доверие через механизм разрешений, реализованный как смарт контракт на блокчейне).
• Все могут читать все записи.
• Чтобы между разными пользователями не возникало конфликтов ключей их записей, всем ключам записей пользователя делается префикс: ID пользователя.
• Более сложные разрешения можно устанавливать с помощью смарт контракта в блокчейне (например, доверие между конкретными пользователями, права на создание/удаление таблиц) и т.д.
• Все разрешения обязательно проверяются и при транзакциях, и при репликациях.

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

Это даёт надежду, что скорость работы такой схемы будет не сильно отличаться от скорости существующих реализаций noSql баз данных. Однако злоумышленник может произвести Sybil attack, генерируя пары ключей и создавая мусорные записи в БД. Эта проблема решается введением мотивации.

Мотивация

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

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

Аналогично Ethereum Swarm предполагаются следующие награды:

• Награда за извлечение данных
• Награда за хранение данных

Награды выделяются из средств пользователя, осуществляющего запросы к БД. Так как платежи через блокчейн проходят весьма долго, для быстрых платежей можно использовать два метода — off-chain транзакции и “чековые книжки”. В случае off-chain транзакций пользователю будет необходимо создавать off-chain канал с каждым узлом БД (или использовать промежуточные каналы между узлами). Учитывая, что каждый такой канал требует резервирования средств на нём, это может быть довольно накладно. Поэтому мы примем в качестве основного подход “чековой книжки”. Поясним, что это такое.

Перед обращением к базе данных пользователь должен зарезервировать часть средств на специальном смарт контракте “чековая книжка”. Далее адрес этого контракта используется узлом БД для получения вознаграждения — контракт “чековая книжка” хранит деньги своего владельца и позволяет третьим сторонам обналичивать подписанные владельцем чеки, просто посылая транзакцию с чеком в качестве данных на метод cash контракта.

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

Чек обналичивается, если

• адрес контракта соответствует адресу на чеке
• чек подписан владельцем (ID пользователя — публичный ключ)
• полная сумма на чеке больше, чем в предыдущем погашенном чеке для данного получателя

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

Награда за извлечение данных

Данные на узлах БД имеют определенный уровень репликации, то есть, данные с определенным ключом хранятся только на части узлов, например, на N. Тем не менее, за данными пользователь может обратиться к любому узлу. Узел, к которой обратился пользователь, выступает далее в качестве “координатора”.

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

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

• Чем быстрее узел вернул данные, тем большую часть оплаты он заслуживает
• Если узел вернул старые данные, оплата уменьшается
• Узел, не вернувший данные, не получает ничего
• Координатор получает фиксированную небольшую часть

Вместе с данными координатор выставляет счет, где указано, какому узлу сколько полагается. Пользователь выписывает чеки каждому. Координатор отправляет чеки узлам. А также обновленные данные, если узел не вернул ничего или вернул старые данные.

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

Награда за хранение

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

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

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

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

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

Полнотекстовый поиск, вторичные индексы

В noSql базах данных быстрый поиск с задействованием небольшого количества узлов возможен только по первичному ключу. Наша БД в этом отношении немногим отличается от них. Между тем, поиск записей по ключевым словам, а также группировка записей по каким-то критериям трудно достижима без вторичных индексов и полнотекстового поиска. Для полнотекстового поиска, а также использования вторичных индексов предлагается использовать решение, аналогичное Elassandra. Это решение представляет собой локальные полнотекстовые индексы ElasticSearch на каждом узле распределенной noSql базы Cassandra. Полнотекстовые запросы рассылаются координатором всем узлам, затем смешиваются и возвращаются клиенту. Поскольку дополнительные индексы создаются локально и независимо на каждом узле, дополнительное предотвращение проблемы византийских генералов не требуется.

Итоги

Таким образом, мы представили концепцию публичной БД, связанной с блокчейном, которая удовлетворяет требованиям для использования децентрализованными приложениями:

• Распределенность
  БД поддерживает неограниченное число реплик, каждая из которых может быть координатором. То есть, обращаясь к одной из них, пользователь получает доступ ко всем данным.
  
  
• Публичность
  БД разработан для работы в публичной среде. Новые узлы могут добавляться к сети и брать на себя часть нагрузки в любой момент.
  
  
• Устойчивость к проблеме византийских генералов и другим типам атак в публичной сети
  Учитывая, что все данные, помещенные в БД, подписываются их владельцем, узлы не могут по своему усмотрению подменить данные, как и не могут испортить данные при репликации на других узлах. Попытки подмены сразу же обнаруживаются, используя механизм электронной подписи. За попытку подмены узел-нарушитель может быть лишен регистрационного депозита и исключен из сети. Для размещения депозита, настройки прав доступа, механизмов взаиморасчетов между узлами используется внешний (для БД) блокчейн, который должен поддерживать тьюринг-полные смарт контракты.
  
  
• Поддержка шардинга (возможность репликации только части данных на каждой ноде, чтобы увеличить максимальный суммарный объем данных).
  Каждая узел БД отвечает за определенный интервал первичных ключей данных, которые он хранит. Уровень репликации (число узлов, хранящих копии данных с одним и тем же первичным ключом) задаётся отдельно и может расти с ростом сети.
  
  
• Скорость
  Принципы хранения данных позволяют предположить, что скорость записи и чтения данных в такой БД не будет сильно отличаться от текущих реализаций подобных баз данных, например, Apache Cassandra.
  
  
• Возможность хранить структурированные данные
  Данные в такой БД поддерживают структуру. Это может быть JSON документ со структурой, удобной для конкретного приложения.
  
  
• Возможность удаления данных
  Удаление данных поддерживается. Гарантировать мгновенное удаление нельзя, но в конце концов при добропорядочном поведении узлов данные будут удалены. Злонамеренный узел может сознательно сохранять все данные, которые удаляются. Однако он не сможет это сделать для всех данных, потому что ему направляются запросы только в определенном интервале первичных ключей.
  
  
• Язык запросов с возможностью осуществлять поиск не только по первичному ключу
  С помощью ElasticSearch, аналогично методам интеграции с Cassandra в проекте Elassandra возможно расширение языка запросов вторичными ключами и полнотекстовым поиском.

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

Концепция такой БД была разработана в рамках open-source проекта Сверхчеловек. Реализации ещё нет (но она явно востребована), а концепция сегодня выносится на суд общественности. Надеемся, что впервые представленная концепция публичной децентрализованной noSql БД заинтересует вас достаточно, чтобы обсудить её или даже присоединиться к разработке. Можете также присоединиться к каналу в телеграм, где можно пообщаться с разработчиками (на англ. языке).

> Первая часть статьи
> Вторая часть статьи