详解为加密白帽设计的执行规范SAFU

科技的最大讽刺之处在于每一个新的解决方案要么限于技术问题而无法实施，要么寿命长到足以成为社会问题，这样的情况在传统科技公司身上已经屡见不鲜。但随着市场规模不断增长，同样的问题在加密市场中也浮出水面。例如 所面临的不再是如何推动需求，而是在需求出现时如何保障用户。迄今为止，由于黑客攻击、漏洞利用等，DeFi 领域已经损失了超过 50 亿美元。虽然我们可以使用字节码的正式规范和验证以及完整的手动审计来保障稳健性，但人为的错误仍然会导致一些漏洞的存在。

幸运的是加密行业受益于世界上令人印象深刻的白帽社区，白帽们随时准备采取行动，帮助团队防御关键漏洞。白帽在协议或平台中搜索潜在的安全问题，并与其开发人员合作，在这些问题被利用之前纠正这些问题。然而当前的 DeFi 市场状态给任何潜在的白帽救星带来了令人生畏的障碍：

虽然漏洞赏金有助于协议建立已知流程，并鼓励负责任的披露，但它们只是解决方案的一部分。早期的协议团队可能无法提供足够大的赏金，或者即使他们提供了，白帽可能不相信团队会履行他们的承诺。此外，许多漏洞例如升级产生的漏洞对于白帽来说可能过于紧迫，白帽没有足够的时间来领取漏洞赏金。在极端情况下，就像涉及 300 多个地址的 Nomad 黑客攻击一样，可能只是在不同时间下，接收者进行重复主动攻击。

我们需要的是一种达成共识的方法：理想情况下，在漏洞被利用之前达成共识，并进行沟通。我们之前的文章《Whitehats and Dropboxes》提出了这样的建议：在预先宣布的地址上放置一个「保管箱」，作为预先担保资金的容器。但这仍然存在几个问题：

SAFU 旨在作为一种简单但可扩展的方式来指定白帽攻击后的执行规范，特别是奖励和分配。它包含两个元素，我们为此提供一般指南和参考实现：

白帽声明：协议团队明确而简单的声明，承诺不对白帽采取法律行动。该声明还指定了几个关键要素：

存入协议资金的 Dropbox：从协议中提取的资金应存入的地址或合约。Dropbox 合约可以是自动执行的，在没有人为输入的情况下按每个存款人处理索赔和奖励。或者是设置一定条件的，并需要额外的输入，例如治理批准或身份验证。当前地址应始终列在声明中，并且 Dropbox 参数应提前包含所设条件。

总而言之，白帽声明和 Dropbox 提供了一个标准化但灵活的框架，任何协议都可以使用该框架来鼓励黑客将用户资金安全返还。例如 SAFU 提供了一种公开可见且可信的方式来实施 Sam Bankman-Fried 最近提出的 5-5 标准（5% 或 500 万美元中的较小者）。我们相信这种解决方案大大优于利用后的谈判，后者通常让协议别无选择，只能被迫接受。

虽然它还不是一份正式的法律合同，但由于 DeFi 的监管环境必须进行改善来让这样的合同合法可行。我们相信 SAFU 能够提供更好的技术、法律和经济模型清晰度，SAFU 也将成为重要的一步。

加密安全的竞争环境比管理它的规则发展得更快。围绕白帽活动存在法律灰色地带，而且对于具有道德感的黑客在发现关键漏洞后应该做什么也没有明确的行为标准。足够高调的黑客可以创建他们自己的策略，但这对于普通研究人员来说既不有效也没有参考价值。

我们将现状视为一个协调问题，考虑到 DeFi 的变化步伐，这是一个自然而然的问题，但必须在行业成熟之前解决这个问题。与其在漏洞被利用后争先恐后地做出应对，团队必须通过声明预先与白帽沟通在发生危机时应该做什么，并预先承诺在漏洞利用后通过 Dropbox 遵守该政策。SAFU 建立一套共享规范，其中明确规定了政策规范，白帽和用户都感到受到公平对待，这将使加密行业能够为协议及其客户提供更好的安全保证。

通过 SAFU 框架，我们希望创建一个谢林点，参与者可以在没有通信的情况下协作。任何人都可以创建一个标准，所以许多人不可避免地会这样做，但在这种情况下，我们相信有一个特别强大的模型可以实现我们的愿景：Y Combinator 的 或未来股权简单协议。

