Bitcoin ядра 0,12 введен новый blocksonly установку. При установке на blocksonly узел ведет себя нормально, но отправляет и не получает беспроигрышные сделки; вместо этого он обрабатывает только полные блоки. Есть много приложений для узлов, где только подтвержденные сделки интересны, и узел, который по-прежнему проверяет и передает блоки по-прежнему способствует сети health-- менее, может быть, чем тот, который ретранслирует сделку: но он также потребляет меньше ресурсов, чтобы начать с. Дополнительный недостаток они не получают латентные преимущества кэширования подписи, так как каждая сделка, они видят совершенно новая для them-- это не то, что шахтеры должны использовать.

Насколько меньше пропускная способность делает blocksonly использовать на практике? Недавно я измерил это с помощью двух методов: После того, как на инструментирование узел для измерения пропускной способности, используемой для блоков против всего остального трафика, и снова несколько раз работает в обоих режимах на один день и мониторинга хостов всего использования сети; в обоих режимах эффективно давали тот же самый результат.

Сколько стоит экономия? Blocksonly уменьшается использование полосы пропускания этого узла с помощью 88%.

Существенное следствие этого является то, что любая схема для уменьшения полосы пропускания, которая работает с использованием уже ретранслируемые транзакций, чтобы уменьшить размер передаваемых блоков может _at MOST_ снизить общее использование полосы пропускания на 12% - при условии, что разностное сжатие достигнуто "бесконечности раза" улучшение. (Пример Закон Амдаля)

Почему реле использовать так много трафика? Основная причина этого заключается в том, потому что реле в Протоколе Bitcoin линейны по количеству сделок и числу сверстников. (Например, пропускная способность является функцией Сделок * пэров). Протокол использует «» эффективную схему INV --- но эта схема только снижает пропускную способность на постоянном множитель: Для каждой операции 36 байт длиной И посылаются (или полученными) от _every_ партнера, а полная транзакция посылается только один раз , Поскольку INV значительной часть размера сделки (например, 36 байт против 300) это означает, что каждые 10 или около того сверстников используют столько же пропускную способность, посылая полную транзакцию каждый раз, когда будет принимать.

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

В литературе имеются схемы весьма эффективной сплетен, но, похоже, компромисс между эффективностью и атаки устойчивостью (например, вы могли бы организовать узлы минимального остовного дерева с корнем в какой-то супер-узла (ов), который был бы оптимальным для повторено пропускная способность, но безумно ненадежны и уязвимы для атак). Даже простая схема INV уязвима для атаки: сверстники могут задержать операции по INVing, но затем передавать данные только после длительной задержки. С эфемерными анонимными коллегами, сопротивление атаки очень важно us--, но, к счастью, нам не нужно, чтобы достичь оптимальной эффективности.

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

Идея заключается в следующем, через случайные промежутки времени узел будет просить один из его коллег по эскизу из лучших X мегабайтами это mempool. В его запросе он также может означать, что он заинтересован только в сделках, чей предок feerate находится на некотором минимальном пороге, вместе с информацией о размере и feerate собственной mempool. Возвращенный эскиз является IBLT (см это Reddit пост для EL5 объяснения, что я создал для IBLT) некоторого размера расчетной отправителем на основе информации, отправленной запрашивающей. В отличие от эффективных предложений IBLT передачи блока, эта IBLT только передает транзакцию IDs--, что позволит избежать фрагментации накладные расходы, необходимые при отправке целые транзакции.

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

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

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

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

Большая часть научной литературы по IBLTs обеспокоены параметрам выборов, которые минимизируют асимптотическую над головой (размер IBLT против установленной разницы) для идеальной реконструкции множества. Эти параметры, однако, приводят к весьма высокой вероятности для полного отказа. В нашем случае, будучи в состоянии восстановить некоторые из множества прекрасно и потому, что mempools не должна быть полностью последовательными, и запросы к другим узлам помогут восстановить недостающие записи.

Аналогичная картина произошла (по той же причине) в изобретении фонтанные коды-- (Можно приблизительно думать о IBLT как двойственный кода фонтана). Для достижения больше шансов на реконструкцию, порядок узлов в графе (изоморфной числу хэша в IBLT) должен быть выбран случайным образом из специального распределения, вместо константы. Эффект, что смесь узлов заказов уменьшает вероятность того, что декодирование застревает, потому что это более вероятно, что будет иметь некоторые элементы, которые имеют оптимальную плотность. Для IBLT это можно сделать с помощью хэш установленного элемента, чтобы выбрать количество ковшей для этого набора так же, как она используется, чтобы выбрать, какие ведра используются.

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

В любом случае, эта схема позволит избежать квадратичного как поведения пропускной способности реле. Это позволило бы узлы торговли задержки выключения реле против накладных расходов, и это позволило бы изящный способ обработки наиболее приоритетных сделок первой. - операции с десяток или более блоков глубоко в mempool не собираются, чтобы получить добывали в ближайшее время, так что если они имеют более низкую реле задержки от примирил их менее часто, что нет большого вреда. Я считаю, что он может сделать это без существенного увеличения уязвимости к атаке. То же самое программное обеспечение, инфраструктура может также использоваться для полосы пропускания минимизируются передач блока для узлов, которые действительно имеют mempools (в противном случае blocksonly дает оптимальные выгоды пропускной способности), хотя задержка Минимизация намного лучше достигается с помощью таких методов, как эффективного реле блока Мэтты protocol--, так самого главного чтобы свести к минимуму задержки, чтобы свести к минимуму туда и обратно.