Стоит ли бояться биткоин

Стоит ли бояться биткоин

Настоящие деньги?

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

Повторюсь — все это не более, чем заблуждения. В основе идеи Bitcoin лежало желание создать не очередные «бумажки», которые представляют реальные деньги, такие как золото, а аналог самого золота. Взять те свойства золота, благодаря которым оно является идеальными деньгами, и сделать электронную валюту на их основе.

Сложность добычи

Золото нельзя скопировать — его можно только добыть. Но это очень затратный процесс как по времени, так и по ресурсам. Частично из-за этого золото ценится так высоко. Чтобы было понятнее, рассмотрим на примере.

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

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

В Bitcoin процесс добычи монеток тоже требует ресурсов и времени. Но в данном случае это не человеческие ресурсы, а компьютерные.

Материальность

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

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

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

Цепочка блоков

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

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

На момент написания статьи количество блоков в цепочке было равно 110 968, и, как я уже говорил ранее, это количество приблизительно через каждые 10 минут увеличивается на 1. Это значит, что кто-то из участников смог создать новый блок.

Кстати говоря, все участники делятся на две группы: на тех, кто работает над новым блоком и кто не работает. По статистике эти группы соотносятся как 1 к 3. Зачем вообще создавать блоки, да еще каждые 10 минут? В блоках записываются транзакции. Каждый блок содержит все транзакции, которые проходили во время его создания, т. е. за 10 минут.

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

Блок

Рассмотрим содержимое блока и процесс его генерации более подробно. Пример блока можно найти на все том же Bitcoin Block Explorer. Блок состоит из заголовка и списка транцакций. Заголовок состоит из следующих свойств:

hash — SHA-256 хэш заголовка блока. Такой хэш является достаточно случайным, а время его вычисления предсказуемо. Хочу заметить, что хэшируется только заголовок, без транзакций. Так что число транзакций не будет сильно влиять на время вычисления хэша.

ver — Версия схемы блока. На данный момент у всех блоков одна версия — 1.

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

mrkl_root — Merkle root — список хэшей транзакций. Хэш блока должен обязательно зависеть от транзакций, чтобы их нельзя было подделать. Но вычислять его напрямую будет долго, если количество транзакций велико. Поэтому сначала хэшируются сами транзакции, а затем их хэши используются для вычисления хэша всего блока.

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

time — uint32_t представляющее время создания блока. Максимально допустимый год — 2106.

bits — Одно из самых важных свойств. Является сокращенной формой целевого значения хэша. Блок считается сгенерированным (валидным), когда его хэш меньше этого целевого значения. Целевое значение определяет сложность создания блока. Чем оно меньше, тем меньше вероятность подобрать подходящий хэш за одну итерацию. Это свойство обновляется каждые две недели.

Происходит это следующим образом. Подсчитывается число сгенерированных блоков за последние две недели и сравнивается с эталоном (1 блок каждые 10 минут). Если блоков слишком много, то сложность увеличивается. Если блоков слишком мало — уменьшается. Таким образом система адаптируется к увеличению числа пользователей и, как следствие, суммарной мощности их компьютеров.

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

Например, версия никогда не меняется. Хэш предыдущего блока обновляется тогда, когда кто-нибудь нас опередит и сгенерирует новый блок. Merkle root обновляется при добавлении транзакции. Время — каждые несколько секунд. Bits (целевое значение, сложность) — каждые две недели. Все это слишком долго. Чтобы не ждать, пока обновится одно из свойств и существует nonce.

Рассмотрим гипотетическую ситуацию. Все значения nonce были проверены и ни одно из них не подходит. За это время ни одно другое свойство не изменилось. Происходит переполнение nonce и оно снова начинается с нуля. Получается, что далее хэши будут повторяться. Чтобы избежать подобных ситуаций, после переполнения nonce, меняется специальное свойство одной из транзакций. После этого обновляется Merkle root и хэши заголовка блока уже не будут повторяться.

n_tx — Количество транзакций в списке.

size — Размер блока в байтах.

Транзакции

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

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

На практике все это реализовано с помощью следующих свойств:

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

ver — Версия схемы транзакции. Пока она ни разу не менялась, так что везде равна 1.

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

vout_sz — Количество адресов, на которые переводятся деньги. Один или более.

lock_time — Пока не используется и везде равно 0. Идея в том, чтобы создавать отложенные транзакции, чтобы они добавлялись не в текущий генерируемый блок, а, например, в слещующий. Подразумевается, что в этом свойстве указано количество блоков, которые должна пропустить транзакция перед добавлением. Это дает возможность в течении некоторого времени изменить транзакцию и переподписать ее.

size — Размер транзакции в байтах. Подразумевается размер транзакции в формате JSON.

in — Содержит список входов (источников) транзакции. В качестве входов используются выходы предыдущих транзакций (prev_out). У каждого выхода есть следующие свойства:

hash — Хэш предыдущей транзакции.

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

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

После списка входов транзакции (in) указывается список выходов (out), т. е. адресатов. Каждый выход имеет следующие свойства:

value — Содержит количество денег, которые будут переведены по новому адресу. Они берутся из предыдущих транзакций. Поэтому данное число не должно превышать их сумму. Например, мы хотим взять 10 монеток из одной транзакции и 20 из другой и направить 25 по новому адресу. Чтобы оставшися 5 монеток не пропали, мы посылаем их самим себе, как сдачу. Таким образом в нашей транзакции будет два адресата, одним из которых являемся мы сами. Value всегда указывается в наномонетах, чтобы избежать дробных чисел.

scriptPubKey — Это свойство, вместе с scriptSig составляют сценарий на модифицированном Forth-like языке. ScriptPubKey содержит операторы языка и хэш публичного ключа получателя транзакции. Сценарий проверяет транзакцию на валидность. Использование подобного сценария дает богатые возможности для описания условий получения денег адресатом. Например, можно заставить получателя указывать пароль вместо ECDSA.

Суммарное количество денег на входе транзакции всегда равно суммарному количеству на выходе. В противном случае деньги либо возникали из воздуха, либо исчезали из оборота. Но в самом начале был график, по которому видно, что число денег экспоненциально растет. Так откуда берутся новые деньги в системе?

На мой вкус, эмиссия денег реализовано просто и элегантно. В каждом блоке первая транзакция в списке является особой транзакцией. У нее всегда один вход, у которого вместо свойства scriptSig есть свойство coinbase. Это свойство может содержать что угодно.

Выход у транзакции также всегда один. Он перенаправляет 50 монеток тому, кто сгенерировал блок, в котором расположена эта транзакция. Это своего рода награда за потраченное время и ресурсы на генерацию блока. Создавая новый блок в цепочке, клиент вносит вклад в работу Bitcoin.

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

Стабильность работы системы основана на количестве пользователей, у которых запущен официальный клиент. Пока их большинство, Bitcoin ничего не угрожает.

Заключение

Proof of work (доказательство работы) — результат работы, которого трудно добиться, но легко проверить. Работа сети Bitcoin основана на этом принципе. Проверить хэш (результат работы) можно за доли секунды. А для того, чтобы его подобрать, требуется много работы.

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

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

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

Как только Bitcoin попал на рынок, его ценность определяется исключительно уровнем доверия к системе. Чем больше человек будут доверять, тем больше купят Bitcoin, тем больше долларов в него вложат и, как следствие, тем дороже будет Bitcoin.

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

Надеюсь, что после этой статьи уровень доверия к Bitcoin хотя бы немного вырастет.