Введение в технологию Блокчейн

Консенсус без идентификации: использование цепочки блоков

Далее мы рассмотрим технические детали алгоритма согласования биткойнов.

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

Это еще одно отличие от традиционных распределенных консенсусных алгоритмов.

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

Технический термин для этого – атака Сибиллы.

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

Другая причина заключается в том, что псевдонимность по своей сути является целью Биткойна.

Напомню, что псевдонимность – это когда все транзакции между всеми адресами (кошельками) общедоступны, но нет данных о владельцах адресов. Однако личность владельца может быть установлена, если становится известна необходимая дополнительная информация.

Даже если бы было возможно или было легко установить идентификаторы для всех узлов или всех участников, мы бы не захотели этого делать.

Хотя Bitcoin не дает серьезных гарантий анонимности в том, что различные транзакции, которые вы делаете, часто могут быть связаны друг с другом, у него есть свойство, что никто не должен раскрывать свою реальную личность, такую как свое имя или IP-адрес, для участия в системе биткойн.

И это важное свойство и центральная особенность дизайна Биткойна.

Если бы узлы имели идентификаторы, дизайн был бы проще.

Для начала идентификаторы позволяли бы нам вводить в протокол инструкции формы: «Теперь узел с таким-то числовым идентификатором должен сделать такой-то шаг».

Без идентификаторов набор возможных инструкций более ограничен.

Но гораздо более серьезная причина для того, чтобы узлы имели идентификаторы – это для обеспечения безопасности.

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

По обоим этим причинам отсутствие идентичности создает трудности для консенсусного протокола в Биткойне.

Мы можем компенсировать отсутствие идентичности, сделав не строгую идентификацию, а более слабую.

Предположим, что есть возможность выбрать случайный узел в системе.

Хорошей мотивирующей аналогией для этого является лотерея.

То, что мы можем сделать в этом контексте, – это выдавать токены или билеты или что-то вроде этого.

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

Поэтому на данный момент сделаем предположение, что таким образом можно выбрать случайный узел из сети биткойнов.

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

Это означает, что противник не сможет увеличивать свою силу, создавая новые узлы.

Позже мы удалим эти предположения и подробно рассмотрим, как реализуются свойства, эквивалентные этим, в биткойне.

Это предположение о случайном выборе узла делает возможным то, что называется неявным консенсусом.

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

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

Нет никакого консенсусного алгоритма для выбора блока и нет никакого голосования.

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

Но что, если этот узел злонамеренный?

Для обработки этого есть процесс, но он неявный.

Другие узлы будут неявно принимать или отклонять этот блок.

Если они согласятся с этим блоком, они просигнализируют о своем решении, расширяя цепочку блоков, и включая принятый блок.

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

Напомним, что каждый следующий блок содержит хеш блока, который он расширяет.

Это технический механизм, который позволяет узлам сигнализировать, какой блок узел расширяет.

Таким образом, упрощенный консенсусный алгоритм биткойна состоит в следующем.

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

1. Новые транзакции передаются всем узлам.

2. Каждый узел собирает новые транзакции в блок

3. В каждом раунде случайный узел получает возможность транслировать свой блок.

4. Другие узлы принимают блок только в том случае, если все транзакции в нем действительны (все подписи валидны).

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

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

Для этого давайте рассмотрим, как вредоносный противник, которого мы назовем Алисой, может подорвать этот процесс.

Рассмотрим кражу биткойнов.

Может ли Алиса просто украсть биткойны, принадлежащие другому пользователю, по адресу, который она не контролирует?

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

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

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

Таким образом, до тех пор, пока основная криптография будет строгой и надежной, она не сможет просто украсть биткойны.

Теперь рассмотрим возможность атаки на отказ в обслуживании.

Скажем, Алисе сильно не нравится какой-то другой пользователь Боб.

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

Другими словами, она отказывает в сервисе Бобу.

К счастью, у Алисы в итоге ничего не получится, это будет не более чем незначительная досада.

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

Рассмотрим атаку двойной траты.

Алиса может попытаться запустить атаку двойной траты.

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

