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

Смарт контракты являются одним из наиболее перспективных направлений развития криптовалют вообще, и Биткойна в частности. Под смарт контрактом понимается компьютерный протокол, который позволяет облегчить и автоматизировать финансовые контракты [1]. Термин «смарт контракт» был введен Ником Сабо (Nick Szabo) в 1990-е годы [2] и стал более актуальным, чем когда-бы то ни было в 2010-х, после того, как криптовалюты приобрели популярность.

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

Биткойн подвергают критике из-за недостатка выразительных возможностей для записи смарт контрактов. Проект Etherium [3], запущенный 30 июля 2015 года, был разработан в качестве замены протокола Биткойн и специально предназначен для пользователей смарт контрактов. Как следствие критики, возникают следующие вопросы:

• Какие возможности и перспективы дает протокол Биткойн в качестве среды для смарт контрактов?
• Каковы основные недостатки Биткойна по сравнению с альтернативами (например, Etherium)? Можно ли устранить или смягчить эти недостатки, оставаясь в рамках протокола?

1. Теория

1.1 Скрипты

Вся информация в протоколе Биткойн хранится в виде децентрализованной бухгалтерской книги — в блокчейне. Краеугольным камнем блокчейна является транзакция, которая содержит один или несколько вводов и выводов [4]. Каждый ввод транзакции является неизрасходованным выводом (UTXO) одной из предыдущих транзакций, записанных в блокчейне. Каждый вывод транзакции ассоциируется с ценностью — целым числом, обозначающим количество расходуемых монет, измеряемых в сатоши (10 в -8 степени BTC). Сумма всех значений вводов транзакций (т.е. значений из UTXO, связанных с этими вводами) равна сумме всех значений выводов транзакции, плюс комиссия за транзакцию, выплачиваемая майнеру для включения транзакции в блок. Таким образом, мы можем представить транзакцию в качестве перераспределения ценности путем «уничтожения» существующих UTXO и создания новых.

Каждый UTXO должен подразумевать персону (или несколько персон), имеющую право потратить стоимость, которая связана с данным UTXO. Чтобы выполнить это условие, протокол Биткойна включает в себя скрипты [5]. Скриптовый язык описывает исполнение определенной программы на стэк-машине [6], и таким образом напоминает язык программирования Forth [7]. Возможности скриптового языка строго ограничены по сравнению с общей идеей. Например, отсутствуют циклы, ввод/вывод и устойчивые состояния. Эти ограничения были введены для защиты сети Биткойн от DoS-атак и для того, чтобы получить приемлемое время прохождения транзакции и подтверждения блока.

Каждый вывод транзакции содержит скрипт, который блокирует деньги, ассоциированные с UTXO. Этот сценарий обычно называют scriptPubKey. Чтобы потратить эти деньги, пользователь сети Биткойн должен продемонстрировать доказательство принадлежности в форме разблокирующего скрипта scriptSig. Следовательно, скрипты являются частью каждого ввода и вывода транзакции.

Проверка пары (scriptPubKey, scriptSig) выполняется в несколько действий:

1. Выполнить скрипт разблокировки scriptSig. Запомнить состояние стэка после исполнения.
2. Не изменяя стэк, выполнить блокирующий скрипт scriptPubKey.
3. Если после выполнения обоих скриптов, стэк не пуст и верхнее значение не является ложью (т.е. стэк содержит одно или более значений 1-бит), значит проверка прошла успешно.

Пример: В случае наиболее распространенного типа транзакций pay-to-pubKeyHash (плата-на-хэш публичного ключа), разблокирующий скрипт scriptSig помещает в стэк два значения:

• цифровую сигнатуру транзакции с затратой средств;
• публичный ключ пользователя.

Блокирующий скрипт scriptPubKey выполняет следующие действия:

1. Проверить, что публичный ключ после хэширования эквивалентен адресу [8] UTXO. Этот адрес в двоичной форме является частью блокирующего скрипта.
2. Убедиться, что публичный ключ соответствует цифровой сигнатуре и транзакции.

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

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

1. RETURN инструкции
2. данные

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

1.2 Версии транзакций

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

