Как определить полусырой блокчейн

Когда цепи и блоки не служат никакой полезной цели

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

Естественно, взрывной рост числа проектов блокчейнов стал причиной разработки разрешенных платформ блокчейнов, на которых строятся эти проекты. Например, наш продукт многоцепочечного За прошедший год число пользователей увеличилось втрое, независимо от того, измеряем ли мы веб-трафик, ежемесячные загрузки или коммерческие запросы. И, конечно же, есть много других платформ, таких как Бигчейндб, цепь, Веревка, кредиты, Elements, Эрис, Ткань, Эфириум (развернут в закрытой сети), ГидраЦепь и Открытая цепь, Не говоря уже о новых стартапах, которые разработали какую-то платформу блокчейна, но не сделали ее общедоступной.

Для компаний, желающих исследовать и понимать новые технологии, выбор, как правило, полезен. Тем не менее, в случае блокчейнов, которые все еще остаются плохо определенными и плохо понятыми, эта рога изобилия имеет существенный недостаток: многие из доступных платформ «блокчейн» на самом деле не решают основную проблему, которую они призваны решить. И что это за проблема? Позвольте мне процитировать краткое определение видео Ричард Гендал Браун, технический директор R3, в полном объеме:

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

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

Еще одна цепочка блоков, которая не помогает с совместным использованием базы данных. – источник.

Минимально жизнеспособный блокчейн

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

Вот шесть основных способов, которыми эта система могла бы подвести своих пользователей:

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

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

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

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

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

Один валидатор блокчейн

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

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

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

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

Блокчейн общего состояния

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

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

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

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

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

Один облачный блокчейн

Безусловно, самым странным явлением, которое я видел, являются платформы блокчейна, доступ к которым возможен только через облачную платформу как разработчик. Чтобы было ясно, мы не говорим о некоторых участниках блокчейна Выбирая разместить свои узлы на своем облачном провайдере, например Microsoft Azure or Amazon Web Services, Скорее, это блокчейн, который может только быть доступным через API, предоставляемые серверами компании, «размещающей» ее.

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

Разгадывать тайну

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

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

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

Что касается коммерческих причин, то каждый стартап, похоже, рассматривает возможность блокчейна под другим углом. Здесь, в Coin Sciences, мы нацелены на то, чтобы стать поставщиком (баз данных) программного обеспечения, поэтому мы распространяем MultiChain бесплатно, развивая премиальный узел с дополнительными функциями. Другие стартапы хотят продавать услуги подписки, поэтому они, естественно, создадут платформу, которую клиенты не смогут разместить самостоятельно. Некоторые надеются централизованно управлять блокчейном или помочь своим партнерам в этом (странное стремление к технологии дезинтермедиации!) И, естественно, тянутся к согласованным алгоритмам, основанным на одном узле. И, наконец, есть компании, основной целью которых является продажа консалтинговых услуг, и в этом случае их платформа вообще не должна функционировать, если ее веб-сайт привлекает крупных клиентов.

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

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

Пожалуйста, оставьте любые комментарии на LinkedIn.

Источник: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/