Разница между правилом соответствия, которое просто записано, и тем, которое реально выполняется.
Я думаю, одно из самых сложных вещей, которые нужно объяснить про ньютон, это то, что соответствие в этой системе — это не документ и не руководство по политике. это реально выполняемый код, который запускается перед каждой отдельной транзакцией.
мьюто́н использует язык под названием рего, чтобы записывать эти правила. это тот же язык, который большие технологические команды используют, чтобы управлять доступом в облачной инфраструктуре. он читаемый, простой и всегда дает один и тот же результат, если подать на вход одни и те же данные. никаких сюрпризов, никакой трактовки.
Проверка санкций в Rego выглядит как простой список условий. Помечен ли отправитель? Помечен ли получатель? Разрешена ли юрисдикция? Если не выполняется хотя бы одно условие, ответ — deny, и транзакция не проходит. Это выполняется до расчетов, а не как проверка «по факту».
То, что я нахожу по-настоящему интересным, — насколько это модульно и комбинируемо. Протокол не пишет одно огромное правило для всего. Они пишут небольшие сфокусированные модули: модуль санкций, модуль KYC, модуль ограничения по скорости. Каждый делает одно дело аккуратно, а затем вы складываете нужные модули под вашу конкретную ситуацию.
Файл политики, который выполняется для любой конкретной транзакции, сохраняется по содержимому (content address) в IPFS. Это означает, что точная версия правил, которая оценила транзакцию, навсегда поддается однозначной ссылке. Регулятору не нужно спрашивать, какая политика действовала в определенную дату. Документ о соответствии (compliance receipt) напрямую указывает на файл.
И поскольку Rego — это чистый функциональный язык, одни и те же входные данные всегда дают один и тот же результат. Именно поэтому становится возможным механизм задачи с нулевым разглашением. Если оператор подпишет неверный результат, любой сможет повторно запустить ровно ту же политику и доказать правильный ответ.
