Официальная документация написана ясно. В структуре Attestation есть поле под названием policyClient. Тип — address. В структуре Task есть поле под названием Policy Client Address. В комментарии говорится, что это адрес смарт-контракта, защищённого политиками. В примере кода SDK поле intent с направлением to указывает на контракт PolicyClient. Контракт Shield перед выполнением проверяет, совпадает ли этот client address. Если проверка не проходит, отклоняется пересылка.
Согласно процессу валидации в Shield, если адрес Policy Client не совпадает с тем, что записано в Attestation, проверка пройти не сможет. Это означает, что область применимости Attestation ограничена определённым контекстом смарт-контрактов.
Сначала я думал, что это чрезмерно продумано. Зачем нужен ещё один слой привязки? Разве нельзя просто проверить подпись пользователя напрямую.
Но логика кода Shield из документации помогла мне понять, почему так. После привязки Attestation к policyClient при каждом выполнении Shield заново должен проверять taskId, policyId, адрес клиента, подпись intent, chain, expiration и replay status. Только если всё совпадает, происходит пересылка. Я понимаю, что такая привязка снижает вероятность того, что Attestation будет использована для другого Policy Client.
С архитектурной точки зрения такой дизайн также помогает ограничить применимость Attestation. Если бы Attestation можно было использовать на любом контракте, границы авторизации стали бы ещё более широкими.@undefined Они выбрали детализацию области авторизации до уровня контракта, а не оставление её только на уровне подписи пользователя.
Цена тоже вполне очевидна. Каждый контракт нужно отдельно регистрировать как Policy Client. В документации упоминается PolicyClientRegistry — именно для этого он и нужен. Контракт должен сначала быть зарегистрирован в этом registry, а затем уже подключаться к авторизационному процессу Newton. Для разработчиков это точка трения. Привязка Policy Client также означает, что процесс интеграции становится немного сложнее.
Но, судя по всему, Ньютон считает, что это препятствие стоит того. Потому что если бы не было этого слоя привязки, границы авторизации для Attestation стали бы значительно более широкими. Даже если BLS-подпись выглядит красиво. Даже если сеть операторов децентрализована. Если Attestation можно произвольно использовать в разных контрактах, предположения по безопасности ослабевают.
У меня ещё один вопрос. Привязка Policy Client решает проблему области авторизации на уровне контракта. Но что если у самого контракта Policy Client есть уязвимость или он будет обновлён? В документации сказано, что обновления PolicyConfig не влияют на старые Attestation. А как быть в случае изменения адреса Policy Client? Пока я не видел в официальной документации подробного объяснения этого.
Кроме того, привязка Policy Client заставляет модель авторизации Newton включать больше шагов. Для каждого dApp, для каждого функционального модуля и для каждого действия пользователя требуется отдельный жизненный цикл Attestation. Это становится обременительным в сценариях с высокой частотой операций.
Ньютон выбрал детализацию авторизационной гранулярности до уровня контракта. Это решение, ориентированное на безопасность. Но из-за этого интеграция Newton по сложности значительно превосходит традиционную валидацию подписей.
Пример из документации про VaultKit очень хорошо это показывает. Каждая защищённая операция vault превращается в Intent. Каждый Intent проходит оценку оператором. Каждый approved action привязывается к Attestation. Затем Shield пересылает. Трёхуровневая структура. Три точки проверки. Всё построено вокруг Policy Client.
Почему Ньютон предпочёл добавить этот слой привязки контрактов, а не оставлять авторизацию только на уровне подписи пользователя.
