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

Что такое блокчейн? | ForkLog

Что такое блокчейн?

Блокчейн (от английского block chain, «цепочка блоков») — это распределенная база данных, доступ к которой может получить любой человек. Иначе ее называют «технологией распределенного реестра», так как не существует какого-либо централизованного органа или регулятора, который мог бы распоряжаться блокчейном по собственному усмотрению.

Чем отличается блокчейн от классической базы данных?

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

Как работает блокчейн?

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

Где хранится блокчейн?

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

Почему вокруг блокчейна такая шумиха?

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

А где сейчас используют блокчейн?

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

Чем отличается открытый блокчейн от приватного?

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

Как можно заставить несколько блокчейнов взаимодействовать?

Для решения этой проблемы предлагаются самые разные варианты. Наиболее популярный из них — так называемые сайдчейны (side chains, «боковые цепочки») — специальные блокчейны. Последние нужны исключительно для соединения одного блокчейна с другим в обход возможного противоречия между их правилами.

forklog.com

Как понять нужно ли интегрировать blockchain в ваш продукт?

Blockchain технологии в данный момент являются слишком раздутыми. О нем пишут и говорят все: от конференций Sibos и Money20/20 до популярных материалов в изданиях The Economist и Euromoney – кажется, что каждый стремится ухватить свою долю в золотой блокчейн-лихорадке.

Как определить, что у вас реальный случай применения технологии блокчейн? Мы в Web-payment.ru много пишем о технологии распределенного реестра, и по роду деятельности нашего Digital агентства, ориентированного на финтех компании, замечаем, что поднятый вопрос очень актуальный для многих игроков рынка. Эта статья, опубликованная в блоге открытой платформы для создания своих блокчейнов MultiChain, призвана помочь разобраться в этом. Огромное количество приходящих в MultiChain проектов вообще не имеет ничего общего с технологией блокчейн. Все происходит по следующему сценарию. Большая компания узнает о том, что blockchain – это технология будущего. Большая компания находит людей извне, которые работают с банковскими технологиями для обращения криптовалюты биткойн. Большая компания выделяет им бюджет и поручает сделать что-нибудь «блокчейновое». И вскоре эти умельцы приходят к MultiChain и, размахивая деньгами, просят нас помочь им выдумать какой-то сценарий использования.

А что не так с теми, у кого действительно есть идея проекта? Очень часто проект может быть замечательно реализован при помощи обычной реляционной базы данных. Это такие железные чудища, как Oracle и SQL Server, а для менее предубежденных – MySQL и Postgres. Так что позвольте начать, расставив все точки над «i»:

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

Почему? Потому что такие продукты, как Oracle и MySQL проверены десятилетиями разработки. Они были установлены на миллионах серверов, обрабатывающих триллионы запросов. Их код был наиболее тщательно тестирован, оптимизирован и отлажен в сравнении с другими на планете Земля. Они, не напрягаясь, обрабатывают тысячи транзакций в секунду.

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

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

1. База данных

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

Регистр для финансовых активов обычно может быть выражен в виде таблицы базы данных, в которой каждая строка представляет один вид активов, принадлежащих одной конкретной сущности. Каждая строка содержит три колонки, содержащие: (а) идентификатор владельца, например, номер счета; (б) идентификатор типа активов, например, «USD» или «AAPL»; (в) количество единиц актива на счету конкретного владельца.

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

2. Множество авторов

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

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

3. Отсутствие доверия

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

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

Что именно я имею в виду говоря об отсутствии доверия? Я говорю о том, что один пользователь не желает, чтобы другой пользователь изменял строки в базе данных, которые «принадлежат» ему самому. Точно так же, когда речь идет о чтении содержимого базы данных, пользователь не будет принимать на веру «правду» другого пользователем, потому что каждый из них имеет различные экономические или политические мотивации.

4. Транзакции без посредников

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

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

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

5. Взаимодействие транзакций

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

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

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

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

6. Установка правил

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

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

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

7. Выберите своих валидаторов

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

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

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

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

Блокчейн – это цепь блоков, в которой каждый блок содержит набор транзакций, подтверждаемых как группа. Но кто несет ответственность за выбор транзакций, которые идут в каждом блоке? Для «частных блокчейнов», которые подходят для корпораций, это закрытая группа валидаторов (майнеров), оставляющих цифровую подпись в создаваемых ими блоках. Этот белый список совмещается со схемой распределенного консенсуса для того, чтобы предотвратить получение контроля над блокчейном меньшинством валидаторов.

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

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

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

8. Обеспечивайте свои активы

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

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

