Инструкция по настройке узла FIBRE

Эта база еще не обновлялась для последней версии с поддержкой SegWit, а базируется на версии Bitcoin Core, непосредственно предшествовавшей ей. Следует отметить, что для нее предусмотрена отдельная лицензия, отличающаяся от лицензии на остальную часть Bitcoin Core, с гораздо большими ограничениями.

Чтобы запустить эту базу, запустите Bitcoin Core как обычно, используя версию FIBRE с github (добавлена зависимость от Yasm для SHA256 на базе ASM). Добавьте параметр -udpport в командную строку или файл bitcoin.conf и задайте в качестве значения нефильтруемый UDP-порт, через который будет осуществляться обмен данными. Для каждого пира добавьте параметр -trustedudpnode или -addudpnode в командную строку или файл bitcoin.conf, либо добавьте их во время работы, используя RPC-команду addudpnode.

По умолчанию скорость исходящего трафика при передаче фиксирована и составляет 1 Гбит/с (несколько МБ на блок), поэтому расширение обычно запускается в сети, которая способна поддерживать такую скорость. В случае более медленных сетей можно соответствующим образом скорректировать значение параметра «target_bytes_per_sec» в src/ udpnet.cpp. Конечно же, следует иметь в виду, что если время задержки между двумя пирами примерно совпадает со временем, необходимым для передачи нескольких сотен кБ (то есть при очень узкополосном канале связи), скорость передачи может быть повышена за счет применения регулярных компактных блоков.

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

Параметры настройки узла

Способы ретрансляции пакетов между «доверенными узлами» и «недоверенными узлами» различаются. В силу характера FEC-кодирования нельзя узнать, являются ли отдельные пакеты частью легитимного блока (или частью какого-либо блока вообще), поэтому их ретрансляция другим пирам до восстановления этого блока приведет не только к бесполезному расходованию пропускной способности нашего канала (возможно, в то время, когда требуется ретранслировать легитимный блок), но и может сорвать восстановление блока. При этом в случае сетей с множеством узлов по всему миру целесообразно, чтобы серверы доверяли друг другу. В таких сетях пакеты от «доверенных узлов» мгновенно ретранслируются всем остальным пирам, благодаря чему затраты при добавлении дополнительных узлов практически не увеличиваются.

Кодовая база FIBRE полностью протестирована при работе с протоколом IPv6, а также демонстрирует хорошие результаты при подключении через NAT. Так как оба пира добавляют друг друга в качестве UDP-пиров, используя свои внешние IP-адреса, большинство NAT-маршрутизаторов автоматически вносят необходимые записи в таблицу NAT, а пакеты проходят обычным способом (применимы очевидные оговорки в отношении использования технологии FIBRE в низкоскоростных каналах связи).

Как узнать, что это работает

Регистрация в кодовой базе FIBRE осуществляется через стандартный файл Bitcoin Core debug.log. При использовании команд -debug=bench и -debug=udpnet генерируется ряд дополнительных регистрационных записей. Регистрационная запись для ретрансляции блока может иметь следующий вид (с комментариями в конце строк по тому, что они представляют):

