У екосистемі Dusk торгівля може бути офіційно визнана системою, швидкість насправді не є визначальним фактором. Справжня проблема полягає в тому — чи пройшла вона ту систему доказів. Якщо доказ не пройдено, ця транзакція на ланцюгу стає марною.

Dusk обирає досить жорсткий шлях. Як тільки транзакція ініціюється, вона повинна одночасно відповідати кільком обмеженням. Головне — ці обмеження не є тим, що перевіряється лише під час виконання, а безпосередньо закодовані у логіку доказу. Статус активів, відповідність умовам облікового запису, внутрішня узгодженість правил — все це перевіряється на етапі доказу. Не існує операцій "спочатку виконай, потім відкоти", і немає можливості "спочатку змінити стан, а потім пояснити вже після".

Найжорсткіший дизайн тут полягає в тому, що Dusk визначає "конфлікт правил" як стан, який також можна довести як невдачу. Багато систем виявляють конфлікти правил вже після запуску користувачами, і потім їх виправляють у надзвичайних ситуаціях. Механізм Dusk змушує вас чітко формулювати правила ще до того, як транзакція відбудеться. Якщо правила нечіткі, доказ не може бути згенерований, і транзакція взагалі не потрапить у систему. Іншими словами, система відмовляється приймати нечіткі правила і визнає лише ті набір правил, які можна довести як істинні.

Це також пояснює, чому логіка відповідності Dusk більше схожа на "жорсткі обмеження", а не на "м’які зобов’язання". Відповідність — це не рекламний слоган і не щось, що можна контролювати за допомогою бекенд-перключика, а перша ворота, через яку має пройти транзакція. Якщо вона не пройдена, транзакція навіть не має права перейти до стану.

Зараз ключове — спостерігати, чи зможе Dusk дотримуватися цього механізму до кінця. Тобто, чи всі зміни стану мають проходити через доказові обмеження, чи існує шлях обійти доказ і змінити стан напряму. Тільки з дотриманням цих двох принципів Dusk справді перетворює складні правила у системну реальність, а не просто у гарну ідею у документації.