Интеллектуальные контракты: Hyperledger Fabric против MultiChain против Ethereum против Corda

Существует несколько способов поместить код в блокчейн

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

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

В этой статье моя цель - изучить некоторые из основных различий между подходами умного контракта и компромиссами, которые они представляют. Я сделаю это, посмотрев на четыре популярные корпоративные блокчейн-платформы, которые поддерживают некоторую форму настраиваемого встроенного кода. Во-первых, IBM Hyperledger Fabric , который называет свои контракты «цепным кодом». Во-вторых, наша платформа MultiChain, которая представляет умные фильтры в версии 2.0. Третий, Эфириум (и его разрешено кворум и Нора спин-оффы), который популяризировал название «умный контракт». И наконец, R3 Corda, который ссылается на «контракты» в своих сделках. Несмотря на всю различную терминологию, в конечном итоге все они относятся к одному и тому же - к конкретному приложению, который определяет правила цепочки.

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

Основы блокчейна

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

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

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

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

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

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

Давайте начнем с правил транзакций, первой из этих задач, и посмотрим, как они выражаются в Fabric, MultiChain, Ethereum и Corda соответственно.

Правила транзакции

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

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

Входы и выходы

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

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

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

Следует отметить, что, несмотря на совместное использование модели ввода-вывода, MultiChain и Corda реализуют ее совершенно по-разному. В MultiChain выходные данные могут содержать активы и / или данные в формате JSON, текстовом или двоичном формате. Правила определены в «фильтрах транзакций» или «потоковых фильтрах», которые могут быть установлены для проверки всех транзакций или только тех, которые связаны с определенными активами или группами данных. Напротив, выходное «состояние» Corda представляется объектом на языке программирования Java или Kotlin с определенными полями данных. Правила Corda определены в «контрактах», которые привязаны к конкретным штатам, и контракт штата применяется только к транзакциям, которые содержат это состояние в своих входах или выходах. Это относится к корде необычная модель видимости, в котором транзакции могут видеть только их контрагенты или те, на чьи последующие транзакции они влияют.

Контракты и сообщения

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

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

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

Пример правил

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

1. Общее количество активов в выходных данных транзакции должно совпадать с общим количеством в ее входных данных. Это мешает пользователям создавать или удалять деньги произвольно.
2. Каждая транзакция должна быть подписана владельцем каждого из ее входов. Это мешает пользователям тратить деньги друг друга без разрешения.

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

В модели контракт-сообщение контракт актива поддерживает сообщение «отправить платеж», которое принимает три параметра: адрес отправителя, адрес получателя и количество для отправки. В ответ контракт выполняет следующие четыре шага:

1. Убедитесь, что транзакция была подписана отправителем.
2. Убедитесь, что у отправителя достаточно средств.
3. Вычтите запрошенное количество из строки отправителя.
4. Добавьте это количество в строку получателя.

Если один из чеков на первых двух этапах не пройден, договор будет прерван, и оплата не будет произведена.

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

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

Встроенные правила

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

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

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

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

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

Правила транзакции	Ткань	многоцепочечного	Эфириум	Веревка
Модель	Договор-сообщение	Ввод, вывод	Договор-сообщение	Ввод, вывод
Встроенные модули	Ничто	Разрешения + активы + потоки	Ничто	Ничто

Детерминизм

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

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

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

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

Источники недетерминизма

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

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

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

Детерминированное исполнение

Начнем с Ethereum, поскольку его подход наиболее «чистый». Контракты Ethereum выражаются в специальном формате, называемом «Байт-код Ethereum», который исполняется виртуальной машиной Ethereum («EVM»). Программисты не пишут байт-код напрямую, а генерируют или «компилируют» его из JavaScript-подобного языка программирования под названием Solidity. (Другие языки раньше были доступны, но с тех пор устарели.) Детерминизм гарантируется тем фактом, что байт-код Solidity и Ethereum не может кодировать какие-либо недетерминированные операции - это так просто.

