Fiducia - 为你的 Safe 提供细粒度控制和协同签名人

不要止步于单一用途的检查。Fiducia是一个强大的Safe Guard，让你可以对你的Safe可以与谁互动，可以做什么，以及何时操作进行细粒度的链上控制 - 此外，还有可选的cosigner（协同签名者）支持来验证敏感操作。

从Guardrail到Fiducia：

Guardrail 展示了单个、有针对性的检查（例如，阻止有风险的 delegatecall ）如何提高仅由所有者进行 tx 参数验证的基线。但是，如果你想控制交易的更多方面呢？Fiducia （在拉丁语中意为“信任”）应运而生——这个名字很贴切，因为它在链上执行信任和规则。Fiducia本质上是Safe的“瑞士军刀”式的 guard。它不是进行一次检查，而是允许你跨地址、calldata（函数选择器）和操作类型强制执行规则，甚至为敏感操作添加额外的批准机制。

这是我们旅程的第二步：Guardrail解决了一个向量（ delegatecall ），而Fiducia将范围扩大到交易的多个维度。

Fiducia 可以做什么

Fiducia 引入了多项功能，这些功能共同显著地加强了安全性：

• 交易允许列表和阻止列表： 你可以指定允许的交易模式——本质上是目标地址、函数（由调用数据中的函数选择器标识）和调用类型（常规调用或 delegatecall ）的组合。默认情况下，任何未预先批准的交易都将被阻止。这意味着你可以允许调用特定 DeFi 合约的 deposit() 函数，但其他任何操作都需要额外的审查。这就像告诉你的Safe，“你可以自由地以这些方式与 X 互动，但对于其他任何事情，请放慢速度，让我仔细检查一下。”如果说Guardrail是一扇简单的门，那么Fiducia就是一个带有名单的保镖——如果你不在名单上，你就进不去（至少不会立即进入）。

• Cosigner 支持（每个交易的额外关注）： Fiducia 的一个显著特点是对 cosigner(协同签名者) 的支持。cosigner 是一个额外的实体，可以以密码学方式批准 未在允许列表中的交易。Cosigner 最初由Safe在 Safenet 中引入。Fiducia 允许你指定一个 cosigner 的地址。当激活后，这意味着每个不在允许列表中的交易，除了通常的Safe所有者签名，还需要该 cosigner 的签名。为什么这很强大？因为 cosigner 可以在链下运行独立的检查，以验证交易的安全性或是否符合策略，然后再签名。这就像有一个自动化的安全分析师实时审查每个交易。如果 cosigner 批准（提供签名），Fiducia 允许交易绕过延迟并立即执行（因为假定 cosigner 进行了必要的验证）。如果 cosigner 不 批准，则交易必须在允许列表中，否则将根本无法执行。我们将在下面更深入地探讨 cosigner，因为它们值得特别讨论。

• Token转移限制： Fiducia 可以对 token 转移设置基于 token 的限制。例如，你可以将其配置为 Safe 每次交易最多可以向任何批准的地址发送 1,000 个 token ABC。这是一种防止在单个交易中进行大量提款的保护措施。如果有人试图转移 10,000 个 token，并且超过了设定的限制，Fiducia 将阻止它（ TokenTransferExceedsLimit 错误）。你可以根据需要微调每个 token 的限制，甚至可以微调特定接收地址的限制（合约中的 setAllowedTokenTransfer() 允许你使用更高的限制来对某些 token+接收者组合进行白名单）。注意：这是每个交易的限制，在未来的迭代中，可以将其配置为具有每日限制或某个时间段的限制等。

• Guard移除保护： 任何安全系统的一个明显的攻击途径是试图禁用它。Fiducia 通过要求一个安全的过程来移除或禁用 guard 本身来预料到这一点。如果Safe所有者决定移除 Fiducia，那么该操作也需要延迟（即，你安排一个 guard 移除，并且只能在延迟后才能最终确定它）。这样，以某种方式获得 Safe 部分控制权的攻击者无法立即剥夺 guard。你会注意到一个计划中的移除，并有时间做出反应。Fiducia 的内部逻辑包括一个 scheduleGuardRemoval() 函数，确保移除符合规则（试图过早移除它会触发 InvalidTimestamp() 错误）。简而言之，Fiducia 不会掉入“关闭警报”的陷阱，而不会自己敲响警钟。

除了这些核心功能之外，Fiducia 还像 Guardrail 一样支持 Safe 模块和 MultiSendCallOnly 交易。在底层，Fiducia 实现了来自Safe的两个必需的 guard 接口（对于常规交易和模块交易），因此它真正地监视着通过你的Safe的所有内容。

Cosigner 的作用 - 你Safe的最佳伙伴 🚨👬

