- PVSM.RU - https://www.pvsm.ru -
В первой части статьи [1] мы обнаружили проблемы с хранением данных приложений в блокчейне. Во второй части [2] мы описали требования к хранилищу данных и рассмотрели, насколько существующие реализации отвечают этим требованиям. Результаты были неутешительные — удовлетворительной реализации не нашлось. В данной части мы предложим концепцию децентрализованного хранилища данных, которое удовлетворяет поставленным требованиям. Разумеется, для более глубокого понимания сути происходящего рекомендуется просмотреть две предыдущие [1] части [2].
Итак, текущие реализации [2] хранилищ по тем или иным параметрам не удовлетворяют требованиям к базе данных, которая подойдет широкому классу децентрализованных приложений на блокчейне.
При том, что в угоду скорости допустима нежесткая связь с блокчейном (то есть, не все транзакции будут проходить через блокчейн), она должна быть устойчива к злонамеренному поведению других узлов БД, обеспечивать достаточный уровень репликации, иметь механизмы мотивации участников на поддержку сети. То есть, такая база будет нуждаться в поддержке блокчейна со смарт контрактами.
При создании такой базы данных предлагается отталкиваться от существующих noSql реализаций, например, Apache Cassandra [3], но при этом наделить нашу БД следующими свойствами:
Обязательная криптографическая подпись каждой записи гарантирует, что её изменение или удаление злонамеренной стороной без знания личного ключа владельца записи невозможно. То есть, таким образом построенное хранение данных устойчиво к византийской проблеме [4] даже без механизма консенсуса.
Это даёт надежду, что скорость работы такой схемы будет не сильно отличаться от скорости существующих реализаций noSql баз данных. Однако злоумышленник может произвести Sybil attack [5], генерируя пары ключей и создавая мусорные записи в БД. Эта проблема решается введением мотивации.
Публичная сеть предполагает, что участники могут свободно присоединяться к ней, предоставляя оборудование, усиливающее вычислительную мощь, объемы хранения информации и распределенность сети. Для стимуляции такого поведения владельцы оборудования должны получать вознаграждение, мотивирующее их на честную работу.
Это означает, что операции с БД будут платными для конечного пользователя. Это может дико звучать для человека, не знакомого с блокчейном, но вполне обосновано. Дело в том, что блокчейн проекты чаще всего не имеют собственника. Ими владеет сообщество. В результате само же сообщество должно оплачивать издержки на функционирование проекта. Деньги совсем небольшие, но ненулевые. Существующие децентрализованные хранилища файлов, которые мы рассмотрели в предыдущей части статьи, также взимают с пользователя плату за хранение файлов. И нам без этого никуда, на базовом уровне функционирование оборудование должно оплачиваться его пользователями. В принципе, эти затраты могут потом компенсироваться из других источников, но эта темы выходит за рамки данной статьи.
Аналогично Ethereum Swarm [6] предполагаются следующие награды:
Награды выделяются из средств пользователя, осуществляющего запросы к БД. Так как платежи через блокчейн проходят весьма долго, для быстрых платежей можно использовать два метода — off-chain транзакции [7] и “чековые книжки”. В случае off-chain транзакций пользователю будет необходимо создавать off-chain канал с каждым узлом БД (или использовать промежуточные каналы между узлами). Учитывая, что каждый такой канал требует резервирования средств на нём, это может быть довольно накладно. Поэтому мы примем в качестве основного подход “чековой книжки”. Поясним, что это такое.
Перед обращением к базе данных пользователь должен зарезервировать часть средств на специальном смарт контракте “чековая книжка”. Далее адрес этого контракта используется узлом БД для получения вознаграждения — контракт “чековая книжка” хранит деньги своего владельца и позволяет третьим сторонам обналичивать подписанные владельцем чеки, просто посылая транзакцию с чеком в качестве данных на метод cash контракта.
Чек обналичивается, если
Тогда при необходимости вознаградить узел БД, пользователь просто шлет ей чек. Узел-получатель может сохранять только последний полученный чек от каждого пользователя и периодически обналичивать его, посылая на контракт “чековая книжка”, что позволяет при некотором доверии экономить на транзакциях блокчейна.
Данные на узлах БД имеют определенный уровень репликации, то есть, данные с определенным ключом хранятся только на части узлов, например, на N. Тем не менее, за данными пользователь может обратиться к любому узлу. Узел, к которой обратился пользователь, выступает далее в качестве “координатора”.
По значению ключа данных вычисляются N узлов, ответственные за хранение этих ключей, и запросы направляются к ним. Возвращенные узлами данные проверяются координатором на соответствие электронным подписям, сравниваются по метке времени, и самая свежая запись возвращается пользователю.
Оплате подлежит работа координатора и реплик, хранящих данные. Пропорции оплаты подлежат более подробному расчету, но для стимуляции правильного поведения необходимо выполнять следующие принципы:
Вместе с данными координатор выставляет счет, где указано, какому узлу сколько полагается. Пользователь выписывает чеки каждому. Координатор отправляет чеки узлам. А также обновленные данные, если узел не вернул ничего или вернул старые данные.
Чтобы защититься от злонамеренных координаторов и пользователей, которые не будут платить, каждый узел ведет список пользователей, от которых он ожидает оплаты, и координаторов, посылающих запросы от этих пользователей. Если уровень задолженности превышает некоторое пороговое значение, узел может перестать принимать запросы от указанных пользователей и координаторов. При получении чеков списки корректируются.
Награда за извлечение косвенным образом стимулирует и хранение, но работает только в отношении популярных и часто запрашиваемых данных. Для стимуляции долговременного хранения данных, особенно если они запрашиваются редко, требуется награда за хранение.
В статье об Ethereum Swarm [8] описана система наград за хранение. Узлы заключают с владельцем информации контракт на хранение данных в течение какого-то времени. Оплата хранения может происходить в момент сохранения (обновления) данных или через некоторое время при условии, что данные действительно хранятся. В случае обнаружения потери данных в течение действия контракта, узел может быть оштрафован, для чего каждому узлу требуется первоначальная регистрация с гарантийным депозитом.
При сохранении данных узел возвращает квитанцию, которая служит доказательством, что узел принял файл на хранение. Эта квитанция впоследствии позволяет проверить, хранятся ли всё ещё соответствующие им данные, и если нет — инициировать транзакцию на судебный смарт контракт, который позволит наказать провинившийся узел.
В нашем случае данные не статичны, запись с одним и тем же ключом может перезаписываться несколько раз. В этом случае предъявленной квитанции может соответствовать не только оригинальная запись, но и более новая запись с тем же ключом.
При инициированной пользователем операции удаления данных, вместо физического удаления данные заменяются специальной “нулевой” записью. Запись может быть физически удалена после истечения контракта хранения на неё.
В noSql базах данных быстрый поиск с задействованием небольшого количества узлов возможен только по первичному ключу. Наша БД в этом отношении немногим отличается от них. Между тем, поиск записей по ключевым словам, а также группировка записей по каким-то критериям трудно достижима без вторичных индексов и полнотекстового поиска. Для полнотекстового поиска, а также использования вторичных индексов предлагается использовать решение, аналогичное Elassandra [9]. Это решение представляет собой локальные полнотекстовые индексы ElasticSearch [10] на каждом узле распределенной noSql базы Cassandra [3]. Полнотекстовые запросы рассылаются координатором всем узлам, затем смешиваются и возвращаются клиенту. Поскольку дополнительные индексы создаются локально и независимо на каждом узле, дополнительное предотвращение проблемы византийских генералов не требуется.
Таким образом, мы представили концепцию публичной БД, связанной с блокчейном, которая удовлетворяет требованиям для использования децентрализованными приложениями:
Такая БД может использоваться децентрализованными приложениями на любых блокчейнах, поддерживающих Тьюринг-полные смарт контракты (впрочем, для других блокчейнов децентрализованные приложения и не создаются). Например, она может быть использована для нужд распределенных приложений поверх блокчейнов Ethereum [12], RChain [13] и других.
Концепция такой БД была разработана в рамках open-source проекта Сверхчеловек [14]. Реализации ещё нет (но она явно востребована), а концепция сегодня выносится на суд общественности. Надеемся, что впервые представленная концепция публичной децентрализованной noSql БД заинтересует вас достаточно, чтобы обсудить её или даже присоединиться к разработке [14]. Можете также присоединиться к каналу в телеграм [15], где можно пообщаться с разработчиками (на англ. языке).
→ Первая часть статьи [1]
→ Вторая часть статьи [2]
Автор: dukei
Источник [16]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/254487
Ссылки в тексте:
[1] первой части статьи: https://habrahabr.ru/post/327836/
[2] второй части: https://habrahabr.ru/post/327947/
[3] Apache Cassandra: http://cassandra.apache.org/
[4] византийской проблеме: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0_%D0%B2%D0%B8%D0%B7%D0%B0%D0%BD%D1%82%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D1%85_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D0%BB%D0%BE%D0%B2
[5] Sybil attack: https://en.wikipedia.org/wiki/Sybil_attack
[6] Ethereum Swarm: https://github.com/ethersphere/swarm
[7] off-chain транзакции: https://en.bitcoin.it/wiki/Off-Chain_Transactions
[8] Ethereum Swarm: http://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/orange-papers/1/sw%5E3.pdf
[9] Elassandra: http://www.elassandra.io/
[10] ElasticSearch: https://www.elastic.co/products/elasticsearch
[11] Cassandra: http://Cassandra
[12] Ethereum: https://ethereum.org/
[13] RChain: https://www.rchain.coop/
[14] Сверхчеловек: https://ubermensch.store
[15] каналу в телеграм: https://t.me/UbermenschProject
[16] Источник: https://habrahabr.ru/post/328004/
Нажмите здесь для печати.