Время блокировки транзакции является целым 4-х байтовым числом, которое определяет либо минимальную метку времени (timestamp), либо минимальный номер блока, когда транзакция считается закрытой. В «обыкновенных» транзакциях, которые просто перемещают стоимость, это поле выставлено в ноль. Для таких транзакций, значение времени блокировки транзакции и версии вводов игнорируются. Если время блокировки ненулевая величина, не превышающая 500 миллионов, то она рассматривается как номер блока. В противном случае, она рассматривается как метка времени, принятая в UNIX.

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

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

1.3 Сигнатуры

Bitcoin протокол включает несколько видов подписей пользователей. Основная функциональность подписи:

Задача: Доказать, что пользователь, владеющий секретным ключом, соответствующим заданному публичному ключу pubKey авторизовал трпнзакцию tx, чтобы потратить средства.

Для решения этой задачи, протокол Биткойн использует цифровые подписи на основе эллиптических кривых [9]. Каждая подпись вычисляется на основе хэша транзакции tx. Это делает невозможным для третьей стороны изменение транзакции после того как она вошла в сеть Биткойн, пока проверяется сигнатура, например в атаке MitM [10].

Части транзакции, используемые для генерирования хэшей, используемых в цифровых сигнатурах, зависят от типа сигнатуры. Тип сигнатуры определяется дополнительным байтом в конце сигнатуры [11]. Всего есть три типа сигнатур:

• SIGHASH_ALL (по умолчанию). Все содержимое транзакции используется для получения хэша, за исключением разблокирующих скриптов (если скрипты прилагались, сигнатура, включенная в один из вводов, делала бы неверными сигнатуры во всех остальных разблокирующих скриптах), но включая все версии вводов ссылки на UTXO, и спецификации всех вводов. Этот тип сигнатуры может быть выражен, как «Пользователь согласен вложить свои деньги, покуда остальные вкладывают свои деньги описанным способом, и деньги тратятся как договорено».
• SIGHASH_NONE. Хэш tx основывается на всех вводах транзакции и игнорирует версии вводов и выводы. Этот тип сигнатуры может быть выражен, как «Пользователь согласен вложить свои деньги, покуда остальные вкладывают свои деньги описанным способом. Пользователя не волнует как будут потрачены деньги».
• SIGHASH_SINGLE. Хэш tx использует единичный вывод, индекс которого такой же, как индекс текущего ввода. Этот тип сигнатуры может быть выражен, как «Пользователь согласен вложить свои деньги, покуда остальные вкладывают свои деньги описанным способом. Пользователь заботится только о своей части денег».

Дополнительно, модификатор ANYONECANPAY может использоваться с любым из этих трех методов. Модификатор означает, что хэш tx игнорирует все вводы, кроме текущего. Это может быть выражено, как «Пользователь не заботится откуда пришли деньги. Его или ее беспокоят только все / никакие / один из выводов» (в зависимости от базового типа сигнатуры).

Пример: ANYONECANPAY совмещенный с SIGHASH_ALL может быть использован для реализации благотворительности или краудфандинга. Пользователь, который захочет поучаствовать, создает UTXO c тем количеством монет, которое он хочет пожертвовать (например, 1 BTC). Затем, он создает транзакцию с сигнатурой SIGHASH_ALL +  ANYONECANPAY, с выводом установленным на адрес краудфандингового / благотворительного сервиса и оплатой, равной цели компании (например, 1000 BTC). Поскольку вывод транзакции больше чем ее ввод, она не может быть распространена в сеть Биткойн. Пользователь посылает ее напрямую на адрес краудфандингового / благотворительного сервиса. Этот сервис собирает все транзакции от пожертвователей в одну транзакцию с с большим количеством вводов (с суммой эквивалентной 1,000 BTC) и единственным выводом. Ввиду наличия флага ANYONECANPAY, все сигнатуры в разблокирующем скрипте остаются действительными в агрегированной транзакции. Следовательно, транзакция действительна, может быть распространена в сети и включена в блокчейн.

2. Приложения

В этой секции в деталях описываются возможные приложения на основе смарт контрактов, построенных на основе блокчейна Биткойна. Многие из этих примеров приложений были взяты со страницы Биткойн-wiki, под авторством Майка Хирна [12].