Если вы хотите использовать блокчейн для учета активов, необходимо ответить на еще один важный вопрос: какова природа этих активов? Я не имею в виду наличные, облигации или коносаменты, хотя это тоже очень важно. Вопрос скорее в том, кто стоит за активами, представленными в блокчейне? Если в базе есть информация о том, что мне принадлежит 10 единиц чего-то, кто позволит мне претендовать на эти 10 единиц в реальном мире? На кого я могу подать в суд, если не смогу преобразовать то, что у меня есть в блокчейне в традиционные физические активы? (См. пример соглашения об активах)

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

Заключение

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

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

habr.com

Разница между блокчейном и классическими базами данных

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

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

Блокчейн также можно назвать базой данных, но ее отличия от классических баз кардинальны.

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

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

Децентрализованное управление

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

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

История самой себя

Большинство централизованных баз данных содержат информацию, актуальную в определенное время. Они похожи на снимок, который запечатлел один момент. СпособЮ который позволяет получить предыдущие «снимки», — создание бэкапа. Эта процедура выполняется регулярно, чтобы восстановить данные (пусть и с какой-то потерей актуальности). Минусы такого подхода в том, что вы каждый раз делаете полноценную копию вашей базы, а она может быть довольно большой.

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

Производительность

Хотя блокчейны могут использоваться для записи и являются идеальными платформами для транзакций, они считаются медленными, по сравнению с традиционными вариантами, типа систем Visa и PayPal. (Примечание: совсем недавно поступили новости, что один из блокчейн-проектов смог реализовать сеть, которая по своей скорости опережает решение Visa в несколько раз).

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

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

Конфиденциальность

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

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

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

Можно заключить, что если конфиденциальность является единственной целью, а доверие между сторонами установлено и нет проблемы с хранением больших объемов данных (бэкапы базы данных), базы на блокчейне не будет иметь для вас особых преимуществ.

Выводы

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

crypto-fox.ru

Технология блокчейн и ее отличие от обычных баз данных

Содержание статьи

Технология блокчейн отличается от традиционной базы данных архитектурой или самим принципом организации. Используемые в интернете базы данных, как правило, основаны на архитектуре клиент-сервер. В отличие от этого, внедрение blockchain предусматривает принцип отсутствия единого сервера и равноправного участия всех пользователей.

Децентрализованное управление

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

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

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

Технология блокчейн и криптовалюты. Быстрый старт

Получите книгу и узнайте все основы технологии блокчейн и криптовалюты за один вечер

Скачать книгу

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

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

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

Различия в принципе хранения данных

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

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

Недостатки блокчейна

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

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

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

Конфиденциальность

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

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

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

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

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

Источник:

https://www.coindesk.com/

Редакция: Команда BlockChainWiki

Технология блокчейн и криптовалюты. Быстрый старт

Получите книгу и узнайте все основы технологии блокчейн и криптовалюты за один вечер

Скачать книгу

blockchainwiki.ru

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

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

