Почему многие варианты использования смарт-контрактов просто невозможны

Доктор Гидеон Гринспен — основатель и генеральный директор Coin Sciences, компании, стоящей за платформой MultiChain для частных блокчейнов.

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

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

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

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

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

Смарт-контракт — это просто красивое название для кода, который работает на блокчейне и взаимодействует с состоянием этого блокчейна. А что такое код? Это Pascal, это Python, это PHP. Это Java, это Fortran, это C++. Если мы говорим о базах данных, это хранимые процедуры, написанные в расширении SQL.

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

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

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

За последние девять месяцев нам предлагали множество вариантов использования смарт-контрактов, и мы раз за разом отвечали, что их просто невозможно реализовать.

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

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

1. Обращение к внешним службам

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

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

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

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

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

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

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

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

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

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

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

Рассматривая эти два обходных пути, мы можем сделать некоторые наблюдения.

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

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

Мы поговорим об этом подробнее позже.

2. Обеспечение осуществления платежей в сети

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

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

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

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

Другими словами, смарт BOND либо бессмыслен для эмитента, либо бессмыслен для инвестора. И если подумать, то это совершенно очевидный результат.

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

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

3. Сокрытие конфиденциальных данных

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

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

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

Итак, если ONE смарт-контракт T может получить доступ к данным другого, решили ли мы проблему конфиденциальности блокчейна? Имеет ли смысл говорить о сокрытии информации в смарт-контракте? К сожалению, ответ — нет.

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

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

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

Более-менее приличный программист мог бы сделать это примерно за час.

Для чего нужны смарт-контракты

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

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

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

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

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

ONE представить себе различные способы выражения этих правил, но на данный момент существуют две доминирующие парадигмы, вдохновленные Bitcoin и Ethereum соответственно. Метод Bitcoin , который мы могли бы назвать «ограничениями транзакций», оценивает каждую транзакцию с точки зрения: (a) записей базы данных, удаленных этой транзакцией, и (b) записей, созданных.

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

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

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

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

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

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

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

Каким бы ни был ответ, главное помнить, что смарт-контракты — это всего лишь ONE из методов ограничения транзакций, выполняемых в базе данных.

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

Изображение карандаша и ластикачерез Shutterstock