Одним из основных аргументов в пользу того, чтобы не увеличивать размер блока в Биткойне, является тот факт, что больший размер блока означает более медленное распространение.
Наиболее занимающий место раздел блока биткойнов — это данные транзакций. Предполагая, что большая часть узлов является полными узлами, в данных блока имеется большая избыточность.
Когда майнер успешно добывает блок, ему необходимо отправить его на другие узлы в сети. Многие из этих узлов уже обладают большей частью данных транзакций, включенных в блок.
Может быть, лучше отправлять хэш каждой транзакции вместо самих данных. Если принимающий узел не имеет этих данных, он может запросить их у передающего узла.
Это может уменьшить размер блока в 5-10 раз (в зависимости от размера хэша) и позволить значительно увеличить размер блока.
Меня беспокоит то, что в случае, когда у получателя нет всех транзакций, дополнительные запросы на их получение в конечном итоге займут больше времени, чем просто отправка их в первую очередь. Майнеры разбросаны по всему миру, но, скорее всего, они смогут платить за быстрые соединения, поэтому я ожидаю, что соединения между ними будут иметь высокую задержку и высокую пропускную способность. В таком случае лучше упреждающе отправить больший объем данных (быстро из-за высокой пропускной способности), чем рисковать запросом/ответом туда и обратно (медленно из-за высокой задержки).
Кроме того, майнеры довольно часто включают транзакции, которые они инициировали, или были отправлены им в частном порядке, или иным образом не транслировались в одноранговой сети. Подумайте о выплатах майнинг-пула, нестандартных транзакциях, транзакциях с низкой комиссией, которые майнер согласился «ускорить» и т. д. Поэтому я думаю, что этот дополнительный протокол запросов будет необходим чаще, чем нет.
Это может быть разумной оптимизацией для полных узлов, которые не являются майнерами и поэтому не нуждаются в срочном получении блока. Таким образом они могут сэкономить некоторую полосу пропускания. Но, с другой стороны, поскольку им не нужно срочно получать блок, мы не так сильно заботимся о них, и трудно оправдать серьезное изменение протокола p2p только ради этого.
Не уверен, как это не получило более полного ответа ранее.
Биткойн уже пару лет не отправляет полный блок в качестве основного метода распространения, см. BIP 152 . Отправляется заголовок блока, 6 байтов на транзакцию и транзакция coinbase. При желании могут быть отправлены дополнительные транзакции, о которых отправитель предсказал, что получатель не будет знать.
Очень короткий хэш возможен, потому что хэш отдельно передается каждым передающим узлом. Это делает невозможным для злоумышленника преднамеренное создание коллизий, и любые коллизии, которые случаются случайно, «маршрутизируются» при распространении по сети в силу того факта, что блоки просто передаются быстрее по ссылкам, где не было коллизии.
Поскольку это сообщение настолько маленькое, BIP152 может часто исключать одно обращение туда и обратно, не выполняя INV. Таким образом, тот факт, что для заполнения отсутствующих транзакций иногда требуется дополнительная передача туда и обратно, оставляет только то же количество операций туда и обратно, что и исходный протокол.
Существует также оптоволокно , которое безоговорочно сокращает передачу до 0,5 круговых обходов, но за счет потери значительной части полосы пропускания. Для быстрых ссылок это самое быстрое, что можно сделать.
Что касается безопасности и стабильности сети, вопрос не только в том, насколько медленным в среднем является распространение, но и в том, насколько медленным его может сделать майнер в первом случае. В среднем BIP152 отлично справляется со своей задачей, но на самом деле не улучшает худший случай. Кроме того, объем данных в блоке также контролирует объем данных за пределами блоков, в большинстве компактных блоков можно только уменьшить общую пропускную способность узла до наполовину по сравнению с исходной схемой.
Дизайн BIP152 был выбран как компромисс между многими факторами — задержкой, пропускной способностью, вычислительной нагрузкой, сложностью реализации. Волокно представляет собой другой компромисс (в пользу абсолютной минимальной задержки вместо меньшей пропускной способности). Мы знаем, как уменьшить размер блоков примерно до 500 байт, что требует значительно большей сложности реализации и вычислений, но не похоже, что для этого есть много причин по сравнению с важностью улучшения других областей протокола. Это вдвойне верно, потому что эти улучшения не помогают в худшем случае. Я считаю, что FIBER уже достигает очень близкой к наилучшей возможной производительности в худшем случае.