Обмен электронных валют по самому выгодному курсу!
 


Kurbetsoft
Доступно в Google PlayBigchainDB: Откуда все пошло, где мы сейчас, и что впереди

bigchain_db

Предыстория BigchainDB: ascribe

Летом 2013 года мы начали работать над проектом ascribe – установление авторства интеллектуальной собственности (ИС) на основе блокчейн. Когда мы рассказывали про него другим, ответ был, как правило, “серьезно?”. Блокчейн не был широко распространенной идеей. На самом деле, даже сам биткойн тогда не был так уж известен! Биткойн достиг пика стоимости полтора года спустя, когда был пройден порог в $1000, но блокчейну потребовался еще один год, чтобы достичь достаточной популярности.

Мы решали “проблему слона в комнате”: как вы хотите хранить цифровое искусство? Как могут создатели цифрового искусства получить за него деньги? Ну серьезно, как мог любой музыкант, рассказчик, видеооператор, дизайнер и т.д. получить отчисления с продаж? Технология блокчейн могла бы решить эту проблему с помощью общего хранилища.

К лету 2014 года мы добились хороших результатов, и я мог полностью переключиться от работы в моем предыдущем стартапе – Solido. Мои кофаундеры Брюс и Маша тоже работали по полной. Мы собрали деньги, наняли несколько сотрудников и продолжали работать над продуктом, пока мы не были довольны им достаточно, чтобы выпустить его в начале 2015 года на базе блокчейна биткойна.

В начале 2014 года сотрудники Monegraph пришли к той же идее и выдали ее за результат посещения хакатона. Они пришли к тому же решению, ну надо же! Конечно, было неприятно видеть кого-то, кто объявился раньше. Несомненно, бесчисленное множество других стартапов испытывали похожее. Ну, да ладно. Наш урок был таков: надо объявлять о продукте как можно раньше, а потом уже доводить его до ума. “Если вас не пугает первая версия вашего продукта, значит вы запустили его слишком поздно” – Рейд Хоффман.

Проблемы масштабирования

В конце 2014 года один из потенциальных клиентов ascribe имел 20 миллионов пользователей и более 100000 работ в день, проходящих через их систему. Это примерно то же количество операций, которое вся сеть биткойн может поддерживать в день; и биткойн уже сталкивался с проблемами масштабирования.

Кроме того, проведение транзакций заметно подорожало: раньше это стоило всего долю цента, а сегодня уже около десяти, так что 100000 транзакций означает более $10000 операционных издержек в день. Чтобы зарегистрировать уже существующие на рынке сто миллионов работ,  понадобилось бы десять миллионов долларов. Мда. Мы поняли, что это огромная проблема для нас. Осенью 2014 года я выступил с докладом на эту тему, и привел сравнение с производительностью “big data” баз данных.

Как стартап мы должны были сосредоточиться на чем-то одном. Мы выбрали путь защиты авторских прав. Мы надеялись, что кто-то решит проблему масштабируемости; мы даже уговаривали друзей работать над этим.

Проблема, которую нужно решить

К концу лета 2015 года всё больше и больше людей стали заниматься масштабированием блокчейна биткойна. Они брали существующий блокчейн, и пытались масштабировать его.

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

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

Я почти 20 лет разрабатывал алгоритмы машинного обучения. Один из моих самых больших уроков того времени заключался в том, что решение под большой масштаб нужно закладывать с самого начала. Вы не можете просто “расширить” какой-то  алгоритм в тысячу или миллион раз. В своей работе по символической регрессии я впервые попробовал осуществить “масштабирование” и у меня ничего не вышло. Но используя радикально более простой подход я всё же получил то, что хотел. Я таким же образом отмасштабировал алгоритм оптимизации топологии, и алгоритм проверки памяти (с моими коллегами из Solido). Исследователи Google получили аналогичные результаты.

Вернемся к блокчейну. Что делать, если механизм хранения изначально и так был предназначен для масштабирования? Распределенные базы данных именно такие. Мы могли бы:

  • Отмасштабировать распределенное хранилище: существующих БД умеют работать поверх многих физических машин. Это то, как Google, Facebook, Netflix (и другие) делают сервисы планетарного масштаба;
  • Отмасштабировать консенсус: если у вас есть распределенная БД, то разные машины могут расходиться во мнении относительно состояния данных. Это проблема. Как осуществить синхронизацию данных? Этим занимаются алгоритмы консенсуса, которые также применяются в уже существующих распределенных базах данных. Порядок операций является сердцем консенсуса. Есть “отказоустойчивая” и “византийская отказоустойчивая” разновидности консенсусных протоколов, таких как Paxos и PBFT, некоторые из которых восходят к 80-м годам, а на самом деле опираются на работы 50-х и 60-х годов (ARPAnet).