# FEC notice that something was decoded (-debug=fec):
2016-06-27 01:25:37.934908 FEC: Decoding complete
# Internal timings in the first InitData (-debug=bench):
2016-06-27 01:25:37.935600 PartiallyDownloadedBlock::InitData took 0.004304 0.077074 0.244742 ms
# Internal timings in the second InitData, including the first InitData (-debug=bench):
2016-06-27 01:25:37.938483 PartiallyDownloadedChunkBlock::InitData took 0.414497 0.224764 0.137372 2.433110 ms
# When the final packet of the block header (the compact block cmpctblock message, with some additional data) is received and processed, you'll see something like (the timings are only present with -debug=bench)
2016-06-27 01:25:37.938563 UDP: Got full header and shorttxids from [2604:180:2::XXXX]:8282 in 0.000588 0.182621 3.282659 ms
# With -debug=bench, individual packets that take longer than 1ms to process will generate a debug print:
2016-06-27 01:25:37.938611 UDP: Packet took 3.705872 ms to process
# On the next packet, if we couldn't reconstruct the entire block from mempool, we initialize the FEC decoder, with as much as we can from mempool:
2016-06-27 01:25:37.940387 UDP: Initialized block 0000000000000000051a6e67f907167a3c452b7b32351f4d8c50f36e3d793028 with 639/975 mempool-provided chunks
2016-06-27 01:25:37.940496 UDP: Packet took 1.245908 ms to process
2016-06-27 01:25:37.948609 UDP: Packet took 1.035811 ms to process
2016-06-27 01:25:37.970034 FEC: Decoding complete
# Internal timings in the block-filler (-debug=bench):
2016-06-27 01:25:37.978776 PartiallyDownloadedChunkBlock::GetBlock took 5.851342 2.653402 ms
# When we've received all the block data, after some processing and handing it off to a background thread to process it, we print some decoding stats (-debug=bench):
# Note that the time here is critical: it is the time from when the first packet about this block was received until this print. This time puts the first packet receive at 2016-06-27 01:25:37.932538
# The two chunk counts here and in the per-peer stats represent the number of chunks (packets) which we used to decode the block (non-duplicate chunks sent to the FEC engine)
# Thus, only the second chunk counts packets we received containing chunks which we generated from mempool, had already received from another peer, or were a part of the header after we had already processed the header
2016-06-27 01:25:37.978911 UDP: Block 0000000000000000051a6e67f907167a3c452b7b32351f4d8c50f36e3d793028 reconstructed from [2604:180:2::XXXX]:8282 with 475 chunks in 46.373000 ms (531 recvd from 2 peers)
2016-06-27 01:25:37.978970 UDP:    401/451 used from [2604:180:2::XXXX]:8282
2016-06-27 01:25:37.979015 UDP:    74/80 used from [2604:180:3::3845]:8282
2016-06-27 01:25:37.979055 UDP: Packet took 9.321480 ms to process
# After we have done SPV validation of the block, we build the FEC chunks we did not already have to send them off to our other peers (the timing and first print are only present with -debug=bench)
2016-06-27 01:25:37.982941 UDP: Building FEC chunks from decoded block
2016-06-27 01:25:37.990111 UDP: Built all FEC chunks for block 0000000000000000051a6e67f907167a3c452b7b32351f4d8c50f36e3d793028 in 7.137531 ms
# For the purposes of the stats page, the encoded block size is printed with -debug=bench
2016-06-27 01:25:37.990355 UDP: Block 0000000000000000051a6e67f907167a3c452b7b32351f4d8c50f36e3d793028 had serialized size 998162
2016-06-27 01:25:37.990584 UDP: Packet took 7.630107 ms to process
# Standard AcceptBlock -debug=bench content follows:
2016-06-27 01:25:37.991760   - Load block from disk: 0.00ms [5.24s]
2016-06-27 01:25:37.991816     - Sanity checks: 0.00ms [5.07s]
2016-06-27 01:25:37.991902     - Fork checks: 0.08ms [0.18s]
2016-06-27 01:25:38.004593 UDP: Packet took 2.023104 ms to process
2016-06-27 01:25:38.208795 UDP: Packet took 1.142253 ms to process
2016-06-27 01:25:38.344671       - Connect 694 transactions: 352.74ms (0.508ms/tx, 0.064ms/txin) [225.27s]
2016-06-27 01:25:38.351640     - Verify 5501 txins: 359.72ms (0.065ms/txin) [295.98s]
2016-06-27 01:25:38.357546     - Index writing: 5.91ms [3.02s]
2016-06-27 01:25:38.357673     - Callbacks: 0.14ms [0.06s]
2016-06-27 01:25:38.357837   - Connect total: 366.07ms [304.59s]
2016-06-27 01:25:38.368921   - Flush: 10.93ms [4.79s]
2016-06-27 01:25:38.369182   - Writing chainstate: 0.42ms [31.94s]
2016-06-27 01:25:38.384789 UpdateTip: new best=0000000000000000051a6e67f907167a3c452b7b32351f4d8c50f36e3d793028 height=418141 version=0x20000001 log2_work=84.895644 tx=138736070 date='2016-06-27 01:25:03' progress=1.000000 cache=74.1MiB(37843tx) warning='4 of last 100 blocks have unexpected version'
2016-06-27 01:25:38.385034   - Connect postprocess: 15.86ms [2.85s]
2016-06-27 01:25:38.385090 - Connect block: 393.28ms [349.41s]
# This line might be duplicated if the block was also provided by a non-UDP peer (in this case the relay network client):
2016-06-27 01:25:38.385174 UDP: Block 0000000000000000051a6e67f907167a3c452b7b32351f4d8c50f36e3d793028 had serialized size 998162

