#dusk $DUSK @Dusk Ранний взгляд на @dusk: первая реакция на самом деле довольно банальная — ещё один случай, когда «приватность + RWA + PoS» связывают в одну историю на L1. Но когда я всё-таки пошёл разбирать документацию и код Rusk, мне стало казаться, что этот вывод занижает масштаб: Dusk больше похож на то, как заново собирают «систему расчётов», а не просто создают ещё одну цепочку.
Моя главная ошибка раньше — считать Phoenix «функцией приватности» Dusk. По исходникам и модели транзакций видно, что это на самом деле другая форма представления активов: Moonlight — это публичная модель учётных записей, а Phoenix разбивает баланс на расходуемые UTXO и использует доказательства с нулевым разглашением, чтобы подтвердить «я имею право потратить эти деньги и не трачу их повторно», не раскрывая при этом все детали транзакции. И самое важное: в итоге обе они сводятся к Transfer contract. То есть приватность — не внешняя надстройка, а нативное состояние на уровне бухгалтерской книги. (DOCS)
Консенсус тоже заставил меня скорректировать впечатление. Изначально я увидел «комитет + PoS» и по привычке отнёс это к обычным validator committee. Но после изучения дизайна SA (Succinct Attestation) стало ясно: он разносит роли «предложение — проверка — окончательное подтверждение» на последовательные стадии. Сначала кто-то делает предложение, затем случайно выбранный комитет его валидирует, а в конце другая группа комитетов выполняет ratification. Когда блок завершает ratification, это даёт детерминированную финальность — а не «сначала на чейн, потом надеемся, что не будет reorg». Для финансовых расчётов это важнее, чем любые цифры TPS. (DOCS)
Есть и деталь на сетевом уровне, которую легко упустить: Dusk не использует традиционный gossip, когда «я получил сообщение — и просто переслал его нескольким соседям». Вместо этого он применяет структурированный overlay Kadcast, чтобы контролировать маршрут сообщений. Ценность этого решения не в том, что оно выглядит «слишком умно» — оно делает полосу пропускания и задержки более предсказуемыми. В финансовых сценариях детерминированность часто важнее, чем пиковая пропускная способность из маркетинговых цифр. (Dusk)
Так что теперь моё мнение о Dusk изменилось: наблюдать за ним стоит не потому, что «сможет ли он стать ещё одной популярной L1», а потому, способен ли он упаковать приватные транзакции, комплаенс-раскрытие, детерминированные расчёты и выпуск активов в один и тот же базовый слой бухгалтерской книги.
Моя главная ошибка раньше — считать Phoenix «функцией приватности» Dusk. По исходникам и модели транзакций видно, что это на самом деле другая форма представления активов: Moonlight — это публичная модель учётных записей, а Phoenix разбивает баланс на расходуемые UTXO и использует доказательства с нулевым разглашением, чтобы подтвердить «я имею право потратить эти деньги и не трачу их повторно», не раскрывая при этом все детали транзакции. И самое важное: в итоге обе они сводятся к Transfer contract. То есть приватность — не внешняя надстройка, а нативное состояние на уровне бухгалтерской книги. (DOCS)
Консенсус тоже заставил меня скорректировать впечатление. Изначально я увидел «комитет + PoS» и по привычке отнёс это к обычным validator committee. Но после изучения дизайна SA (Succinct Attestation) стало ясно: он разносит роли «предложение — проверка — окончательное подтверждение» на последовательные стадии. Сначала кто-то делает предложение, затем случайно выбранный комитет его валидирует, а в конце другая группа комитетов выполняет ratification. Когда блок завершает ratification, это даёт детерминированную финальность — а не «сначала на чейн, потом надеемся, что не будет reorg». Для финансовых расчётов это важнее, чем любые цифры TPS. (DOCS)
Есть и деталь на сетевом уровне, которую легко упустить: Dusk не использует традиционный gossip, когда «я получил сообщение — и просто переслал его нескольким соседям». Вместо этого он применяет структурированный overlay Kadcast, чтобы контролировать маршрут сообщений. Ценность этого решения не в том, что оно выглядит «слишком умно» — оно делает полосу пропускания и задержки более предсказуемыми. В финансовых сценариях детерминированность часто важнее, чем пиковая пропускная способность из маркетинговых цифр. (Dusk)
Так что теперь моё мнение о Dusk изменилось: наблюдать за ним стоит не потому, что «сможет ли он стать ещё одной популярной L1», а потому, способен ли он упаковать приватные транзакции, комплаенс-раскрытие, детерминированные расчёты и выпуск активов в один и тот же базовый слой бухгалтерской книги.