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

原文作者：Lucas Baker、Joe Howarth、Nihar Shah

原文编译：aididiaojp.eth，Foresight News

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

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

• 法律不确定性：虽然在黑客攻击协议之后，大多数团队会提供一些宽限期，希望黑客能够以白帽身份归还被盗资产，同时会给予白帽一定的奖励。但这没有任何保证，团队总是会决定采取法律行动。即使是像白帽这样善意安全研究的基本概念也只是在今年早些时候才获得官方认可，而当涉及到用户资金时，风险要高得多。

• 缺乏明确性：假设白帽和协议团队都是善意的，仍然存在如何处理攻击获得的资金的问题。它们是要返回到原始协议地址还是发送到新创建的地址？如果协议治理是去中心化的，谁来把资金存入协议，当使用用户资金时，这个人可以被信任吗？

• 执行风险：黑客与协议团队之间的沟通通常是在一种极度紧迫和混乱的状态，就像是在进行一场迷雾战争。相互矛盾的提议或指示包括冒名顶替者或欺诈地址可能会导致不可能逆转的错误。

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

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

• 白帽会足够信任协议团队使用「保管箱」吗？如果承诺了奖励，如何确保它会被兑现？仅治理本身无法提供任何保证。例如 Tribe DAO 在第四次投票后，最终同意放弃偿还 Rari 黑客攻击的受害者 8000 万美金的损失。

• 我们如何创建白帽和协议团队都支持的有效规范？如果每个协议都创建自己的规范，白帽可能没有时间或途径来正确审查这些规范，并且缺陷或歧义可能不会变得明显，等到它们被完善已经为时已晚。

SAFU：资金上传的简单方案

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

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

• 发生漏洞时可以从中提取资金的来源地址

• 应存入资金的 Dropbox 地址或合约

• 白帽可索取的奖励，指定为带有可选上限的百分比

• 索赔所需的条件，以及评估过程和解决时间表

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

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

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

达成共识的必要性

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

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

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

SAFE、SAFT、SAFU

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

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

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

设计原则

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

• 对协议的信任：必须避免不同级别的人工参与。在一个极端情况下，零信任方法需要完全自动化的保管箱合约，因为即使团队本身不受信任，也无需人工干预即可分配奖励和返还资金。另一方面，高度信任的方法将允许一个或多个指定地址（治理、多重签名等）对每个声明进行精细控制。

• 来自白帽的承诺：必须进行不同级别的白帽披露。完全匿名的解决方案必须允许任何地址进行存款和索赔，而完全披露的方法可能需要白帽通过合规和 KYC 筛选，获得治理的批准后履行额外的义务，例如事件记录。

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

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

• 简单：应可以用一句话概括政策的全部内容。

• 明确：应明确协议的法律和经济意图，以及合同的开源技术实施。

• 明智：应提供适用于大多数协议的默认值，无需额外适应。

• 灵活：应适应各方的信任、条件和匿名性。

• 可信：应明确要求奖励必须满足哪些条件，以及对于给定的有效存款水平可以保证什么最低奖励。

• 不可利用：至少应防止不受信任的实体以廉价方式破坏合约的预期功能，例如通过稀释或延迟奖励。全自动保管箱应防止所有实体包括所有者和协议的破坏。

SAFU 用户手册

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

白帽声明

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

• 奖励政策：白帽有权获得的一部分存款，通常指定为百分比或上限奖励例如资金的 5% 或 1000 ETH 。这些可能以总量或每个代币计价，但我们预计 Dropbox 本身将使用每个代币规范来避免 预言机 依赖。

• 时间表：可以存入和领取资金的事件顺序。为清楚起见，我们鼓励协议根据具体情况而不是事件来解决索赔（例如，Nomad 漏洞是按照一次黑客攻击还是 300 次攻击？）。基本时间表包括：

• 存款间隔：发件人从协议中盗取资金后必须将资金存入 Dropbox 的宽限期。从法律角度来看，直接和立即转移可能更可取，但并非在所有情况下都是可能的。

• 索赔延迟：发件人可以要求奖励之前的最短等待期。我们建议至少 24 小时，在此期间漏洞利用的程度将变得清晰。

• 发件人索赔间隔：协议可以收回发件人奖励的最长等待期，以避免资金滞留在合约中。

• 发件人批准流程：发件人必须完成的步骤，例如身份验证以索取资金。应具体说明流程将如何进行，包括治理投票和紧急理事会等，谁将负责批准索赔，以及做出决定的最大延迟时间。

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

协议基金的 Dropbox

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

• 存款：接受代币，注册发送者。并根据指定的比例和上限更新每个代币分配的奖励。

• 认领：支付发件人在当前无人认领的奖励中的份额。要求发送者声明延迟已经过去，如有必要发送者被批准，并且协议尚未收回奖励。

• 赏金：显示给定存款的潜在赏金和当前批准状态。

