Это, пожалуй, самая интересная статья о перспективах применения смарт-контрактов в деловой практике, которая мне попадалась (правда, попадалось их не так уж много). Она написана юристами и опубликована в конце мая на сайте Гарварда. Хоть и на примере США, текст раскрывает такие вопросы как применение законодательства к сделкам на смарт-контрактах, проблему понимания сторонами кода, проблему оракулов, риски и другие.

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

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

1. Введение в смарт-контракты

1.1. Как работают смарт-контракты

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

Необходимо, чтобы входные параметры и этапы выполнения смарт-контракта были конкретными и объективными. Иными словами, «если произойдёт Х — тогда сделать Y». Следовательно, смарт-контракты выполняют простейшие задачи, например автоматически переводят криптовалюту с кошелька одной стороны на кошелёк другой, если соблюдены нужные условия. По мере распространения блокчейна и увеличения средств, вкладываемых в токены или отправляемых в рамках блокчейна (on-chain), смарт-контракты будут усложняться и получать возможность обрабатывать сложные транзакции. Многие разработчики уже создают более сложные смарт-контракты, объединяя в них несколько этапов транзакций. Тем не менее нам придётся ждать ещё много лет, пока код сможет определять субъективные юридические критерии, такие как «соответствуют ли действия стороны критериям коммерчески оправданных усилий (commercially reasonable efforts)» или «стоит ли выполнить пункт о возмещении и выплатить компенсацию».

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

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

• оплата, инициируемая определёнными событиями,
• наложение финансовых санкций при невыполнении объективных условий.

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

Например, смарт-контракты могут избавить вас от так называемых кассовых разрывов (procure-to-pay gap). Как только товар прибыл на склад и зарегистрирован, смарт-контракт способен мгновенно отправить запросы на подтверждения. Получив их, он сразу же переведёт средства от покупателя продавцу. При этом продавцы получат оплату быстрее, им не придётся напоминать клиентам о необходимости заплатить, а покупатели сэкономят на банковских операциях. Всё это может снизить требования к оборотному капиталу и упростить финансовые операции для обеих сторон. Что касается обязательности исполнения, то смарт-контракт можно запрограммировать таким образом, чтобы он закрывал доступ к подключённым через интернет активам (например, к контенту), пока не получена оплата.

1.2. Историческая справка

Термин «смарт-контракт» придумал около 20 лет назад специалист по информатике криптограф Ник Сабо (Nick Szabo), который тогда был аспирантом Вашингтонского университета:

Благодаря цифровой революции стали возможны новые государственные институты и новые способы формализации взаимоотношений, формирующие эти институты. Я называю эти контракты «умными», потому что они гораздо функциональнее своих безжизненных бумажных предшественников. В них не используется искусственный интеллект. Смарт-контракт — это набор обещаний, определённых в цифровом виде, включая протоколы выполнения сторонами этих обещаний [3].

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

Ещё один исток современных смарт-контрактов — Ricardian Contract. Эта идея появилась в 1996-м в работе Иэна Григга (Ian Grigg) и Гэри Хоуланда (Gary Howland), посвящённой платёжной системе Ricardo. Григг представлял рикардианский контракт как мостик между текстовыми контрактами и кодом со следующими параметрами:

1) одиночный документ — контракт, который эмитент предлагает держателям;
2) на имущественное право держателей, управляемое эмитентом;
3) легко распознаётся людьми (как и обычный бумажный контракт);
4) считывается программами (парсится как база данных);
5) подписывается цифровым образом;
6) содержит ключи и информацию о сервере;
7) сочетается с уникальным и защищённым идентификатором [4].

2. Взаимосвязь с традиционными текстовыми соглашениями

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

Первая — смарт-контракты, создаваемые и развёртываемые без обязательных к исполнению текстовых контрактов. Например, две стороны устно договариваются, какие деловые отношения хотят установить, и сразу переводят договорённость в исполняемый код. Назовём это «исключительно программные смарт-контракты» (code-only smart contracts).