Фильтры MultiChain и контракты Corda выбирают другой подход, адаптируя существующие языки программирования и среды выполнения. MultiChain использует JavaScript, запущенный в Google V8 движок, который также формирует ядро ​​браузера Chrome и платформы Node.js, но с отключенными источниками недетерминизма. Точно так же Corda использует Java или Котлиноба из которых скомпилированы в «байт-код Java», который выполняется в виртуальной машине Java («JVM»). На данный момент Corda использует стандартную недетерминированную JVM от Oracle, но ведется работа по интеграции детерминистическая версия, Тем временем разработчики контрактов Corda должны позаботиться о том, чтобы не допустить недетерминизма в их коде.

Как пуризм Эфириума соотносится с эволюционным подходом, принятым MultiChain и Corda? Основным преимуществом Ethereum является минимизация рисков - встроенная виртуальная машина с меньшей вероятностью содержит непреднамеренный источник недетерминизма. Хотя любое такое упущение может быть исправлено обновлением программного обеспечения, оно может нарушить работу любой цепочки, которой не повезло встретить ее. Проблема Ethereum, однако, заключается в том, что Solidity и EVM составляют крошечную и зарождающуюся экосистему в более широком контексте языков программирования и сред выполнения. Для сравнения, JavaScript и Java являются два лучших языка на Github, работают на миллиардах цифровых устройств и имеют время выполнения, оптимизированное за десятилетия. Предположительно, именно поэтому публичный блокчейн Ethereum рассматривает возможность перехода к eWASM, детерминированный форк появляющегося стандарта WebAssembly.

Детерминизм одобрением

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

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

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

Ткань детерминизм за одобрение имеет ряд интересных последствий. Во-первых, цепной код может быть написан на многих разных языках программирования, поскольку их не нужно адаптировать к детерминизму (в настоящее время поддерживаются Go, Java и JavaScript). Во-вторых, цепной код может быть скрыт от некоторых участников блокчейна, поскольку он должен выполняться только клиентами и индоссантами (сама база данных видна глобально). Наконец, что особенно важно, код цепи Fabric может выполнять действия, запрещенные в других средах блокчейна, например, проверять погоду с помощью онлайн-веб-API. В худшем случае, когда каждый индоссант получает разные ответы от этого API, клиенту не удастся получить достаточное количество одобрений для какого-либо конкретного результата, и транзакция не состоится. (Следует отметить, что члены команды Fabric до сих пор рекомендовать использование детерминированной логики внутри цепочки кода, чтобы избежать неожиданностей.)

Какую цену Ткань платит за эту гибкость? Если цель блокчейна состоит в удалении посредников из приложения, управляемого общей базой данных, то зависимость Fabric от индоссантов делает большой шаг от этой цели. Участникам цепочки уже недостаточно следовать правилам цепочки кодов - им также нужны определенные другие узлы, чтобы согласиться с тем, что они это сделали. Хуже того, злонамеренное подмножество индоссантов может одобрить изменения в базе данных, которые вообще не соответствуют цепочечному коду. Это дает индоссантам гораздо больше возможностей, чем валидаторам в обычных цепочках блоков, которые могут подвергать цензуре транзакции, но не могут нарушать правила цепочки блоков. Разработчики приложений Blockchain должны решить, имеет ли этот компромисс смысл в их конкретном случае.

Детерминизм	Ткань	многоцепочечного	Эфириум	Веревка
Модель	Подтверждения	Адаптированная среда выполнения	Специально построенная ВМ	Адаптированная среда выполнения
Языки	Перейти + Java + JavaScript	JavaScript	основательность	Ява + Котлин
Видимость кода	Контрагенты + индоссанты	Блокчейн	Блокчейн	Контрагенты + иждивенцы
Насильственные	Нет	Да	Да	Нет пока что)

Предотвращение конфликтов

До сих пор мы обсуждали, как разные платформы блокчейнов выражают правила транзакций в коде и как они детерминистически гарантируют, что каждый узел применяет эти правила одинаково. Теперь пришло время поговорить о третьем аспекте нашего вскрытия: как каждая платформа имеет дело с возможностью того, что две транзакции, которые являются действительными сами по себе, конфликтуют друг с другом? В простейшем примере представьте, что Алиса имеет 10 долларов в бухгалтерской книге и транслирует две транзакции: одну отправляет 8 долларов Бобу, а другую - 7 долларов Чарли. Очевидно, что только одна из этих транзакций может быть успешно завершена.

Две модели

