作者：Lucas Baker, Joe Howarth, Nihar Shah
技术的巨大讽刺是，每一个新的解决方案要么死于技术问题，要么成为一个社会问题活得足够长。对于传统的科技公司来说，这显然是真的，但随着使用量的增长，同样的动态在加密货币中也迅速变得明显。例如，DeFi的问题不再是如何推动需求，而是如何处理需求出现时的失败模式。这一点在协议安全方面最为重要，到目前为止，由于黑客攻击、漏洞利用和其他漏洞，已经损失了超过50亿美元。虽然我们可以用字节码验证和形式化规范等工具来设计健壮性，以及彻底的人工审计，但人类的易变性导致总有一些东西会从缝隙中溜走。
幸运的是，加密货币也受益于世界上最令人印象深刻的白帽子社区，他们跃跃欲试，帮助团队免受关键漏洞的影响。白帽子，或称道德黑客，在协议或平台中寻找潜在的安全问题，并与开发商合作，在这些问题被利用之前纠正它们。然而，DeFi安全的现状给任何可能的拯救者带来了艰巨的障碍。
- 法律上的不确定性：虽然大多数协议团队在黑客利用漏洞后提供了一些宽限期，让黑客宣布自己是白帽子，但他们依旧没有任何保证，而且团队随时可能决定采取法律行动。安全研究人员一直生活在这种风险之中（甚至连善意的安全研究这一基本概念也是在今年早些时候才得到官方认可的）但当涉及到用户资金时，风险就大得多了。
- 缺少明确性：假设白帽子和协议团队都有诚意，还有一个问题是如何处理通过漏洞获得的资金。它们是被退回到原来的协议地址还是被发送到一个新创建的地址？如果协议的管理是去中心化的，谁来为协议说话，这个人是否可以被信任为用户的资金？
- 执行风险：对一个漏洞的反应通常是在“战争的迷雾”中进行的（一种极端紧急和混乱的状态）。相互矛盾的建议或指示（可能包括冒名顶替者或欺诈性地址）可能导致难以或不可能逆转的错误。
虽然bug赏金有助于协议建立一个已知的流程并鼓励负责任的披露，但它们只是解决方案的一部分。早期阶段的协议团队可能无法提供足够大的赏金，或者即使他们提供了赏金，白帽子们也可能不相信团队会履行他们的承诺。此外，许多漏洞（比如那些由升级产生的漏洞）对于白帽子来说可能太紧急了，无法依靠漏洞悬赏所需要的多天沟通周期。在极端情况下，就像涉及 300 多个地址的 Nomad 黑客攻击一样，可能只有时间与不同的接收者重播主动攻击。
我们需要的是一种达成共识的方法：最好是在漏洞发生前就达成共识并进行沟通。我们之前就提出了这样的建议：在一个预先宣布的地址上设立一个 “Dropbox”，作为预先保障资金的接收点。尽管如此，仍有几个问题：
- 白帽子们是否会足够信任协议团队，从而使用dropbox？如果承诺了奖励，白帽子们怎么知道它将被兑现？仅仅是治理就能提供很少的保证。例如，Tribe DAO在偿还8000万美元的Rari黑客攻击的受害者上出尔反尔，最后在第四次投票后才同意。
- 我们如何才能创建白帽子和协议都支持的有效规范？如果每个协议都创建了自己的政策，白帽子们可能没有时间或资源来正确审查这些政策，而缺陷或歧义可能直到修复它们时已经太晚了才变得明显。
为了解决这些问题，我们引入了SAFU，即资金上传的简单安排。
继续阅读，深入讨论SAFU项目的灵感和设计原则，或者直接深入到我们在Github上的政策声明和Solidity合约的参考实现。
SAFU：资金上传的简单安排
SAFU旨在作为一种简单但可扩展的方式来指定白帽子的开发后政策，特别是奖励和分配。它包括两个元素，我们为其提供了一般指南和参考实现：
1、白帽子的声明：协议团队的一份措辞清晰简单的声明，承诺不对白帽子采取法律行动。该声明还规定了几个关键的政策要素：
- 在出现漏洞时可提取资金的来源地址
- 资金应存入的Dropbox地址或合约
- 白帽子可索取的奖励，指定为百分比，有一个可选择的上限
- 要求的条件，以及评估过程和解决的时间表
2. 协议资金的Dropbox：一个地址或合约，从协议中提取的资金应存入其中。Dropbox合约可以是自动的，在每个存款人的基础上处理索赔和奖励，不需要人工输入；也可以是有条件的，需要额外的输入，如治理批准或身份验证。当前地址应始终列在声明中，而Dropbox参数应反映那里所阐述的条件。
综合来看，声明和Dropbox提供了一个标准化但灵活的框架，任何协议都可以用来鼓励用户资金的安全返回。例如，SAFU为实施Sam Bankman-Fried最近提出的5-5标准（5%或500万美元中的较小者）提供了一个公开可见和可信的方式。我们相信这个解决方案大大优于开发后的谈判，后者往往相当于 “要么接受，要么离开 ”的提议，协议者除了接受之外没有什么选择。
虽然它还不是一个正式的法律合约，因为DeFi的监管环境必须解决这样的合约，我们相信SAFU将作为一个重要步骤，在最需要的时候提供更好的技术、法律和经济清晰度。
需要一个共同的理解
正如我们所概述的，加密货币安全领域的发展速度比管理它的规则要快。不仅围绕着白帽子的活动存在着法律上的灰色地带，而且对于道德黑客在发现关键漏洞后应该做什么也没有明确的行为标准。足够高知名度的黑客可以制定他们自己的政策（包括可怕的 “u up?”，就像samczsun一样），但这对普通研究人员来说既不有效也无法扩展。
我们认为现状是一个协调问题，鉴于DeFi的变化速度，这是很自然的，但在行业成熟之前必须解决这个问题。团队必须预先沟通白帽子在发生危机时应该做什么（通过声明），并预先承诺在漏洞发生后遵守该政策（通过Dropbox），而不是在当下争先恐后地回应。建立一套共同的规范（政策在前面明确说明，白帽子和用户都感到受到公平对待）将使加密货币行业能够为协议和他们的客户提供更好的保证。
通过SAFU框架，我们希望创建一个谢林点，在没有沟通的情况下，参与者可以默认。自然，任何人都可以创建一个标准（许多人不可避免地这样做），但在这种情况下，我们相信有一个特别强大的模型来启发我们的方法。Y Combinator的SAFE，即未来股权的简单协议。
安全，SAFT，SAVU
在前YC风险资本的黑暗时代，每家公司都创建了自己的定制条款，即使是为极端早期阶段的公司。第一次创业的人往往既没有背景也没有法律资源来正确理解拟议的条款，而无良的投资者可能会利用他们的天真，采取一些微妙的方法，如稀释和清算优先权。
YC在2013年推出的SAFE解决了这种缺乏标准的问题。这种工具本质上提供了一种精简的可转换债务形式，使创始人能够轻松理解条款表，并在苹果的基础上比较报价。[1] 条款可以用一句话来表达（200万美元上限的100万美元的SAFE不需要解释），让创始人和投资者可以透明和有效地相互交流。
类似的早期阶段问题经常出现在加密货币中，特别是当代币发行发生在协议生命周期的开始阶段。协议实验室的SAFT，复制了代币募集的SAFE，因此自2017年推出以来，也同样得到了广泛的采用。SAFE和SAFT一起使一个广泛而复杂的主题（早期投资）立即变得易懂，通过提供一个标准化的框架，解决了其主要的协调问题之一，尽管如此，它依旧可以适应所有的标准关注。通过引入SAFU，我们希望在加密货币安全研究中加速这一进程。
设计原则
为了提供类似的简单性和适应性的组合，我们需要确保哪些品质？我们认为至少有两个主要的变量，任何解决方案都应该对其进行概括：
- 对协议的信任。必须处理不同程度的人类参与。一个极端、零信任的方法需要一个完全自动化的Dropbox合约，即使团队本身不受信任，也能在没有人类互动的情况下发放奖励和返回资金。另一方面，高信任度的方法将允许一个或多个指定的地址（治理、多重认证等）对每一个索赔施加细微的控制。
- 来自白帽子的承诺：必须处理不同级别的白帽子披露。一个完全匿名的解决方案必须允许任何地址存款和索赔，而一个完全披露的方法可能需要白帽子通过合规/KYC筛选，由治理部门批准，和/或履行额外的义务，例如事件记录。
在这两个轴上嵌入了所有通常的 “加密货币属性”，如去中心化、无信任、无许可和主权身份。此外，由于治理和身份等领域是复杂的主题，因此设计良好的dropbox应与其中任何一个（包括未来版本）完美结合。
在这一点上，我们也旨在履行以下设计原则：
- 简单：应该可以用一句话来概括政策的全部范围。
- 明确：应该明确协议的法律和经济意图，以及合约的技术实施（开源）。
- 合理：应该提供适用于大多数协议的默认值，很少或没有调整。
- 灵活：应该适应不同程度的信任、条件性和匿名性。
- 可信的：应该明确必须满足什么条件才能索取奖励，以及在给定的有效存款水平下可以保证什么最低奖励。
- 不可剥削性：至少应该防止不受信任的（非协议）实体廉价破坏合约的预期功能，例如通过稀释或延迟奖励。一个完全自动化的dropbox应该防止所有实体的破坏，包括所有者/协议。
Stay SAFU：用户手册
一个SAFU由一个声明和一个Dropbox组成，但在这些范围内，协议对协议资金的奖励和返还过程有相当大的决定权。下面，我们概述了协议团队在建立SAFU时需要做出的关键选择。
白帽子的声明
该声明的实质是两方面的。首先，它涉及一个承诺，即不对按照声明行事的白帽子采取法律行动。其次，它涉及到奖励政策的概要，履行该政策所需的条件，以及对解决索赔的过程和时间表的高级描述。更准确地说，我们预计大多数协议将规定以下内容：
- 奖励政策：白帽子有权获得的存款的一部分，通常指定为一个百分比（如资金的5％）或上限的奖励（如1000 ETH）。这些可以以总金额或以每个令牌为基础，但我们希望Dropbox本身将使用每个代币的规格，以避免预言机的依赖。
- 时间线：资金可以被存入和索取的事件顺序。为明确起见，我们鼓励协议在个案基础上解决索赔问题，而不是在事件基础上（例如，Nomad漏洞是一次黑客攻击还是300次攻击？） 一个基本的时间线包括：
- 存款间隔 - 发件人从协议中删除资金后必须在Dropbox中存款的宽限期。从法律角度来看，直接和立即转移可能是最好的，但这在所有情况下可能不可能。
- 索赔延迟 - 发件人可以索赔奖励之前的最低等待时间。我们建议至少24小时，在此期间，漏洞的程度将变得清晰。
- 发送者索赔间隔 - 一个最大的等待期，在这之后，协议可能会收回发送者的奖励，以避免让资金滞留在合约中。
- 发件人批准程序：如果有的话，寄件人必须完成的步骤（如身份验证），以便申请资金。应具体说明该过程将如何进行（治理投票、紧急理事会、Kleros法庭等），谁将负责批准索赔，以及作出决定的最大延迟。
该声明应通过协议在显著位置公开显示（例如，网站或推特上的顶级链接），最好是包含某种形式的可验证的历史记录，使观察者能够确切地知道在漏洞发生时发布了什么。我们推荐Arweave，但任何 “一次写入，永远查看”的解决方案都可以。
协议资金的Dropbox
在最简单的情况下，Dropbox可以是一个由协议控制的预先指定的地址，例如通过multisig或治理。然而，我们相信，智能合约，如通过SAFU repo提供的模板，将帮助协议在回报过程中建立信任，在代码中明确规定奖励和依赖关系。本着这种精神，我们定义了一个具有以下功能的接口（技术规范见GitHub）：
- 存款：接受代币，注册发送者，并根据指定的比例和上限更新每个代币分配的奖励。
- 索赔：发放发件人在当前无人认领的奖赏中的份额。要求发件人的索赔延迟已经过去，发件人在必要时被批准，并且（如果索赔间隔已经过去）奖励尚未被协议收回。
- 赏金：显示特定存款的潜在赏金和当前批准状态。
- Withdraw and WithdrawToken: 支付协议资金，不包括任何分配的发送者奖励（除非超过索赔截止日期）。
- ApproveBounty 和 DenyBounty：批准/拒绝给定存款的索赔；打算在完成任何身份验证或其他发件人特定过程后调用。
我们的实现还包括以下参数：
- BountyPercent（每个代币）：发送者可以要求获得奖励的存入资金的百分比。
- BountyCap（每个代币）：可以分配给奖励的最大资金量。可以由合约所有者增加。
- 批准（每笔存款）：每个存款的批准标志；如果不需要身份验证或其他索赔审批程序，默认为真。
上述接口是为了涵盖从没有人类中介（无论是必要的还是可能的）到对每个发送者的披露和基于治理的批准的全部范围。
- 完全自动化：一旦最小延迟过后，发件人可以立即索取他们的奖励，协议不能以任何方式限制或拒绝。
- 完全有条件的：合约所有者必须为每个发件人单独批准奖励。(我们预计这将是与机构合作和/或在以美国为中心的监管环境下的协议的首选或要求。)
该接口和我们的参考实现，可以适应任何一种模式，都可以在GitHub上找到。
开发者注意事项
虽然我们希望我们的默认实现能够满足大多数基于EVM的协议的需要，但我们鼓励使用其他链和语言的开发者扩展我们的模型。然而，我们建议在扩展功能或改变索赔过程时要谨慎，引入一个漏洞比消除一个漏洞要容易得多。在设计过程中，我们考虑了以下所有的问题：
- 欺骗：恶意的发送者可以廉价地推迟奖励或资金的索取。
- 稀释：恶意发件人可以廉价地稀释其他发件人的可索取奖励。
- 超额支付：一些行动序列导致总奖励超过指定的上限。
- 滞留资金：一些行动序列产生了一个永久锁定的余额。
正如DeFi本身一次又一次地证明，每一种机制都会引入潜在的非预期或利用行为。不要让恢复机制成为薄弱环节
创造一个更好的共识
正如任何工程师都会承认的那样，冒着加密安全的黑暗森林带着某种浪漫。然而，任何行业成功的最终标志是变得枯燥无味：建立一个运作良好的解决方案，以便将注意力转移到其他地方。正如数学家 Alfred North Whitehead 写道：“文明的进步在于扩大了我们可以不假思索地执行的重要操作的数量”。正如SAFEs和SAFTs为早期股权和代币交易结构所做的那样，我们希望SAFU将作为一个精简和易于理解的工具，帮助协议和白帽子协调（无论是否有 “u up”）。
要在你的项目中添加SAFU，只需从我们的GitHub repo开始。
附录：我们的实现
我们提供了一个Solidity实现，它可以被部署为自动或有条件的dropbox。在自动模式下，白帽子可以从dropbox中索取奖励，而不需要任何酌情检查。而在有条件的模式下，白帽子只有在得到协议的批准后才可以索取奖励。前者对双方来说更可预测，因为协议和白帽子之间的互动受到透明代码的严格约束。然而，对于希望进行KYC或治理检查的协议来说，后一种模式可能是可取的，无论是出于合规还是调查的目的。
在这一节中，我们首先描述实现，然后说明某些设计元素（以某些复杂性为代价）阻止了操纵行为。
实施周期
为了启动，协议团队部署了Safu Dropbox合约。在启动合约时应指定以下参数：
- 给予白帽子的份额（bountyPercent）。
- 管辖奖励是否可以自动索取的标志（autoApprove）。
- 白帽子必须等待的最小时间间隔来索取他们的奖励份额，以及协议可以没收奖励之前的最大时间间隔（分别为minDelay和maxDelay），以及
- 契约的管理机构（authority）。
此外，协议可能希望在启动时调用函数 increaseBountyCapForToken。
- 默认情况下，合约将所有代币的上限设置为零。为了激励白帽子，协议应该提高选定代币的上限。请注意，如果悬赏是以多个代币提供的，白帽子可以选择将资金存入具有最高价值上限的代币，除非声明中另有规定。
- 请注意，这个函数可以根据需要经常调用，而且每次只增加特定代币的上限。为了保护等待奖励的白帽子，上限不能减少。
假设一个白帽子发现了协议中的一个漏洞，并确保了资金。白帽子会通过调用存款函数将资金存入SAFU合约，而SAFU会给他们开具存款收据。
- 如果标志autoApprove被设置为 “true”，则收据会被自动批准。
- 否则，协议必须使用 approveBounty 函数手动批准收据（也许是在白帽子经过检查后）。请注意，一旦收据被批准，无论是自动还是手动，以后都不能再批准了。
- 如果协议不批准收据，它可以调用denyBounty函数，删除收据，并将所有存入的资金标记为可由协议索赔。
假设白帽子收到批准的收据，他们现在希望从协议中提取他们的奖励。他们通过调用索赔函数来做到这一点，该函数处理已批准的收据，为他们的存款至少等待了minDelay的时间。
- 白帽子不能在minDelay过期前提出要求。此外，如果白帽子等待的时间太长（直到maxDelay过后）白帽子可能发现协议已经拿走了白帽子的奖励。因此，白帽子应该在minDelay和maxDelay之间的时间窗口中索取他们的奖励。
- 白帽子的奖励与两个变量有关：资金安全份额和总代币上限。如果未付和已付收据的奖励总和不超过上限，那么白帽子就会按比例得到他们所获得的资金份额。如果超过了上限，那么白帽子就会收到按比例分配的剩余上限空间。这将在下一节中进一步讨论。
最后，协议团队可以收回自己的资金。他们通过调用给定代币的 withdrawToken 函数（或 withdraw 函数，它涵盖所有代币类型）来这样做。该函数的工作方式如下：
- 首先，计算所有被拒绝或超过其最大延迟的未付收据的可用资金。
- 接下来，将所有被批准且超过minDelay等待时间的收据的资金减去可能的最大支付额后的总和。
- 如果收据既没有被批准也没有被拒绝（直到达到maxDelay），则故意将其排除在外。这是为了激励协议做出决定，而不是让这些收据和他们的白帽子陷入困境。
- 未超过minDelay的已批准收据也被排除在外。虽然这似乎是不必要的，但它可以防止下一节中所概述的一种利用媒介。
该协议可以在间隔时间内继续提款。最后，一旦每张未兑现的收据都越过了maxDelay阈值，协议就可以将所有剩余的资金（存款、无人认领的奖励和缓冲奖励的混合体）扫入合约。
最后，我们实现了一个协议可以调用的关闭函数，它可以阻止新的资金存入合约。这可以帮助协议安全地退出合约，而且不能被撤销。
计算赔付
赔付逻辑被设计为按照资金安全的比例发放奖励，但有一个可选的上限。为了说明问题，假设一个协议有1亿美元的TVL，向白帽子提供10%的份额，并设置了800万美元的最大上限。此外，假设有三个白帽子依次存款。Alice有5000万美元，Bob有4000万美元，而Charlie有1000万美元。
- 如果Bob和Charlie在Alice的最短等待期（minDelay参数）内存款，他们的潜在索赔总额为500万美元、400万美元和100万美元，超过800万美元的上限。他们都得到了按比例的分配。Alice因获得50%的TVL而获得400万美元，Bob因获得40%而获得320万美元，Charlie因获得10%而获得80万美元。
- 如果Bob和Charlie在Alice退出后存款（即在她的最低等待期过后的某个时间），分配就不同了。在所有情况下，Alice都能得到她的全部500万美元（作为5000万美元担保的10%），因为在她提款时，所有声称的和潜在的奖励都没有超过800万美元的上限。
- 在后一种情况下，Bob和Charlie的分配现在取决于Charlie是在Bob提款之前还是之后存款。
- 如果Charlie在Bob提取奖励前存款，他们就会平分剩余的300万美元的奖励。Bob获得80%（240万美元），Charlie获得20%（60万美元）。
- 如果Charlie在Bob提款后存款，那么Bob获得剩余的300万美元奖励（因为他持有唯一未兑现的收据），而Charlie则一无所获。
如上所示，这种设计也创造了一个强大的激励机制，让人们尽早存款并索取剩余奖励的最大份额。
看守人
契约逻辑试图代表协议和白帽子来执行良好的行为。下面，我们解释五个潜在的问题以及如何缓解这些问题。
- Griefing：廉价拖延支付的能力，无论是对白帽子还是对协议。乍一看，一个自然的设计可能会使用一些 “事件”的概念（例如一个特定的黑客），它从存款开始，并在一段时间内没有任何存款时结束。然后合约可以计算并发放奖励。然而，一个恶意的用户可以利用这种设计，反复向合约发送小额存款，所以事件永远不会被认为是关闭的。相反，我们的合约在很大程度上孤立地处理每笔存款，存款只通过合约的最大赔付上限进行互动。
- 竞相索取：一种结果是奖励不公平地偏向早期存款人。这个合约在领取前引入了一个minDelay参数，即使是已批准的收据，以避免在奖励有上限时白帽子之间的竞争状况。为了说明问题，以我们之前的例子为例，一个协议有1亿美元，10%的赏金和800万美元的上限。两个白帽黑客（Alice和Bob）在几分钟内各自获得5000万美元。如果没有最低限度的延迟，Alice可以索取500万美元，只给Bob留下300万美元，尽管他们的贡献基本上是相同的。更糟糕的是，如果合约中还有剩余的资金，其他白帽子就没有动力去获得这些资金，因为上限使他们无法获得奖励。相比之下，设立minDelay允许所有白帽子在该区间内确保资金，并得到公平的奖励，例如，Alice得到400万美元，Bob得到400万美元。
- 滞留资金：资金被永久锁定在合约中的结果。我们的实现有一个最大延迟（maxDelay），之后协议可以从存款中收回所有资金，包括奖励。这是必要的，以防止资金滞留在合约中，如果一个发送者未能索取他们的奖励。
- 慢速审批：为了激励协议完成审批过程（假设autoApprove是假的），我们防止协议在批准或拒绝某笔存款之前收回自己的资金。当然，协议可以一直等待maxDelay间隔，或者拒绝所有的收据，但这种方法既明显又要付出信誉上的代价。当然，最大公约数的方法是简单地将autoApprove设置为true。
- 稀释：一种结果，即确保资金的发送者集体收到的奖励比他们应得的份额要小。回顾一下这个例子，一个协议有1亿美元的TVL，由Alice和Bob担保，上限为800万美元。如果该协议能够立即提取自己的资金，它可以在minDelay期间提取并重新存入非专用的9200万美元，从而大量减少支付给Alice和Bob的总体奖励。为了避免这种情况，我们还要求协议在取回之前等待minDelay。当然，协议依旧可以用其他资本来源稀释奖励，或者一旦minDelay到期，但这种方法使协议自己的TVL更难做到这一点。(我们可以通过让协议自己的minDelay稍微长一点来提高保证，但为了参考实现的简单性，我们决定这样做）。
尾注
[1] 从概念上讲，SAFE取代了可转换的债务，其功能是无息、无期限的贷款，在下一轮估值时转换为股权，可选择估值上限或折扣率等条款。这一机制也解决了投资者的第二个问题：对早期阶段的公司进行估值的困难。在种子阶段，估值基本上是不同结果的加权平均值，SAFE允许创始人和投资者将估值推迟到下一轮，而不是强制承诺一个特定的估值。届时，公司将有机会发展出更好的产品——市场契合度，双方将能够采取更明智的观点。
原文地址：https://m.toutiao.com/i7158896046947500548/ |
发表于 2022-11-30 07:59:32
