Россия, Москва, МГОУ, 2007 |
Транзакции Биткоина
Приложения из скриптов Биткоина
Замена простого указания открытых ключей скриптами имеет множество практических применений, о которых будет рассказано далее. Одно из них - это транзакция под условия.
Рассмотрим классическую ситуацию с онлайн-оплатой. Алиса и Боб хотят заключить между собой сделку, скорее всего, Алиса выиграла какой-нибудь онлайн-аукцион и теперь хочет что-то купить у Боба.
И вот Алиса хочет заплатить Бобу биткионами, а Боб в обмен отправил бы Алисе какой-то материальный товар. Но проблема в том, что Алиса не хочет платить, пока не получит товар, а Боб не хочет посылать товар, пока он не будет оплачен.
У Биткоина на этот случай есть отличное решение, которое очень часто используется на практике. Это - привлечь третью сторону и совершить условную транзакцию.
Алиса пересылает деньги не напрямую к Бобу, а создает MULTISIG-транзакцию, которая, чтобы переслать монеты, требует подписи двух или трех человек.
Пусть этими тремя людьми будут Алиса, Боб и Джуди, которая будет в роли судьи и вступит в переговоры в случае спора. Итак, Алиса создаст транзакцию с нужной суммой. Причем с двумя из трех действительных подписей между Алисой, Бобом и Джуди. Элис подписывает транзакцию для пересылки Биткоинов, которыми она владеет, и это опубликуется в блокчейне. В этот момент эти деньги для Алисы, Боба и Джуди будут находиться в состоянии залога. И любой из двоих подписавших могут указать, куда эти деньги нужно переслать.
Боб будет убежден, что он может со спокойной душой отправлять товар Алисе. И тогда он отправит их в материальном виде по почте или посылкой.
Теперь останется надеяться на то, что в реальной жизни Алиса и Боб - честные люди.
В таком случае товар придет вовремя и он будет удовлетворять потребностям Алисы, и тогда она перешлет заложенные деньги Бобу, и он получит право на их личное расходование.
Если это произойдет, Алиса и Боб смогут подписать транзакцию, выпускающую деньги из-под залога и пересылающую их Бобу. И самое приятное в этом то, что Джуди не пришлось вмешиваться. Спора не случилось. И таким образом, Алиса и Боб сработались, и подтверждение тому - два ключевых человека, подписавших MULTISIG-транзакцию, вместо трех.
Что бы случилось, если бы Боб не отправил товар? Или если бы он его отправил, но он потерялся на почте? Или если бы он отправил не тот размер?
Алиса не захочет платить Бобу, потому что она решит, что он ее обманул, и она захочет вернуть деньги назад.
В таком случае, они не подпишут совместную транзакцию, которая бы отправила деньги Бобу. Но также Боб не подпишет транзакцию, которая отправляет деньги назад к Алисе, поскольку будет отрицать обвинения Алисы о своем мошенничестве.
На этом этапе привлекается Джуди. Именно Джуди предстоит рассудить, кто из этих двоих честный, а кто не заслуживает получить деньги.
И если Джуди решит, что обманщик - Боб, то она решит подписать транзакцию совместно с Алисой, чтобы вернуть ей её деньги. То есть Алиса и Джуди сработаются, будут подписаны две ключевые подписи, и Алиса получит деньги назад.
Конечно же, у Джуди есть право пойти по другому пути. Если она решит, что виновата Алиса, что она отказывается платить положенную ей сумму, Джуди подпишет транзакцию, пересылающую деньги Бобу.
То есть, у Джуди появляется полное право действий, но самое хорошее здесь в том, что пока не откроется спор, ей не придется вступать в него.
Проблема: Элис хочет заплатить Бобу. Боб не хочет ждать 6 подтверждений об отсутствии двойных затрат, или не находится в сети.–Еще один способ использования скриптов - "зеленые адреса".
Допустим, Алиса хочет отправить Бобу деньги, а его нет в сети. То есть, Боб не сможет войти в блокчейн и проверить, не приходили ли от Алисы какие-либо транзакции. Может быть, у Боба просто нет времени зайти в блокчейн и подождать подтверждения транзакции ( рис. 3.15).
Чтобы транзакция была прикреплена шестью блоками в блокчейне, потребуется примерно час.
Или у Боба просто нет возможности подключиться к Интернету и проверить блокчейн. В качестве примера может выступить такой случай, что Боб - это простой уличный торговец. Чтобы можно было переслать Биткоины, несмотря на неспособность получателя проверить блокчейн, нужно снова привлекать третью сторону, коей в данном случае окажется банк.
Алиса соединяется со своим Банком и говорит: "Здравствуйте, это Алиса, я ваш постоянный клиент. Вот мое удостоверение личности. Мне нужно переслать деньги Бобу, вы можете мне помочь?"
И в Банке ей говорят: "Конечно, сейчас мы снимем часть денег с вашего счета и выполним транзакцию через один из наших зеленых адресов напрямую к Бобу."
Обратите внимание, что деньги пришли из Банка прямо к Бобу. Часть этих денег в виде переадресации, возможно, перейдет обратно в Банк.
По сути, Банк пересылает Бобу деньги через адрес, подконтрольный Банку. Такие адреса дают гарантию того, что не случится двойной переплаты. Так что, как только Боб увидит, что транзакция подписана Банком, и если он поверит гарантии Банка об отсутствии двойной переплаты, он сможет подтвердить то, что он получил деньги, как только об этом будет сообщено в блокчейне. Заметьте, что эта гарантия была предоставлена не Биткоином, а реальным объектом, и Бобу нужно будет поверить в то, что Банк знает свое дело и заботится о своей репутации, и поэтому не будет требовать двойной переплаты.
Банк также сможет сказать: "Вы можете посмотреть на мою историю и убедиться, что этот зеленый адрес используется уже давно, и двойных трат не было еще ни разу. Поэтому вряд ли это когда-то случится в будущем".
Само собой, если Банк хоть раз совершит двойную трату, то доверие к нему обрушится почти мгновенно.
Существовало два наиболее надежных онлайн-сервиса, предоставлявших зеленые адреса, а именно Instawallet и Mount Gox, и оба они обрушились. Изначально сообществу Биткоина понравилась идея, что оплату можно совершать быстрее и не нужно обращаться для этого в блокчейн. Сейчас же эта идея настораживает людей тем, что банкам оказывается слишком много доверия. В результате, несмотря на всю прелесть этого протокола, в реальности он используется крайне редко.
Проблема: Алиса хочет оплатить Бобу каждую минуту услуги. Она не хочет создавать новые транзакции ежеминутно.
Третий пример - это способ эффективного проведения микротранзакций. Алиса покупатель, который хочет оплатить Бобу какую-то недорогостоящую услугу.
Может быть, в данном случае, Боб работает консультантом, и Алиса платит небольшую сумму денег за каждую минуту разговора по телефону.
Если создавать транзакции за каждую минуту разговора, их будет слишком много. За них будет запрошено много пошлин, и никто не будет этому рад. И если разговор Алисы с консультантом займет 2 часа, то потребуется 120 транзакций.
При помощи последовательных микротранзакций можно объединить маленькие счета в большой. Необходимо создать MULTISIG-транзакцию, которая будет содержать настолько большую сумму денег, насколько Алиса будет планировать потратиться, и потребует как от Алисы, так и от Боба, подписи, которые дадут разрешение на ее расходование.
Теперь, после каждой минуты разговора, или при первой же необходимости у Алисы совершить микротранзакцию, она подписывает транзакцию, которая расходует те монеты, которые были отправлены на MULTISIG-адрес, посылая одну монету Бобу, и возвращая остаток назад к Алисе.
После первой минуты проводимой консультации, Алиса подписывает следующую транзакцию, и тогда у Боба будут уже две монеты, в то время остаток снова окажется у Алисы.
Подписывает транзакции только Алиса, а Боб этого не делает ни разу.
Алиса будет совершать транзакции каждую минуту, которую она тратит на консультацию с Бобом.
Обратите внимание на то, что транзакции в блокчейне не публикуются. Они просто совершаются между Алисой и Бобом.
В определенный момент Алиса решит завершить консультацию. Тогда она скажет Бобу: "Все, завершаем разговор, я не хочу платить еще больше." А Боб скажет: "Хорошо, тогда я отключаюсь. Я возьму последнюю проведенную вами транзакцию, подпишу ее и опубликую в блокчейне."
Итак, поскольку каждая транзакция пополняла Бобу счет, а Алисе наоборот, понижала, то какой бы ни была последняя пересылка, Боб все же решит ее подтвердить, таким образом получив свою оплату за предоставленные услуги, и вернув разницу обратно на счет к Алисе.
Что еще хорошо, так это то, что все транзакции, которые Алиса подписала до нее, не будут вписаны в блокчейн, Бобу не нужно их подписывать, и поэтому они будут стерты.
Технически все эти транзакции будут считаться двойной тратой, в отличие от случая с зелеными адресами. Тем не менее, в реальной жизни, если обе стороны взаимодействуют исправно, Боб не будет подписывать ни одной транзакции, кроме последней, и по этой причине блокчейн не увидит намерения совершить двойную трату.
Что произойдет, если Боб так и не подпишет последнюю транзакцию (рис.3.18)? Вдруг он скажет: "Меня устраивает тот факт, что заложенные деньги так и останутся под залогом навсегда." В таком случае, деньги пересланы ему не будут, но Алиса потеряет все, что она вложила в самом начале. Для этого был придуман таймер (Lock_Time).
Чтобы избежать подобной проблемы, Элис и Боб предварительно подписывают транзакцию, которая пересылает все деньги обратно к Элис, но которые остаются недоступными до определенного момента времени.
То есть, до того, как Элис подпишет первую транзакцию об оплате первой минуты консультации, возможно, она захочет создать возвратную сделку, чтобы деньги остались у нее. Она захочет быть уверена, что если в указанный момент времени t Боб не подпишет любую из посланных Элис транзакций, то она сможет опубликовать свою транзакцию, и она вернет себе обратно все деньги.
Рис. 3.19. Блокирующий индекс, или отметка реального времени, до которого транзакция не может быть опубликована
Если еще раз посмотреть на метаданные в транзакции Биткоина, то можно понять, что речь идет о параметре "lock_time".
Если в этом параметре опубликовать отличный от нуля момент времени, майнеры не будут публиковать транзакцию до наступления этого момента. Транзакция будет считаться недействительной и не будет публиковаться, пока в блоке будет содержаться особый номер блокировки или момент времени, подкрепленный конкретной точкой отсчета.
Таким образом можно подготовить транзакцию, которая может быть совершена в будущем лишь в том случае, если в этом будущем не случится что-то еще. То есть если Боб не подпишет последнюю транзакцию, деньги вернутся к Алисе.
В этой лекции было рассмотрено три способа применения скриптов. Существуют и другие способы. Один из них - многопользовательские лотереи, которые содержат в себе очень сложный, многоступенчатый протокол, с множеством транзакций и кучей сделок с указанными моментами времени. Все они являются залогами, создаваемыми на случай мошенничества.
С помощью скриптов можно заплатить кому-то, кто знает прообраз хеша и заставить его работать на себя. Есть еще пара отличных протоколов, которые позволяют разным людям перемешивать между собой свои биткоины, чтобы в дальнейшем невозможно было определить, кто каким биткоином владеет. Эти протоколы будут рассмотрены в лекции про анонимность.
Общий термин для подобных контрактов - "смарт-контракты", это означает, что такие контракты осуществляют технический контроль того, что обычно контролируется законами или арбитражными судами.
У Биткоина много замечательных особенностей - можно использовать скрипты, задействовать майнеров и применять валидацию сделок для залогов и микротранзакций. При этом отсутствует централизованное управление этими сделками.
В настоящее время смарт-контракты очень востребованы. Существует множество смарт-контрактов, которые люди хотели бы использовать, но сегодняшние возможности Биткоина не позволяют их реализовать. Эти смарт-контракты либо невозможно создать, либо для реализации не найдено подходящее решение. Тем не менее с помощью скриптов можно создать несколько интересных смарт-контрактов, о которых будет рассказано в следующих лекциях.