Один важный тип смарт контрактов, включенный в протокол Биткойн, это M-из-N транзакций с мультиподписью. Они разработаны как отдельная инструкция скриптового языка, CHECKMULTISIG. Этим транзакциям требуется некоторое количество (M) цифровых подписей в разблокирующем скрипте Каждая из сигнатур должна относиться к одному из публичных ключей N, N ⩾ M, включенных в блокирующий скрипт. Есть множество способов, как такой тип сигнатуры может использоваться в смарт контрактах. Некоторые из них мы обсудим ниже.

2.1 Эскроу

Задача: Алиса хочет купить кое-что у Боба за биткойны, хотя она не доверяет ему в достаточной степени, чтобы просто отправить деньги, используя транзакцию pay-to-pubKeyHash до того, как она получит товар. Так же и Боб, не доверяет Алисе настолько, чтобы отправить товары без гарантии платежа.

Решение:

1. Алиса и Боб договариваются об использовании посреднического сервиса (который, например, может быть ассоциирован с онлайн-рынком, который они используют для торговли).
2. Алиса создает и отправляет в сеть транзакцию Tx1, с блокирующим скриптом c мультисигнатурой «2 из 3», с публичными ключами, принадлежащими ей, Бобу и посредническому сервису.
3. После того как Боб видит транзакцию Алисы в блокчейне, он может быть уверен, что она не сможет потратить эти деньги дважды (так как это потребовало бы от нее сговориться с посредническим сервисом). Следовательно, он может безопасно отправлять товар Алисе.

Заблокированные деньги могут быть потрачены путем подписания транзакции Tx2, которая тратит Tx1, с двумя сигнатурами:

• Алисы и Боба (успешная сделка, либо Боб соглашается возместить Алисе)
• Алисы и посредника (товар не приехал, возврат денег)
• Боба и посредника (Боб забирает деньги несмотря на то, что это сделку оспаривает Алиса)

2.3 Депозит

Задача: Алиса хочет доказать свою благонадежность оператору определенного вебсайта (например, форума или wiki) Бобу. Сайт предлагает решение в форме временного депозита. Алиса хочет быть уверена, что сайт не украдет ее деньги.

Решение:

1. Алиса берет публичный ключ вебсайта (из соображений безопасности, Боб может создавать новую пару ключей для каждого нового контракта) и создает транзакцию Tx1, заблокированную блокирующим скриптом с мультисигнатурой «2 из 2», который требует сигнатуры ее и вебсайта для разблокировки. Сумма заблокированная в транзакции является достаточной, с точки зрения Боба (например, 0,1 BTC).
2. Алиса отправляет Tx1 Бобу. Для обеспечения максимальной безопасности, Алиса может отправить только хэш транзакции, если есть риск, что Боб может опубликовать Tx1 и откажется от дальнейшего сотрудничества (в этом случае у Алисы не будет способа вернуть деньги). Хэша Tx1 достаточно, чтобы сконструировать транзакцию-контракт.
3. Боб создает транзакцию-контракт Tx2, которая тратит UTXO транзакци Tx1 путем отправки его назад Алисе. Время блокировки Tx2 выставлено на какую-то дату в будущем (например, на +6 месяцев). Затем Боб подписывает ввод Tx2 своей сигнатурой и отправляет незавершенную транзакцию обратно Алисе.
4. Алиса проверяет контракт, завершает его подписанием своей сигнатурой и отправляет Tx1 в сеть. Tx2 может быть отправлен в сеть, когда истечет время блокировки.

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

2.4 Каналы микроплатежей

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

Решение:

1. Алиса создает новый публичный ключ и запрашивает публичный ключ Боба.
2. Алиса создает новую транзакцию Tx1 с количеством денег достаточных для типичной пользовательской сессии (например, 0,1 BTC) и выставляет блокирующий скрипт с проверкой мультисигнатуры «2 из 2». Она использует публичные ключи — свой и сервиса — для блокировки денег.
3. Алиса создает транзакцию-возврат Tx2, которая тратит деньги от UTXO Tx1 путем их отправки обратно Алисе. Время блокировки Tx2 выставлено на какое-то заранее оговоренное время в будущем (например, +1 день). Алиса подписывает Tx2 и отправляет эту неполную транзакцию Бобу.
4. Боб подписывает Tx2, завершая транзакцию, и отправляет ее обратно Алисе.
5. Алиса подписывает Tx1 и  начинает пользоваться сервисом.
6. Время от времени Алиса создает микроплатежную транзакцию Tx3, которая тратит UTXO Tx1 путем отправки части денег Бобу и остатка —  ей самой. Она подписывает эту транзакцию своей подписью и отправляет Бобу. Боб проверяет, что сигнатура Алисы верна, и что размер оплаты верен. Если все верно, Боб продляет пользование сервисом для Алисы. Обратите внимание, что Алиса не распространяет Tx3 в сеть (у нее неполная версия транзакции, в которой нет подписи Боба), равно как и Боб не будет делать этого (он конечно может закрыть ее, но ему это не нужно, так как каждая следующая версия открытой транзакции принесет ему больше денег).
7. Когда Алиса закончит пользоваться сервисом, Боб подписывает последнюю версию Tx3 и отправляет ее в сеть.

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

