作者：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允許創始人和投資者將估值推遲到下一輪，而不是強制承諾一個特定的估值。屆時，公司將有機會發展出更好的產品——市場契合度，雙方將能夠採取更明智的觀點。

SAFU：為白帽創建標準