Для обработки этого есть процесс, но он неявный.
Другие узлы будут неявно принимать или отклонять этот блок.
Если они согласятся с этим блоком, они просигнализируют о своем решении, расширяя цепочку блоков, и включая принятый блок.
Напротив, если они отклонят этот блок, они будут в дальнейшем расширять цепочку, игнорируя этот блок, и начиная с предыдущего блока в цепочке блоков.
Напомним, что каждый следующий блок содержит хеш блока, который он расширяет.
Это технический механизм, который позволяет узлам сигнализировать, какой блок узел расширяет.
Таким образом, упрощенный консенсусный алгоритм биткойна состоит в следующем.
Этот алгоритм упрощен в том, что он предполагает возможность выбора случайного узла таким образом, что делает этот выбор не уязвимым для атак Сибиллы.
1. Новые транзакции передаются всем узлам.
2. Каждый узел собирает новые транзакции в блок
3. В каждом раунде случайный узел получает возможность транслировать свой блок.
4. Другие узлы принимают блок только в том случае, если все транзакции в нем действительны (все подписи валидны).
5. Узлы выражают свое принятие блока, включая его хеш в следующем блоке, который они создают.
Давайте теперь попытаемся понять, почему этот консенсусный алгоритм работает.
Для этого давайте рассмотрим, как вредоносный противник, которого мы назовем Алисой, может подорвать этот процесс.
Рассмотрим кражу биткойнов.
Может ли Алиса просто украсть биткойны, принадлежащие другому пользователю, по адресу, который она не контролирует?
Нет. Даже если настанет очередь Алисы предложить следующий блок в цепочке, она не сможет украсть биткойны других пользователей.
Для этого потребуется, чтобы Алиса создала действительную транзакцию, которая делает проводку этой монеты.
Для этого нужно, чтобы Алиса подделала подписи владельцев, что она не может сделать, если используется безопасная схема цифровой подписи.
Таким образом, до тех пор, пока основная криптография будет строгой и надежной, она не сможет просто украсть биткойны.
Теперь рассмотрим возможность атаки на отказ в обслуживании.
Скажем, Алисе сильно не нравится какой-то другой пользователь Боб.
Поэтому Алиса может решить, что она не будет включать какие-либо транзакции, происходящие из адреса Боба, в любом блоке, который она предлагает, чтобы попасть в цепочку блоков.
Другими словами, она отказывает в сервисе Бобу.
К счастью, у Алисы в итоге ничего не получится, это будет не более чем незначительная досада.
Если транзакция Боба не будет включена в следующий блок, который предлагает Алиса, эта транзакция просто подождёт, пока честный узел не получит предложение предложить блок, а затем его транзакция попадет в этот блок.
Рассмотрим атаку двойной траты.
Алиса может попытаться запустить атаку двойной траты.
Чтобы понять, как это работает, предположим, что Алиса является клиентом какого-либо онлайн-продавца или веб-сайта, который ведет Боб, который предоставляет некоторые онлайн-услуги в обмен на оплату в биткойнах.
Скажем, сервис Боба позволяет загружать некоторые программы.
Вот как может работать атака с двойной тратой.
Алиса добавляет товар в свою корзину на веб-сайте Боба, и сервер запрашивает платеж.
Затем Алиса создает транзакцию биткойна со своего адреса Бобу и транслирует ее в сеть.
Предположим, что какой-то честный узел создает следующий блок и включает эту транзакцию в этот блок.
Теперь есть блок, который был создан честным узлом, который содержит транзакцию, которая представляет платеж от Алисы покупателю Бобу.
Напомним, что транзакция представляет собой структуру данных, содержащую подпись Алисы, инструкцию для оплаты открытому ключу Боба и хэш.
Этот хэш представляет собой указатель на предыдущую транзакцию, который Алиса получила перед этим и сейчас тратит.
Этот указатель должен ссылаться на транзакцию, которая была включена в какой-то предыдущий блок в консенсусной цепочке.
Заметьте, кстати, что здесь есть два разных типа хеш-указателей, что может запутать.
Во-первых, Блоки содержат хеш-указатель на предыдущий блок, который они расширяют.
И во-вторых, транзакции включают один или несколько хэш указателей на предыдущие транзакции, которые не являются потраченными.
Вернемся к тому, как Алиса может начать атаку двойной траты.
Последний блок был создан честным узлом и включает транзакцию, в которой Алиса платит Бобу за загрузку программного обеспечения.
Увидев эту транзакцию, включенную в цепочку блоков, Боб приходит к выводу, что Алиса заплатила ему и позволяет Алисе загрузить программное обеспечение.
Предположим, что следующий случайный узел, выбранный в следующем раунде протокола, контролируется Алисой.
Теперь, когда Алиса предложит следующий блок, она может предложить блок, который игнорирует блок, содержащий платеж Бобу, и вместо этого содержит указатель на предыдущий ему блок.
Кроме того, в блоке, который она предлагает, Алиса включает транзакцию, которая передает те самые монеты, которые она посылала Бобу, на другой адрес, который она же сама контролирует.
Это классический шаблон двойной траты.
Поскольку две транзакции делают проводку одних и тех же монет, только одна из них может быть включена в цепочку блоков.