首先来呈现一个逻辑化的起源故事。在前 YC 的黑暗时代，每家公司都创建了自己的定制条款清单，非常早期的公司也是如此。早期公司往往既没有背景也没有法律资源来正确理解提议的条款，不道德的者可以通过稀释和清算优先权等方法获取超额奖励。

2013 年 YC 引入 SAFE 解决了这种缺乏标准的问题。SAFE 本质上提供了一种简化的可转换债务形式，使创始人能够轻松理解条款清单，并在合理的基础上公平比较报价。用一句话来传达，就是 100 万美元的 SAFE 和 2000 万美元的上限不需要任何解释，让创始人和投资者可以透明而有效地相互交流。

类似的早期问题经常出现在加密领域，尤其是在协议生命周期开始时提供代币时。Protocol Labs 的 SAFT 复制 SAFE 以进行代币融资，自 2017 年推出以来也得到了类似的广泛采用。SAFE 和 SAFT 使一个广泛而复杂的主题早期投资变得容易理解，它们通过提供一个标准化框架来解决协调问题，该框架仍然适用于所关注的所有标准。通过引入 SAFU，我们希望加速加密安全研究中的相同过程。

为了提供类似的简单性和适应性组合，我们需要确保哪些特性？目前至少两个主要变量，任何解决方案都应该对其进行概括：

嵌入在这两个特质的是所有常见的加密属性，例如去中心化、无需信任、无需许可和主权身份等。此外由于治理和身份等领域是具有比较规范且快速发展的解决方案的复杂主题，因此设计良好的保管箱应与其中任何一个或未来版本完美结合。

在这方面，我们旨在实现以下设计原则：

SAFU 由 Statement 和 Dropbox 组成，但团队在这些范围内对管理奖励和协议资金返还的过程具有相当大的自主裁决权。下面我们概述了协议团队在建立 SAFU 时需要做出的关键选择。

该声明的本质是双重的。首先它涉及承诺不对按照声明行事的白帽采取法律行动，同时涉及奖励政策的概述、实现它所需的条件，以及解决索赔的过程和时间表等关键描述。更准确地说我们预计大多数协议将指定以下内容：

该声明应通过协议显着注明且公开地显示，例如在网站或 Twitter 介绍上的靠前链接，并且理想情况下应包含某种形式的可验证历史记录，以便观察者准确了解在漏洞利用时发布的内容。我们推荐 ，或者任何一次编写，永久查看的解决方案都可以。

在最简单的情况下，Dropbox 可以是通过多重签名或治理，由协议控制的预先指定的地址。但我们相信如通过 SAFU 存储库提供的模板更加合适，它将通过在代码中明确指定奖励和依赖关系来帮助协议在退还资金过程中建立信任。本着这种精神，我们定义了一个具有以下功能的接口（GitHub 中的技术规范）：

我们的实现还包括以下参数：

上述界面旨在涵盖从无人工中介到每个发件人的披露和基于治理的批准的全部范围：

可以在 GitHub 上找到可以适应任一模式的接口和我们的参考实现。

虽然我们希望我们的默认实现能够满足大多数基于 EVM 的协议的需求，但我们鼓励开发人员使用其他链和语言来扩展我们的模型。但我们建议在扩展功能或更改声明流程时要谨慎 ，因为引入漏洞比消除漏洞容易得多。我们在设计过程中考虑了以下所有因素：

正如 DeFi 本身一次又一次地证明的那样，每一种机制都可能导致意外或恶意行为，不要让恢复机制成为薄弱环节！

正如任何工程师都会承认的那样，加密安全的黑暗森林带着某种浪漫。然而任何行业成功的最终标志都是变得乏味，制定一个行之有效的解决方案，从而将注意力转移到其他地方。正如数学家 Alfred North Whitehead 所写的那样，「文明的进步是通过扩展我们可以在不考虑它们的情况下执行的重要操作的数量。」 正如 SAFE 和 SAFT 为早期股权和代币交易结构做出的贡献一样，我们希望 SAFU 将作为一种简化且易于理解的工具来帮助协议和白帽协调。

我们提供了一个 Solidity 实现案例，可以用来部署为自动或有条件的保管箱。在自动模式下，白帽可以从保管箱中领取奖励，而无需任何检查。在条件模式下，白帽只有在协议批准后才能领取奖励。前者对双方来说更容易预测，因为协议和白帽之间的交互受到透明代码的严格控制。但是出于合规性或调查目的，希望执行 KYC 或治理检查的协议可能需要后一种模式。

在本节中，我们首先描述实现，然后说明某些以一些复杂性为代价阻止操纵的设计元素。

