В тот раз, когда ночью пришло SMS-уведомление о узловой тревоге и взорвало мой телефон, первая мысль была: RPC подгружают слишком активно — пока в iftop не увидел, что везде сплошь kadcast-порты с внешними повторными передачами, и только тогда дошло. Та самая традиционная привычка gossip: «получил — сразу пересылай всем соседям» — при дрожании между зонами превращается в самовозбуждающий усилитель. Потом я сел разбирать исходники Rusk и белую книгу версии 2024, раздел 2, и стало ясно: Dusk заменил рассылку на Kadcast не как маленькую правку ради экономии полосы, а фактически переписал P2P-слой под адресацию в XOR-метрике Kademlia DHT. Каждый узел ведёт контакты по bucket’ам, а при пересылке выбирает только те peer’ы, чья XOR-дистанция возрастает, и делает каскадную передачу — не «заливает» всем интернет-диапазоном.
В исследовании, на которое ссылается белая книга, сказано, что по сравнению с gossip экономия составляет 25%–50% полосы и при «быстрых блоках» устаревание stale block уменьшается на 10%–30% — я воспринимал это как верхнюю границу в лаборатории. В реальной среде: provisioner-узлы периодически входят и выходят раз в несколько минут, RTT от Токио до Франкфурта «плывёт» в районе 40 мс, refresh bucket’ов завязан на периодический ping, а не на событийную реакцию. Поэтому таблицы маршрутизации на несколько секунд стареют — и сообщения вынужденно откатываются к широковещанию; сэкономленная полоса снова «выливается обратно» примерно наполовину.
На уровне консенсуса SA в три стадии (Generation → 1st/2nd Reduction → Agreement) сообщения голосования комитета целиком идут через Kadcast. Если на пересылающем пути при churn происходит разрыв, 2/3 BLS законных голосов не собираются — и дело уже не в том, экономится ли полоса, а в том, что раунд просто не проходит.
Сильная сторона Kadcast по сравнению с gossip в том, что он реально размазывает «точку происхождения» сообщений: он не опирается на прямых соседей, а ещё заметно усложняет связывание IP-источника с транзакциями, которые Phoenix экранирует. Цена — тяжёлая когнитивная нагрузка на отладку: mempool по умолчанию на 10000 записей, локальная политика истечения в Rusk по умолчанию 3 дня, а node-installer выставляет 30 минут — такое разбиение параметров для новичка в операционке превращается в набор «призрачных» багов.
Я думаю, стоит ли Kadcast своих денег: не по тому, что написано на бумаге про 25%–50%, а по трём жёстким проверкам. Во-первых, происходит ли сходимость bucket-обновлений в пределах 1 epoch после того, как узел отвалился. Во-вторых, на двойном разбиении зон голосование SA — получится ли собрать 67% кворума, опираясь на оставшуюся связную подграф-структуру. В-третьих, когда доля household-узлов с домашним провайдером у provisioner’а вырастет, не «провалится» ли хвостовая задержка. Если эти три условия проходят — это «структурная доставка», которая и должна быть у финансовой цепочки. Если нет — это просто красивая статья, которую потом приходится превращать в ловушки для операционщиков. #disk @Dusk $DUSK
В исследовании, на которое ссылается белая книга, сказано, что по сравнению с gossip экономия составляет 25%–50% полосы и при «быстрых блоках» устаревание stale block уменьшается на 10%–30% — я воспринимал это как верхнюю границу в лаборатории. В реальной среде: provisioner-узлы периодически входят и выходят раз в несколько минут, RTT от Токио до Франкфурта «плывёт» в районе 40 мс, refresh bucket’ов завязан на периодический ping, а не на событийную реакцию. Поэтому таблицы маршрутизации на несколько секунд стареют — и сообщения вынужденно откатываются к широковещанию; сэкономленная полоса снова «выливается обратно» примерно наполовину.
На уровне консенсуса SA в три стадии (Generation → 1st/2nd Reduction → Agreement) сообщения голосования комитета целиком идут через Kadcast. Если на пересылающем пути при churn происходит разрыв, 2/3 BLS законных голосов не собираются — и дело уже не в том, экономится ли полоса, а в том, что раунд просто не проходит.
Сильная сторона Kadcast по сравнению с gossip в том, что он реально размазывает «точку происхождения» сообщений: он не опирается на прямых соседей, а ещё заметно усложняет связывание IP-источника с транзакциями, которые Phoenix экранирует. Цена — тяжёлая когнитивная нагрузка на отладку: mempool по умолчанию на 10000 записей, локальная политика истечения в Rusk по умолчанию 3 дня, а node-installer выставляет 30 минут — такое разбиение параметров для новичка в операционке превращается в набор «призрачных» багов.
Я думаю, стоит ли Kadcast своих денег: не по тому, что написано на бумаге про 25%–50%, а по трём жёстким проверкам. Во-первых, происходит ли сходимость bucket-обновлений в пределах 1 epoch после того, как узел отвалился. Во-вторых, на двойном разбиении зон голосование SA — получится ли собрать 67% кворума, опираясь на оставшуюся связную подграф-структуру. В-третьих, когда доля household-узлов с домашним провайдером у provisioner’а вырастет, не «провалится» ли хвостовая задержка. Если эти три условия проходят — это «структурная доставка», которая и должна быть у финансовой цепочки. Если нет — это просто красивая статья, которую потом приходится превращать в ловушки для операционщиков. #disk @Dusk $DUSK