Как полные узлы получают информацию об устаревших блоках?

В Биткойне многие форки происходят, когда несколько майнеров добывают блоки одновременно. Тогда будет несколько блоков на той же высоте блока. Я просматривал руководство разработчика Bitcoin P2P по адресу https://developer.bitcoin.org/devguide/p2p_network.html .

Для распространения блоков ретранслятор отправляет сообщение «inv» своим одноранговым узлам. Одноранговые узлы запрашивают информацию о заголовке с помощью «getheaders», а ретранслятор отвечает сообщением «headers». Затем одноранговые узлы запрашивают информацию о блоке с помощью «getdata», а реле отвечает сообщением «блок».

В этом случае, как можно гарантировать, что одноранговые узлы получат несколько блоков одинаковой высоты? Ретранслятор может преднамеренно распространять сообщения «inv» и «headers» только для одного из блоков на той же высоте блока.

Как сверстники вообще могут знать, что произошел форк? Является ли получение информации о форке обязанностью ретранслятора или узла?

Ответы (1)

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

Итак, ожидается ли, что честный ретранслятор будет отправлять заголовки для обеих боковых цепей в сообщении «inv» и «headers»? Если несколько ретрансляторов отправляют сообщение «inv» узлу, будет ли узел отправлять сообщение «getheaders» каждому из них и сравнивать? Или узел отправит сообщение «getheaders» только одному из реле?
Предполагая, что хотя бы одно из реле является честным, какие проверки/механизмы использует узел, чтобы убедиться, что у него есть полное представление?
Нет такой вещи, как "полное представление". Каждый узел самостоятельно решает, какой блок он считает активным в данный момент, основываясь на имеющейся у него информации, и честные узлы будут передавать эту информацию своим партнерам. Узлы знают об устаревших блоках только потому, что во время их ретрансляции с точки зрения ретранслятора они не были устаревшими.
Спасибо, Питер :) Пожалуйста, дайте мне знать, если это правильно. Предположим, узел подключен к 8 узлам. Каждый из (честных) пиров, у которого есть новый блок, отправляет узлу сообщение «inv», «если пир считает, что этот блок будет частью основной цепочки». Узел отвечает сообщением «getheaders» «всем узлам», отправившим сообщение «inv». Всякий раз, когда одноранговый узел возвращает заголовок, узел запрашивает «getdata» у того же однорангового узла. Если узел не получает «блок» в течение 2 секунд, узел выбирает другого узла, отправившего такой же заголовок, и запрашивает у него «getdata».
Существует ли какая-либо (несколько) формальная спецификация необходимых предположений о распространении блоков Биткойн для работы? Например: что здесь означает «честный» сверстник? Какая информация требуется для распространения «честному» одноранговому узлу, а какая не является обязательной? Я пытаюсь интегрировать Биткойн с другим блокчейном. Знание формальных предположений очень важно.
Есть ли где-нибудь псевдокод того, как узлы работают при распространении блоков?
Не может быть формальной спецификации протокола Биткойн, потому что нет органа, который мог бы его принять. Правила сети определяются тем, что люди запускают, каким бы неудовлетворительным это ни было. Представьте, что мы пишем документ и каким-то образом благословляем его стать спецификацией протокола Биткойн. И теперь кто-то находит несоответствие между этим документом и программным обеспечением узла, реально работающим в сети. В отсутствие органа, который может заставить всех загружать новое программное обеспечение, единственный вывод состоит в том, что документ неверен и его необходимо исправить.
Есть конечно документация, где люди описывают правила (а не прописывают ) их. Некоторые из них можно найти на вики bitcoin.it (хотя многое там устарело) и на developer.bitcoin.org . Наиболее существенные изменения, влияющие на взаимодействие между различными реализациями, сначала предлагаются в виде BIP ( github.com/bitcoin/bips ), но гораздо более специфичная для клиента политика, такая как поведение реле, просто находится в соответствующих исходных кодах клиента.
Как полные узлы получают информацию об устаревших блоках?
СпросиСетьПолитика конфиденциальности1y, 0v