Logo
Поделиться этой статьей

Почему смарт-контрактам потребуются «умные условия» для соответствия

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

Checklist

Тед Млынар и Айра Шефер — партнеры в практике интеллектуальной собственности в Hogan Lovells в Нью-Йорке. Они консультируют по вопросам патентов и других вопросов интеллектуальной собственности, связанных с технологиями блокчейна и Криптовалюта .

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

Продолжение Читайте Ниже
Не пропустите другую историю.Подпишитесь на рассылку Crypto Long & Short сегодня. Просмотреть все рассылки

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

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

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

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

Короче говоря, практические и юридические препятствия на пути внедрения протокола о намерениях можно преодолеть.

Не такой уж гипотетический пример

В качестве примера полезности «умного» перечня условий давайте рассмотрим гипотетический Политика страхования от землетрясений в Нью-Йорке (NYC).

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

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

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

Традиционный упрощенный перечень условий страхования от землетрясений в Нью-Йорке может выглядеть следующим образом:

  • Стороны: Earthquake Insurance Co («Страховщик») и Unshakable Corp («Застрахованный»).
  • Зона покрытия: Нью-Йорк
  • Покрытие: Застрахованное лицо получает 50 млн долларов США, если землетрясение произойдет в пределах зоны покрытия.
  • Премия: 500 тыс. долл. США за 12 месяцев покрытия
  • Возможность продления: Политика можно продлить на 12 месяцев при условии уплаты страховой премии в течение трех дней с даты истечения срока действия.
  • Минимальная платежеспособность: Страховщик будет поддерживать ликвидные активы на уровне не менее 30% от размера риска в зоне покрытия Страховщика.
  • Дополнительно: Обычные положения и условия

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

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

Перевод концепций в код

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

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

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

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

1. Стороны: Earthquake Insurance Co. («Страховщик») и Unshakable Corp. («Страхователь»).

2. Зона покрытия:Пять районов Нью-Йорка(Оракул 1)

3. Покрытие: застрахованное лицо получает 5 млн долларов США в Bitcoin (BTC), если Геологическая служба США публикует публичное заявление о том, что эпицентр землетрясения был обнаружен в пределах зоны покрытия.

3.1. Срабатывание при землетрясении магнитудой 5,0 или выше по данным Службы оповещения о землетрясениях Геологической службы США (USGS) (или данных ATOM Syndication) (Oracle 2)

3.2 Курс обмена валют определяется в реальном времени CoinDesk Индекс цены Bitcoinв момент уплаты Премии (Oracle 3)

3.3 Определите местоположение эпицентра землетрясения относительно зоны покрытия с помощью API геокодирования Google Карт (Oracle 4)

3.4 Выплата на кошелек Страхователя в[адрес кошелька]

4. Премия: 50 тыс. долларов США в Bitcoin (BTC) за 12 месяцев покрытия

4.1. Курс обмена валюты, определяемый текущим индексом цен Bitcoin CoinDesk на момент уплаты премии (Oracle 3)

4.2. Оплата на счет Страховщика в[адрес кошелька]

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

6. Минимальная платежеспособность: Страховщик будет поддерживать ликвидные активы в размере не менее 30% от максимального риска Страховщика в Охватываемой зоне в течение предыдущего 30-дневного периода.

6.1. Остаток ликвидных активов страховщика, доступный на [адрес кошелька]

6.2. Ежедневный риск страховщика в зоне покрытия доступен по адресу[адрес кошелька]

6.3. Страховщик возвращает премию, если остаток ликвидных активов падает ниже 30% от максимального дневного риска в течение предыдущих 30 дней.

7. Дополнительно: Обычные положения и условия

7.1. 168-часовое событие: землетрясения и толчки, происходящие в течение любого 168-часового (1 неделя) периода, должны считаться одним землетрясением.

7.2. Ограничение выплат: по одному Политика будет произведено максимум две (2) выплаты.

7.3. Передача: Страховщик не может передать этот договор, Страхователь может

7.4 Выбор права: применяется законодательство штата Нью-Йорк.

7.5 Арбитраж: Все споры, касающиеся предмета договора, будут переданы в обязательный арбитраж в Нью-Йорке.

Будьте умны, будьте готовы

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

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

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

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

Контрольный список

изображение через Shutterstock

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

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

Picture of CoinDesk author Ted Mlynar and Ira Schaefer