如前所述，cosigner 是在交易中提供第二个签名的链下代理。但是，与人类共同所有者不同，此代理的“批准”通常是自动化的，并且基于预定义的安全检查。可以将其视为你Safe的烟雾探测器——它不会阻止你点燃蜡烛（安全操作），但是如果检测到燃烧的东西（危险交易），它会发出警报。

每次你或任何其他人从Safe提交交易时，都应期望 cosigner 服务检查该交易，如果一切正常，则生成 Fiducia 可以识别的签名。如果签名存在且有效，则 Fiducia 允许交易跳过延迟并立即执行。否则，交易将失败或根据允许列表进行检查。从本质上讲，cosigner 为每个交易引入了经过验证的检查。与单独的链上 guard 相比，它们可以运行更复杂的分析，因为它们并不总是受到 gas 的限制。他们可能会模拟交易，将其与已知的攻击模式进行比较，检查安全目标的允许列表，甚至可能需要人工确认才能进行高价值操作。我们将 cosigner 强调为“经过验证的检查的基本层”，它们充当独立的签名者，确认交易的安全性。

有关Cosigner的更多信息，我们已经使用我们的项目 Varangian 撰写了一篇文章。Fiducia与Varangian cosigner兼容，因此你可以检查当多个安全选项（guard + cosigner）组合在一起时，事物如何工作。

用简单的英语使用 Fiducia

Fiducia 的 Safe App：https://www.safe.dev/fiducia/ (在 Safe{Wallet} 中添加为 自定义 Safe App)

设置 Fiducia 比 Guardrail 稍微复杂一些，但仍然可以管理，尤其是对于开发人员：

1. 部署 Fiducia Guard 合约（就像部署 Guardrail 一样，使用像 Forge 这样的工具）。你可以配置初始延迟（例如，使用 1 天或 12 小时的默认延迟来实例化它）。假设我们使用 24 小时延迟来部署它。

2. 将其附加到你的 Safe：执行 Safe 交易以将此新合约设置为 Safe 的 guard ( safe.setGuard(guardAddress) )。由于 Fiducia 也涵盖了模块交易，因此你还可以调用 safe.setModuleGuard(guardAddress) - 实际上，Safe 将通过 Fiducia 路由所有交易执行。

3. 初始配置：现在你可以使用 Fiducia 的设置函数来配置允许的交易和限制（这些是通过从 Safe 所有者到 guard 合约的交易来完成的）：

   • 使用 setAllowedTx(target, functionSelector, operation) 允许特定的调用，而没有延迟。例如，你可以允许 UniswapRouter.swapExactTokensForTokens() （通过其函数选择器和 router 的地址标识）作为允许的交易类型。在此之后，在该 router 上的任何交换都不会被 Fiducia 延迟或阻止。

   • 使用 setAllowedTokenTransfer(tokenAddress, recipient, amountLimit) 对某些 token 转移进行白名单。例如，允许每次交易最多向特定业务合作伙伴的地址发送 1000 个 USDC。

   • 使用 setCosigner(cosignerAddress) 注册你的 cosigner。如果你不想要 cosigner，则可以将其设置为未设置（地址 0 ），在这种情况下，所有非允许的交易都将被拒绝。如果你确实设置了一个，那么从现在开始，Fiducia 将期望该 cosigner 对交易进行签名以立即执行。

4. 持续运营：现在 Safe 在 Fiducia 的监视下工作。让我们来看两个方案：

   • 方案 A：允许的交易。 假设你预先允许了对某个 DeFi 协议的调用。Safe 所有者提交一个与这些允许的模式之一匹配的交易（正确的目的地和函数）。一旦收集到所需的所有者签名，就可以立即执行该交易。Fiducia 看到它，将其与允许的模式进行匹配，并从本质上说“这很好。”这对于你信任的常规操作非常有用，因为你的 Safe 不会被瓶颈。

   • 方案 B：新的或未经批准的交易。 现在考虑一个不在任何允许列表中的交易 - 例如，向一个全新的地址发送资金或调用一个你尚未允许的函数。当 Safe 所有者提交此交易时，如果你有 cosigner，则会发生以下两种情况之一：

     • (i) cosigner 会对其进行审查。如果 cosigner 发现它实际上是安全的（例如，你的 cosigner 被编程为批准任何低于 0.1 ETH 的传出 ETH 转移），它会签名并包括其签名。Fiducia 看到 cosigner 的祝福，并允许交易立即进行，即使该交易未被预先允许

     • (ii) 如果 cosigner 不 提供签名（这意味着它标记了 tx 或根本没有被编程为批准它），那么 Fiducia 将不会立即执行该 tx。相反，它要求首先将其添加到允许列表中。所有者将需要等待 24 小时（或任何延迟），然后在时间过去后重新执行交易（如果有人试图在没有 cosigner 的情况下立即在新模式上执行交易，则会抛出 FirstTimeTx() 错误）。此延迟期是你调查交易的机会。最后，延迟后，可以执行交易。