Мы можем начать с объединения подходов MultiChain и Corda к этой проблеме. Как описано ранее, оба они используют модель ввода-вывода для представления транзакций и их правил, в которых каждый вход транзакции тратит выходные данные предыдущей транзакции. Это приводит к простому принципу предотвращения конфликтов: каждый выход может быть проведен только один раз. Фильтры MultiChain и контракты Corda могут полностью полагаться на свои соответствующие платформы для обеспечения соблюдения этого ограничения. Поскольку Алиса в размере 10 долларов США представляет собой результат предыдущей транзакции, это правило одноразовых расходов автоматически останавливает ее отправку как Бобу, так и Чарли.

Несмотря на это сходство, важно указать на ключевое различие в том, как MultiChain и Corda предотвращают конфликты. В MultiChain каждый узел видит каждую транзакцию и поэтому может независимо проверять, что каждый вывод расходуется только один раз. Любая транзакция, которая выполняет двойные расходы против ранее подтвержденной транзакции, будет немедленно и автоматически отклонена. В отличие от этого, в Corda нет глобальной цепочки блоков, поэтому для предотвращения двойных расходов необходимы «нотариусы». Каждое состояние выхода Corda присваивается нотариусу, который должен подписать любую транзакцию, тратящую этот вывод, подтверждая, что она не была потрачена ранее. Участники блокчейна должны доверять нотариусам, чтобы честно следовать этому правилу, а злые нотариусы могут вызвать хаос по желанию. Как и в случае одобрения в ткани, это «разовый расход как услуга«Дизайн имеет преимущества с точки зрения конфиденциальности, но вновь вводит посредников, идущих против зерна блокчейна. (Важно уточнить, что нотариусы Corda могут управляться группами участников с использованием согласованного алгоритма, поэтому целостность регистра по-прежнему может быть защищена от отдельных плохих действующих лиц).

Давайте перейдем к Ethereum. Чтобы напомнить, Ethereum использует контракты и сообщения, а не входы и выходы. В результате конфликты транзакций, такие как два платежа Алисы, не сразу видны движку блокчейна. Вместо этого они обнаруживаются и блокируются контракт который обрабатывает транзакции после подтверждения их заказа в цепочке. При обработке каждого платежа Алисы контракт проверяет, является ли ее баланс достаточным. Если транзакция, выплачивающая Бобу 8 долларов США, наступит первой, она будет обработана как обычно, и Алиса получит 2 доллара на своем счете. В результате, когда контракт обрабатывает вторую транзакцию, выплачивая Чарли 7 долларов, он видит, что Алисе не хватает необходимых средств, и транзакция прерывается.

Выходы против контрактов

До сих пор мы видели два разных метода предотвращения конфликтующих транзакций: одноразовые затраты в MultiChain и Corda и проверка на основе контрактов в Ethereum. Так что лучше?

Чтобы помочь ответить на этот вопрос, давайте рассмотрим примерный счет с несколькими подписями «1-о-2», который держит 100 долларов от имени Гэвина и Хелен и позволяет любому из них тратить эти деньги независимо. Гэвин поручает своему заявлению заплатить 80 долларов Донне, а через несколько секунд Хелен хочет отправить 40 долларов Эдварду. Поскольку для обоих платежей недостаточно средств, эти транзакции неизбежно будут конфликтовать. В случае, если обе транзакции переданы, результат будет определяться тем, что сделает его первым в цепочке. Обратите внимание, что в отличие от примера Алисы, этот конфликт случайный, поскольку никто не пытается нарушить правила приложения - им просто не повезло.

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

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

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

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

Чтение-запись наборов

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

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

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

Предотвращение конфликтов	Ткань	многоцепочечного	Эфириум	Веревка
Модель	Чтение-запись наборов	Разовые расходы	Контрактные проверки	Разовые расходы
проверка	Независимый	Независимый	Независимый	Доверенные нотариусы
Скорость	~ 10с (подтверждение)	~ 1 с (распространение)	~ 10с (подтверждение)	0 ~ 5с (нотариус)

Комплексный выбор

В этой части мы рассмотрели многие из различных способов, которыми Corda, Ethereum, Fabric и MultiChain решают ключевые проблемы «умных контрактов» или кода приложения, встроенного в блокчейн. И у каждой платформы есть свои ответы на три основных вопроса: как представлены правила транзакций? Как код выполняется детерминистически? И как мы можем предотвратить конфликты?

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

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