Есть код для построения страницы статистики, аналогичной той, что отображается на странице статистике, который при определенных усилиях можно сделать общим. Если кому-либо интересно, свяжитесь со мной. При анализе времени имейте в виду, что время тактовых генераторов на большинстве хостов в сети Интернет может различаться на сотни миллисекунд из-за неспособности NTP справляться с асимметрией путей и рассинхронизацией вышестоящих тактовых генераторов. В случае достоверно известной симметрии путей и работы на физическом оборудовании настоятельно рекомендуется использовать параметр NTP «peer» и контролировать статистику синхронизации NTP, чтобы добиться улучшения тактовой синхронизации.

Настройка серверов

Выбор сервера

Наиболее важным этапом настройки сети ретрансляции после подготовки эффективного программного стека ретрансляции является выбор серверов, на которых будут работать ретрансляционные узлы. При правильном выборе серверов нет необходимости тратить примерно $50-200/месяц или больше на узлах, хотя если вы ленивы и у вас есть лишние деньги, можно пропустить большую часть данного раздела и позвонить своему местному представителю NTT/Sprint/PCCW и т.п.

Общие замечания относительно хостинга

Поскольку FIBRE является расширением Bitcoin Core, основные требования для запуска Bitcoin Core должны выполняться независимо от выбранного хоста. Разумеется, если ваша система размещена на дешевой площадке ARM, ожидать выдающихся характеристик не приходится, и использование технологии быстрой ретрансляции будет выглядеть странно.

Как правило, чтобы увидеть выигрыш от использования данной кодовой базы в протяженных линиях связи, достаточно любого хоста, на котором можно запустить Bitcoin Core и обрабатывать блоки за 1-2 с.

Поскольку данный сервис оптимизирован по задержкам, а не по общим характеристикам, настоятельно рекомендуется отключить подкачку, по крайней мере для процесса bitcoind. Также учтите, что в VPS зачастую происходят резкие увеличения задержки из-за затрат на виртуализацию, шума соседних узлов, частоты опроса сетевого интерфейса и неконтролируемого использования области подкачки. Даже если резкие увеличения задержки до 100 мс все-таки допустимы, правильный выбор VPS в большинстве случаев вполне оправдывает себя.

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

Общие проблемы при маршрутизации

Очевидно, одной из главных составляющих задержки передачи блоков является задержка передачи пакетов между хостами в сети. К сожалению, Интернет — это сложное хитросплетение неизвестных проблем маршрутизации, которые способны удваивать (или еще больше увеличивать) время передачи. Как правило, использование карты «Submarine Cable Map» и размещение серверов вблизи крупных точек выхода кабелей на берег позволяют добиться хороших результатов. При этом важно уделять внимание следующему:

