Я прослеживал, как Даск перемещает блоки по сети, ожидая привычную байку про «затопление» сплетнями. Вместо этого я наткнулся на нечто более узкое и намеренное.

Kadcast не «заливает». Он маршрутизирует. Используя структуру XOR-дистанций Кадемлии, каждый узел пересылает данные по детерминированным путям в конкретные бакеты (корзины) пиров, а не всем подряд. На этом обычно и останавливаются, рассказывая об эффективности.

Но у структурной маршрутизации есть очевидная слабость: если узел на пути уйдёт офлайн, сообщение просто умрёт на нём? Вот на этом я и замедлился. Kadcast не полагается на один путь на бакет — он использует параметр избыточности β, который выбирает несколько делегатов в каждом бакете, чтобы они получали и пересылали тот же самый фрагмент повторно. Потеряй одного — остальные всё равно донесут.

А ещё есть RaptorQ, встроенный как прямая коррекция ошибок: данные кодируются так, чтобы получатель мог восстановить исходное по неполным фрагментам, не дожидаясь, пока придут все пакеты целиком.

Так что устойчивость — это не столько про то, что узлы «держатся онлайн». Это про то, что протокол предполагает обратное и закладывает избыточность прямо в структуру маршрутов, а не в слепое затопление.

Заставляет задуматься, как β настраивают по мере роста валидаторных наборов: больше избыточности — больше расходов на полосу пропускания и меньше — на надёжность. Где Даск проводит эту черту в масштабе?

#dusk $DUSK @Dusk