На этот раз, разбираясь с правилами перевода активов в Dusk, я наоборот зацепился за довольно незаметный шаг: почему перед тем, как транзакция действительно отправляется, сначала нужно пройти проверку и симуляцию?

Раньше, когда я смотрел ончейн-переводы, привычный порядок был такой: подпись, отправка, а потом ожидание результата.

Но регулируемые активы работают иначе.

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

> Я думаю, что эта ступень по-настоящему решает не просто проблему фразы «транзакция не удалась», а то, чтобы ошибочные действия не успели стать фактом прямо в блокчейне.

Если смотреть с позиции эмитента или площадки, разница получается очень существенной.

Традиционная логика в ончейне больше похожа на:

сначала отправить;

если не получилось — потом разбираться.

А Dusk хочет сделать иначе:

сначала определить;

если не соответствует правилам — по возможности остановить до отправки.

Конечно, это добавляет дополнительный слой логики проверок, и передача активов уже не будет зависеть только от баланса и подписи, как у обычных токенов.

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

Именно это, как мне кажется, и делает Dusk действительно интересным.

Это не просто «перенести ценные бумаги в блокчейн», а попытаться сделать саму логику «кто может переводить, кто может получать и в каких случаях нужно отказать» частью правил работы актива.

Если вы эмитент, вы бы скорее согласились на дополнительную предварительную проверку, или предпочли бы сохранить простую схему как у обычных токенов: сначала перевести, а потом обрабатывать исключения?@Dusk

#dusk $DUSK