Зная это, как мы могли соединить блокчейн и распределенную базу данных? Мы определили три характеристики блокчена:

  • Децентрализованность: ни одна организация не владеет или управляет БД;
  • Неизменность: более высокая стойкость к изменению данных, чем у обычной БД. На самом деле, существующие БД и технологии создания мгновенных снимков состояния и так позволяют добиться “неизменности” данных, но чуть в меньшей степени.
    Если добавить цифровые подписи в механизм голосования (для достижения консенсуса) – то это еще больше усилит неизменность в текущих базах данных;
  • Активы: можно регистрировать и передавать активы, при этом владелец закрытого ключа является владельцем актива.

Вперед, к первой версии BigchainDB!

В конце лета 2015 года, с описанными выше начальными условиями, мы должны были выбрать распределенную БД, чтобы начать работу. Мы протестировали Cassandra, MongoDB, Elasticsearch и многие другие. Неудивительно, что каждая из них имела гораздо лучшую масштабируемость, чем блокчейн (но я признаю, что они решают несколько иные проблемы!) Мы остановились на RethinkDB (лицензия AGPL) – хранилище документов с иерархическими ключами в стиле JSON. Основной причиной выбора RethinkDB был его отличный механизм сообщения об изменениях: каждый раз, когда какой-либо узел вносил изменения в данные, все остальные узлы информировались об этом. Это свойство могло оказаться чрезвычайно полезным для построения базовой функциональности, а также повышения отказоустойчивости.

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

Прорыв случился, когда мы поняли, что упорядочивание/запись были самым узким местом нашей системы. Но зато эту проблему можно решить средствами самой RethinkDB. Как и многие другие распределенные БД, RethinkDB обладает тем свойством, что по мере добавления серверных узлов, пропускная способность линейно растет (максимально 64 узлов). Подумайте над этим. Это удивительный результат, хоть и неочевидный! Как RethinkDB увеличивает пропускную способность за счет добавления узлов? Секрет в шардировании: каждый узел хранит лишь часть данных. Каждая транзакция идет только к нужному узлу. Таким образом, нагрузка от входящих транзакций и записей распределяется между многими узлами.

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

Таким образом, пропускная способность возрастает пропорционально числу узлов N. Но есть еще общение самих узлов между собой. Все узлы общаются со всеми узлами, поэтому число таких связей равно квадрату числа узлов. Возникает резонный вопрос: как же это не убивает масштабируемость? Ответ заключается в том, что RethinkDB поддерживает максимум 64 узла.

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

Блоки были не нужны, но требовалась большая оптимизация. Когда мы начали работу над BigchainDB, мы работали на уровне транзакций, то есть объект транзакции должен был содержать хэш объекта предыдущей транзакции. В конце концов, кому нужны блоки, если база данных и так хорошо упорядочивает транзакции? Всё очень просто! Тем не менее, цепочки на уровне транзакций означают, что необходимы цифровые подписи для каждой транзакции, а это уже дорого. Мы могли бы оптимизировать это путем объединения упорядоченных множеств операций в блоки, то есть цепочки на уровне блоков. Мы были готовы пойти на такую сложность во имя скорости. Но затем мы осознали: не нужна цепь блоков, чтобы получить характеристики блокчейна. Блоки – это просто оптимизация!

Можно задать вопрос: при условии, что каждый узел может иметь право голоса по каждому блоку, почему голосование не становится узким местом? Ответ: каждый узел работает в несколько десятков ядер/процессов/потоков, обрабатывая операции параллельно.

Версия v0.1

Начиная с рождения идеи осенью 2014 года, до интенсивных усилий в конце лета 2015 года, мы наконец-то объявили выход BigchainDB 10 февраля 2016 года, на блокчейн-конференции в Сан-Франциско. Это было очень смешно: все думали, что Брюс собирался говорить об авторских правах и интеллектуальной собственности. А вместо этого – BigchainDB! Мы выпустили систему с открытым кодом версии v0.1. Мы открыли каналы в Твиттере, группы Google.

