#dusk $DUSK Сегодня я смотрел сетевой уровень документации @Dusk и изначально думал, что P2P-сети у блокчейнов почти одинаковые — рассылают транзакции, синхронизируют блоки, и особо вникать не во что. Но как только я увидел слово «Kadcast», стало понятно, что Dusk не пошёл по старому пути протокола Gossip.

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

Kadcast заменяет случайную рассылку структурированной overlay-сетью. Узлы не выбирают соседей случайно, а передают сообщения направленно по заранее организованной топологии. В официальной документации говорится, что это позволяет экономить от 25% до 50% пропускной способности по сравнению с традиционным Gossip-протоколом.

Как я понимаю, это решение обусловлено ограничениями: в финансовых сценариях подтверждение транзакций нельзя полагаться на случайность вроде «если разослать несколько раз, то рано или поздно дойдёт». Структурированная маршрутизация означает, что путь распространения сообщения более предсказуем, а задержка — лучше контролируема. Для финансовых рынков, где требуется детерминированное расчётное завершение, знать «примерно через сколько сообщение дойдёт» так же важно, как и то, что оно вообще дойдёт.

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

Смотря на сетевой уровень #dusk , я хочу видеть не только TPS и время генерации блока, но и реальные замеры экономии полосы пропускания и распределения задержек в основной сети при фактическом распределении узлов после запуска. Если нижний уровень DUSK работает стабильно, то и финансовые приложения сверху получат надёжную основу. #dusk @Dusk