Механика биткоина. Биткоин-транзакции

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

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

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

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

Рис. 3.1. Реестр на основе счетов

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

Транзакция будет в этом случае выглядеть наподобие "А сейчас мы переводим 17 коинов от Алисы к Бобу", и под этим будет стоять алисина подпись. Это вся информация о транзакции, содержащаяся в реестре. На рисунке 3.1 видно, что после того, как Алиса за первую транзакцию получила 25 коинов, она за вторую отправила Бобу 17, и на её счету осталось 8 биткоинов. Оборотная сторона такого метода заключается в том, что если некто желает проверить валидность транзакции, ему придётся постоянно следить за балансами на счетах.

Посмотрите на рисунок 3.1 повнимательней. У Алисы есть 15 коинов, которые она пытается отправить Дэвиду? Чтобы это узнать, нужно будет посмотреть на все предыдущие транзакции, которые затрагивали алисин счёт, и убедиться, что в момент, когда она пытается отослать Дэвиду 15 коинов, у неё на счету есть немного больше. Конечно, можно создать определённые структуры данных, которые будут проверять счёт Алисы после каждой транзакции - но это повлечёт за собой создание масштабного бухгалтерского аппарата помимо самого реестра. Из-за всех этих недостатков в биткоине не применяется модель на основе счетов - вместо неё применяется реестр, который контролирует транзакции, подобно скруджкоину из первой главы.

Рис. 3.2 Реестр на основе транзакций (достаточно похож на реестр биткоина). Транзакции задают количество входов и выходов (вспомним пейкоины для скруджкоина). Можно представить себе, что входы - это коины, которые потребляются (т.е., создаются в предыдущей транзакции), а выходы - это коины, которые создаются. В транзакциях, которые чеканят новые коины, никакие коины не потребляются. У любой транзакции есть уникальный шифр: выходы индексируются шифрами, которые начинаются с 0, поэтому первый выход можно называть "выход 0"

А теперь поближе познакомимся с рисунком 3.2. В транзакции 1 входов нет, так как она создаёт новые коины, а выход у неё - 25 коинов, посланных Алисе. Кроме того, поскольку в ней создаются новые коины, подпись не требуется. Если Алиса желает послать немного коинов Бобу, она создаёт новый транзакцию - транзакцию 2 в нашем примере. В ней она должна однозначно сослаться на предыдущую транзакцию, из которой и будут браться отправляемые деньги.

Здесь она ссылается на выход 0 транзакции 1 (фактически, единственный у неё), который принёс ей 25 биткоинов. Также ей надо уточнить адрес выхода в транзакции - здесь она задаёт два выхода: 17 коинов Бобу и 8 Алисе. И, конечно, всё это подписывается самой Алисой, так что мы знаем, что это она авторизовала эту транзакцию. Смена адреса. ачем это Алиса отправляет деньги самой себе? Поскольку коины неизменны, весь выход транзакции должен поглощаться другой транзакцией целиком, либо не поглощаться вовсе.

Поскольку отправляет Алиса только 17 биткоинов, а её собственный выход составляет 25, ей нужно создать новый выход, где 8 биткоинов отправляются ей. Это может быть и другой адрес, но он также должен принадлежать ей. Это называется сменой адреса.

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

Консолидация средств. Поскольку у транзакции может быть много входов и выходов, разделение и объединение ценностей достаточно несложно. Например, Боб получил деньги из двух разных транзакций — 17 в одной и 2 в другой. Боб может подумать — а сделаю-ка я транзакцию, которую потрачу потом, в которой будут все 19 биткоинов. Так нет ничего проще — он создаёт транзакцию с двумя входами и одним выходом, который ведёт на адрес, принадлежащий ему самому. Это позволяет ему консолидировать две транзакции.

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

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

Рис. 3.3. Настоящая транзакция биткоина

Как видно из рисунка 3.3, у транзакции есть три составляющие: некоторые метаданные, серия входов и серия выходов.

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

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

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

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