5. 移除/更改：如果你需要禁用 Fiducia（希望不是，除非你正在升级到其他 guard），你不能立即将其关闭。你需要调用 scheduleGuardRemoval()，该函数会启动移除 guard 的计时器。只有在延迟后，你才能通过后续调用实际移除它。这确保了已经损害了一些所有者的攻击者无法立即移除 Fiducia 以执行邪恶行为 - 你会收到早期警告。此外，你可以随时通过 Safe 交易更新 cosigner 或允许列表到 guard 合约。

实际益处和用例

对于那些很好地处理了其典型交易活动并希望锁定其他所有内容的人来说，Fiducia 是理想的选择。例如，假设你为一个项目运行一个加密货币国库：你定期将稳定币转移给你的工资提供商，并与几个 DeFi 协议进行交互以获得收益。使用 Fiducia，你可以允许这些特定操作（地址/函数），它们将顺利进行。如果黑客诱骗你的一名员工尝试将资金转移到一个未知的地址，Fiducia 将介入：如果你已经设置了 cosigner，它可能不会签署该交易; 最坏的情况是，转移将永远处于 limbo 状态。这让你有机会做出反应（也许这名员工会说“嗯，我没有发起那个！”而你意识到正在发生攻击）。在没有 guard 的标准多重签名中，如果有足够的签名者受到损害或被愚弄，那么该交易将被执行并且资金已经消失，而在这里，guard 为攻击者提供了额外的障碍。

对于不太懂技术的读者，你可以将此与银行帐户或公司国库上的消费限额和批准相结合，并结合一个自动化的审计员来监视每笔付款。这听起来可能很复杂，但其想法是自动执行“我们确定我们想这样做吗？”检查，如果负责任的人能够仔细审查每一笔交易，他们会提出这些问题（实际上，他们可能不会这样做 - 人们会快速点击“批准”，或者时区不同，等等）。Fiducia 在代码中强制执行这些“你确定吗？”检查点。它体现了“信任，但要验证”的原则——因此得名 Fiducia（信任）——因为它甚至不会盲目地信任你的所有者的签名; 它将验证条件，并可能还需要受信任的 cosigner 的第二次批准。

Cosigner 优势回顾

特别是对于 cosigner，我们在 tx 分析和链上强制执行之间获得了友好的协同作用。Cosigner 可以使用复杂的逻辑（甚至是 AI 或外部数据）来确定交易是否安全，由于某些限制，我们无法完全在智能合约中做到这一点。但是，一旦 cosigner 感到满意，链上 guard (Fiducia) 将通过允许 tx 通过来兑现这一点。如果 cosigner 不满意或离线，guard 会回退到延迟 - 这意味着你的安全仍然有效。加密货币安全社区中的许多人将 cosigner 签名交易视为未来：甚至我们都注意到 cosigner 会添加经过验证的交易批准，从而大大减少了盲目签名带来的漏洞。

关于用户体验的快速说明

安全功能有时会增加摩擦。Fiducia 确实添加了一些，例如，初始设置以及可能偶尔的延迟。但是，如果明智地使用（使用 cosigner 和设置良好的允许列表），则可以将其配置为使你 90% 的常规交易看不到任何明显的变化，而 10%（有风险/不寻常的交易）将被标记。这是一种权衡：为了获得内心的平静，付出一些不便。对于大多数精通加密货币的人和开发人员（根据我们的受众，这是大多数），这是一个受欢迎的交易。对于初学者来说，像 cosigner 这样的概念可能是新的，但要点是：你有一个机器人伙伴在仔细检查一切。

接下来是什么？

由于 Fiducia 涵盖了如此多的领域，你可能想知道还有什么可以改进的。尽管它功能强大，但在我们的 Safe Guard 之旅中还需要再走一步。Fiducia 虽然灵活，但它是一个你使用各种规则配置的单个 guard 合约。如果你想插入完全独立的策略，或者拥有一个易于扩展的系统，可以在其中独立开发多个策略，然后将其附加到你的 Safe 怎么办？这就是 Policy Engine（策略引擎） 的用武之地，它是下一个（也是主要的）演变。它将通过允许多个并发策略和更模块化的定义方法，将 Safe Guard 的概念提升到一个新的水平。有兴趣吗？让我们继续进行盛大的结局：Safe 的策略引擎。

关于 Safe Research

Safe Research 是 Safe 的应用研发部门，致力于推进自我托管堆栈。我们的工作基于 安全性、抗审查性 和 隐私性 的密码朋克原则，我们专注于为智能账户和钱包构建无需信任、以用户为中心的基础设施。

让我们一次又一次地提交，实现以太坊最初的密码朋克愿景。

• 原文链接： safe.global/blog/safe-re...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～