Мы уже были научены опытом: сначала релиз, затем доведение до ума. К тому же версия “0.1” может подразумевать, что программное обеспечение было на стадии альфа-теста. Были заложены основы: создание активов, передачи активов, а также основной полезной нагрузки данных. Помогло то, что мы сидели на фундаменте большого, относительно зрелого кода RethinkDB. Документация была нормальной, но её было не много. Контроль уровня доступа был сделан довольно грубо: только на уровне транзакций. Систему было трудно развернуть в кластере. Мы нашли множество неисправностей/возможных атак (например, один из узлов удаляет кучу данных), но пока не торопились решать их. Таким образом, люди могли бы загрузить код и сделать всё сами, но это не было готовым продуктом.

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

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

Версии v0.2 и v0.3

Мы продолжили работу, чтобы сделать проще развертывание кластеров и тестирование производительности. Мы приложили тонну усилий (на самом деле больше, чем мы ожидали) и из-за этого мы были медленнее, чем ожидалось.

26 апреля 2016 года мы выпустили v0.2, куда входил улучшенный код развертывания кластера,  улучшенная документация, исправления ошибок, и многое другое.

Параллельно с этим мы сделали транзакции, поддерживающие спецификацию Interledger. Это позволяло использовать несколько входов и выходов, пороговые условия, мультиподписи и многое другое – и все это было встроено в новый модуль криптоусловий. Мы выпустили эту версию 3 мая 2016 года как v0.3 сразу после выхода v0.2. Богатые транзакции принесли более богатые возможности контроля прав доступа.

BigchainDB: где мы сейчас

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

Наше программное обеспечение по-прежнему в “альфа” стадии. Оно имеет богатую инфраструктуру активов и широкие возможности контроля прав доступа. Тем не менее, еще нет должной поддержки условного депонирования (escrow). К слову, мы никогда не будет стремиться к Тьюринг-полным транзакциям. По нашему мнению, это другая часть головоломки, решаемая людьми из Ethereum, Tendermint и т.д.

Вам придется изрядно потрудиться, чтобы использовать запросы. Но зато теперь мы можем гордиться нашей документацией. Стало проще развернуть BigchainDB в кластере. Мы по-прежнему исправляем только некоторые из выявленных недостатков, так что впереди еще много работы. Короче говоря: больше функциональных возможностей, проще в использовании, но еще не готово к боевому применению. Это нормально, так как большинство блокчейн проектов сейчас находятся на стадии Proof-of-Concept; люди могут создать какие-то свои PoC поверх BigchainDB и проверить их.

BigchainDB будут расти в качестве, а PoC постепенно превратятся в реальные жизнеспособные проекты.

Ошибка: неверные ожидания

Мы совершили ошибку, и задним числом мы ругаем себя за то, что случилось: мы не сообщили, где мы находимся и куда мы направляемся. В то время как мы много общались на GitHub (дорожная карта, контрольные точки, номера версий <1, и т.д.) и в разговорах, у нас не было простого высокоуровневого описания, например на посадочной странице thebigchaindb.com… Да и внутри GitHub всё было достаточно запутано. Мы не давали ожидаемых характеристик для различных сценариев развертывания, не рассказывали о проблемах и ошибках.

Это то, что я понял из недавних диалогов с большим количеством умных людей. Например, они загружают код и удивляются, получая очень низкие показатели производительности. Но ведь это наша работа – высокая производительность!

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

BigchainDB: Куда мы идем

Во-первых, мы принимаем краткосрочные меры по решению проблем коммуникации. К ним относятся:

  • Улучшена связь на предмет того, над чем мы работаем сейчас и в ближайшем будущем, в целях повышения производительности, безопасности и так далее. Дорожную карту теперь проще понять. [Обновление: сделано, смотрите здесь]
  • Хорошая документация по производительности для различных сценариев развертывания, поэтому любой человек может легко повторить наши тесты. [Обновление: сделано, смотрите здесь и здесь.]
  • Хорошая документация о том, где есть не исправленные ошибки; более подробный FAQ и информация о отказоустойчивости
  • Улучшилась страница bigchaindb.com
  • Технические обновления, которые легко понять (как и этот блог)! Мы будем выпускать больше сообщений в блоге с большим количеством деталей.

Кроме того, мы будем продолжать работать над введением BigchainDB в продакшн. Это включает в себя улучшение производительности, безопасности и так далее в соответствии с целями версии. Мы также работаем над публичной версией BigchainDB; больше об том расскажем в ближайшие недели.

Если вы дочитали до этого момента: благодарим Вас за интерес, проявленный к BigchainDB! Мы очень рады этой технологии и тому, как она связывает блокчейн с современными  распределенными БД. Впереди будет еще интереснее!

Источник: блог компании

 




[vkontakte] [facebook] [twitter] [odnoklassniki] [mail.ru] [livejournal]

Каталог сайтов