Вторая — смарт-контракты, применяемые как средство для реализации конкретных положений традиционного текстового контракта, текст которого ссылается на использование смарт-контракта для реализации этих положений. Назовём это «вспомогательные смарт-контракты» (ancillary smart contracts).

3. Смарт-контракты обязательны к исполнению?

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

Дискуссия об обязательности исполнения смарт-контрактов должна начинаться с фундаментального разделения понятий «соглашение» и «контракт». Штаты в целом сходятся в том, что две стороны могут заключать соглашения, однако понятие «контракт» означает, что соглашение юридически обязательно и подлежит исполнению в судебном порядке [5]. Чтобы определить обязательность исполнения, суды штатов традиционно оценивают, удовлетворены ли требования предложения, принятия и рассмотрения (requirements of offer, acceptance and consideration). Эти базовые требования, несомненно, можно соблюсти с помощью вспомогательных смарт-контрактов. Например, страховая компания создаёт продукт в сфере страхования полётов, который автоматически выплачивает застрахованному лицу страховку, если рейс задержан более чем на два часа [6]. Ключевые условия вроде процедуры вычисления задержки заранее прописываются в текстовом контракте, в то же время вспомогательный смарт-контракт обрабатывает предмет соглашения (это выплата страховки) и его исполнение (автоматическая выплата в результате проверяемой задержки). Таким образом, страховщик предлагает застраховать полёты, а страхуемое лицо принимает предложение, уплачивая страховой взнос.

Сегодня определённые контракты должны быть представлены в письменной форме. Также могут потребоваться дополнительные формальности, например в рамках Единообразного торгового кодекса (Uniform Commercial Code, UCC) [7] или принятых в штатах законов о борьбе с мошенничеством. Однако соглашения не всегда должны быть письменными, чтобы их исполнение стало обязательным [8]. Следовательно, многие исключительно программные смарт-контракты будут применяться в соответствии с законами, регулирующими контрактные отношения. В этом смысле поучителен пример Сабо с вендинговым автоматом: хотя у покупателя есть много подразумеваемых прав, контракт составлен без значимых прописанных условий, за исключением отображения цены каждого товара. Таким образом, тот факт, что соглашение отражено только в коде, как в случае с code-only смарт-контрактами, не особо препятствует формированию контракта вне рамок, обозначенных UCC или законами по борьбе с мошенничеством. Целый ряд законов и правовых конструкций уже давно учитывают роль информационных технологий при составлении контрактов.

К примеру, Единый закон об электронных транзакциях (Uniform Electronic Transactions Act, UETA), принятый в 1999-м и взятый за основу в 47 штатах, гласит следующее. Электронные записи, в том числе созданные компьютерными программами, а также цифровые подписи с использованием шифрования на основе открытых ключей имеют ту же юридическую силу, что и текстовые записи (с определёнными ограничениями) [9]. В UETA даже признаётся законность электронных агентов, которые определены как «компьютерные программы, электронные или иные автоматизированные средства, независимо используемые для инициирования действия или ответа на электронные записи либо на всю деятельность или её часть без контроля или участия человека» [10]. Как гласит UETA, электронный агент «способен в рамках параметров своей программы инициировать действия, отвечать на записи или взаимодействовать с другими сторонами или их электронными агентами, после того как он был активирован одной из сторон, без дополнительного внимания этой стороны» [11]. Возможно, это предварительное признание смарт-контрактов.

Аналогично федеральный Закон о регистрации электронных подписей (Electronic Signatures Recording Act, E-Sign Act) не только признаёт законность электронных подписей и электронных записей в коммерческих отношениях между штатами, но и гласит, что контракт (или иная запись, относящаяся к транзакции) «не может быть лишён юридической силы, законности или обязательного исполнения лишь потому, что его оформление, создание или доставка подразумевает действие одного или нескольких электронных агентов, если действие любого такого электронного агента юридически относится к лицу, связанному обязательствами» [12]. Термин «электронный агент» означает компьютерную программу, электронное или иное автоматизированное средство, независимо используемое для инициирования действия или ответа на электронные записи либо на всю деятельность или её часть без контроля или участия человека [13].

