Проблемы применения смарт-контрактов в деятельности компании

Liberty Bell – первый игровой автомат, появился в 1880 году. См. URL: (дата обращения: 16 декабря 2018 года).

ции о движении некой расчетной единицы» [5].

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

Наиболее широкое распространение смарт-контракты получили в финансовой сфере (подробнее см. [6]) и банковских операциях (подробнее см. [7]), поскольку блокчейн позволяет совершать сделки с хорошей отслеживаемостью их истории, характеризуется прозрачностью и отсутствием посредников в совершении транзакции.

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

Смарт-контракты могут реализовываться в разных формах.

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

Прежде чем созданный смарт-контракт будет исполнен, требуется оплатить транзакционную комиссию за добавление контракта в блокчейн. Например, в блок-чейне Ethereum смарт-контракты исполняются в виртуальной машине Ethereum Virtual Machine (EVM), а комиссия в криптовалюте ether (эфир) называется газом (gas). Чем сложнее смарт-контракт, тем больше газа требуется заплатить. Таким образом, газ становится условием, предохраняющим виртуальную машину от выполнения слишком больших или сложных смарт-контрактов.

Сейчас смарт-контракты больше всего подходят для применения в ситуациях двух типов:

• 1)    оплата, инициируемая различными событиями;

• 2)    наложение финансовых санкций при наступлении определенных условий.

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

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

Трудности понимания кода лицами без специального образования

Смарт-контракт может содержать условия договора, а договор можно прописать в самом контракте и компьютерном коде. Однако здесь возникают сложности.

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

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

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

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

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

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

При использовании исключительно программных смарт-контрактов во взаимоотношениях между компаниями и потребителями могут возникнуть дополнительные проблемы. Суды неохотно требуют исполнять соглашения, если потребители не получили адекватного описания условий соглашений, и могут с сомнением отнестись к идее обязательного исполнения смарт-контрактов, если потребителям не предоставляется базовое текстовое соглашение, в которое включены все определения (см. [9]).

Смарт-контракты и их зависимость от off-chain ресурсов

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

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

Во-вторых, код реплицирован на множество узлов блокчейн-сети, и если данные идут постоянным потоком, то ноды (узлы) будут получать разную информацию. Например, на узел-1 пришли сведения, что температура – 0,5 градуса, а на узел-2 – что температура 0 градусов. Для валидации транзакции нужен консенсус между узлами, а несогласованность данных может привести к тому, что условие смарт-контракта будет считаться невыполненным.

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

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

Финальное соглашение сторон об условиях

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

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

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

Одно из решений – использовать текстовый контракт, когда параметры, запускающие исполнение смарт-контракта, не только прописаны в тексте, но и включены в него. В примере с посевами условие «ниже 0 градусов» можно прописать текстом и указать в виде параметра в смарт-контракте, тем самым исключив возможность несогласованности.

Изменение и расторжение смарт-контрактов

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

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

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

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

Распределение рисков при атаках и сбоях

Смарт-контракты создают дополнительные риски, отсутствующие в большинстве письменных соглашений, а именно:

• •    взлом контракта;

• •    непреднамеренные программные ошибки в коде или протоколе.

Если учесть относительную безопасность блокчейна, то эти концепции тесно взаимосвязаны. Большинство «взломов», ассоциируемых с блокчейном, – это эксплойты непреднамеренных ошибок в коде. Как и в случае со многими багами, эти ошибки не критичны, но после их использования становятся очевидными. Например, в 2017 году атакующий вывел из несколь- ких кошельков с мультиподписями эфир на 31 миллион долларов (см. [10]). Кошельки с мультиподписями безопаснее, поскольку для доступа к ним требуется более одного приватного ключа. Однако злоумышленник перехватил поток данных в коде компании Parity, переинициализировал смарт-контракт и сделал себя единственным владельцем кошельков с мультиподписями.

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

Информационная безопасность и компьютерная уязвимость кода

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

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

Регулирующее законодательство и территориальная подсудность

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