- -
- 100%
- +
Боб предположительно запускает свой биткойн-узел, и это будет честный узел.
Узел Боба отклонит эту ветвь как недействительную, так как она содержит недействительную транзакцию.
Эта ветка недействительна, потому что подписи не проходят проверку.
Поэтому узел Боба просто игнорирует самую длинную ветвь, потому что это недействительная ветка.
И из-за этого, недостаточное подорвать консенсус.
Вы должны подорвать криптографию, чтобы украсть биткойны.
Таким образом, мы делаем вывод, что эта атака невозможна для 51-процентного злоумышленника.
Следует отметить, что все это всего лишь мысленный эксперимент.
Если бы были фактические признаки 51-процентной атаки, то, вероятно, разработчики заметят это и отреагируют на это.
Они будут обновлять программное обеспечение Bitcoin, и мы могли бы ожидать, что правила системы, включая одноранговую сеть, могут измениться в той или иной форме, чтобы затруднить успешную атаку.
Но мы не можем этого предсказать. Таким образом, мы работаем в упрощенной модели, где 51-процентная атака происходит, но нет никаких изменений или настроек правил системы.
Давайте рассмотрим еще одну атаку.
Может ли 51-процентный злоумышленник сдерживать некоторые транзакции?
Скажем, есть некий пользователь, Кэрол, которого нападающий очень не любит.
Злоумышленник знает некоторые адреса Кэрол и хочет сделать так, чтобы монеты, принадлежащие одному из этих адресов, не смогли быть потрачены.
Это возможно? Поскольку он контролирует консенсусный процесс блочной цепи, злоумышленник может просто отказываться создавать любые новые блоки, содержащие транзакции с одного из адресов Кэрол.
Злоумышленник может также отказаться не только от создания, но и от использования блоков, содержащих такие транзакции.
Однако он не может запретить передачу этих транзакций в одноранговую сеть, поскольку сеть не зависит от цепочки блоков или от консенсуса, и мы предполагаем, что злоумышленник не полностью контролирует сеть.
Злоумышленник не может остановить передачу транзакции большинству узлов.
Может ли злоумышленник изменить вознаграждение блока?
То есть, может ли злоумышленник притвориться, что награда за блок, вместо 12.5 биткойнов, составляет 100 биткойнов?
Это изменение правил системы, и поскольку злоумышленник не контролирует копии программного обеспечения Bitcoin, на котором работают все честные узлы, это также невозможно.
Это похоже на то, почему злоумышленник не может включать недопустимые транзакции.
Другие узлы просто не узнают про увеличение вознаграждения блока, а атакующий, таким образом, не сможет его потратить.
Наконец, может ли атакующий каким-то образом уничтожить доверие к Биткойну?
Давайте представим, что произойдет.
Если бы было много попыток двойной траты, ситуаций, в которых узлы не расширяли бы самую длинную действующую ветвь и другие атаки, тогда люди, скорее всего, решат, что Биткойн больше не работает как децентрализованная книга, которой они могут доверять.
Люди потеряют уверенность в валюте, и мы можем ожидать, что обменный курс биткойнов резко упадет.
На самом деле, если будет известно, что существует сторона, которая контролирует 51 % хэш-мощности, тогда возможно, что люди потеряют уверенность в биткойне, даже если злоумышленник не обязательно попытается атаковать.
Таким образом, это не только возможно, но и на самом деле вероятно, что 51-процентный злоумышленник любого типа уничтожит доверие к валюте.
Действительно, это основная практическая угроза, что когда-либо появится 51 процентный владелец хэш-мощности.
Никакие другие атаки не представляют угрозу, учитывая объем расходов, которые злоумышленник должен понести, чтобы атаковать Биткойн и достичь 51-процентного большинства, эти атаки не имеют смысла с финансовой точки зрения.
Надеюсь, теперь вы получили хорошее представление о том, как в биткойне достигается децентрализация, как идентификаторы работают в Bitcoin, как распространяются и проверяются транзакции, роль одноранговой сети в Bitcoin, как цепочка блоков используется для достижения консенсуса, а также то, как работает головоломка и майнинг.
Дальше мы будет рассматривать детали и нюансы биткойна.
Bitcoin транзакции
Далее мы рассмотрим механизм Биткойна более детально.
Мы рассмотрим реальные структуры данных и реальные скрипты.
Для начала вспомним, где мы остановились в прошлый раз.
Механизм консенсуса биткойнов дает нам реестр только для добавления, поэтому мы можем только записывать структуры данных, и как только данные записываются, они существуют навсегда.
И есть децентрализованный протокол для установления консенсуса относительно значений этого реестра.
И есть майнеры, которые выполняют этот протокол и которые проверяют транзакции, все вместе гарантируя, что транзакции хорошо сформированы, что нет двойных расходов, и в конечном итоге, что этот реестр и сеть могут функционировать как валюта.
И все потому, что мы предположили, что эта валюта может мотивировать этих майнеров.
Теперь, давайте в деталях рассмотрим, что представляет собой транзакция в биткойне, его центральная часть.
На данный момент мы будем использовать упрощенную модель реестра.
Вместо блоков предположим, что в реестр добавляются отдельные транзакции по одной за раз.
Как мы можем построить валюту на основе такой книги или реестра?
Первая модель, о которой вы могли бы подумать, которая на самом деле является ментальной моделью, которую многие люди используют для понимания того, как Биткойн работает, заключается в том, что у вас есть система на основе учетной записи.
Вы можете добавить некоторые транзакции, которые создают новые монеты и передают их кому-либо.
А затем позже вы можете эти монеты передавать дальше.
Транзакция будет содержать что-то вроде «мы передаем 17 монет от Алисы к Бобу», и эта транзакия будет подписана Алисой.
И эта информация о транзакции будет содержаться в книге.
В этом примере, после того как Алиса получила 25 монет в первой транзакции, затем передает 17 монет Бобу во второй транзакции, и у нее осталось еще 8 биткойнов на ее счете.
Недостатком этого способа ведения реестра является то, что любой, кто хочет определить, действительно ли транзакция валидна, должен будет отслеживать эти остатки на счетах.
В этом примере, что нужно сделать, чтобы понять, есть ли у Алисы 15 монет, которые она пытается передать Дэвиду?
Для этого вам нужно будет просмотреть всю книгу назад во времени, чтобы увидеть каждую транзакцию, относящуюся к Алисе, и вычислить ее баланс на момент, когда она пытается передать 15 монет Дэвиду.
Конечно, мы можем сделать это немного более эффективно с помощью дополнительной структуру данных, которая отслеживает баланс Алисы после каждой транзакции.
Но это потребует большого количества дополнительного обслуживания, кроме обслуживания самой книги.
Поэтому Bitcoin не использует модель на основе учетной записи.
Вместо этого Bitcoin использует книгу, которая просто отслеживает транзакции, подобные ScroogeCoin.
Транзакции указывают количество входов и количество выходов.
Вы можете думать о входах как о монетах, которые потребляются и которые были созданы в предыдущей транзакции, и о выходах как о создаваемых монет.
Для транзакций, в которых создаются совершенно новые монеты, нет монет, которые потребляются.
Каждая транзакция имеет уникальный идентификатор.
Выходы индексируются, начиная с 0.
В этом примере, первая транзакция не имеет входа, потому что эта транзакция создает новые монеты, и у нее есть выход из 25 монет, отправляемых Алисе.
Кроме того, поскольку это транзакция, в которой создаются новые монеты, здесь подпись не требуется.
Теперь предположим, что Алиса хочет отправить некоторые из этих монет Бобу.
Для этого она создает новую транзакцию, вторую транзакцию в нашем примере.
В транзакции она должна явно ссылаться на предыдущую транзакцию, в которой эти монеты поступили к ней.
Здесь она ссылается на выход 0 транзакции 1 (единственный выход транзакции 1), который присвоил Алисе 25 битконов.
Она также должна указать выходные адреса в этой транзакции.
В этом примере Алиса указывает два выхода, 17 монет Бобу и 8 монет Алисе.
И, конечно же, эта транзакция подписывается Алисой, так что мы знаем, что Алиса разрешает эту транзакцию.
Почему Алиса должна отправить деньги самой себе в этом примере?
Так как монеты являются неизменяемыми, в биткойне весь вывод транзакции должен потребляться другой транзакцией.
То есть транзакция должна быть самодостаточной, чтобы не калькулировать балансы.
Алиса хочет заплатить Бобу только 17 биткойнов, но выход, который у нее есть, стоит 25 биткойнов.
Поэтому ей нужно создать еще один выход, где 8 биткойнов отправляются обратно ей.
Это может отличаться от адреса, которому принадлежат 25 биткойнов, но он должен принадлежать ей. Это называется изменение адреса или change address.
Когда новая транзакция добавляется в реестр, как можно легко проверить, что она является валидной?
В нашем примере нам нужно найти выход транзакции, на который ссылается Алиса, и убедиться, что он имеет значение 25 биткойнов и что он еще не был потрачен.
Найти выход транзакции легко, так как мы используем хэш указатели.
Чтобы убедиться, что этот выход не был потрачен, нам нужно отсканировать цепочку блоков между указанной транзакцией и последним блоком.
Нам не нужно проходить весь путь назад к началу цепочки блоков, и это не требует хранения каких-либо дополнительных структур данных, хотя, как мы увидим, дополнительные структуры данных ускорят работу.
Так как транзакции могут иметь много входов и много выходов, разделять и объединять значения легко.
Например, Боб получил деньги в двух разных транзакциях – 17 биткойнов в одной и 2 биткойна в другой.
Боб может сказать, что хотел бы иметь одну транзакцию, которую он может потратить позже, где у него будут все 19 биткойнов.
Сделать это легко – он создает транзакцию с двумя входами и одним выходом, причем выходной адрес принадлежит ему.
Это позволяет ему консолидировать эти две транзакции.
Также, легко сделать и совместные платежи.
Предположим, Кэрол и Боб оба хотят заплатить Дэвиду.
Они могут создать транзакцию с двумя входами, которые принадлежат разным людям, и одним выходом.
И единственное отличие от предыдущего примера состоит в том, что, поскольку два выхода из предыдущих транзакций, которые здесь заявляются, относятся к разным адресам, для новой транзакции потребуется две отдельные подписи: одна – Кэрол, а другая – Боба.
Концептуально это все, что связано с транзакцией биткойнов.
Теперь посмотрим, как она представлена на низком уровне в биткойне.
В конечном счете, каждая структура данных, которая отправляется в сеть, представляет собой строку бит.
То, что здесь показано, является низкоуровневым форматом, но далее это дополнительно компилируется до компактного двоичного формата, который не читается человеком.
Как вы можете видеть в этом примере, транзакция делится на три части: некоторые метаданные, серия входов и серия выходов.
Что качается метаданных, здесь есть некоторая информация о самой транзакции – размер транзакции, количество входов и количества выходов.
Также здесь указан хэш всей транзакции, который служит уникальным идентификатором транзакции.
Это позволяет нам использовать хеш-указатели для ссылок на транзакции.
Наконец, есть поле «lock_time», к которому мы вернемся позже.
Теперь о входах.
Входы транзакций образуют массив, и каждый вход имеет один и тот же формат.
Вход указывает предыдущую транзакцию с помощью хэша этой транзакции, который работает как хэш-указатель на предыдущую транзакцию.
Вход также содержит индекс выхода предыдущей транзакции, на которую идет ссылка.
И здесь еще есть подпись.
Помните, что мы должны подписать транзакцию, чтобы показать, что мы на самом деле имеем возможность претендовать на эти предыдущие выходы транзакций.
Теперь о выходах.
Выходы также представляют собой массив.
Каждый выход имеет только два поля. У каждого выхода есть значение, а сумма всех выходных значений должна быть меньше или равна сумме всех входных значений.
Если сумма выходных значений меньше суммы входных значений, разница представляет собой плату за транзакцию для майнера, который публикует эту транзакцию.
Также, у выхода есть строка, которая выглядит как адрес получателя.
Мы видим, что здесь есть хэш публичного ключа, а также есть набор команд.
Так что это поле на самом деле является скриптом.
Bitcoin скрипты
Каждый выход транзакции не просто указывает публичный ключ или адрес следующего получателя монет.
На самом деле он определяет скрипт.
Что такое скрипт и почему мы используем скрипты?
Далее мы рассмотрим язык Bitcoin скриптов и поймем, почему скрипт используется вместо простого указания открытого ключа.
Наиболее распространенным типом транзакции в биткойне является трата выхода предыдущей транзакции путем подписания с помощью правильного ключа.
В этом случае мы хотим, чтобы на выходе транзакции говорилось: «этот выход транзакции может быть потрачен с помощью подписи следующего владельца указанного адреса.»
Напомним, что адрес является хешем публичного ключа.
Поэтому просто указание адреса не дает нам публичный ключ, и не дает нам возможности проверить подпись!
Таким образом, вместо этого выход транзакции говорит нам: «этот выход транзакции может быть потрачен публичным ключом, который хешируется, а также подписью владельца этого публичного ключа».
Теперь, что происходит с этим скриптом?
Кто его запускает, и как именно эта последовательность инструкций обеспечивает соблюдение вышеуказанного утверждения?
Секрет в том, что входы также содержат скрипты вместо просто подписей.
Чтобы проверить, что новая транзакция правильно потребляет выход предыдущей транзакции, мы объединяем входной скрипт новой транзакции и выходной скрипт предыдущей транзакции.
Мы просто соединяем их вместе, и полученный скрипт должен успешно выполниться, чтобы новая транзакция была действительной.
Эти два скрипта называются scriptPubKey и scriptSig, потому что в простейшем случае выходной скрипт просто указывает хэшированный публичный ключ или адрес, который может потребить этот выход транзакции, а входной скрипт следующей транзакции указывает подпись с этим публичным ключом.
Bitcoin язык скриптов был создан специально для биткойнов и называется просто «Скрипт».
Он имеет много общего с языком под названием Forth, который является старым, простым, основанным на стеках языком программирования.
Но вам не нужно изучать Форт, чтобы понимать скрипты биткойнов.
Язык Script был создан, чтобы иметь что-то простое и компактное, но с собственной поддержкой криптографических операций.
Поэтому в нем существуют специальные инструкции для вычисления хеш-функций, а также для вычисления и проверки подписей.
Язык Script основан на стеках.
Это означает, что каждая инструкция выполняется ровно один раз, линейно.
В частности, в языке Script биткойнов нет циклов.
Таким образом, количество инструкций в скрипте дает нам верхнюю оценку того, сколько времени потребуется для запуска скрипта и сколько памяти он может использовать.
Этот язык не имеет возможности вычислять произвольно мощные функции.
И по замыслу, именно майнеры должны запускать эти скрипты, которые предоставляются произвольными участниками сети.
Поэтому мы не хотим дать этим произвольным участникам возможность представить сценарий, который может иметь бесконечный цикл.
Таким образом, чтобы проверить, правильно ли новая транзакция потребляет выход предыдущей транзакции, мы создаем комбинированный скрипт, добавляя скрипт scriptPubKey предыдущей транзакции снизу к скрипту scriptSig новой транзакции.
Обратите внимание, что
Мы используем это обозначение, чтобы указать, что мы позже проверим, что это значение равно хешу публичного ключа, который предоставлен во входном скрипте.
Есть только два возможных результата при выполнении скрипта биткойнов.
Он либо успешно выполняется без ошибок, и в этом случае транзакция действительна.
Или, если во время выполнения скрипта есть какая-либо ошибка, тогда вся транзакция будет недействительной и не должна приниматься в цепочку блоков.
Язык скриптов биткойнов очень маленький.
В нем есть только 256 инструкций, и каждая из них представлена одним байтом.
Байт состоит из восьми бит. Используя один байт, можно закодировать один символ из 256 возможных (256 = 2 в 8 степени). Таким образом, один байт равен одному символу, то есть 8 битам.
Из этих 256 инструкций, 15 в настоящее время отключены, и 75 зарезервированы.
Зарезервированные инструкции еще не получили никакого специального значения.
Многие из основных инструкций – это те, которые вы ожидаете в любом языке программирования.
Там есть базовая арифметика, базовая логика, такая как ‘if’ и ‘then, выброс ошибки, возврат return.
Наконец, существуют криптографические инструкции, которые включают хеш-функции, инструкции для проверки подписи, а также специальную и важную инструкцию CHECKMULTISIG, которая позволяет проверять несколько подписей в одной инструкции.
Для инструкции CHECKMULTISIG требуется указать n открытых ключей и параметр t как пороговое значение.
Чтобы эта инструкция выполнялась корректно, должно быть не менее t подписей от t из n этих открытых ключей, которые действительны. В этой инструкции мы можем определить компактным образом, что t из n указанных открытых ключей должны дать правильные подписи, чтобы транзакция была действительной.
Позже мы рассмотрим несколько примеров того, как используются мультиподписи.
Кстати, существует ошибка в реализации мультиподписи, и она была там все время.
Инструкция CHECKMULTISIG выталкивает значение дополнительных данных из стека и игнорирует его.
Это всего лишь причуда языка биткойнов, и с этим приходится иметь дело, добавляя в стек дополнительную фиктивную переменную.
Ошибка была в первоначальной реализации, и затраты на ее исправление намного выше, чем причиненный ущерб, как мы увидим позже.
На данный момент эта ошибка считается просто особенностью биткойна.
Чтобы выполнить скрипт на стековом языке программирования, все, что нам понадобится, это стек, в который мы можем вносить данные и из которого можем извлекать данные.
Нам не нужна никакая дополнительная память или переменные.
Это делает скрипт простым в вычислении.
В скрипте существует два типа инструкций: инструкции данных и коды операций или опкоды.
Когда в скрипте появляется инструкция данных, эти данные просто вставляются в верхнюю часть стека.
С другой стороны, опкоды выполняют некоторую функцию, часто беря данные, находящиеся вверху стека, как входные данные.
Теперь давайте посмотрим, как выполняется Bitcoin скрипт.
Здесь мы показываем состояние стека после каждой инструкции.
Первые две инструкции в этом скрипте – это инструкции данных – подпись и публичный ключ этой подписи.
Они были указаны в элементе scriptSig или входном скрипте.
Как мы уже сказали, когда мы видим инструкцию данных, мы просто вносим данные в стек.
Дальше идет скрипт scriptPubKey.
Здесь сначала у нас есть команда дублирования OP_DUP, поэтому мы просто вносим копию публичного ключа в верхнюю часть стека.
Следующей инструкцией является OP_HASH160, в которой говорится, что нужно вытолкнуть из стека верхнее значение, вычислить его криптографический хеш и внести результат в верхнюю часть стека.
Когда эта команда завершит выполнение, мы заменим публичный ключ на вершине стека его хешем.
Здесь речь идет о публичном ключе текущего владельца биткойнов.
Затем мы вносим в стек хэш публичного ключа, который был указан в предыдущей транзакции как получатель монет и который должен использоваться для создания подписи, чтобы потратить полученные монеты.
Таким образом, на данный момент в верхней части стека есть два значения.
Существует хэш публичного ключа, который был указан в выходном скрипте, и хэш публичного ключа, который используется при трате монет и который указан во входном скрипте.
На этом этапе мы запускаем команду EQUALVERIFY, которая проверит, что эти два значения в верхней части стека равны.
Если это не так, произойдет ошибка, и скрипт прекратит выполнение.
В нашем примере мы будем считать, что они равны, то есть получатель монет использовал правильный публичный ключ.
Эта инструкция потребляет те два элемента данных, которые находятся в верхней части стека.
И теперь стек содержит два элемента – подпись и публичный ключ, который использовался для этой подписи.
Мы уже проверили, что этот публичный ключ является публичным ключом, который требуется, и теперь мы должны проверить, действительна ли подпись.
Это отличный пример того, как язык скриптов Bitcoin построен с учетом криптографии.
Несмотря на то, что это довольно простой язык с точки зрения логики, в нем есть некоторые довольно сильные инструкции, такие как инструкция «OP_CHECKSIG».
Эта инструкция выталкивает эти два значения из стека и выполняет всю проверку подписи за один раз.
Но чего это подпись?
Какой был вход функции подписи?
Оказывается, есть только одна вещь, которую вы можете подписать в биткойн – это целая транзакция.
Таким образом, инструкция «CHECKSIG» выталкивает из стека два значения, открытый ключ и подпись, и проверяет, является ли эта подпись валидной для всей транзакции, используя этот публичный ключ.
Теперь мы выполнили каждую инструкцию в скрипте, и в стеке ничего не осталось.
Если ошибок не было, выход этого скрипта будет просто true, указывая, что транзакция действительна.
Теоретически, скрипт позволяет нам в каком-то смысле указать произвольные условия, которые должны быть выполнены для того, чтобы потратить монеты.
Но на сегодняшний день эта гибкость практически не используется.
Если мы посмотрим на скрипты, которые на самом деле были использованы в истории Биткойна, подавляющее большинство, 99,9 %, – это точно такой же скрипт pay-to-public-key-hash, который мы использовали в нашем примере.
Как мы видели, этот скрипт pay-to-public-key-hash просто указывает один публичный ключ, вернее его хэш, и требует подписи для этого публичного ключа, чтобы потратить монеты.
Однако существуют несколько других инструкций, которые действительно полезны.
Иногда используется специальный тип скрипта под названием «Pay-to-Script-Hash», который обрабатывает мультиподписи MULTISIG и который мы обсудим позже.
Вообще говоря, не существует большого разнообразия используемых скриптов.
Это связано с тем, что узлы биткойнов по умолчанию имеют белый список стандартных скриптов, и они отказываются принимать скрипты, отсутствующие в списке.
Это не означает, что эти другие скрипты нельзя использовать вообще; это просто усложняет их использование.
На самом деле это различие – это очень тонкая вещь, к которой мы вернемся, когда мы будем говорить об одноранговой сети Bitcoin.
Далее рассмотрим несколько видов стандартных скриптов.
Proof of burn доказательство сжигания – это скрипт, в котором биткойны никогда не могут быть потрачены.
Отправка монет в скрипт с доказательством сжигания устанавливает, что они уничтожены, так как нет никакой возможности для их расходования.
Одно из использований доказательства сжигания заключается в том, чтобы загрузить альтернативу биткойну, заставив людей уничтожить биткойн, чтобы получить монеты в новой системе.
Мы обсудим это более подробно позже.
Доказательство сжигания довольно просто реализовать: опкод OP_RETURN выбрасывает ошибку и маркирует транзакцию как недействительную.