在启动时协议团队部署了 Safu Dropbox 合约。启动合约时应指定以下参数：

此外，协议可能希望在启动时调用函数 increaseBountyCapForToken。

假设白帽在协议中发现了漏洞并获得了资金。白帽将通过调用存款函数将资金存入 SAFU 合约，该函数会向他们发出存款收据。

假设白帽收到批准的收据，他们现在希望从协议中撤回他们的奖励。他们通过调用 claim 函数来完成此操作，该函数处理已批准的存款收据，至少已等待 minDelay 时间段。

最后，协议团队可以收回他们自己的资金。他们通过调用给定代币的 withdrawToken 函数（或扫描所有代币类型的 withdraw 函数）来做到这一点。该功能的工作原理如下：

该协议可以继续间隔退出。最后一旦每张未清收据都超过了 maxDelay 阈值，该协议就可以清除合约中的所有剩余资金，包括存款、无人认领的奖励和缓冲奖励等。

最后，我们实现了协议可以调用的关闭函数，以防止新资金存入合约。这可以帮助协议安全地退出合同，并且无法撤消。

支付逻辑旨在根据已获得的资金按比例发放奖励，但有一个可选的上限。举例来说，假设一个协议有 1 亿美元的 TVL，向白帽提供 10% 的份额，并设置了 800 万美元的最高上限。此外假设有三个白帽按顺序存入：Alice 存入 5000 万美元，Bob 存入 4000 万美元，Charlie 存入 1000 万美元。

在后一种情况下，Bob 和 Charlie 的分配现在取决于 Charlie 是在 Bob 取款之前还是之后存款。

如上所示，这种设计还创造了一种激励，让他们提前存款并获得剩余奖励的最大份额。

合约逻辑试图代表协议和白帽强制执行规范行为。下面我们将解释五个潜在问题以及如何缓解这些问题。

恶意拖延：能够廉价地拖延支付给白帽或协议的能力。一个自然的设计可能会使用一些事件的概念例如特定的黑客攻击，它以存款开始，并在一段时间过去没有任何存款时结束，然后合约可以计算和支付奖励。但是恶意用户可以通过向合约发送重复的小额存款来利用这种设计，因此该事件永远不会被视为已结束。相反我们的合约在很大程度上孤立地处理每笔存款，存款仅通过合约的最大支付上限进行交互。

争夺奖励：奖励不公平地分配给早期存款人的结果。该合约在声明之前引入了一个 minDelay 参数，即使对于已批准的收据，也可以避免在奖励上限时白帽之间的竞争。为了说明这一点，以我们之前的协议示例为例，该协议具有 1 亿美元、10% 的赏金和 800 万美元的上限。两个白帽黑客 Alice 和 Bob，他们在几分钟内各自获得了 5000 万美元。如果没有最低限度的延迟，Alice 可以索取 500 万美元，而 Bob 只剩下 300 万美元，尽管他们的贡献基本相同。更糟糕的是，如果合同中还有资金，其他白帽公司将缺乏获得资金的动力，因为上限会阻止他们获得奖励。相比之下，建立一个 minDelay 允许所有白帽在该时间间隔内获得资金并获得公平的奖励，例如给 Alice 400 万美元，给 Bob 400 万美元。

搁浅资金：资金被永久锁定在合约中的结果。我们的实现具有 maxDelay 的特点，之后协议可以从存款中收回所有资金，包括奖励。如果发件人未能领取奖励，这对于防止资金锁定在合约中是必要的。

缓慢批准：为了激励协议完成批准过程，假设 autoApprove 为 false，我们阻止协议在给定存款中收回自己的资金，直到它批准或拒绝该存款。当然协议总是可以等待 maxDelay 间隔或拒绝所有收据，但这种方法会在声誉上付出高昂的代价。当然最清晰的方法就是将 autoApprove 设置为 true。

稀释：确保资金的发送者集体获得的奖励少于他们应该有权获得的份额。回想一下这个例子，一个协议有 1 亿美元的 TVL，由 Alice 和 Bob 担保，上限为 800 万美元。如果协议能够立即提取自己的资金，它可以在 minDelay 期间提取和重新存入未指定用途的 9200 万美元，从而大大减少支付给 Alice 和 Bob 的整体奖励。为了避免这种情况，我们还要求协议在回收之前等待 minDelay。当然，协议仍然可以用另一种资金来源稀释奖励，但是这种方法使得使用协议自己的 TVL 更难做到这一点。我们可以通过使协议自己的 minDelay 稍微延长一些来改进，但决定支持参考实现的简单性。