#dusk $DUSK @Dusk Раньше я думал, что у блокчейн-перевода есть только два возможных исхода: он проходит или он не проходит. «Успех» означал, что значение переместилось. «Неудача» означала, что что-то сломалось. Но чем глубже я разбирался в том, как Dusk описывает регулируемые переводы активов, тем больше понимал, что эта модель для финансовых рынков слишком грубая.
На обычной цепочке отклонённая транзакция почти ничего не говорит. Газа не хватило, условие require сработало и прервало выполнение, состояние изменилось у вас «под ногами». Вам остаётся гадать, что именно произошло.
Для регулируемого актива эта неоднозначность недопустима. В документации Dusk описаны проверки перевода, которые могут завершиться ошибкой с понятными причинами, и — это то, что я нашёл особенно интересным — проверки, которые можно смоделировать до того, как транзакция будет вообще отправлена.
Особенно примечательно, что означает второй момент. Это значит, что право на участие — не то, что вы узнаёте, просто попробовав выполнить перевод и дождавшись, пока он сломается. Вы можете сначала задать вопрос и получить ответ, вообще не обращаясь к реестру.
Это похоже на то, как уже работает традиционная сторона. Брокер не отправляет заявку и не надеется, что система комплаенса её пропустит. Проверка происходит заранее, и когда сделку отказываются совершать, кто-то может объяснить очень точно — контрагент не был аккредитован, срок удержания не истёк, юрисдикция была ограничена. «Отклонено» без причины — не ответ, который годится в регулируемом процессе.
Неудача превращается в информацию, а не в случайность. И отказ с причиной, пожалуй, полезнее, чем успех без какой-либо причины.
Я всё ещё не могу оценить, насколько подробными являются эти причины на практике, и насколько большая часть этого доступна приложению уже сейчас, а не описана лишь как целевой дизайн.
С этого момента я начал смотреть на дизайн иначе. Комплаенс on-chain, возможно, заключается не в том, чтобы блокировать плохие транзакции. Возможно, он заключается в том, чтобы сделать исход предсказуемым ещё до того, как кто-либо в него ввяжется.
На обычной цепочке отклонённая транзакция почти ничего не говорит. Газа не хватило, условие require сработало и прервало выполнение, состояние изменилось у вас «под ногами». Вам остаётся гадать, что именно произошло.
Для регулируемого актива эта неоднозначность недопустима. В документации Dusk описаны проверки перевода, которые могут завершиться ошибкой с понятными причинами, и — это то, что я нашёл особенно интересным — проверки, которые можно смоделировать до того, как транзакция будет вообще отправлена.
Особенно примечательно, что означает второй момент. Это значит, что право на участие — не то, что вы узнаёте, просто попробовав выполнить перевод и дождавшись, пока он сломается. Вы можете сначала задать вопрос и получить ответ, вообще не обращаясь к реестру.
Это похоже на то, как уже работает традиционная сторона. Брокер не отправляет заявку и не надеется, что система комплаенса её пропустит. Проверка происходит заранее, и когда сделку отказываются совершать, кто-то может объяснить очень точно — контрагент не был аккредитован, срок удержания не истёк, юрисдикция была ограничена. «Отклонено» без причины — не ответ, который годится в регулируемом процессе.
Неудача превращается в информацию, а не в случайность. И отказ с причиной, пожалуй, полезнее, чем успех без какой-либо причины.
Я всё ещё не могу оценить, насколько подробными являются эти причины на практике, и насколько большая часть этого доступна приложению уже сейчас, а не описана лишь как целевой дизайн.
С этого момента я начал смотреть на дизайн иначе. Комплаенс on-chain, возможно, заключается не в том, чтобы блокировать плохие транзакции. Возможно, он заключается в том, чтобы сделать исход предсказуемым ещё до того, как кто-либо в него ввяжется.