2.5 Оракулы

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

Задача: Алиса и Боб хотят заключить пари: Алиса хочет поставить 10 BTC на то, что к концу 2015 цена одного биткойна будет $500. Боб более пессимистичен. Они оба хотят использовать независимый сервис (оракул), которому они оба доверяют, чтобы не забыть об этом пари и провести его своевременно.

Решение:

1. Сервис-оракул создает новый публичный ключ и получает публичные ключи Боба и Алисы. Используя эти ключи, оракул адрес с мультисигнатурой «2 из 3», который высылает участникам.
2. Алиса создает новую транзакцию Tx1, которая отправляет желаемое количество денег на адрес с мультиподписью, и распространяет транзакцию в сети Биткойн.
3. Оракул проверяет Tx1 и создает три транзакции с затратами UTXO Tx1:
   • TxA отправляет деньги обратно Алисе и определяет ее победителем пари
   • TxB отправляет деньги обратно Бобу и определяет его победителем пари
   • TxR является возвратной транзакцией, которая отправляет деньги обратно Алисе. В отличие от TxA, у этой транзакции ненулевое значение времени блокировки, которое относится к определенному моменту в будущем.
4. Сервис отправляет TxA, TxB и TxR Алисе и Бобу. TxA и TxB отправляются не подписанными. Любая из этих транзакций может быть выполнена без помощи сервиса, если Боб и  Алиса согласятся на это.  TxR подписывается сигнатурой оракула, что означает, что транзакция станет действительна по истечении времени блокировки.
5. После получения транзакций от оракула, Алиса подписывает TxA и TxB своей подписью и возвращает их оракулу. Теперь оракул может подписать и распространить в сети TxA или TxB (но не обе) сразу же, как только определится результат пари.

Описанный процесс очень гибок:

• Условие может быть проверено единожды, в оговоренное заранее время (в 23:59:59, 31 декабря 2015 года, в рассматриваемом примере) или периодически (например, каждый день или каждую минуту).
• Условие может выражать любую информацию о внешнем мире, доступную оракулу. Например, условие может содержать пари, или страховой контракт, или даже завещание.
• В контракт могут быть вовлечены более одного оракула или более двух участников.
• Чтобы монетизировать сервис, оракул может включить небольшой платеж самому себе в транзакции контракта (TxA или TxB в нашем примере).

2.6 Умная собственность

(Этот пример взят со страницы Биткойн вики, под авторством Майка Хирна [13]. Он слегка гипотетичен, принимая во внимание, что пока нет машин или другой собственности со встроенными Биткойн-чипами, но технология стоит на пороге возможности их производства.)

Задача: Алиса хочет купить машину у Боба, используя смарт контракты на блокчейне Биткойна.

Решение:

Этот пример предполагает, что у машины Боба есть связанный с ней ключ владельца — обыкновенная пара ключей на эллиптической криптографии, используемой в протоколе Биткойна. Небольшое количество денег (скажем, 0,001 BTC) лежит на депозите на адресе определенном публичной частью ключа владельца.

1. Боб создает пару ключей и говорит Алисе публичный ключ и цену машины.
2. Алиса создает новый ключ владельца машины.
3. Алиса создает транзакцию-контракт с двумя вводами и двумя выводами. Вводами являются ее платеж за машину и ввод затраты UTXO, ассоциированного с ключом владельца Боба. Выводы идут на адрес, который Боб дал Алисе, и на вывод заблокированный ключом владельца Алиса. Поскольку у Алисы нет приватной части ключа владельца Боба, она только подписывает первый ввод транзакции и отправляет ее Бобу.
4. Боб проверяет транзакцию-контракт, подписывает второй ввод, и отправляет завершенную транзакцию в сеть.
5. Алиса и Боб ждут нескольких подтверждений.
6. Алиса представляет машине транзакцию-контракт. Бортовое программное обеспечение машины способно проверить, что транзакция действительна, имеет достаточное количество подтверждений, и оформлена таким образом, что позволяет трактовать себя как переход права собственности.