Скажем, сервис Боба позволяет загружать некоторые программы.

Вот как может работать атака с двойной тратой.

Алиса добавляет товар в свою корзину на веб-сайте Боба, и сервер запрашивает платеж.

Затем Алиса создает транзакцию биткойна со своего адреса Бобу и транслирует ее в сеть.

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

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

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

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

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

Заметьте, кстати, что здесь есть два разных типа хеш-указателей, что может запутать.

Во-первых, Блоки содержат хеш-указатель на предыдущий блок, который они расширяют.

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

Вернемся к тому, как Алиса может начать атаку двойной траты.

Последний блок был создан честным узлом и включает транзакцию, в которой Алиса платит Бобу за загрузку программного обеспечения.

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

Предположим, что следующий случайный узел, выбранный в следующем раунде протокола, контролируется Алисой.

Теперь, когда Алиса предложит следующий блок, она может предложить блок, который игнорирует блок, содержащий платеж Бобу, и вместо этого содержит указатель на предыдущий ему блок.

Кроме того, в блоке, который она предлагает, Алиса включает транзакцию, которая передает те самые монеты, которые она посылала Бобу, на другой адрес, который она же сама контролирует.

Это классический шаблон двойной траты.

Поскольку две транзакции делают проводку одних и тех же монет, только одна из них может быть включена в цепочку блоков.

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

И как мы узнаем, удастся ли эта попытка двойной траты или нет?

Это зависит от того, какой блок в конечном итоге будет в конце консенсусной цепочкой – тот, который связан с транзакцией Алиса → Боб или с транзакцией Алиса → Алиса.

Что определяет, какой блок будет включен?

Честные узлы следуют политике расширения самой длинной действующей ветви, поэтому какая ветвь будет расширяться?

Правильного ответа нет!

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

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

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

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

С технологической точки зрения, однако, эти две транзакции полностью идентичны, и оба блока одинаково действительны.

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

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

Но это не строгое правило.

И в любом случае, из-за латентности сети, легко может оказаться, что блок, о котором сначала услышал узел, на самом деле является блоком, который был создан позже.

Таким образом, существует некоторый шанс, что следующий узел, который может предложить блок, расширит блок, содержащий двойную трату.

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

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

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

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

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

Давайте теперь пересмотрим всю эту ситуацию с точки зрения Боба-торговца.

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

Когда Алиса транслирует транзакцию, которая представляет ее платеж Бобу, Боб слушает в сети и слышит об этой транзакции еще до создания следующего блока.

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

Это называется транзакцией с нулевым подтверждением.

Это приводит к появлению еще большей вероятности атаки двойной траты, чем было описано до этого.

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

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

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

Если Боб увидит, что Алиса успешно запускает атаку двойной траты, он поймет, что блок, содержащий оплату Алисы для него, остался сиротой.

Он должен отказаться от транзакции и не позволить Алисе загрузить программное обеспечение.

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

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

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

Шанс, что более короткая ветка с двойной тратой догонит длинную ветку, становится все более незначительным, поскольку она растет дольше, чем любая другая ветвь.

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

Фактически, вероятность двойного расходования экспоненциально уменьшается с количеством подтверждений.

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

Наиболее распространенная практика, используемая в экосистеме биткойнов, – это ждать шесть подтверждений.

В числе шесть нет ничего особенного.

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

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

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

С другой стороны, защита от двойных трат осуществляется исключительно и только на основе консенсуса.

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

Но именно консенсус определяет, какая из них окажется в долгосрочной консенсусной цепочке.

И, наконец, вы никогда на 100 процентов не можете быть уверены, что транзакция, в которой вы заинтересованы, находится в консенсусной ветке.

Но экспоненциальная вероятностная гарантия этого довольно хорошая.

После шести транзакций практически нет шансов, что вы ошибетесь.

Стимулы и доказательства работы

Теперь у нас есть базовое представление консенсусного алгоритма Биткойна и представление, почему мы считаем, что это безопасно.

Но вспомним, что децентрализация Боткойна – это с одной стороны технический механизм, а с другой стороны умная стимуляция.

