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

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

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

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

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

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

Тем не менее, нет необходимости, чтобы Боб слушал в сети; запуск узла для Боба не требуется для получения средств.

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

Что именно здесь означает, что узлы достигают консенсуса в сети Bitcoin?

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

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

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

Аналогичным образом, в биткойне мы принимаем консенсус на основе блокчейна.

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

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

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

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

Как именно узлы достигают консенсуса по блоку?

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

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

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

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

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

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

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

Этот подход имеет некоторое сходство с тем, как работает биткойн, но это не совсем так, как на самом деле работает биткоин.

С этим подходом существует ряд технических проблем.

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

Во-вторых, и особенно в контексте биткойнов, сеть крайне несовершенна.

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

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

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

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

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

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

Поэтому консенсусный протокол не может содержать инструкции в виде: «Узел, который отправил самое первое сообщение на шаге 1 протокола, должен выполнить нечто на шаге 2».

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

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

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

В качестве примера рассмотрим проблему византийских генералов.

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

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

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

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

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

Другой результат невозможности достичь консенсуса, известный под именами авторов, которые его впервые доказали, называется результатом невозможности Фишера-Линча-Патерсона.

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

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

Одним из наиболее известных среди этих протоколов является Paxos.

Paxos допускает определенные компромиссы.

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