• ОБАЗЯТЕЛЬНО РЕГУЛЯРНО проверяйте свои маршруты: единственным, что можно вынести за рамки данного раздела, является то, что пакеты чаще всего проходят по неожиданным маршрутам. Современная маршрутизация почти всегда осуществляется по принципу наименьших затрат, а не наименьшего времени, и даже те хосты, которые пытаются действовать более интеллектуально, зачастую терпят неудачу из-за отсутствия возможности контроля. Единственным способом не допустить, чтобы пакеты обходили земной шар дважды, прежде чем достичь адресата, служит сравнение времени задержки, указанного в журнале debug.log, со скоростью света между вашими двумя серверами (в идеальном случае следует ожидать скорости передачи чуть меньше, чем две скорости света).
• При использовании трассировки маршрута изучение DNS-записей обратного маршрута для хостов за пределами материковой части Китая обычно позволяет составить достоверную карту, напр., ae-0.r22.asbnva02.us.bb.gin.ntt.net находится в сети NTT ASBurn, шт. Вирджиния, США, pccw-gw-cr1.lax05.ipv4.pccwbtn.net — в сети PCCW в Лос-Анджелесе (код аэропорта LAX).
• Никогда не доверяйте трассировке маршрута! Хотя трассировка маршрута является невероятно полезным инструментом для выявления проблем маршрутизации, существует множество причин, по которым она довольно часто приводит к ошибочным результатам. Многие ссылки в сети Интернет находятся под IP-уровнем, то есть пакет, движущийся из Сингапура в Лондон, зачастую характеризуется только одним переходом (скачком) в трассировке несмотря на то, что сначала проходит через маршрутизаторы в Мумбае, Суэце, Марселе и Париже. Иногда в трассировках указываются даже абсолютно ложные маршруты, когда провайдеры направляют разные типы трафика через разные маршрутизаторы.
• На более мелких хостах довольно часто готовы изменить свою таблицу маршрутизации для вас! Если пакеты проходят до адресата по кольцевому маршруту, а на хосте имеются альтернативные пути, попробуйте обратиться в службу поддержки, чтобы изменить предпочтительный путь для требуемых диапазонов IP-адресов.
• Маршрутизация в Юго-Восточной Азии ужасна: в Юго-Восточной Азии и Австралии невероятно распространена маршрутизация пакетов через Лос-Анджелес с последующим возвратом через Тихий океан к адресату. Проверяйте свои маршруты, прежде чем переходить на серверы на длительный срок, и регулярно перепроверяйте их, так как маршруты постоянно меняются.
• Маршрутизация между Западной Европой и Юго-Восточной Азией по умолчанию почти всегда проходит через США, что вносит значительные задержки и вызывает потери при доставке пакетов. Существует два способа решения этой проблемы.
  1. Маршруты из Сингапура, как правило, нормальны: один из множества путей обычно проходит через Мумбай, Суэц и Марсель. К сожалению, такой маршрут является довольно медленным и в случае данных, отправляемых из Японии, может оказаться даже медленнее, чем обычный маршрут через США.
  2. Наиболее быстрым маршрутом из Японии/Китая и большей части Юго-Восточной Азии в Западную Европу безусловно является маршрут через кабельную сеть TEA. Однако найти два недорогих хоста в Европе и Юго-Восточной Азии, которые будут осуществлять маршрутизацию на его основе, удается крайне редко. При этом большинство хостов используют данный маршрут при маршрутизации до серверов в Сибири, входящих в сеть Ростелеком. Поскольку размещать целый биткоин-узел в Сибири малоцелесообразно, в файл src/udp-echo.cpp включена простая программа эхо-передачи UDP (с указаниями по сборке в начале файла). Ее можно сохранить на сервере и настроить на два FIBRE-узла, между которыми она будет передавать пакеты. Процесс фактического приобретения хостинга в Сибири оставим в качестве упражнения читателю (а если серьезно, когда уже в Bitcoin устранят эту проклятую проблему разрозненных финансовых сетей?)

Часто задаваемые вопросы

При наличии каких-либо вопросов, не рассмотренных в разделе «Часто задаваемые вопросы», обращайтесь к нам.

Будет ли когда-нибудь данный код внедрен в Bitcoin Core?
В настоящее время данный код не планируется внедрять в Bitcoin Core. Если кто-либо желает пойти дальше и провести его через этот процесс, я с огромным удовольствием перелицензирую его соответствующим образом.

Он работает?
Да! Существует демо-сеть, работающая вместе с основной сетью ретрансляции биткион-блоков. Вы можете изучить некоторые статистические данные этой сети на соответствующей странице статистики. Ее показатели на не особо идеальных VPS гарантированно находятся в диапазоне 100-300 мс. Я все еще раздумываю, открыть или нет данную сеть для общего доступа.