Понимать правовые рамки важно, чтобы укрепить обязательность исполнения смарт-контрактов, однако их использование в будущем может не опираться на законы, созданные до эпохи развития технологии блокчейна. Аризона и Невада уже изменили местные версии UETA, чтобы явным образом задействовать блокчейн и смарт-контракты [14]. Отметим: два штата приняли серьёзно различающиеся определения критически важных понятий. Поэтому можно предположить, что чем больше штатов последуют их примеру и изменят местные версии UETA, тем сильнее будет потребность принять единые определения, отражающие развитие блокчейна и смарт-контрактов.

4. Трудности на пути широкого применения смарт-контрактов

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

4.1. Как далёкие от технологий стороны могут обсуждать, составлять и корректировать смарт-контракты?

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

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

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

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

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

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

Наконец, по мере того как законность или действие смарт-контрактов всё чаще будет признаваться юридически, судам может потребоваться система назначаемых экспертов, которые станут помогать разбираться в компьютерном коде. Сегодня стороны прибегают к помощи своих экспертов, когда в центре дискуссии оказываются технические проблемы. Хотя у федеральных судов и судов штатов есть право назначать собственных экспертов, они редко им пользуются [16]. Данный подход может потребовать изменений, если увеличится количество стандартных разбирательств вокруг интерпретации кода смарт-контрактов.

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

Часто предполагается, что смарт-контракт получит информацию или параметры от ресурсов, расположенных не в блокчейне, — от так называемых off-chain-ресурсов. Например, смарт-контракт страхования посевов запрограммирован так, что страховка будет выплачена, если температура воздуха упадёт ниже 0 градусов по Цельсию. Информацию о температуре смарт-контракт получит из внешнего источника. Здесь возникает две проблемы.

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

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

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

4.3. Что такое «финальное» соглашение сторон?

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

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

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

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

4.4. Автоматизация смарт-контрактов

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

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

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

4.5. Изменение и разрыв смарт-контрактов

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

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

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

4.6. Объективность и пределы внедрения в смарт-контракты желаемой неоднозначности

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

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

4.7. Гарантируют ли смарт-контракты оплату?

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

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

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

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

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

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

5. Лучшие практики

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

• Сейчас сторонам, заключающим любые контрактные договорённости, лучше всего придерживаться гибридного подхода — комбинации текста и кода. Есть сильные аргументы в пользу того, что исключительно программные смарт-контракты должны быть обязательны к исполнению, как минимум в рамках местных законодательств в США. Однако пока не появится большей ясности об их законности и обязательности, исключительно программные смарт-контракты следует использовать только для простых взаимоотношений. Сторонам понадобятся текстовые версии соглашений, чтобы прочитать обсуждённые условия и вписать условия, которые смарт-контракт не учитывает; потребуется, чтобы под рукой был документ, который примут в суде.
• В гибридном контракте текст должен ясно определять код смарт-контракта, с которым он ассоциирован, а стороны должны видеть все переменные, передаваемые в смарт-контракт, их определения и транзакционные события, инициирующие исполнение кода.
• Полагаясь в получении сторонних данных на оракулы, стороны должны решить, что будет, если оракул не сможет передавать данные, предоставит ошибочную информацию или просто прекратит работать.
• Стороны должны понимать распределение рисков при ошибках в коде.
• Текстовое соглашение, сопровождающее код, должно определять регулирующее законодательство и территориальную подсудность, а также приоритетность кода и текста в случае конфликтов их содержимого.
• Текстовое соглашение должно включать в себя сообщения обеих сторон о том, что они проанализировали код смарт-контракта и что код отражает условия, описанные в текстовом соглашении. Хотя такое подтверждение не заставит стороны действительно проанализировать код, оно поможет другой стороне защититься от обвинений в том, что код вообще не анализировался. Стороны также могут застраховаться от риска ошибок в коде. Как отмечалось ранее, стороны могут привлечь сторонних экспертов для анализа кода.