Есть так же несколько других приложений для умной собственности:

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

3. Предлагаемые улучшения в протоколе Биткойна

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

3.1 Избавление от пластичности транзакций

В настоящий момент Биткойн-транзакции пластичны: сигнатуры не покрывают всех данных транзакции, которые используются для создания хэша транзакции [14]. Один из непокрываемых фрагментов транзакции, это разблокирующие скрипты. Пластичность означает, что для третьей стороны возможно изменить транзакцию отправленную в Биткойн-сети таким образом, что это сделает ее хэш недействительным. И хотя выводы транзакции защищены от атаки, небезопасно принимать цепь неподтвержденных транзакций, потому что более поздние транзакции зависят от хэшей предыдущих транзакций, а они могут быть изменены до того, как транзакция будет включена в блок. Такое поведение усложняет организацию каналов для микроплатежей (см. раздел 2.4).

Одно из предложенных улучшений пластичности транзакций описывается в BIP 62 [15]. Полное устранение пластичности невозможно (очевидно, что сигнатура транзакции не может покрыть саму себя); ограничения на разблокирующие скрипты, вводимые BIP 62, могут быть вредны для разработки смарт контрактов.

3.2 СHECKLOCKTIMEVERIFY

CHECKLOCKTIMEVERIFY предложена в качестве дополнительной инструкции для скриптового языка Битойн [16]. Целью инструкции является алгоритмическое подтверждение условия, что определенный UTXO не может быть потрачен до определенного момента времени в будущем. CHECKLOCKTIMEVERIFY работает следующим образом:

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

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

3.2.1 Пример: Эскроу

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

Решение: Вместо того, чтобы использовать стандартный блокирующий скрипт с мультиподписью «2 из 3», Алиса (клиент) создает транзакцию с блокирующим скриптом, которая включает ветвление исполнения используя условный оператор (IF):

• Средства могут быть использованы транзакцией, подписанной посредником и либо Алисой, либо Бобом (продавцом), но только по истечении некоторого времени. Это правило относится к возврату средств или вынужденной оплате.
• Средства могут быть потрачены транзакцией, подписанной и Бобом и Алисой.

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

3.2.2 Пример: Каналы Микроплатежей

Задача: та же самая, что и в разделе 2.4.

Решение: Инструкция CHECKLOCKTIMEVERIFY позволяет добавить правило о возврате средств непосредственно в контракт-транзакцию. Точно так же, как и в случае с эскроу, клиент сервиса создает транзакцию с блокирующим скриптом, ветвящимся на две ветки исполнения. Одна из двух веток возвращает все средства обратно клиенту, при этом контракт заблокирован по времени. Вторая ветка исполнения является контрактом с мультиподписью «2 из 2».

3.2.3 Пример: Замороженные Средства

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

Решение: Алиса создает транзакцию с блокирующим скриптом, состоящим из двух частей:

1. CHECKLOCKTIMEVERIFY мешает потратить UTXO до определенного момента в будущем.
2. Обыкновенный набор инструкций, чтобы доказать право собственности (например, инструкция pay-to-pubKeyHash).

3.3 Опосредованная замена транзакций через порядковые номера

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

Соответственно, улучшение в BIP 68 [17] предлагает изменить семантику порядковых номеров вводов. Для изменения требуется софт-форк. Выглядеть оно будет так:

• Транзакции с номерами по умолчанию могут быть включены в любой блок
• Транзакция с нестандартным порядковым номером n может быть включена (2 в 32 степени — 1 — n) блоков после транзакции, содержащей UTXO, где тратится соответствующий ввод. Например, транзакция с единственным вводом с порядковым номером 2 в 32 степени —  2 (на единицу меньше, чем максимально возможный номер) может быть включена в любой блок после блока с транзакцией TxR, на которую ссылается ввод, но не в тот же блок, куда включена TxR
• Альтернативно, если порядковый номер определенной транзакции меньше, чем (2 в 32 степени — 500 * 10 в 16 степени), то это указывает на минимально необходимый интервал времени между блоком, содержащим транзакцию и блоком, содержащим транзакцию, на которую ссылается ее ввод.

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

