Я заметил нечто странное, когда отслеживал пакет попыток переводов по сделке @Dusk на прошлой неделе: несколько подач продолжали терпеть неудачу в том, что выглядело как один и тот же контрольный пункт (checkpoint). Моё первое предположение было про сетевую перегрузку — что-то обычное, не заслуживающее второго взгляда.

Копнув глубже, я понял, что сбои вовсе не были случайными. Они группировались вокруг проверки прав на участие — этапа, на котором подтверждается, что кошелёк имеет разрешение на хранение конкретного актива (security) ещё до выполнения любого перевода. Именно тогда я по-настоящему понял, насколько центральным является этот слой авторизации. Это не формальность, стоящая рядом с транзакцией: это ворота, через которые транзакция должна проходить каждый раз.

Это изменило то, как я думаю о происходящем здесь. Большинство людей воспринимают «перевод» и «авторизацию» как одно и то же событие, но это не так. Перевод — это намерение. Авторизация — это разрешение. Когда разрешение молча не проходит или с запаздыванием срабатывает, цифры объёма скрывают трение, которое никогда не проявляется в блок-эксплорере.
$DUSK
То, что я пока не могу разрешить, — где именно в ежедневной работе живёт эта логика верификации. Если она сильно опирается на внецепочные (off-chain) решения о соответствии (compliance), которые затем отражаются на цепочке (on-chain), то сетевые метрики рассказывают лишь половину истории. Я не знаю, какая часть процесса остаётся действительно децентрализованной, а какая — фактически централизованной операционно.

Дальше я хочу отслеживать соотношение неуспешных и успешных авторизаций во времени, а не только сырые количества переводов, а также как часто те же самые кошельки проходят повторную верификацию для новых инструментов.

В итоге меня оставляет вопрос: превращаются ли повторяющиеся проверки авторизации в отдельную форму спроса — отдельно от тех переводов, которые они пропускают (которые они «разрешают»). #dusk