Блокчейн (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 как-то выкручиваются… В следующей части мы рассмотрим существующие подходы к решению этой проблемы.

→ Вторая часть статьи → Третья часть статьи

habr.com

Практическое применение блокчейна как распределенного хранилища данных / Хабр

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

Задача

Регистрация на площадке по государственным закупкам процесс достаточно бюрократизированный. Исполняя требования законодательства и реализуя принцип Know your customer (KYC), площадкам и удостоверяющим центрам приходиться собирать множество документов, подтверждающих личность клиента и происхождение средств. У компании-заказчика возникла идея, создать сервис единовременной аккредитации на всех площадках по государственным закупкам регулируемых разными законами — создать единый профиль контрагента (это позволило бы собрать необходимые документы только 1 раз). Такой сервис был бы полезен всем – пользователи после регистрации на любой площадке получили бы возможность работать со всеми остальными без дополнительной волокиты; площадки получили бы новых пользователей, за счёт упрощения регистрации. В дальнейшем, к этой платформе можно было бы привлечь конкурирующие площадки и другие смежные организации.

Решение

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

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

Основные характеристики разработанного решения:

Данные распределяются между всеми узлами системы, ни один из участников системы не может сфальсифицировать или удалить данные, однажды выданные другому участнику, а также отсутствует единая точка отказа. Даже при физическом отключении узла участника от сети, данные, полученные до момента отключения, остаются на этом узле и доступны для работы с ними, а при восстановлении подключения происходит получение данных, появившихся во время отсутствия узла в сети.
Используется закрытый блокчейн (консорциум) – т.е. для подключения к нему требуется либо согласование узлом-координатором, либо, если выбрана консенсусная модель администрирования – всеми участниками сети.
После подключения, участник консорциума может создавать как публичные (доступные всем участникам), так и закрытые (доступные выбранному кругу участников) коллекции данных. Безопасность закрытых данных обеспечивается посредством криптозащиты данных с помощью ГОСТовских алгоритмов.
Управлять доступом к коллекции может лишь ее создатель.
При добавлении к списку доступа уже существующей коллекции нового участника, опубликованные ранее данные становятся ему доступны автоматически.
При удалении участника из списка доступа новые опубликованные данные будут ему недоступны.
Платформа поддерживает структурирование данных в коллекции в формате JSON и валидацию формата документа в ней по JSON-схеме.
Платформа предоставляет АПИ, изолирующий пользователя от деталей реализации самого блокчейна и позволяющий работать с понятиями более высокого уровня («документ» и «коллекция»).
Платформа не предусматривает удаления данных, таким образом, ни один участник не может удалить документ из коллекции, доступной другим участникам.
При обновлении документа, сохраняется полная история его изменений, и есть возможность получения любой из версий документа.
Платформа поддерживает отправку внешним системам участника настраиваемых уведомлений об изменении/обновлении данных в интересующей коллекции, таким образом, информационные системы одного участника могут оперативно реагировать на обновления данных, сделанные информационными системами другого участника.

Как видите список довольно внушительный. Конечно, у системы есть и некоторые недостатки, о которых мы знаем: например, если мы один раз дали кому-то доступ к данным, можно предположить, что эти данные он уже скопировал и может отдать кому-либо еще, но это уже вне контроля нашей системы. Однако, такого рода риски есть у любой системы. Еще одним недостатком системы, обусловленным использованием блокчейна и необходимостью операций шифрования/дешифрования данных на лету, является общая пропускная способность, составившая ~30 транзакций в секунду, что оказалось более чем достаточно для конкретной задачи, но может являться ограничивающим фактором для применения Платформы в ряде других сценариев.

Что касается принципа работы механизма управления доступом к данным, то он основан на гибридной схеме шифрования:

Зарегистрированный участник системы получает публичный и приватный ключ. Публичный ключ каждого участника является общедоступным и публикуется в блокчейне.
Участник №1 создаёт новую коллекцию и определяет, с кем из участников системы он хотел бы поделиться её содержимым (Участник №2 и №3), затем добавляет в эту коллекцию документ.
Платформа шифрует документ сгенерированным симметричным ключом (это значит, что для расшифровки потребуется тот же ключ, что и для шифрования). Такой ключ имеет значительно меньший объем, чем, сам зашифрованный документ.
Платформа извлекает из блокчейна публичные ключи участников №2 и №3 и шифрует ими симметричный ключ, и помещает результаты в блокчейн.
Участники №2 и №3 входят в систему и пытаются просмотреть содержимое коллекции. Платформа расшифровывает приватными ключами участников №2 и №3 симметричный ключ, после чего этим ключом расшифровывает документ. Таким образом участники №2 и №3 получают доступ к его содержимому.

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

Участник проходит регистрацию в Учётном центре (далее УЦ№1), подавая все необходимые документы и данные.
Учётный центр выдаёт участнику электронную подпись и привязывает к ней все подданные им данные, складывая всё это в блокчейн.
Когда участник заходит на площадку по государственным закупкам (далее Площадка №1), она извлекает его регистрационные данные из Коллекции, созданной УЦ№1.
Возможна ситуация, когда площадке не хватит этих данных и она запросит дополнительные или же захочет хранить другую информацию (например, историю участия в торгах) по конкретному клиенту, чтобы поделиться ей с другой дружественной площадкой. В этом случае, она создаёт в блокчейне новую коллекцию с этими дополнительными данными.
Когда Участник решает зарегистрироваться на Площадке №2 она также берёт его регистрационные данные из коллекции УЦ №1 или же из коллекции созданной Площадкой №1

Итог

На данный момент наше решение внедрено и успешно работает. Если у вас есть вопросы или замечания – пишите в комментарии, будем рады ответить или подискутировать.

habr.com

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

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

Распределенность — поскольку вся инфраструктура блокчейна и приложений на нем распределенная, хранилище данных также должно быть распределенное и децентрализованное.
Публичность — блокчейн позволяет всем желающим добавлять своё оборудование в сеть. Логично было бы ожидать того же от хранилища данных.
Устойчивость к проблеме византийских генералов и другим типам атак в публичной сети — в публичной распределенной сети без этого никак.
Поддержка шардинга — если мы ожидаем, что приложение будет популярно и будет хранить огромные объемы данных, то хорошо бы воспользоваться мощностью сети, чтобы увеличить максимальные объемы хранения. Полная репликация данных на каждом узле, разумеется, уменьшает шансы потери данных в случае проблем с отдельными узлами. Однако в случае большой мощности сети, например, сотни или тысячи серверов, дублировать все данные на всех серверах чрезвычайно избыточно, и можно уменьшить уровень репликации в пользу увеличения максимального суммарного объема данных. То есть, если у нас 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 совершенно не подходит для хранения данных децентрализованных приложений в публичных сетях.

Выводы

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

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

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

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

→ Третья часть статьи → Первая часть статьи

habr.com