Применение биткоин-скриптов. Эффективные микроплатежи

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

Эскроу-транзакции. Скажем, Алиса с Бобом решили заключить сделку - она хочет заплатить биткоинами за вещи, которые отправит ей он. Проблема в том, что Алиса не хочет платить, пока не получит товар, а Боб не хочет отправлять его, пока не получит за него деньги. Что делать в этой ситуации? Здесь на помощь приходит изячное решение, которое очень часто применяется на практике - введение в сделку третьей стороны и выполнение эксроу- транзакции.

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

В этот момент Боб может быть уверен, что товар можно без опасений отправлять Алисе, которая, получив его, подпишет транзакцию вместе с Бобом, и средства будут высвобождены с депонирования и поступят Бобу. Заметьте, что в этом случае, если и Алиса и Боб ведут честную игру, Джуди никак себя не проивляет. Никто ни с кем не спорил, подписи Алисы и Боба соответствуют требованию "2 из 3". Так что в нормальном случае это ненамного менее эффективно, чем прямая отправка денег Бобу - для уверенности требуется лишь одна лишняя транзакция по блокчейну.

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

Здесь-то и приходит пора Джуди выйти из тени. Она должна решить, кому из них причитаются деньги. Если она решит, что обманщик Боб, она подпишет транзакцию вместе с Алисой, и они отправятся с депонента к последней. Подписи Алисы и Джуди соответствуют требованию "2 из 3", и Алиса получит назад свои коины. И, разумеется, если Джуди рассудит, что заблуждается как раз Алиса, и что она отказывается платить за то, за что должна, то может подписать транзакцию с Бобом, и тогда деньги получит он. Поэтому задача Джуди - выбрать между двумя возможными исходами. Хорошо, однако, что ей не нужно вмешиваться, если никакого спора нет.

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

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

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

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

Конечно, если банк внезапно совершит двойное расходование, люди перестанут доверять его зелёным адресам. На самом деле, среди известных сервисов, пользовавшихся зелёными адресами, были Instawallet и Mt.Gox, и оба закончили свои дни стремительным крахом. Сегодня зелёные адреса используются не так уж часто. Когда идею только предложили, она вызвала большое одобрение как способ проведения быстрых платежей без доступа к блокчейну. Теперь же люди стали более подозрительными и не слишком доверяют банкам.

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

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

В следующую минуту Алиса подписывает ещё одну транзакцию, выплачивая в этот раз уже две единицы, и отправляя остальное себе. Отметьте, что подписи ставит только Алиса, а Боб пока бездействует, и в блокчейне транзакции пока не появляются. Алиса отправляет эти транзакции за каждую минуту пользования услугой, но в конце концов разговор заканчивается, и она говорит Бобу: "Ну всё, я закончила. Отключай. Больше я не плачу". И Боб отвечае: "Отлично. Я отключаю услугу, и это последняя транзакция, которую ты мне отправила, подписывай и публикуй в блокчейне".

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

На практике, однако, если обе стороны работают честно, Боб не подпишет ни одной транзакции, кроме последней, и в этом случае в блокчейн не попадёт двойная трата. Есть, однако, тонкий момент: что, если Боб так и не подпишет последнюю транзакцию? Он может просто сказать: "А мне нравится, что все эти коины вечно торчат на депоненте", в каковом случае они не будут перемещаться, но Алиса лешится всей суммы, которую заплатила вначале. Но есть весьма умный способ избежать всего этого с помощью особенности, которая бегло упоминалась выше. Сейчас пришла пора рассказать о ней подробней.

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

Что значит, что деньги заблокированы до условленного времени? Вспомним метаданные в биткоин-транзакции, где был параметр lock_time, который мы тогда не стали объяснять. Работает он так: если вы задаёте любое отличное от нуля значение для этого времени, он сообщает майнерам, что не нужно публиковать транзакцию, пока время не выйдет.

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

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

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

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