В первой части статьи была обозначена проблема хранения данных приложений в блокчейне. Для понимания сути происходящего рекомендуем её прочитать. В этой части статьи мы обозначим наши пожелания к свойствам идеального хранилища данных, а также рассмотрим существующие подходы к решению этой проблемы.
Итак, если у нас есть децентрализованное приложение, какие требования к хранилищу данных стоило бы предъявить? Мы предлагаем следующие требования
Давайте посмотрим, насколько существующие технологии удовлетворяют этим требованиям.
IPFS (InterPlanetary File System) — технология распределенной файловой системы, основанная на DHT (Distributed Hash Table) и протоколе BitTorrent. Она позволяет объединить файловые системы на различных устройствах в одну, используя контентную адресацию.
Достоинства:
Недостатки:
Именно с использованием IPFS строится социальная сеть AKASHA (Ethereum + IPFS) и торговая площадка OpenBazaar. Они в полной мере наследуют указанные выше недостатки IPFS, основной из которых — нельзя разместить информацию в сети и выйти оффлайн, пока она не распространилась по пирам.
Такие хранилища позволяют объединять отдельные устройства в общее облачное хранилище. В результате пользователи могут хранить там свои файлы так же, как они это могли бы делать в классическом централизованном хранилище, например, Dropbox, но дешевле. Владельцы устройств (“фермеры”), предоставляя место для хранения чужих файлов, получают за это деньги от пользователей соответственно своему вкладу. Чтобы измерить вклад, обеспечить надежность хранения и пресечь злоупотребления, используются различные проверки, например, proof of storage (доказательство принятия файла), proof of retrievability (доказательство, что файл в наличии и может быть извлечен), основанные на криптографии. За успешное прохождение проверки пользователь платит, а фермер получает некоторую сумму в криптовалюте.
Строятся такие проекты, в основном, с использованием технологии DHT и контентной адресации (когда хэш от файла является его идентификатором). Некоторые дополнительно используют смарт контракты.
Таких проектов на рынке на текущий момент довольно много, например, Sia, Storj, Ethereum Swarm, MadeSAFE. Они все построены по схожим принципам. Причем Ethereum Swarm задумывался в том числе и для обеспечения удобного хранилища файлов для dApps.
Достоинства:
Недостатки:
Для хранения файлов распределенные файловые хранилища выглядят привлекательно. Однако для хранения структурированной динамической информации, например, пользовательских данных социальной сети, хранение данных в статических файлах представляет собой серьезную проблему. Дело в том, что файловые хранилища ничего не знают о содержимом файла, а приложению может требоваться искать информацию не только по идентификатору (или имени) файла, но и по его содержимому. Например, найти всех пользователей с ключевым словом blockchain. Или находящихся в определенном городе. Или даже осуществлять полноценный поиск по публикациям. Поэтому продолжаем искать реализацию получше.
К сожалению, в силу теоремы CAP нельзя получить полностью распределенную базу данных, которая одновременно обеспечивает согласованность, доступность и устойчивость к разделению (последнее означает, что бд продолжает функционировать даже если часть узлов выключилась из сети, или сообщения от них не доходят).
Для наших нужд требуется именно распределенная база данных, разумеется, устойчивая к разделению и доступная — нам необходимо быстро получать ответ из неё, хотя, возможно, и не самый свежий. Это ограничивает наш выбор рядом NoSQL баз данных, потому что ACID SQL СУБД в первую очередь обеспечивают согласованность.
Реализаций распределенных NoSQL баз данных великое множество. Например, MongoDB, Cassandra, RethinkDB. Все они способны работать с большим количеством реплик, объединяющихся в кластер. Клиент работает с одной из реплик, а данные автоматически синхронизируются с остальными. Для балансировки нагрузки может использоваться шардинг, когда часть данных хранится только на части реплик. Добавление в кластер новой реплики практически линейно масштабирует кластер, причем некоторые реализации (например, Cassandra) позволяют реплике автоматически принять на себя часть работы кластера.
NoSQL базы данных обеспечивают “целостность в конечном итоге” (eventual consistency), то есть, данные становятся согласованы через некоторое время, когда отдельные реплики синхронизируются. В этом они похожи на блокчейн — подтверждение транзакции тем вероятнее, чем больше времени прошло.
NoSQL базы данных могут хранить как просто ключ-значение, так и поддерживать внутреннюю структуру значения, а также дополнительные индексы. Наиболее продвинутые имеют также базовую поддержку транзакций и SQL-подобный язык запросов (например, Cassandra).
По всему вышесказанному этот класс баз данных может показаться идеальным для использования в блокчейне. Но есть проблема. Представьте, что в слаженный кластер таких баз данных кто-то добавил злонамеренную реплику, которая начинает сообщать другим репликам в кластере, что все данные необходимо удалить! Все остальные реплики послушно все данные удалят, и база данных будет безнадежно испорчена. То есть, такая слаженная работа реплик возможна сейчас только в доверенной среде (кластер таких баз данных неустойчив к проблеме византийских генералов). Если в кластер поместить злонамеренно работающую реплику, она может вызвать уничтожение данных всего кластера.
Достоинства:
Недостатки:
Существует реализация блокчейна под названием BigChainDB или, как она ещё называется, IPDB (InterPlanetary DataBase), которая часто упоминается как решение всех проблем с хранилищем данных. Авторы заявляют очень высокую скорость транзакций (1 млн/сек), огромную емкость хранилища (за счет распределенного хранения с частичной репликацией). BigChainDB получает эти преимущества за счет упрощенного консенсуса при формировании блоков, а также за счет хранения всех блоков и транзакций в существующей реализации noSql базы данных — RethinkDB или MongoDB.
К сожалению, подобная архитектура имеет существенный недостаток — каждый узел имеет полные права на запись в общее хранилище данных, а значит, система в целом неустойчива к проблеме византийских генералов. Авторы этого проекта знают об этом, обещая подумать об этом позже. Однако исправление фундаментальных проблем в базовой архитектуре после выпуска продукта весьма трудоёмко и чаще всего невозможно, потому что может привести к существенно другому продукту с другой архитектурой. Такое легкое отношение к фундаментальной проблеме вызывает критику проекта со стороны сообщества, потому что демонстрируемые высокие скоростные и объёмные характеристики BigChainDB в условиях отсутствия BFT (Byzantine Fault Tolerance) не так уж и отличаются от характеристик, демонстрируемых изначально noSql базами данных RethinkDB и MongoDB, которые используются ею для хранения данных. Но раз уж всё равно требуется полное доверие между узлами, то почему не пользоваться указанными базами данных напрямую?
Таким образом, реальное использование BigChainDB ограничивается приватными сетями. Чтобы не вводить людей в заблуждение, BigChainDB стоило бы назвать BigPrivateBlockChain, тогда никаких вопросов не возникало бы. Для публичных сетей она совершенно не подходит.
Достоинства:
Недостатки:
Таким образом, BigChainDB совершенно не подходит для хранения данных децентрализованных приложений в публичных сетях.
Мы рассмотрели несколько подходов к организации хранения данных для публичных сетей, которые могут использоваться распределенными приложениями. Их было мало, но больше на текущий момент и нет. К сожалению, ни один из подходов не удовлетворяет всем требованиям, которые мы сформулировали в начале статьи.
Сложившаяся ситуация напоминает этап становления компьютеров, когда программы могли сохранять данные только в файлах, и это было неудобно. Поэтому для компьютеров реализовали СУБД, а некоторые сделали на этом состояние.
В результате существующие децентрализованные приложения перебиваются хранением данных напрямую в блокчейне или в распределенных файловых системах,как в каменном веке. Они вынуждены самостоятельно реализовывать индексы по файлам, придумывать собственный формат данных и вообще тратить массу времени на изобретение велосипедов, хоть и децентрализованных.
Но мир децентрализованных приложений не может оставаться без удобного хранилища данных. Поэтому в следующей части статьи на ваш суд будет представлена концепция хранилища, претендующего на удовлетворение всех поставленных выше требований.
→ Третья часть статьи
→ Первая часть статьи
Итак, если у нас есть децентрализованное приложение, какие требования к хранилищу данных стоило бы предъявить? Мы предлагаем следующие требования
- Распределенность — поскольку вся инфраструктура блокчейна и приложений на нем распределенная, хранилище данных также должно быть распределенное и децентрализованное.
- Публичность — блокчейн позволяет всем желающим добавлять своё оборудование в сеть. Логично было бы ожидать того же от хранилища данных.
- Устойчивость к проблеме византийских генералов и другим типам атак в публичной сети — в публичной распределенной сети без этого никак.
- Поддержка шардинга — если мы ожидаем, что приложение будет популярно и будет хранить огромные объемы данных, то хорошо бы воспользоваться мощностью сети, чтобы увеличить максимальные объемы хранения. Полная репликация данных на каждом узле, разумеется, уменьшает шансы потери данных в случае проблем с отдельными узлами. Однако в случае большой мощности сети, например, сотни или тысячи серверов, дублировать все данные на всех серверах чрезвычайно избыточно, и можно уменьшить уровень репликации в пользу увеличения максимального суммарного объема данных. То есть, если у нас N серверов, то каждая запись должна реплицироваться только на m из них, m < N. Это позволит линейно увеличивать суммарный объем хранимых данных добавлением серверов.
- Скорость — для популярных приложений могут потребоваться сотни тысяч, если не миллионы транзакций по сохранению или чтению данных в секунду
- Структурированность — хранилище должно быть способно сохранять внутреннюю структуру данных, чтобы давать возможность приложениям связывать отдельные записи между собой
- Удаление данных — хранилище должно поддерживать удаление более ненужных для приложения данных, чтобы освободить место
- Вторичные ключи,
полнотекстовый поиск, язык запросов — Приложения должны иметь возможность осуществлять быстрый поиск по хранимым данным, учитывая их внутреннюю структуру
Давайте посмотрим, насколько существующие технологии удовлетворяют этим требованиям.
IPFS
IPFS (InterPlanetary File System) — технология распределенной файловой системы, основанная на DHT (Distributed Hash Table) и протоколе BitTorrent. Она позволяет объединить файловые системы на различных устройствах в одну, используя контентную адресацию.
Достоинства:
- Каждое устройство хранит только те файлы, которые ему нужны, плюс метаинформацию по расположению файлов на других устройствах. Поэтому не требуется доп. мотивация за хранение файлов.
- Нет необходимости доверять пирам, потому что адресация файлов осуществляется по содержимому.
- Устойчивость к флуду (загрузке ненужных файлов в сеть), потому что файлы размещаются только на собственное устройство.
- Высокая пропускная способность (благодаря BitTorrent)
Недостатки:
- Хранение только файлов (неструктурированной информации).
- После размещения файла нельзя выходить из сети, пока он по ней не разойдется.
- Хранение данных другими устройствами не гарантировано, для гарантированного предоставления своего файла другим нужно быть онлайн
- Файлы статичны (неизменяемы)
- Удаление файла в принципе не предусмотрено.
Именно с использованием IPFS строится социальная сеть AKASHA (Ethereum + IPFS) и торговая площадка OpenBazaar. Они в полной мере наследуют указанные выше недостатки IPFS, основной из которых — нельзя разместить информацию в сети и выйти оффлайн, пока она не распространилась по пирам.
Распределенные файловые хранилища
Такие хранилища позволяют объединять отдельные устройства в общее облачное хранилище. В результате пользователи могут хранить там свои файлы так же, как они это могли бы делать в классическом централизованном хранилище, например, Dropbox, но дешевле. Владельцы устройств (“фермеры”), предоставляя место для хранения чужих файлов, получают за это деньги от пользователей соответственно своему вкладу. Чтобы измерить вклад, обеспечить надежность хранения и пресечь злоупотребления, используются различные проверки, например, proof of storage (доказательство принятия файла), proof of retrievability (доказательство, что файл в наличии и может быть извлечен), основанные на криптографии. За успешное прохождение проверки пользователь платит, а фермер получает некоторую сумму в криптовалюте.
Строятся такие проекты, в основном, с использованием технологии DHT и контентной адресации (когда хэш от файла является его идентификатором). Некоторые дополнительно используют смарт контракты.
Таких проектов на рынке на текущий момент довольно много, например, Sia, Storj, Ethereum Swarm, MadeSAFE. Они все построены по схожим принципам. Причем Ethereum Swarm задумывался в том числе и для обеспечения удобного хранилища файлов для dApps.
Достоинства:
- Файлы хранятся в облаке и доступны независимо от доступности их владельца.
- Высокая пропускная способность.
- За счет финансовой мотивации обеспечивается надежность хранения и извлечения файлов.
- Удаление ненужных файлов возможно
Недостатки:
- Хранение только файлов (а не структурированной информации)
- Файлы статичны
- Хранение небесплатно
Для хранения файлов распределенные файловые хранилища выглядят привлекательно. Однако для хранения структурированной динамической информации, например, пользовательских данных социальной сети, хранение данных в статических файлах представляет собой серьезную проблему. Дело в том, что файловые хранилища ничего не знают о содержимом файла, а приложению может требоваться искать информацию не только по идентификатору (или имени) файла, но и по его содержимому. Например, найти всех пользователей с ключевым словом blockchain. Или находящихся в определенном городе. Или даже осуществлять полноценный поиск по публикациям. Поэтому продолжаем искать реализацию получше.
Распределенные базы данных
К сожалению, в силу теоремы CAP нельзя получить полностью распределенную базу данных, которая одновременно обеспечивает согласованность, доступность и устойчивость к разделению (последнее означает, что бд продолжает функционировать даже если часть узлов выключилась из сети, или сообщения от них не доходят).
Для наших нужд требуется именно распределенная база данных, разумеется, устойчивая к разделению и доступная — нам необходимо быстро получать ответ из неё, хотя, возможно, и не самый свежий. Это ограничивает наш выбор рядом NoSQL баз данных, потому что ACID SQL СУБД в первую очередь обеспечивают согласованность.
Реализаций распределенных NoSQL баз данных великое множество. Например, MongoDB, Cassandra, RethinkDB. Все они способны работать с большим количеством реплик, объединяющихся в кластер. Клиент работает с одной из реплик, а данные автоматически синхронизируются с остальными. Для балансировки нагрузки может использоваться шардинг, когда часть данных хранится только на части реплик. Добавление в кластер новой реплики практически линейно масштабирует кластер, причем некоторые реализации (например, Cassandra) позволяют реплике автоматически принять на себя часть работы кластера.
NoSQL базы данных обеспечивают “целостность в конечном итоге” (eventual consistency), то есть, данные становятся согласованы через некоторое время, когда отдельные реплики синхронизируются. В этом они похожи на блокчейн — подтверждение транзакции тем вероятнее, чем больше времени прошло.
NoSQL базы данных могут хранить как просто ключ-значение, так и поддерживать внутреннюю структуру значения, а также дополнительные индексы. Наиболее продвинутые имеют также базовую поддержку транзакций и SQL-подобный язык запросов (например, Cassandra).
По всему вышесказанному этот класс баз данных может показаться идеальным для использования в блокчейне. Но есть проблема. Представьте, что в слаженный кластер таких баз данных кто-то добавил злонамеренную реплику, которая начинает сообщать другим репликам в кластере, что все данные необходимо удалить! Все остальные реплики послушно все данные удалят, и база данных будет безнадежно испорчена. То есть, такая слаженная работа реплик возможна сейчас только в доверенной среде (кластер таких баз данных неустойчив к проблеме византийских генералов). Если в кластер поместить злонамеренно работающую реплику, она может вызвать уничтожение данных всего кластера.
Достоинства:
- Высокая скорость
- Линейное масштабирование скорости и размера хранилища
- Устойчивость к недоступности отдельных реплик
- Зрелые реализации
Недостатки:
- Необходимость доверять пирам — неустойчивость к проблеме византийских генералов.
BigChainDB
Существует реализация блокчейна под названием BigChainDB или, как она ещё называется, IPDB (InterPlanetary DataBase), которая часто упоминается как решение всех проблем с хранилищем данных. Авторы заявляют очень высокую скорость транзакций (1 млн/сек), огромную емкость хранилища (за счет распределенного хранения с частичной репликацией). BigChainDB получает эти преимущества за счет упрощенного консенсуса при формировании блоков, а также за счет хранения всех блоков и транзакций в существующей реализации noSql базы данных — RethinkDB или MongoDB.
К сожалению, подобная архитектура имеет существенный недостаток — каждый узел имеет полные права на запись в общее хранилище данных, а значит, система в целом неустойчива к проблеме византийских генералов. Авторы этого проекта знают об этом, обещая подумать об этом позже. Однако исправление фундаментальных проблем в базовой архитектуре после выпуска продукта весьма трудоёмко и чаще всего невозможно, потому что может привести к существенно другому продукту с другой архитектурой. Такое легкое отношение к фундаментальной проблеме вызывает критику проекта со стороны сообщества, потому что демонстрируемые высокие скоростные и объёмные характеристики BigChainDB в условиях отсутствия BFT (Byzantine Fault Tolerance) не так уж и отличаются от характеристик, демонстрируемых изначально noSql базами данных RethinkDB и MongoDB, которые используются ею для хранения данных. Но раз уж всё равно требуется полное доверие между узлами, то почему не пользоваться указанными базами данных напрямую?
Таким образом, реальное использование BigChainDB ограничивается приватными сетями. Чтобы не вводить людей в заблуждение, BigChainDB стоило бы назвать BigPrivateBlockChain, тогда никаких вопросов не возникало бы. Для публичных сетей она совершенно не подходит.
Достоинства:
- Скорость и хранилище, сопоставимое с распределенными noSql базами данных
Недостатки:
- По сути, это и есть обычная noSql база данных, дополненная недостатками блокчейна
- Неизменяемость (данные нельзя удалить легально, но можно злонамеренно)
- Неустойчивость к проблеме византийских генералов, следовательно, невозможность использования в публичной сети
Таким образом, BigChainDB совершенно не подходит для хранения данных децентрализованных приложений в публичных сетях.
Выводы
Мы рассмотрели несколько подходов к организации хранения данных для публичных сетей, которые могут использоваться распределенными приложениями. Их было мало, но больше на текущий момент и нет. К сожалению, ни один из подходов не удовлетворяет всем требованиям, которые мы сформулировали в начале статьи.
Сложившаяся ситуация напоминает этап становления компьютеров, когда программы могли сохранять данные только в файлах, и это было неудобно. Поэтому для компьютеров реализовали СУБД, а некоторые сделали на этом состояние.
В результате существующие децентрализованные приложения перебиваются хранением данных напрямую в блокчейне или в распределенных файловых системах,
Но мир децентрализованных приложений не может оставаться без удобного хранилища данных. Поэтому в следующей части статьи на ваш суд будет представлена концепция хранилища, претендующего на удовлетворение всех поставленных выше требований.
→ Третья часть статьи
→ Первая часть статьи