В вопросах производительности блокчейна девять из десяти сразу думают про TPS. Остальные, возможно, смотрят на задержки. Но если про Dusk — откройте его whitepaper и внимательно разберите: там есть вещь, за которой стоит следить даже больше, чем за скоростью транзакций — это то, как узлы «разговаривают» между собой.
Впрочем, с «хлебом» вроде бы все нормально — BTC просел не так уж сильно!
Я так говорю не потому, что TPS не важен, а потому что «считать быстро» и «передавать быстро» — это совершенно разные вещи. Если ваш исполнительный слой работает как часы, а дизайн консенсуса продуман до мелочей, но сообщения в сети узлов застревают — предложение не доходит до валидаторов, а результаты валидации не возвращаются в комитет по ratification — тогда весь трехэтапный процесс будет просто ждать. Блоки приходят с опозданием на пару секунд: в легком случае это ухудшает пользовательский опыт, в тяжелом — разные узлы видят разные кандидаты на блок, и доля stale blocks начинает расти как на дрожжах.
Dusk выбрал путь Kadcast. Это не тот «Gossip»-подход, где «увидел — переслал всем», а структурированная система покрытия на базе Kademlia DHT: расстояние между ID узлов по XOR определяет маршрутизацию, а сообщения разворачиваются по слоям, как дерево. Звучит по-научному, правда? Но суть в одной фразе: каждое сообщение идет только по нужному маршруту — не по «обходным» дорогам.
В whitepaper цитируется исследование: Kadcast по сравнению с Gossip позволяет сэкономить 25–50% пропускной способности. Например, раньше уходило 100 единиц bandwidth, а теперь примерно 50–75. Но эту цифру нельзя напрямую переводить как «стоимость узлов уменьшится вдвое». Конфигурации машин не меняются, вычисления при доказательствах не меняются, затраты на хранение не меняются — меняется только стоимость передачи на сетевом уровне. Однако для людей, которые запускают ноды: что означает «получить вдвое меньше bandwidth»? Это означает, что при тех же условиях по сети можно подключать больше узлов, или что при том же масштабе системы сложнее «упереться» в горлышко из-за расходов на bandwidth.
Есть один нюанс, который довольно наглядно это показывает. В документации по нодам 9000/udp помечен как необходимый порт для Kadcast: Provisioner должен иметь возможность участвовать в консенсусе, а значит этот канал должен быть достижим. 8080/tcp, наоборот, опциональный — он нужен только если требуется endpoint для запросов. Другими словами, Kadcast — это не «декор» с архитектурной схемы: он буквально ставит порог, могут ли узлы вообще участвовать в консенсусе.
Те, кто знаком с P2P-вещанием в BTC, знают: то, как сообщения проходят через сеть узлов, никогда не было пустяком. @Dusk $DUSK #dusk
Впрочем, с «хлебом» вроде бы все нормально — BTC просел не так уж сильно!
Я так говорю не потому, что TPS не важен, а потому что «считать быстро» и «передавать быстро» — это совершенно разные вещи. Если ваш исполнительный слой работает как часы, а дизайн консенсуса продуман до мелочей, но сообщения в сети узлов застревают — предложение не доходит до валидаторов, а результаты валидации не возвращаются в комитет по ratification — тогда весь трехэтапный процесс будет просто ждать. Блоки приходят с опозданием на пару секунд: в легком случае это ухудшает пользовательский опыт, в тяжелом — разные узлы видят разные кандидаты на блок, и доля stale blocks начинает расти как на дрожжах.
Dusk выбрал путь Kadcast. Это не тот «Gossip»-подход, где «увидел — переслал всем», а структурированная система покрытия на базе Kademlia DHT: расстояние между ID узлов по XOR определяет маршрутизацию, а сообщения разворачиваются по слоям, как дерево. Звучит по-научному, правда? Но суть в одной фразе: каждое сообщение идет только по нужному маршруту — не по «обходным» дорогам.
В whitepaper цитируется исследование: Kadcast по сравнению с Gossip позволяет сэкономить 25–50% пропускной способности. Например, раньше уходило 100 единиц bandwidth, а теперь примерно 50–75. Но эту цифру нельзя напрямую переводить как «стоимость узлов уменьшится вдвое». Конфигурации машин не меняются, вычисления при доказательствах не меняются, затраты на хранение не меняются — меняется только стоимость передачи на сетевом уровне. Однако для людей, которые запускают ноды: что означает «получить вдвое меньше bandwidth»? Это означает, что при тех же условиях по сети можно подключать больше узлов, или что при том же масштабе системы сложнее «упереться» в горлышко из-за расходов на bandwidth.
Есть один нюанс, который довольно наглядно это показывает. В документации по нодам 9000/udp помечен как необходимый порт для Kadcast: Provisioner должен иметь возможность участвовать в консенсусе, а значит этот канал должен быть достижим. 8080/tcp, наоборот, опциональный — он нужен только если требуется endpoint для запросов. Другими словами, Kadcast — это не «декор» с архитектурной схемы: он буквально ставит порог, могут ли узлы вообще участвовать в консенсусе.
Те, кто знаком с P2P-вещанием в BTC, знают: то, как сообщения проходят через сеть узлов, никогда не было пустяком. @Dusk $DUSK #dusk