3.3.1 Пример: Двунаправленные каналы платежей

Задача: Алиса и Боб хотят получить офф-чейновый канал проведения платежей в обоих направлениях.

Решение:

1. Алиса создает финансовую транзакцию Tx1, которая отправляет ожидаемо максимальное количество денег на UTXO, заблокированный сигнатурой, которая позволяет трату средств либо с согласия обеих сторон (мультисигнатура 2-из-2), либо самой Алисе после долгой задержки, например T = 30 дней. Это может быть достигнуто с использованием инструкции CHECKLOCKTIMEVERIFY, как описано в части 3.2, либо Алиса может использовать отдельную транзакцию для возврата.
2. Если Алиса хочет отправить деньги Бобу, она конструирует транзакцию с двумя выводами (один Бобу, другой себе самой), которая затратит Tx1. Она выставляет относительное время блокировки транзакции, как период меньший, чем T (например, 29 дней), подписывает транзакцию и отправляет ее Бобу.
3. Алиса может увеличить количество денег, отправляемых Бобу, путем отправки ему новой незакрытой транзакции.
4. Если Боб хочет отправить деньги Алисе, он конструирует транзакцию с двумя выводами (один себе, другой Алисе), затрачивающими Tx1. Порядковый номер транзакции Боба должен быть выставлен в значение времени меньшее, чем относительное время блокировки транзакции Алисы (то есть 28 дней). Это потому, что у Боба есть более предпочтительная транзакция, ранее отправленная ему Алисой. С меньшим временем блокировки у Алисы
5. ёесть целый день для того, чтобы распространить измененную транзакцию в сеть, до того как назреет следующая транзакция.
6. Время блокировки уменьшается каждый раз, когда платежный канал изменяет направление, до тех пор, пока относительное время блокировки не станет нулем, или обе стороны не согласятся закрыть канал. Порядковый номер последней транзакции выставляется в значение по умолчанию (2 в 32 степени — 1) и подписывается обеими сторонами.

4. Существующие решения со смарт контрактами

4.1 Сервисы кошельков

Как Виталик Бутерин писал в этой статье [18], в течение следующих нескольких лет все сервисы Биткойн-кошельков трансформируются в схему с мультиподписью «2-из-3», как описано в части 2. По сравнению с pay-to-pubKeyHash эта схема предлагает дополнительную безопасность и для пользователей кошельков, и для торговцев, принимающих их платежи. И в самом деле, схема с мультиподписью становится все более популярна и уже используется следующими сервисами:

