[Перевод] Почему многие кейсы применения умных контрактов попросту неосуществимы
Одно из предназначений смарт-контрактов — автоматизация платежных операций между контрагентами. На этом рынке работает и наш платежный блокчейн-сервис Wirex. Несмотря на перспективность смарт-контрактов, автор материала анализирует недостатки этой технологии.
Как разработчика популярной блокчейн-платформы меня иногда спрашивают есть ли в планах развития нашего сервиса Multichain место умным контрактам по типу тех, что используются в Ethereum. В ответ всегда звучит: «Нет, или во всяком случае не сейчас».
Но ведь в шумном хайповом мире блокчейнов умные контракты считаются чем-то очень крутым. Почему же ответ всегда нет? Что ж, проблема в том, что если в случае с работающими подобно биткоину контролируемыми блокчейнами нам известны как минимум три мощных сценария их практического применения (отслеживание истории происхождения, хранение документов компаний, облегченная организация финансовых систем), то для эфирных умных контрактов эквивалентных по эффективности кейсов попросту не существует.
Дело не в том, что люди не понимают, чего они хотят от умных контрактов. Проблема скорее в том, что очень многие из этих идей попросту неосуществимы. Когда умные люди слышат термин «умные контракты», они, как правило, дают волю своему воображению. Рисуют в голове картины умного автономного ПО, оседлавшего волну данных и подключающегося к решению задач реального мира. К сожалению, реальная картина работы умных контрактов гораздо более прозаична.
Умный контракт — фрагмент кода, хранящийся в блокчейне. Он приводится в действие блокчейн-транзакциями и читает из блокчейна или пишет в него данные. Вот и все. Ни больше, ни меньше.
Умный контракт — всего лишь звучное название кода, который работает на блокчейне и взаимодействует с его состоянием. Что же это за код? Это Pascal, Python или PHP. А может быть, Java, Fortran или C++. Если мыслить форматом баз данных, то его можно представить в виде процедур, написанных на каком-либо расширении SQL.
Фундаментально все эти языки эквиваленты, они решают те же самые виды задач, применяя те же способы их решения. Конечно, у каждого из них есть сильные и слабые стороны. Вы сошли бы с ума, пытаясь создать веб-сайт на C или сжать HD-видео в Ruby. Но по крайней мере чисто теоретически вы могли бы это сделать, если бы захотели. Вам просто пришлось бы заплатить высокую цену с точки зрения удобства, производительности, и весьма вероятно, потерять немало волос на голове.
Проблема умных контрактов заключается не только в чрезмерно завышенных ожиданиях, но еще и в том, что ожидания эти приводят к тому, что немалое количество людей тратят время и деньги на идеи, реализовать которые на практике едва ли получится.
Практика показывает, что у крупных компаний, как правило, есть достаточно ресурсов чтобы пройти длинный путь от момента, когда топ-менеджмент узнает о новой технологии до момента, когда ее преимущества и ограничения становятся по-настоящему понятны.
На протяжении последних девяти месяцев мы выслушали немало питчей на тему возможных сценариев применения умных контрактов и так уж вышло, что раз за разом мы отвечали их авторам, что эти идеи попросту невозможно воплотить в реальной жизни.
В результате мы выделили тройку наиболее распространенных заблуждений на тему умных контрактов. Эти идеи неверны не потому, что технология еще недостаточно созрела или не из-за того, что у нас пока нет каких-то инструментов.
Вместо этого, они основываются на непонимании фундаментальных свойств кода, живущего в базе данных и обрабатываемого децентрализованным способом.
1. Взаимодействие с внешними сервисами
Часто можно слышать предложение воспользоваться умными контрактами, изменяющими свое поведение в ответ на некое внешнее событие. К примеру, сельскохозяйственный страховой полис, производящий выплаты в зависимости от количества осадков, выпавших в тот или иной месяц.
По замыслу авторов идеи процесс протекает примерно следующим образом: умный контракт выжидает некоторое предопределенное время, получает метеосводку от внешнего сервиса и ведет себя в соответствии с полученными данными.
Звучит довольно просто. Просто и в то же время невозможно. Почему? Потому что блокчейн — это основанная на консенсусе система, а это означает, что работать она будет, только если каждый узел сети достигает одинакового состояния после обработки каждой транзакции и каждого блока.
Все происходящие в блокчейне операции должны быть полностью детерминированы, без малейшей вероятности, что в его работу закрадется какое-либо различие. Как только два честных узла занимают разные позиции по вопросу состояния чейна, вся система становится бесполезной.
А теперь напомню, что каждый узел чейна исполняет умные контракты независимо. Это значит, что если умный контракт получает некоторую информацию из внешнего источника, то каждый узел повторяет процедуру получения данных самостоятельно. Но поскольку источник находится за пределами блокчейна, нет никакой гарантии, что каждый узел получит одинаковый ответ.
Возможно, источник изменит свой ответ в некий момент времени между запросами двух разных узлов, или возможно станет временно недоступен. Так или иначе, консенсус достигнут не будет и весь блокчейн перестанет работать.
Какой же можно найти выход из ситуации? А выход на самом деле очень простой. Надо всего лишь заменить процесс обращения умного контракта к внешнему источнику на одного или нескольких доверенных сторон (так называемых оракулов) создающих транзакцию, записывающую нужные данные в чейн. Тогда у каждого узла будет идентичная копия данных, и их можно будет использовать в вычислениях умного контракта.
Другими словами, вместо умного контракта, «подтягивающего» данные извне, оракул будет вписывать эти самые данные в блокчейн.
Похожие проблемы возникают и когда дело доходит до умных контрактов, инициирующих определенные события во внешнем мире. К примеру, многим нравится идея умных контрактов, обращающийся к API банка для перевода денег. Но если каждый узел выполняет код чейна независимо, какой из узлов будет отвечать за вызов API?
Если это будет какой-то один узел, то что произойдет, если именно этот узел, умышленно или непроизвольно начнет сбоить? А если обращаться будут все узлы, можем ли мы доверять каждому узлу пароль от API? Да и оправдано ли будет делать сотни обращений вместо одного? И что еще хуже: если умному контракту необходимо определять успешность обращения к API, то мы снова сталкиваемся с проблемой зависимости от внешних данных.
И здесь тоже есть простой выход. Вместо того чтобы поручать обращение к внешнему API умному контракту, мы можем воспользоваться доверенным сервисом, осуществляющим мониторинг состояния блокчейна и совершающим определенные действия в ответ на полученные данные. Например, банк мог бы проактивно следить за блокчейном и осуществлять переводы денег, соответствующие одобренным в чейне транзакциям. Такой подход не создает никаких рисков для достижения консенсуса, поскольку чейн в этой модели играет абсолютно пассивную роль.
Рассмотрев предложенные выходы из описанных выше ситуаций, мы можем сделать некоторые выводы.
Во-первых, оба подхода требуют наличия некой доверенной третьей стороны для управления взаимодействиями между блокчейном и внешним миром. Несмотря на теоретическую возможность реализации такой модели, любая децентрализация в ее рамках теряет всякий смысл.
Во-вторых, использованные в этих примерах механизмы представляют собой прямые примеры чтения и записи в базу данных. Предоставляющий внешнюю информацию оракул просто пишет ее в чейн. А сервис, повторяющий состояние блокчейна в реальном мире выполняет не что иное, как чтение из этого чейна. Другими словами, любое взаимодействие между блокчейном и внешним миром в таком случае сводится к обычным операциям с базой данных.
Подробнее мы раскроем этот факт далее в материале.
2. Выполнение платежей внутри чейна
Еще одно предложение, которое мы слышим довольно часто: применение умных контрактов для автоматизации выплат по купонам так называемых умных облигаций. Суть идеи в автоматической инициализации выплаты в нужно время, выполняемой умным контрактом. Это позволит избежать ручной обработки выплаты и гарантирует, что эмитент не сможет объявить дефолт.
Конечно, чтобы эта идея сработала, используемые для выплат средства должны также находиться внутри блокчейна. В противном случае умный контракт просто не сможет гарантировать выплату.
Давайте вспомним, что блокчейн — всего лишь база данных. В нашем случае — финансовый реестр, содержащий выпущенные облигации и некоторую кассу. Поэтому когда мы говорим о купонных выплатах, мы на самом деле говорим об операциях с базой данных, выполняемых автоматически в согласованный срок.
Несмотря на то что с технической точки зрения такая автоматизация осуществима, затруднения возникают с финансовым аспектом модели. Если используемые для купонных выплат средства управляются облигационным умным контрактом, то тогда эти выплаты действительно можно гарантировать. Но в таком случае эмитент облигаций не сможет воспользоваться этими средствами для каких-либо других целей. А вывод средств из-под контроля умного контракта, делает любые гарантии их выплаты недействительными.
Иными словами, умная облигация оказывается бессмысленна или для эмитента, или для инвестора. Если поразмышлять над этой ситуацией, то подобный вывод становится совершенно очевиден.
С точки зрения инвестора, суть покупки облигаций заключается в возможности получить привлекательную прибыль, при наличии некоторого, приемлемого риска дефолта. Для эмитента смысл выпуска облигаций заключается в привлечении средств для продуктивной, но несколько рискованной деятельности, такой, например, как постройка новой фабрики.
Для эмитента не существует способа привлечь средства, и в то же время однозначно гарантировать выплаты инвесторам. Думаю, никого не удивит тот факт, что существующая между риском и прибыльностью закономерность — не входит в список задач, которую блокчейны способны решить.
3. Потребность спрятать конфиденциальные данные
Как я уже писал ранее, самый серьезный вызов, с которым мы сталкиваемся при развертывании блокчейнов — это крайняя степень прозрачности, которую они предоставляют.
Например, если группа из 10 банков захочет вместе создать блокчейн, любые двусторонние транзакции в этом блокчейне немедленно становятся видимы восьми остальным участникам. Несмотря на наличие различных стратегий, позволяющих нивелировать этот эффект, ни одна из них не может превзойти простоту и эффективность централизованной базы данных, управляемой неким доверенным лицом, обладающим полным контролем над уровнями видимости и доступа всех участников.
Некоторые люди полагают, что умные контракты могут решить эту проблему. Их рассуждение начинается с того, что каждый умный контракт содержит собственную миниатюрную базу данных и полностью ей управляет. Все операции чтения и записи в этой БД проходят при полном посредничестве кода контракта, что исключает ситуацию, когда один контракт читает данные другого. (Эта тесная связь между данными и кодом называется инкапсуляцией. Она лежит в основе популярных парадигм объектно-ориентированного программирования).
Итак, ни один умный контракт не может получить доступ к данным других умных контактов. Но решает ли это задачу конфиденциальности внутри блокчейна? Есть ли смысл говорить о сокрытии информации внутри умного контракта? К сожалению, ответ отрицательный.
Да, умный контракт не может читать данные других контрактов, однако эти копии этих данных по-прежнему находятся в каждом отдельном узле сети. Каждый ее участник хранит эти данные в своей памяти или на жестком диске системы, находящейся под полным его контролем. В итоге ничто не останавливает этого участника от чтения информации в собственной системе, если и когда он захочет это сделать.
Попытки скрыть данные в умном контракте сопоставимы по уровню безопасности с попыткой спрятать их в HTML-коде веб-страницы. Конечно, обычные веб-пользователи такую информацию не увидят, поскольку она не будет отображаться в окне браузера. Но для ее раскрытия требуется всего лишь нажать на кнопку отобразить «исходный код», которая есть во всех современных браузерах и данные сразу же становятся как на ладони.
Аналогично и в случае со спрятанными в умном контракте данными, требуется всего лишь внести изменения в ПО для работы с блокчейном, чтобы оно отображало полное состояние контракта и вся видимость секретности сразу же сойдет на нет.
Любой программист средней руки справится с этой задачей не более чем за час.
Каково предназначение умных контрактов?
После всего написанного выше возникает резонный вопрос: где вообще умные контракты могут найти применение? Но для того чтобы ответить на этот вопрос нам необходимо мысленно вернуться к базовым понятиям блокчейнов. Если коротко, то блокчейн позволяет группе не доверяющих друг другу лиц совместно, напрямую и безопасно работать с базой данных без необходимости обращаться за помощью к некоему главному администратору.
Блокчейны позволяют отказаться от посредничества в работе с данными, что может привести к существенному упрощению и снижению затрат.
Чтобы внести изменение в любую базу данных, необходимо выполнить так называемую транзакцию, содержащую набор изменений в базе, которые либо будут успешно применены, либо будут отклонены все вместе. Возьмем, к примеру, ситуацию с финансовым реестром, когда Алиса совершает платеж в пользу Боба. Платеж представляется в виде транзакции, которая: a) проверяет, достаточно ли у Алисы средств на счету, б) вычитывает указанное количество средств со счета Алисы и c) добавляет это же количество на счет Боба.
В обычной централизованной базе данных эти транзакции создаются неким единым доверенным управляющим. В противовес этому, в общедоступной БД блокчейн-типа транзакции могут быть созданы любым пользователем блокчейна. И поскольку между этими пользователями нет абсолютного доверия, в БД должны быть правила, накладывающие ограничение на выполнение транзакций.
Например, в финансовом реестре, все узлы которого находятся в равном положении, параметры каждой транзакций не должны приводить к нарушению общего баланса средств. В противном случае участники смогут беспрепятственно выделять себе столько денег, сколько захотят.
Способов соблюдения этих правил можно придумать великое множество, но в настоящее время преобладают две парадигмы, получившие распространение под влиянием Биткоина и Ethereum. Метод Биткоина, который по-другому можно назвать «ограничением транзакций» оценивает каждую транзакцию с точки зрения: a) записей в БД, удаленных с помощью этой транзакции и б) созданных записей.
В финансовом реестре используется правило: общее количество средств в удаленных записях не должно конфликтовать с общей суммой в созданных. (изменение в записи рассматривается как удаления этой записи и ее пересоздание с нужными значениями).
Вторая парадигма, берущее свое начало в Ethereum — это умные контракты. Согласно ей все изменения в данных контракта должны выполняться его кодом. (В контексте традиционных баз данных, можно считать, что речь идет об обязательной к выполнению хранимой процедуре) Для изменения данных контракта, пользователи блокчейн отправляют запросы его коду, определяющему, следует ли выполнять запрос и каким образом это следует сделать.
В свете приведенного выше примера, умный контракт для финансового реестра выполняет те же самые задачи, что и администратор централизованной базы данных: проверка наличия достаточного количества средств, вычитание их с одного счета и прибавление к другому.
Обе парадигмы работают эффективно, и у каждой из них есть свои преимущества и недостатки. Если вкратце, то ограничение транзакций биткоин-типа позволяет добиться лучших показателей одновременной доступности и производительности, в то время как умные контракты эфириумного типа позволяют добиться большей гибкости.
Поэтому, возвращаясь к вопросу о том, для чего предназначены умные контракты: они необходимы, когда реализовать блокчейн-кейс с помощью ограничения транзакций не удается.
Но даже определившись с этим критерием для использования умных контрактов, я по-прежнему затрудняюсь назвать хотя бы один сценарий их применения для закрытых блокчейнов, где традиционный биткоиновый подход действительно был бы неприменим.
Все действительно интересные блокчейн проекты, которые я знаю, могут быть реализованы с помощью биткоинового подхода, в рамках которого можно реализовать как разделение прав доступа и хранение данных, так и создание активов, их перемещение, депонирование, обмен и уничтожение. Как бы то ни было, новые пользовательские кейсы регулярно появляются и я не удивлюсь, если некоторым из них действительно потребуется мощь умных контрактов. Или, по крайней мере, расширение парадигмы Биткоин.
Так или иначе, ключевое правило в любой ситуации — помнить, что умные контракты — это всего лишь один из методов ограничения выполнения транзакций в базе данных.
Они, без сомнения, представляют собой очень полезную вещь и играют важную роль в обеспечении безопасности совместного доступа к базе данных. Тем не менее умные контракты не способны на что-либо другое. И уж точно они не могут выйти за рамки базы данных, в которой существуют.
