官方文档写得清楚。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、client address、intent signature、chain、expiration 和 replay status。全部匹配才转发。我理解，这种绑定可以降低 Attestation 被用于其他 Policy Client 的可能性。
从架构来看，这种设计也有助于限制 Attestation 的适用范围。如果一个 Attestation 可以在任意合约上使用。那么授权边界就会变得更加宽泛。@undefined 选择了把授权范围细化到合约级别。而不是只停留在用户签名层面。
代价也很明显。每个合约都需要独立注册为 Policy Client。文档里提到的 PolicyClientRegistry 就是干这个的。合约要先用这个 registry 注册。然后才能接入 Newton 的授权流程。这对开发者来说是一个摩擦点。Policy Client 绑定也意味着集成流程会更复杂一些。
但 Newton 显然认为这个摩擦是值得的。因为如果没有这层绑定，Attestation 的授权边界就会变得更加宽泛。BLS 签名再漂亮。Operator 网络再去中心化。只要 Attestation 可以跨合约随意使用。安全假设就会变弱。
我还有一个疑问。Policy Client 绑定解决了合约级别的授权范围问题。但如果 Policy Client 合约本身有漏洞或者被升级了怎么办。文档里说 PolicyConfig 更新不影响旧 Attestation。但 Policy Client 地址变更的情况呢。我目前还没有在官方文档中看到对这一点的详细说明。
另外 Policy Client 绑定让 Newton 的授权模型需要更多步骤。每个 dApp 每个功能模块每个用户操作都需要独立的 Attestation 生命周期。这对高频操作场景是一个负担。
Newton 选择了把授权粒度细化到合约级别。这是一个安全优先的设计决策。但它也让 Newton 的集成比传统签名验证复杂得多。
文档里 VaultKit 的例子很能说明问题。每个受保护的 vault 操作都变成 Intent。每个 Intent 都经过 Operator 评估。每个 approved action 都绑定到 Attestation。然后 Shield 才转发。三层结构。三个验证点。全部围绕 Policy Client 展开。
为什么 Newton 宁愿增加这层合约绑定也不愿意让授权只停留在用户签名层面。