6. Будущее смарт-контрактов

Сегодня смарт-контракты представляют собой прототипный пример Amara’s Law — концепции, которую сформулировал Рой Амара, специалист по информатике из Стэнфордского университета. Эта концепция гласит, что мы склонны переоценивать новые технологии в краткосрочной перспективе и недооценивать в долгосрочной. Хотя смарт-контрактам ещё нужно развиваться, прежде чем они станут широко использоваться в сложных коммерческих взаимоотношениях, всё же они влияют на революцию в структуре вознаграждения и стимулирования, которая определит форму контрактов в будущем. При рассмотрении смарт-контрактов важно не просто думать о том, как перенести в эту новую технологию существующие концепции и структуры. Скорее подлинная революция смарт-контрактов будет спровоцирована совершенно новыми парадигмами, которые мы ещё не спрогнозировали.

Сноски

1. См. What is the «Gas» in Ethereum? Cryptocompare, 18 ноября 2016.
2. Там же.
3. Nick Szabo. Smart Contracts: Building Blocks for Digital Market. 1996.
4. Ian Grigg. The Ricardian Contract.
5. См., напр., «Переформулирование (второе) контрактов», часть 1, Американский институт права, 1981. В США за договорное право обычно отвечают законодательные органы штатов. Хотя в этой статье мы рассматриваем основные принципы договорного права, характерные для большинства штатов, нужно отметить, что различия в законодательствах могут влиять на обязательность исполнения смарт-контрактов в определённых штатах.
6. Как минимум одна компания, AXA, сейчас уже предлагает такой продукт.
7. Cм. UCC § 2-201.
8. Например, см. дело Lumhoo v. Home Depot USA, Inc. 229 F. Supp. 2d 121, 160 (E.D.N.Y. 2002). Считается, что истцы привели достаточные доказательства для подтверждения, что стороны заключили устный договор, который гласил: работодатель оплачивает как сверхурочную любую работу, превышающую восемь часов в день.
9. Cм. Uniform Electronic Transactions Act (Unif. Law Comm’n 1999). В Нью-Йорке, Иллинойсе и Вашингтоне действуют свои законы, регулирующие валидность электронных транзакций.
10. Там же. § 2(6).
11. Там же. § 2 cmt. 5.
12. 15 U.S.C. § 7001(h).
13. 15 U.S.C. § 7006(3).
14. Cм. 2017 Ariz. HB 2417 44-7061 and Nev. Rev. Stat. Ann. § 719.090.
15. Cм. дело Nicosia v. Amazon.com, Inc. 834 F.3d 220 (2d Cir. 2016) (отмена решения окружного суда об отказе в удовлетворении иска и логичное сомнение в том, что Amazon предоставила потребителю разумное уведомление об обязательном арбитражном разбирательстве).
16. Cм. Charles Alan Wright & Arthur R. Miller. Federal Practice and Procedure, Section 6304 (3d ed. Supp. 2011) («Фактически правило 706 применяется редко. Это как минимум отчасти связано с тем, что назначение свидетеля-эксперта увеличивает нагрузку на судью, увеличивает расходы сторон и препятствует состязательному контролю над представлением доказательств»), а также Stephanie Domitrovich, Mara L. Merino & James T. Richardson. State Trial Judge Use of Court Appointed Experts: Survey Results and Comparisons, 50 Jurimetrics J. 371, 373—374. 2010.
17. См. Haseeb Qureshi. A Hacker Stole $31M of Ether—How it Happened, and What it Means for Ethereum. FreeCodeCamp. 20 июля 2017.