Производные смарт-контракты

[Оригинал: https://eprint.iacr.org/2020/138.pdf]

Аннотация

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

Наш механизм работает, даже если базовый смарт-контракт не предназначен для работы с производным смарт-контрактом. Как и в традиционных финансах, производные инструменты получают свою стоимость (и, в более общем смысле, — состояние) через потенциально сложные зависимости. Мы показываем, как производные смарт-контракты могут быть развернуты на практике на блокчейне Ethereum без каких-либо форков или дополнительных предположений (к принятию). Мы используем механизм NIPoPoWs (например, FlyClient) для получения кратких доказательств для произвольных событий, что делает их доказательство недорогим для пользователей. Последняя конструкция представляет особый интерес, поскольку она формирует первый интроспективный SPV-клиент: SPV-клиент для Ethereum в Ethereum. Наконец, описываем применения производных смарт-контрактов, которые были невозможны до нашей работы, в частности, возможность создания децентрализованных страховых смарт-контрактов, которые страхуют базовую ценную бумагу внутри блокчейна, такую как ICO, а также фьючерсы и опционы.

Введение

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

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

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

• Первый основан на специальной функции Solidity и является самым дешёвым в реализации и использовании.
• Второй основан на конструкции BTC-Relay и требует, чтобы полезные пользователи подстраивали каждый блок под этот контракт оракула.
• Наконец, третий… использует возможности не-интерактивных доказательств работы (NIPoPoWs) для повышения эффективности.
• Смарт-контракт oracle может представлять самостоятельный интерес, поскольку функционирует как клиент Ethereum SPV, работающий внутри самого Ethereum, и является первым в своем роде интроспективным клиентом SPV.

Предыдущая работа

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

Наш вклад сводится к следующему:

1. Ставим вопрос о проблеме производных смарт-контрактов и предлагаем конструкцию, решающую её без дополнительных предположений (в сети Эфириума);
2. Предлагаем три варианта нашего оракула: первый опирается на особенности Solidity, второй вдохновлён конструкцией BTC-Relay, а третий использует NIPoPoWs;
3. Представляем первый интроспективный клиент SPV-клиент для системы блокчейн, работающий внутри этой же системы блокчейн.
4. Обсуждаем, что схема может быть использована для инстанцирования некоторых стандартных финансовых деривативов: страхования, фьючерсов и опционов.

Интроспективная SPV

Условные обозначения. [Menaskop: весь матаппарат — см. в оригинале]. 

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

1. Получить значение частной переменной состояния базового контракта в любой момент в прошлом;
2. “Вспомнить”, было ли определённое событие запущено базовым контрактом в любой момент времени, и получить значения параметров события;
3. Отчёт о любых прошлых вызовах методов базового контракта, выполненных другими контрактами или обычными счетами, включая значения параметров и деньги, уплаченные во время вызова.

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

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

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

Поиск приватной переменной

Предположим, что в унаследованном смарт-контракте есть интересующая нас переменная, которая, как оказалось, является приватной. Это означает, что с помощью обычных методов Solidity доступ к этой переменной невозможен. Мы покажем, как это можно обойти с помощью ненадёжной третьей стороны, которая предоставляет некоторые доказательства. При условии, что известен фактический хэш блока… достаточно проверить два доказательства, чтобы убедиться в том, что… (известно) … постоянное место хранения переменной (px).

Обнаружение транзакций. Напомним, что Ethereum хранит корень … всех транзакций в своём заголовке… Такие доказательства уже используются на практике для предотвращения опережающего обхода.

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

Опкод BLOCKHASH. Ethereum предлагает опкод BLOCKHASH, который позволяет смарт-контракту получить хэши предыдущих блоков. Эта функция позволяет убедиться, что предоставленный блок находится в лучшей цепочке: контракт извлекает b.height, вызывает BLOCKHASH для этого номера высоты и сравнивает H(b) с результатом вызова BLOCKHASH. Если они совпадают, то блок действителен. К сожалению, эта функциональность ограничена последними 256 блоками. Существует предложение по устранению этого искусственного ограничения, которое, как ожидается, будет реализовано в будущем хард форке Ethereum. Для Ethereum это идеальное решение проблемы верификации блоков, приводящее к минимально возможным затратам на доказательство событий.

SPV в стиле BTCRelay. BTCRelay получил известность в 2016 году как способ предоставления клиентских возможностей Bitcoin SPV любому смарт-контракту Ethereum. Каждый блок передается в контракт полезными, но недоверенными участниками, формируется и подтверждается цепочка заголовков. Сопоставление ведётся таким образом, чтобы можно было определить, находится ли какой-либо блок в текущей лучшей цепочке заголовков. BTCRelay также предлагает стимулы для отправителей блоков, где отправители получают вознаграждение всякий раз, когда размещенные ими блоки используются для доказательства какого-либо события. Эта схема может использоваться для проверки блоков в цепочке Ethereum на Ethereum — «ETCRelay». 

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

Реализация

Мы суммируем все эти функциональные возможности в полном контракте Introspective SPV, показанном в Алгоритме (ниже). Насколько нам известно, это первый контракт, который является клиентом SPV для своей цепочки.

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

Конкретные примеры

Теперь перейдём к рассмотрению некоторых конкретных приложений, которые могут быть реализованы с помощью контрактов, построенных на функциональности Introspective SPV. 

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

Контракт работает следующим образом:

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

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

Одним из таких примеров является страхование базового смарт-контракта ICO от определённого условия убытка. Условие описывает то, что страхователь считает неудачным результатом ICO. Например, страхователь может указать, что для успеха ICO необходимо наличие не менее 5 инвесторов-китов, определяемых как инвесторы, каждый из которых внес более 1 000 000 долларов США в рамках одной транзакции в течение периода сбора средств ICO [Menaskop: более интересное решение предлинное DAO ENVELOP].

Страховые требования в данном примере осуществляются следующим образом. Если страхователь определяет, что произошло событие убытков (т.е. было менее 5 инвесторов-китов), то в конце периода сбора средств ICO он подаёт претензию. Эта претензия не содержит никаких доказательств.

После открытия претензии начинается период оспаривания, в течение которого страховщик может подать встречный иск, доказывающий, что претензия была мошеннической. Данный встречный иск включает в себя доказательство, состоящее из 5 транзакций, совершённых со смарт-контрактом ICO, каждая из которых относится к разным наследодателям и оценивается более чем в $1 000 000. Это доказательство встречного иска может быть проверено на действительность с помощью средств, описанных ранее.

Если в течение периода оспаривания встречных претензий нет, то истцу выплачивается компенсация.

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

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

Опционы. Традиционно опцион — контракт между держателем и продавцом. Он позволяет держателю либо купить (опцион колл), либо продать (опцион пут) базовый актив продавцу по определенной цене исполнения и до определенной даты истечения.

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

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

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

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

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

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

Фьючерсы. Подобно опциону, фьючерс — контракт между двумя сторонами. Определяющим отличием от опциона является то, что держатель обязан совершить определенное действие (купить или продать) базовый актив по цене исполнения и в указанную дату истечения срока. Для упрощения дату истечения можно описать как высоту блока внутри смарт-контракта. Легко понять, как эта система может быть реализована с помощью клиринговой палаты, аналогично опциону. Проще говоря, в случае мошенничества страхователь может заявить, что «между началом действия договора и истечением срока действия не было зарегистрировано ни одного события Solidity, указывающего на то, что автор купил или продал у меня оговоренную сумму по оговоренной цене».

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

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

[Оригинал: https://eprint.iacr.org/2020/138.pdf]