• Armory wallet (https://bitcoinarmory.com/)
• BitGo wallet (https://www.bitgo.com/)
• Copay (https://copay.io/). Позволяет создавать произвольные конфигурации мультиподписей
• Cubits Wallet (https://cubits.com/). Схема с мультиподписью так же используется для перевода денег с пользовательского холодного кошелька на его горячий кошелек
• Gem Wallet (https://gem.co/)
• MyMoneyEx (https://www.mymoneyex.com/). Так же поддерживает схему с мультиподписью «2-из-2»
• Ninki (https://ninkip2p.com/)
• GreenAddress (https://greenaddress.it/en/). Использует кошельки с мультиподписью «2-из-2».

4.2 Обнаружение воровства

Сервисы по обнаружению воровства относятся к кошелькам с мультиподписью. Эти сервисы подписывают пользовательские транзакции блокирующими скриптами с мультиподписью «2-из-3». Два ключа принадлежат пользователю (один обыкновенный ключ кошелька, второй ключ физического восстановления). Третий ключ принадлежит сервису и используется для подписания транзакций на основе рейтинга рисков:

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

Некоторые сервисы, внедрившие такого рода защиту от воровства:

• CryptoCorp (https://cryptocorp.co/)
• Bitrated (https://www.bitrated.com/), объединенный с сетью доверия (web of trust).

4.3 Сервисы-оракулы

Сервисы-оракулы реализуют чтение данных из офф-чейн источников, как описано в разделе 2.5. Два наиболее распространенных типа данных, считываемых оракулами:

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

Сервисы-оракулы включают:

• Hedgy (http://hedgy.co/), оракул-сервис хэдж-контрактов на блокчейне Биткойна
• Early Temple (http://earlytemple.com/), оракул-сервис, использующий контракты на основе веб-страниц
• Orisi (http://orisi.org/), сеть для распределенных оракулов, которые коммуницируют, используя протокол BitMessage. С целью увеличения безопасности, Система Orisi поддерживает несколько оракулов для одного контракта
• BTCOracle (http://btcoracle.com/), сервис-оракул для биткойн-опционов
• RealityKeys (https://www.realitykeys.com/), сервис-оракул, использующий обменные курсы и прочие API для получения данных. В отличие от других сервисов, RealityKeys не создает транзакции на блокчейне Биткойна. Вместо этого сервис создает две пары ключей, по одной для каджого из возможных исходов контракта. Публичные ключи доступны немедленно и могут быть использованы для проектирования транзакций контракта. Приватный ключ, относящийся к истинному исходу контракта, выпускается в день, назначенный сторонами, и может быть использован для подписания транзакции-контракта. Второй приватный ключ уничтожается.

4.4 Платежные каналы офф-чейн

Существует несколько прототипов и работающих решений офф-чейновых каналов платежей:

• Однонаправленные платежные каналы включены в bitcoinj (bitcoinj.github.io), библиотеку для работы с Биткойн-протоколом, разработанным на Java [19]
• Lightning Network (lightning.network), концепция двунаправленных каналов платежей [20]. Если использовать некоторые софт-форки к протоколу Биткойна (см. раздел 3), эта сеть может начать работать в обозримом будущем [21]
• Impulse (http://impulse.is/), концепция каналов моментальной оплаты на блокчейне Биткойна
• Платежные каналы являются одним из возможных применений SidechainElements от Blockstream (https://blockstream.com/).

4.5 Создаваемые смарт контракты

• SmartContract (http://www.smartcontract.com/) это сервис, предлагающий несколько типов смарт контрактов на основе Биткойна:
  • Эскроу, освобождаемое как только данные вписанные в контракт подтвердятся произведенными действиями
  • Стабилизированные платежи, связывающие вместе опции оплаты в USD и BTC
  • Гарантированные платежи за произведенные действия
  • Контракты с умной собственностью (не стандартизированные, создаваемые вручную)
  • Контракты на основе местоположения в пространстве, с использованием GPS навигации (не стандартизированные, создаваемые вручную)
• Mirror (https://mirror.co/), p2p платформа для торговли Биткойн смарт контрактами
• Counterparty (http://counterparty.io/), платформа, которая представляет сделанные на заказ токены, поверх Биткойн-блокчейна. Токены могут быть использованы для смарт контрактов, где сам протокол Counterparty выступает в роли посредника.

5. Конкуренты

Несмотря на рост популярности цифровых валют в 2010-х, смарт контракты остаются относительно малоисследованной областью приложения криптовалют. Есть только один основной конкурент смарт контрактам на блокчейне Биткойна, Etherium (https://www.ethereum.org/). Девелоперы Counterparty портировали функционал Etherium на свою платформу, чтобы сделать возможными смарт контракты на блокчейне Биткойна. На момент июля 2015, проект находился в стадии беты. Другой многообещающий проект с аналогичными целями, Codius (https://codius.org/), недавно был свернут [22].

5.1 Etherium

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

• Аналогично Биткойну, данные в Etherium хранятся в распределенном блокчейне, безопасность которого обеспечивает криптографический алгоритм proof-of-work (PoW). В отличие от Биткойна, PoW используемый в Etherium, настроен на меньшее время генерации блока (примерно 10 секунд), так что транзакции подтверждаются значительно быстрее
• Как и в Биткойне, Etherium использует скриптовый язык для смарт контрактов. Но в отличие от Биткойна скриптовый язык в Etherium Тьюринг-полный (то есть, на нем можно реализовать любую вычислимую функцию)
• Смарт контракты в Etherium являются независимыми игроками с некоторым адресом. У каждого смарт контракта есть ассоциированные скрипты,  которые позволяют ему проводить входящие транзакции. Таким образом, транзакция в Etherium не имеет преодпределенной семантики, по сравнению с Биткойном, где все транзакции переводят ценность. Семантика транзакции определяется ее назначением.
• Блокчейн Etherium хранит не только транзакции, но также системные состояния. Скриптовый язык Etherium включает специальные инструкции чтения и записи данных из/в блокчейн.

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

• Проект все еще находится на ранней стадии (он только-только был запущен 30 июля 2015), что означает, что скорее всего в нем есть еще не обнаруженные пока уязвимости и ошибки проектирования. Etherium с равной вероятностью предстоит пройти серьезные конструктивные изменения, судя по тому, как шла разработка перед запуском
• Сравнительно небольшие майнинговые мощности, которые уделяются обеспечению безопасности блокчейна Etherium , делают его уязвимым для атак. С точки зрения безопасности, блокчейн Биткойна выглядит более привлекательно и сохранит этот статус в обозримом будущем
• Универсальность протокола Etherium делает его сложным, по сравнению с Биткойном. Например, хотя данные и могут быть сохранены на блокчейне Etherium, операции по записи больших массивов данных будут (вполне возможно, чрезмерно) дороги, так что контракты типа оракул, скорее всего все равно будут хранить данные офф-чейн
• Как предполагает работа [23], возможно, сама архитектура протокола Etherium делает его уязвимым к атакам: он демотивирует майнеров включать вычислительно-сложные транзакции в блоки, равно как и проводить полную проверку всех входящих блоков
• Etherium страдает от неоптимального менеджмента. Например, до сих пор неизвестны детали предполагаемого изменения от PoW к PoS алгоритму. Дата изменения и некоторые другие ключевые события в жизненном цикле Etherium не заданы формально, но остаются на усмотрение команды.

5.2 Counterparty

С 2014 года Counterparty включает окружение для смарт контрактов, построенное на базе виртуальной машины Etherium, и дающее виртуально те же самые возможности [24]. Сейчас система доступна только для тестирования. Окружение дает возможность запускать смарт контракты Etherium на блокчейне Биткойна, и в то же время наслаждаться преимуществами платформы Counterparty, такими как управление определенными пользователем цифровыми активами. Смарт контракты на Counterparty будут более безопасны, а так же они будут использовать экосистему более богатую приложениями, чем в ETherium. С другой стороны, пока непонятно, как хорошо смарт контракты (особенно те, что оперируют информацией из офф-чейн источников) будут переваривать длинное время подтверждения на блокчейне Биткойна. Вероятно, есть более эффективные способы интеграции Биткойна и Etherium, например используя Etherium как связанный сайдчейн [25].

5.3 Codius

Codius, это платформа для хостинга децентрализованных приложений, включая смарт контракты. Платформа разрабатывалась RippleLabs примерно около года, до того как была свернута в июне 2015, вследствие недостаточного к ней интереса. По аналогии с Ripple Network, Codius на самом деле не был децентрализован: он использовал бы нескольких доверенных хостинг-провайдеров выбранных Ripple для запуска децентрализованных приложений. Это удешевило бы платформу с точки зрения затрат вычислительной мощности и потребления электроэнергии.

Одним из аспектов Codius являются смарт контракты. В отличие от Биткойна или Etherium , контракты разрабатываются, используя языки программирования общего назначения без каких-либо особых требований к среде исполнения. Контракты могут содержать или манипулировать активами в одной или нескольких цифровых валютах, таких как Биткойн или Ripple. С одной стороны, это делает смарт контракты в Codius более гибкими, с другой стороны, они не осуществляемы естественно. Например, правило о возврате денег в Биткойн-контракте прозрачно для всех сторон. Это следует из свойств Биткойн-протокола самого по себе:

• Возвраты выполнимы
• Возврат не может быть выполнен раньше, чем оговорено
• Возврат не может быть выполнен вместо основного контракта или вместе с ним.

Cовсем не тот случай с Codius, или любой другой системой, основанной на компьютерном окружении общего назначения.

6. Выводы

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

• низкий фактор доверия в системе, и
• безопасность, проистекающая из математических законов, а не из авторитета посредника.

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

Наиболее многообещающие категории смарт контрактов на блокчейне Биткойна:

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

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

По сравнению с главным конкурентом, Etherium, у Биткойн-контрактов есть следующие преимущества:

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

С другой стороны, Etherium имеет несколько преимуществ, по сравнению с Биткойном:

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

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

Таблица 1: Категории смарт контрактов и их потенциал

Источник: Bitfury.com

Перевод сделан при содействии проекта #takemybitcoin.