Комиссия за 1 DUSK, примерно 15 минут. Это официальная стоимость и время для переноса нативного DUSK с основной сети на BSC (BEP20-версия). Сам по себе этот показатель не особенно впечатляет, но подход к дизайну стоит взглянуть хотя бы один раз.

Механизм переноса — это «запирание + чеканка»: пользователи отправляют нативный DUSK в мостевой кошелёк в основной сети, а протокол после проверки этой блокировки в цепочке только затем запускает чеканку соответствующего количества BEP20 DUSK на стороне BSC. Нативный DUSK при этом всегда рассматривается как единственный источник реальной стоимости, а версия на BSC — лишь обёрточный актив. Недавно этот же режим открыли и для обратных операций: нативный DUSK и BEP20 DUSK теперь могут двигаться в обе стороны.

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

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

Фиксированная комиссия 1 DUSK плюс примерно 15 минут — не скажу, что это быстро. Но если это намеренно консервативный подход ради запаса безопасности, я скорее понимаю, почему так: учреждения, которые управляют межсетевыми активами, вряд ли будут считать скорость моста ключевым показателем. Гораздо важнее, чтобы управление подписной властью, стоящее за этим, выдерживало проверку.

Как вы думаете, при оценке надёжности межсетевого моста что стоит ставить в приоритет — аудит кода протокола или то, как управляются подписные права для запуска чеканки/разрешения?

#dusk $DUSK @Dusk