#dusk $DUSK @Dusk
Я начал считать независимые маршруты в DuskEVM — и список быстро стал коротким. Документация DUSK направляет пользователей к одному RPC, одному обозревателю, одному мостовому шлюзу Web Wallet и к секвенсору в единственном числе.

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

Это важно для DUSK, потому что спрос на газ и ликвидность моста зависят от того, что пользователи доходят до исполнения, а не от того, что провайдеры продолжают завершать процесс «снизу». Конструкция распределяет расчёт; практический путь может концентрировать доступ через официальную инфраструктуру. Это разные вещи.

Большинство людей путают проверяемый расчёт с нейтральным доступом. Они не равны. Один и тот же тест должен распространяться на одноранговые кластеры, выпуски учётных данных Citadel и правило пополнения 90/10: десять провайдеров, размещённых вместе, — это не десять независимых доменов отказа.

Моя тихая обеспокоенность — отсутствие данных. Я не могу найти публичные доли трафика по RPC, медианные значения числа пиров, детали failover секвенсора или пороги управления мостом. Пока DUSK не сделает их доступными, децентрализация описывает слой расчётов увереннее, чем весь путь пользователя.