• 取款和取款代币：支付协议资金，不包括任何分配的发件人奖励。

• 批准和拒绝赏金：批准或拒绝对给定存款的索赔；旨在在完成任何身份验证或其他发件人特定过程后调用。

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

• 赏金百分比：发送者可以要求作为奖励的存入资金的百分比。

• 赏金金额：可分配用于奖励的最大资金量。可以由合同所有者增加。

• 已批准（每次存款）：每次存款批准标志，如果不需要身份验证或其他索赔批准过程，则默认为 true。

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

• 完全自动化：一旦最小延迟过去，发件人可以立即索取他们的奖励，协议不能以任何方式限制或拒绝。

• 完全有条件的：合约所有者必须为每个发送者单独批准奖励。我们预计这对于与机构合作和或在以美国为中心的监管环境中的协议来说将是首选或必需的。

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

告诫 开发者

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

• 恶意发件人：恶意发件人可以廉价地延迟来索取奖励或资金。

• 稀释：恶意发件人可以廉价地稀释其他发件人的可索取奖励。

• 超额支付：某些操作序列导致总奖励超过指定上限。

• 搁浅的资金：某些操作序列会产生永久锁定的余额。

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

建立更好的共识

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

附录：实现案例

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

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

生命周期

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

• 给予白帽的份额（bountyPercent ）

• 控制奖励是否可自动领取的标志（autoApprove）

• 白帽必须等待领取其奖励份额的最小时间间隔，以及协议没收奖励之前的最大时间间隔（分别为 minDelay 和 maxDelay）

• 合同的管理机构（权威）

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

• 默认情况下，合约将所有代币的上限设置为零。为了激励白帽，协议应该提高选定代币的上限。请注意，如果以多个代币提供赏金，除非声明中另有规定，否则白帽可能会选择将资金存入具有最高价值上限的代币中。

• 请注意，可以根据需要多次调用此函数，并且每次只会增加给定令代币的上限。为了保护等待奖励的白帽，上限永远不会降低。

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

• 如果标志 autoApprove 设置为 true，则自动批准收据。否则协议必须使用 approveBounty 函数手动批准收据。请注意，收据一旦被自动或手动批准，以后就不能被拒绝。

• 如果协议不批准收据，它可以调用 denyBounty 函数删除收据并将所有存入的资金标记为可被协议索取。

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

• 在 minDelay 过去之前，白帽无法声明。此外如果白帽等待的时间过长，直到 maxDelay 过去之后，白帽可能会发现协议已经无法获取奖励。因此，白帽应该在 minDelay 和 maxDelay 之间的时间窗口内领取他们的奖励。

• 白帽的奖励与两个变量有关：获得的资金份额和总代币上限。如果未偿和已付收据的奖励总和不超过上限，则白帽将获得按比例获得安全资金份额。如果超过上限，则白帽将按比例获得剩余上限空间的份额。

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

• 首先，计算来自未结收据的所有可用资金，这些收据要么被拒绝，要么已超过其 maxDelay。

• 接下来，将所有已批准且已超过 minDelay 等待的收据的资金相加，减去可能的最大支出。

• 如果收据既没有被批准也没有被拒绝（直到达到 maxDelay），则故意将其排除在外。这是为了激励协议做出决定，而不是让这些收据及其白帽陷入困境。

• 未超过 minDelay 的已批准收据也被排除在外。虽然这似乎没有必要，但它可以防止一些漏洞利用向量。

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

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

计算支出

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

• 如果 Bob 和 Charlie 在 Alice 的最短等待期内（minDelay 参数）存款，他们的潜在索赔总额为 500 万美元、400 万美元和 100 万美元，超过了 800 万美元的上限。他们都按比例分配：Alice 获得 400 万美元以获得 TVL 的 50%，Bob 获得 320 万美元获得 40%，Charlie 获得 80 万美元获得 10%。

• 如果 Bob 和 Charlie 在 Alice 取款后存款（即在她的最短等待期过去后的某个时间），则分配是不同的。在所有情况下，Alice 都得到了她作为 5000 万美元担保的 10% 的全部 500 万美元，因为在她退出时，所有声称的和潜在的奖励都没有超过 800 万美元的上限。

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

• 如果 Charlie 在 Bob 提取奖励之前存款，他们将平分剩余的 300 万美元奖励。Bob 获得 80%（240 万美元），Charlie 获得 20%（60 万美元）。

• 如果 Charlie 在 Bob 取款后存款，那么鲍勃将获得剩余的 300 万美元奖励（因为他持有唯一的未清收据），而 Charlie 则一无所获。

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

五个潜在问题以及应对方案

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

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

争夺奖励：奖励不公平地分配给早期存款人的结果。该合约在声明之前引入了一个 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 稍微延长一些来改进，但决定支持参考实现的简单性。

原文链接