Часть 1. Где хранить данные децентрализованным приложениям на блокчейне?

в 19:46, , рубрики: big data, bitcoin, blockchain, cryptocurrency, data storage, decentralization, decentralized systems, Ethereum, nosql, open source, smart contracts, Анализ и проектирование систем, базы данных, криптография

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

А что же это такое блокчейн?

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

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

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

Но ладно, допустим, одного нечестного майнера легко вычислить и проигнорировать. Но что, если их много, и они сговорились? Представьте, что все люди вокруг вас считают красный свет зеленым. :) И смотрят на вас, как на ненормального, если вы считаете иначе. Социальные эксперименты показывают, что большинство людей в такой ситуации начинают сомневаться и присоединяются к мнению большинства. А ведь в блокчейне как раз и работает правило большинства!

Подобная проблема выяснения истины в условиях, когда твои собеседники могут бессовестно врать, была названа Лесли Лампортом «Проблемой византийских генералов», а решена двумя годами ранее в 1980 году им же совместно с другими авторами. Было показано, что при n шпионах, которые могут врать и искажать информацию, консенсус между участниками может быть достигнут при общем количестве участников 3n+1. А если гарантировать, что шпионы не могут искажать переданную через них сообщения, то достаточно и 2n+1. В блокчейне за счет электронной подписи зловредные узлы не могут искажать информацию, поэтому если в блокчейне менее половины зловредных узлов, то сеть устойчива.

Устойчивость сети к зловредным узлам называется устойчивостью к византийской проблеме (Byzantine Fault Tolerance, BFT). BFT очень важна для публичных сетевых систем, в которые могут свободно добавляться произвольные узлы. Именно такими системами является большинство проектов на блокчейне.

Применение блокчейна не ограничивается созданием криптовалют. Внутрь блока можно записывать что угодно. В биткоине туда записывается список новых транзакций, и применяется это для обмена криптовалютой между её владельцами. В NameCoin в блоках хранятся произвольные пары ключ-значение, что можно применить для создания децентрализованных DNS. В других реализациях блокчейна используются ещё какие-нибудь фишки. А вот Ethereum пошел значительно дальше. Он позволяет хранить в блокчейне не только транзакции, но и полноценные Тьюринг-полные программы, называемые смарт-контрактами, которые позволяют очень тонко настроить блокчейн на прикладную задачу. Например, NameCoin реализуется на Ethereum 5 строками кода.

Ethereum задумывался как универсальная платформа для создания децентрализованных проектов на основе блокчейна. Зачем реализовывать весь блокчейн заново, разворачивать собственную инфраструктуру, если можно парой-тройкой смарт контрактов реализовать то, что тебе нужно, на Ethereum, как, например, аналог NameCoin? Поэтому последнее время Ethereum переживает бурный рост. С марта 2017 ETH (криптовалюта Ethereum) всего за два месяца выросла в цене в 5 раз, и рост продолжается. На Ethereum работают уже сотни приложений, например, социальная сеть AKASHA, биржа фрилансеров Ethlance, игра в слова, да много их!

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

Казалось бы, что ещё нужно? Приложения получаются действительно децентрализованными, неподверженными цензуре и запрещению. В общем, блокчейн — это сплошные достоинства! Но если бы всё было так хорошо… При создании действительно мощных приложений сразу обнаруживаются и недостатки.

Неизменяемость. Неизменяемость — это, конечно, хорошо. Именно неизменяемость даёт блокчейну публичность и BFT. Однако есть и обратная сторона медали. Все данные, которые приложения пишут в блокчейн, остаются там навсегда. Поиграли в слова — блокчейн это запомнил. Разместили информацию в социальной сети — она навсегда сохранена в блокчейне, даже если вы потом удалили свой профиль. Взрывной рост числа приложений на блокчейне приводит к сильному раздуванию цепи блоков в размере. Уже сейчас размер полного блокчейна Ethereum перевалил за 130Гб, хотя он работает меньше 2 лет. У биткоина меньше при его солидном возрасте более 7 лет.

Конечно, в некоторые реализации Ethereum включают технологию State Tree Pruning, которая позволяет хранить только последнее состояние блокчейна, с ограниченной историей примерно на сутки, что на текущий момент позволяет сократить хранимую информацию в 20 раз. Например, go-ethereum full node требует для хранения блокчейна 130 Гб, а Parity с поддержкой данной технологии — всего 6 Гб. Однако, учитывая, что рост числа приложений только начинается, а каждому узлу Ethereum приходится хранить все данные всех приложений, это выглядит хоть и необходимой, но всего лишь отсрочкой проблемы. С ростом размера блокчейна он перестанет помещаться на массово выпускаемые жесткие диски, его обслуживание станет по карману лишь большим организациям, что ведет к опасной централизации — сосредоточению контроля над более чем 50% сети у одной организации. Это может нарушить BFT.

Медленность транзакций. За свою устройчивость блокчейны расплачиваются скоростью транзакций. У биткоина 7 транзакций в секунду, у Ethereum — 15. И это на всю сеть, потому что каждый узел полностью реплицирует другие узлы. Добавление нового узла повышает устойчивость системы, но никоим образом не увеличивает скорость её работы или максимальный объём хранения данных. То есть, изменение данных (а каждое изменение данных в блокчейне — это транзакция) является бутылочным горлышком. Популярные приложения сразу же натолкнутся на это ограничение.

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

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

Но ведь существующие приложения, например, AKASHA как-то выкручиваются… В следующей части мы рассмотрим существующие подходы к решению этой проблемы.

Автор: dukei

Источник

Поделиться

* - обязательные к заполнению поля