加密白帽為 Web3 保駕護航的同時也會遇到障礙，行業需要一種白帽和協議團隊都支持的有效規範。
原文：SAFU: Creating a Standard for Whitehats（jump Crypto）
作者： Lucas Baker、Joe Howarth、Nihar Shah
編譯： aididiaojp.eth，Foresight News
封面： Photo by Shubham Dhage on Unsplash
科技的最大諷刺之處在於每一個新的解決方案要么限於技術問題而無法實施，要么壽命長到足以成為社會問題，這樣的情況在傳統科技公司身上已經屢見不鮮。但隨著市場規模不斷增長，同樣的問題在加密市場中也浮出水面。例如 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 稍微延長一些來改進，但決定支持參考實現的簡單性。
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
