Чтобы понять базовые требования к распределенному реестру, было бы полезно прояснить чем эти системы отличаются от обычных баз данных, управляемых, как правило, одной организацией. В качестве примера давайте рассмотрим простую систему отслеживания прав собственности на акции компании. Каждая строка помещенного в базу данных реестра содержит два столбца: идентификатор личности, такой, как имя, и соответствующее ему количество акций.
Существует шесть ключевых аспектов, с точки зрения которых эта система может не выполнить возложенные на нее обязанности.
- Подделка: Перевод акций от одного человека к другому без разрешения владельца.
- Цензура: Отказ от выполнения какого-либо запроса на перевод акций в чью-либо пользу.
- Откат операций: Отмена ранее совершенных переводов.
- Нелегитимность: Изменение общего количества акций в системе без ведома эмитента или действий с его стороны.
- Непоследовательность: Предоставление разных ответов на идентичные запросы разных пользователей.
- Простой: Полное отсутствие какого-либо ответа на полученные запросы.
Вероятность каждого такого сбоя вынуждает акционеров внимательно следить за тем, чтобы управляющий реестром от их лица посредник действительно заслуживал столь высокого уровня доверия. Создание достойной такого доверия организации и успешное управление ей требует немалых усилий и затрат.
Блокчейны и распределенные реестры устраняют потребность в подобного рода операторах централизованных БД, позволяя пользователям базы взаимодействовать друг с другом напрямую на основе равноправного подхода. Применительно к нашему примеру акционеры могли бы безопасно держать свои акции в блокчейне и делать мгновенные прямые переводы в пользу друг друга, управляя им коллективно.
Все это возвращает нас обратно к вопросу блокчейн-платформ. Чтобы быть пригодным в качестве основы для одноранговой коллективной базы данных, блокчейн должен защищать своих участников от всех шести типов сбоев, то есть подделки, цензуры, отката операций, неправомерных операций, непоследовательности и простоев. Несмотря на то что многие продукты на рынке соответствуют этим требованиям, есть все же целая группа решений, которые не вписываются в подобную характеристику. Я называю такие блокчейн «наполовину сырыми», поскольку они позволяют устранить некоторые из перечисленных выше рисков, но не все. В каждом из таких проектов есть по крайне мере некоторые аспекты, где пользователи базы остаются зависимыми от правильного поведения одного-единственного участника процесса — сценарий, которого блокчейн-решениям необходимо избегать.
Несмотря на большое разнообразие таких полусырых блокчейнов, существуют три архетипа, выделяющиеся из общего потока как наиболее распространенные или очевидные. В этом материале я воздержусь от названия индивидуальных проектов поскольку не хочу кидать камни в чей-либо огород. Тем не менее важно понимать, что если мы хотим, чтобы блокчейны рано или поздно получили признание в качестве полноценной, понятной и завершенной категории продуктов, нам важно научиться проводить линию между полусырыми и реальными решениями.
Блокчейн с единственным валидатором
Один из распространенных подходов сводится к созданию блокчейна, в котором задача генерации блоков подтвержденных транзакций отводится некоему единственному узлу сети. Вместо рассылки транзакции всем узлам сети, система отправляет их одному-единственному узлу, в результате чего вместо объективного процесса достижения согласия со стороны большинства участников этот процесс попадает в зависимость от капризов центрального узла. Впрочем, после генерации каждый блок все же рассылается всем остальным, каждый из которых самостоятельно подтверждает валидность содержащихся в нем транзакций и фиксирует новый блок в своей локальной копии реестра без возможности его последующего изменения.
Если рассмотреть этот тип блокчейнов с точки зрения нашей модели из шести пунктов, то он окажется вполне очень даже полезным продуктом. Транзакции проходят обязательную подписку со стороны узла, чьи средства они затрагивают, поэтому центральный валидатор не сможет их подделать. Они не подлежат возврату, поскольку каждый из узлов хранит собственную копию «чейна». Кроме того, транзакции не могут быть использованы для запрещенных операций, таких, как создание активов из воздуха, поскольку каждый узел проверяет каждую транзакцию на достоверность самостоятельно и независимо от других. И, наконец, каждый узел сохраняет собственную копию базы данных поэтому ее содержимое всегда доступно для чтения.
К сожалению, четырех из шести пунктов недостаточно. Узел-валидатор может с легкостью подвергнуть цензуре отдельные транзакции, отказавшись включить их в создаваемые им блоки. И даже если оператор этого узла ведет себе максимально честно, системный или коммуникационный сбой может сделать его недоступным, что приведет к приостановке обработки абсолютно всех транзакций. Вдобавок к этому, в зависимости от настроек, узел-валидатор имеет возможность отправлять разным участникам различные версии блокчейнов. С точки зрения таких характеристик, как цензура и последовательность работы, такой тип баз данных по-прежнему имеет единую точку отказа, от которой при этом зависит работоспособность всех остальных узлов.
Существует одна платформа, предлагающая некоторую измененную версию этой схемы, когда блоки генерируются централизованно одним узлом, но проверяются кворумом специально назначенных узлов, подписывающих блоки и завершающих тем самым процесс достижения консенсуса. В плане последовательности дела в таких системах обстоят существенно лучше. Узлы кворума отдают свою подпись в пользу одной-единственной версии блокчейна, которую, таким образом, можно считать авторитетной. Как бы то ни было, узлы кворума не смогут помочь, если генератор блоков пожелает подвергнуть транзакции цензуре или попросту потеряет связь с Интернетом. В конечном счете архитектура этого типа блокчейнов сводиться к принципу «головы и подчиненных», но никак не к одноранговой сети.
Блокчейн с коллективной проверкой состояния
Говоря технически, между блокчейнами и более традиционными распределенными БД, такими как Cassandra и MongoDB существует много сходств. В обоих случаях, транзакции могут быть инициированы единственным узлом сети, а информация о них должна быть передана всем узлам в процессе достижения консенсуса по поводу состояния БД и внесенных в нее изменений. Как блокчейны, так и распределенные базы должны уметь справляться с задержкой (например, коммуникационными задержками, обусловленными расстоянием между узлами) и предусматривать вероятностью того, что некоторые узлы и/или коммуникационные каналы периодически испытывают неполадки.
Распределенные БД существуют уже довольно давно, поэтому любой разработчик блокчейн-платформ без проблем разберется с их алгоритмами консенсуса и стратегиями, которые они применяют для общего регулирования транзакций и разрешения конфликтов. Как бы то ни было, важно не заходить слишком далеко в этом сравнении поскольку блокчейны, в отличие от первых, всегда предстают перед ключевым и непростым дополнительным условием — отсутствие доверия между узлами базы данных. В то время как распределенные БД предоставляют масштабируемость, надежность и высокие показатели работы в рамках одной организации, блокчейны должны быть изначально спроектированы так, чтобы уметь преодолевать подобные рамки.
Вернемся, однако, к нашим шести характерным для БД рискам. Узел распределенной базы данных заботится только о простое. Например, о ситуациях, когда другие узлы становятся недоступны. В таких условиях валидность каждой транзакции или сообщения в сети никак не поддаются проверке и потому факты подделки, цензуры, возврата, нарушения правил или ошибочной отработки упускаются из виду. Худшая с точки зрения таких БД проблема — обработка двух одновременных, но валидных транзакций, инициированных разными узлами и касающихся одной и той же информации. Конечно, разрешение этих конфликтов тривиальным процессом вовсе не является. И все же обработка таких ситуаций гораздо проще «задачи византийских генералов», когда некоторые узлы намеренно действуют так, чтобы подорвать функционирование других.
Безопасная коллективная работа с базой данных вне рамок доверия может быть достигнута, только если все узлы изначально относятся к любой активности с определенной долей подозрения. К примеру, каждая транзакция, которая изменяет базу данных должна быть подписана индивидуальной цифровой подписью, поскольку при использовании одноранговой архитектуры не существует иного способа узнать, откуда начались те или иные изменения. Похожим образом каждое входящее сообщение, такое, как объявление нового блока, должно пройти критическую оценку как содержимого блока, так и контекста его формирования. В отличие от распределенных БД, здесь каждый отдельный узел не должен иметь возможности прямо и мгновенно изменять состояние любого другого узла.
Некоторые «блокчейн-платформы» изначально разрабатывались на основе распределенной базы с последующим добавлением поверх этой базы таких «фишек», которые позволили бы им лучше сойти за своего в ряду полноценных блокчейн-решений. К примеру, группируя транзакции в блоки и сохраняя хеши этих блоков в базе данных, они пытаются получить некую форму неизменяемости. Однако в условиях, когда каждый узел не может быть уверен, что его список хешей не защищен от модификации со стороны другого узла, такая неизменяемость легко поддается обходу.
Черный блокчейн-ящик в облаке
Самый странный на данный момент феномен, который мне доводилось видеть — это блокчейн-платформы, доступ к которым можно получить только посредством приобретения облачной platform-as-a-service услуги, расположенной на стороне разработчика. Сразу внесу ясность и скажу, что речь идет не о решении некоторых участников сектора выбрать поставщиков облачных решений, таких, как Microsoft Azure или Amazon Web Services в качестве площадки для своих узлов. Мы говорим скорее о блокчейнах, воспользоваться которыми можно только посредством API, доступного с серверов обслуживающей такой блокчейн компании.
Допустим, спора ради, что централизованный блокчейн-поставщик действительно обладает группой узлов, работающих под его управлением. Но что это меняет для пользователей системы, которые в данном случае могут только отправлять API-запросы и получать на них ответы? Они фактически не имеют никакого способа оценки ошибок или упущений, возникающих при обработке транзакций. В результате реальной становиться ситуация, при которой центральный сервис может работать некорректно, а также умышленно подвергать цензуре или откатывать отдельные транзакции. Но даже если вы верите, что блокчейн-поставщик не имеет причин так поступать, почему бы, вместо этого, не воспользоваться подобным сервисом для хранения самой обычной централизованной базы данных? Вы получите более зрелый продукт с лучшими показателями производительности, исключив любые риски, сопутствующие работе с новыми технологиями. Говоря кратко, централизованные блокчейны столь же полезны, как несколько деталей лего, связанных вместе одной ниткой.
Загадки и их разгадки
Итак, мы только что рассмотрели три типа платформ, позиционирующих себя на рынке как «блокчейны», действительно применяющие на практике «блоки и чейны», но не предоставляющие, однако, решения фундаментальной задачи, ради которой они были изначально придуманы. Если коротко, суть ее в том, чтобы создать условия для безопасной коллективной работы с базой данных в отсутствии какого-либо доверия и центрального посредника.
Кроме самого рассказа об этом любопытном феномене, я полагаю, поучительно было бы также рассмотреть, что может лежать в его основе. Почему столь многие блокчейн-стартапы создают продукты, неспособные сдержать связанных с этой технологией обещаний? Почему они останавливаются на уровне традиционных централизованных или распределенных баз данных? Почему так много талантливых людей тратят впустую так много своего времени?
Здесь я вижу два главных направления рассуждения — техническое и коммерческое. С технической точки зрения, создание распределенной системы достижения консенсуса, способной выдержать непредсказуемое и вредоносное поведение одного или нескольких узлов — задача не из простых. В случае с MultiChain разработчики немного схитрили, взяв за основу для разработки проверенную в боевых условиях эталонную реализацию Биткойна, и после, заменив механизм «доказательства работы» структурно схожим алгоритмом консенсуса под названием mining diversity. Команды, занятые разработкой блокчейн-узлов с нуля должны как следует продумать асинхронные и состязательные процессы, а это такое сочетание, опыт работы с которым есть далеко не у всех программистов. Я прекрасно понимаю желание поддаться соблазну и пойти по более короткому пути, сосредоточив, к примеру, генерацию блоков «в руках» одного узла. Точно так же понятно и желание создать вариацию на тему современных распределенных БД или запускать «боевые» узлы только в доверенной среде. Выбор любого из этих подходов, вне всяких сомнений, упрощает разработчикам жизнь, даже если такое решение и сказывается на итоговой практической пользе от проекта.
Что касается коммерческих причин, то здесь каждый стартап ищет собственный подход к тому, чтобы выжать максимум из Блокчейна как бизнес-идеи. Компания Coin Sciences, например, распространяет MultiChain бесплатно, параллельно предоставляя возможность разработки премиум-узлов с дополнительной функциональностью. Другие стартапы хотят продавать услуги подписки и потому, как принято в таких моделях, создают платформы, которые клиенты не смогут полностью разместить в собственных средах. Некоторые надеются управлять блокчейнами централизовано или помогать своим партнерам осуществлять такое управление (что, конечно, звучит очень странно, учитывая что речь идет о технологии, устраняющей посредников) и потому они, по вполне понятным причинам, выбирают алгоритмы консенсуса, полагающиеся на единственный узел. Ну и наконец, существуют компании, главная цель которых заключается в продаже консалтинговых услуг. Они не нуждаются в собственной функционирующей платформе до тех пор, пока их веб-сайт продолжает привлекать сколько-нибудь крупных клиентов.
Другая возможная проблема заключается в том, что руководителям некоторых блокчейн-компаний — людям, безусловно, очень талантливым — попросту не хватает глубокого понимания технологии как таковой. Все же в стартапах, формирующих новые области и рынки, ключевые стратегические решения должны приниматься людьми, хорошо понимающими природу технологии и способными оценить разницу между ней и ее аналогами. История знает немало примеров стартапов, которые сами загнали себя в угол, пытаясь угнаться за привлекательным для их клиентов, но нереализуемым на практике видением.
Будучи пользователем блокчейнов, как можете вы избежать тех же ошибок? Оценивая ту или иную блокчейн-платформу, всегда спрашивайте, выполняет ли она шесть главных требований, справедливых для каждой безопасной одноранговой коллективной БД: предотвращение простоев, одинаковые результаты обработки идентичных транзакций, наличие механизмов защиты от подделок, цензуры, откатов транзакций и нарушения легитимности. И, конечно, будьте очень внимательны если в ответ звучит невнятное бормотание или активная жестикуляция руками: скорее всего, все это будет означать «нет».