До сих пор мы в основном рассматривали технический механизм.

Теперь давайте поговорим о стимулах, которые применяются в Биткойне.

Также вспомним, что мы сделали предположение, что мы можем выбрать случайный узел и, возможно, более проблематично, что, по крайней мере, в 50 процентов случаев, при этом мы выберем честный узел.

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

Тогда возникает вопрос: можем ли мы дать узлам стимул вести себя честно?

Рассмотрим снова попытку двойной траты после одного подтверждения.

Можем ли мы каким-то образом наказывать узел, который создал блок с транзакцией с двумя тратами?

Ответ – не совсем.

Как я говорил ранее, трудно понять, что является морально легитимной сделкой.

Но даже если бы мы это сделали, все равно трудно наказывать узлы, так как у них нет идентификаторов.

Поэтому вместо этого давайте подойдем с другой стороны и спросим, можем ли мы вознаградить каждый из узлов, которые создали блоки, которые в конечном итоге оказались в долгосрочной консенсусной цепочке?

И, опять же, поскольку эти узлы не раскрывают свою реальную идентичность, мы не можем отправить им наличные на их домашние адреса.

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

Вероятно, вы уже видите, к чему я иду.

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

Давайте на мгновение остановимся.

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

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

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

Как это делается?

В Биткойне есть два отдельных механизма стимулирования.

Первое стимулирование – это награда за блок.

Согласно правилам биткойна, узел, который создает блок, включает специальную транзакцию в этот блок.

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

Конечно, этот узел, как правило, выбирает адрес, принадлежащий самому себе.

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

На сегодняшний момент значение вознаграждения блока фиксировано на уровне 12.5 биткойнов.

Но на самом деле это вознаграждение делится пополам при добавлении каждых 210 000 блоков.

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

Сейчас мы находимся в третьем периоде.

В течение первых четырех лет существования Биткойна награда за блок составляла 50 биткойнов.

Теперь она равна 12.5 биткойнов.

Это имеет некоторые интересные последствия, которые мы увидим.

Возможно, будет интересно понять, почему вознаграждение в блоке стимулирует честное поведение.

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

Это не так!

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

Это ключевая идея этого механизма стимулирования.

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

Это первый механизм стимулирования Биткойна.

Я уже сказал, что каждые 210 000 блоков (или примерно четыре года) вознаграждение за блок сокращается вдвое.

На слайде наклон этой кривой постоянно уменьшается вдвое, пока не уменьшится до нуля в 2140 году.

Bitcoin построен таким образом, чтобы увеличивать количество средств в логарифмической прогрессии пока не будет достигнута цифра в 21 млн. биткойнов.

Важно отметить, что майнинг, это единственный способ создания новых биткойнов.

Не существует другого механизма генерации монет, и именно поэтому 21 млн – это окончательное и общее число (такие сейчас правила), сколько биткойнов может когда-либо быть.

Поэтому вознаграждение за создание нового блока закончится в 2140 году.

Означает ли это, что система остановит свою работу в 2140 году и станет небезопасной, потому что у узлов больше не будет стимула вести себя честно?

Не совсем.

Награда за блок является лишь первым из двух механизмов стимулирования в Биткойне.

Второй механизм стимулирования называется комиссией за транзакцию.

Создатель любой транзакция может выбрать комиссию или разницу между общим значением транзакционных выходов и общим значением транзакционных входов.

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

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

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

В определенной степени это уже сейчас происходит.

Но пока неясно, как будет развиваться система.

Это интересная область открытых исследований в Биткойне.

И по-прежнему остается несколько проблем с консенсусным механизмом, который мы описали.

Первой проблемой является предположение, что мы можем выбрать случайный узел.

Во-вторых, мы создали новую проблему, предоставив узлам стимулы для участия.

Система может стать нестабильной, так как стимулы создают среду, где каждый хочет запустить биткойн узел в надежде получить вознаграждение.

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

Оказывается, все эти проблемы связаны, и все они имеют решение, которое называется доказательством работы.

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