Тед Млайнер (Ted Mlynar) и Ира Шефер (Ira Schaefer) являются партнерами в компании Hogan Lovells в Нью-Йорке, практикующей в сфере интеллектуальной собственности. Они консультируют по вопросам патентования и другим проблемам интеллектуальной собственности, которые касаются блокчейна и криптовалют.

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

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

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

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

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

Блокчейн Биткоина существует с 2009 года, но несмотря на различные попытки, мало подходит для удобной реализации умных контрактов (пока единственное исключение - стартап Rootstock). В отличие от него, блокчейн Эфириума, анонсированный в 2014 и запущенный в 2015 году, специально предназначен для реализации смарт-контрактов.

Существующие проблемы

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

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

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

Но злоупотребление ресурсами - не единственный тип возможного неправильного употребления. В последнем докладе было отмечено, что среди 19 000 изученных смарт-контрактов, 44% содержат уязвимости. Поскольку код контракта был скопирован множество раз, некорректная формулировка его составления была повторена, вследствие чего ошибка переходила из контракта в контракт. Старый некорректный код, по-видимому, стал неустойчивой основой для новых контрактов.

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

Как исправить неизменяемую систему?

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

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

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

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

Для этого нового вида контракта следует внедрить новый вид правовой ответственности. Смарт-контракты смешивают закон и программный код. Правовая ответственность по смарт-контрактам должна сделать то же самое.

Due diligence в эпоху блокчейна

Какая степень проверки добросовестности (Due diligence) необходима для смарт-контракта? Традиционный анализ предложенной транзакции и договорных условий контракта должен идентифицировать практические и юридические вопросы. Анализ исходного кода должен идентифицировать недостатки в программировании смарт-контракта, прежде, чем он будет выпущен.

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

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

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

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

Более строгая проверка добросовестности смарт-контрактов сможет, наконец, принести некоторое душевное спокойствие.