代幣經濟的設計必須要經過嚴謹的假設以及驗證，才足以應對用戶行為的變化，想設計好代幣經濟需要滿足哪些前提呢？本文源自於 a16z 的投資合夥人 Guy Wuollet 的文章 《7 Sanity Checks Before Designing a Token》，由 PANews 編譯整理。
（前情提要：香港Web3嘉年華》肖風閉幕演講全文：Web3應用的三種代幣模式 ）
（背景補充：香港Web3嘉年華》HashKey Group法務總監Anna Liu解說代幣化的未來 ）
代幣是一種非常強大的新型原語，可以通過多種方式定義；在文章「Tokenology：超越代幣經濟學」中已經闡述了為什麽我們應該將代幣的研究和設計考慮得更廣泛，而不僅僅是「代幣經濟學」。
代幣為設計帶來了非常豐富的空間。但是我們仍處於探索代幣設計的早期階段，更不用說改進了。在這裡，我們所追求的聖杯就是電腦科學家常常暱稱為「龍書」的現代版。
這本書指的是《編譯原理》（由Alfred Aho、Monica Lam、Ravi Sethi 和 Jeffrey Ullman 所著），有時也可能指早期版本的該書或 Aho 和 Ullman 的早期作品《編譯器設計原理》。
該書統一、定義並影響了幾代電腦科學家對編譯器設計的研究。它影響了許多人，以至於該書的兩位作者在幾年前被授予了 ACM 圖靈獎，其中一位是「為編程語言實現打下基礎的算法和理論」，另一位是「通過在他們的高度影響力的書籍中綜合這些結果和其他人的成果，教育了幾代電腦科學家」。
我們距離像編譯器設計領域裡的「龍書」那樣的代表性著作還有很長的路要走，現在要編寫一本關於代幣的權威指南還為時過早。我們的研究主管 Tim Roughgarden 指出，距離這個目標可能還需要十年左右的時間，這是一項長期的工作。
在 20 世紀 50 年代，編譯器設計是一個非常覆雜和混亂的電腦科學難題。《龍書》的出現，通過階段性應用嚴格的原則，幫助將這個問題轉化為了一個更好解決的問題。
但一些早期的機會和陷阱已經變得清晰起來了。因此，我認為，如果我整理一份我們團隊在與其他人進行代幣設計時經常討論的一些合理性檢查列表，那麽這對於那些正在構建代幣的人將是有幫助的。我還鼓勵大家觀看 Eddy Lazzarin 最近關於代幣設計的演講，其中涵蓋了心理模型、常見模式和陷阱、當前代幣的功能以及許多尚未探索的設計空間。
實際情況是，許多團隊試圖為自己的項目找到「正確」的代幣設計，但通常缺乏測試過的設計框架，因此遇到了其他人曾經遇到的相同挑戰。幸運的是，也存在早期的成功案例和「好」的代幣設計示例。最有效的代幣模型將具有與其目標獨特的元素，但大多數有缺陷的代幣設計都共享一些常見的缺陷。因此，這裡列出了一些有用的提示，以避免最常見的失敗模式。
#1 設定明確的目標
在設計代幣時最大的困難是在明確目標之前構建一個覆雜的模型。沒有所謂的好代幣設計或壞代幣設計——只有實現你的目標的代幣設計或者沒有實現目標的代幣設計。
第一步應該始終是嚴謹地審視目標，並確保你（和你的團隊）充分理解它：是什麽，為什麽重要，你真正想要實現什麽？沒有嚴謹地定義目標通常會導致重新設計和浪費時間。明確定義目標還有助於避免「為了代幣經濟而代幣經濟」的問題，這是對一些代幣設計的常見（而且不無道理的）批評。
此外，目標應該針對代幣具體而言。這可能看起來很顯然，但經常被忽視。以下是一些具體的代幣目標示例：
- 一個遊戲想要設計一個最佳的代幣模型，以實現可擴展性並支持模組化
- 一個 DeFi 協議想要設計一個最優的代幣模型，以在參與者之間分配風險
- 一個聲譽協議想要確保資金不能直接用於聲譽（例如，通過將流動性與聲譽信號分離）
- 一個儲存網路想要保證文件低延遲可用
- 一個質押網路想要提供最大的經濟安全
- 一個治理機制想要獲取真實偏好或最大參與度。 ……列表可以不勝枚舉。代幣可以支持任何用例和目標，而不是反過來
那麽，如何開始明確目標呢？明確的目標通常來自於一份使命宣言。雖然使命宣言往往是高層次和抽象的，但目標應該是具體和簡化到最基本的形式。
我們以 EIP-1559 為例。Roughgarden 提出的 EIP-1559 的一個明確目標是：「EIP-1559 應通過易於估算費用的優化方式，改善用戶體驗，使其在需求急劇上升時，能夠以‘顯而易見的最優出價’的形式存在。」
他還提出了另一個明確的目標：「我們是否可以重新設計以太坊的交易費用機制，使得設置交易的 gas 價格更像在亞馬遜購物？理想的情況是一個公布價格的機制，即為每個用戶提供一個接受或放棄的 gas 價格，以便在下一個區塊中包含。我們將看到…在 EIP-1559 中提出的交易費用機制就像一個公布價格的機制，除非需求大幅度增加。」
這兩個例子共同之處在於：闡述了一個高層次的目標；提供了一個易於理解的類比，以幫助他人理解這個目標；然後繼續概述最好支持該目標的設計。
#2 從第一原理出發評估現有工作
在創建新事物時，研究已經存在的東西通常是個好主意。當你評估現有協議和文獻時，應該客觀地從技術優劣的角度來評價它們。
代幣模型經常基於代幣價格或相關項目的受歡迎程度進行評估。這些因素可能與代幣模型實現其目標的能力無關。估值、受歡迎程度或其他單純的評估代幣模型的方法可能會讓構建者走入歧途。
如果你認為其它模型能夠正常工作，但實際上它們不能，那麽你就可能會創建一個有缺陷的代幣模型。如果你為了不同的目標重新使用一個代幣模型，你可能會不經意地繼承不適合你的代幣模型的假設。
#3 闡明假設
當你專注於構建一個代幣時，很容易將基本假設視為理所當然。你也很容易錯誤地表述你真正做出的假設。
讓我們以一個新協議為例，假設它的硬體瓶頸是計算速度。將這種假設作為代幣模型的一部分（例如，限制參與協議所需的硬體成本）可以幫助將設計與期望的行為對齊。
但是，如果協議和代幣設計者沒有陳述他們的假設，或者他們陳述的假設是錯誤的，那麽可能會有參與者意識到偏差並從協議中提取價值。「駭客」通常是那些比系統的設計者更了解系統的人。
闡述你的假設可以使人更容易理解你的代幣設計，並確保其正常工作。如果沒有明確表述你的假設，你也無法驗證你的假設……
#4 驗證假設
俗話說，「讓你陷入麻煩的不是你不知道的，而是你肯定知道但並非如此的事情。」
代幣模型通常會做出一系列假設。這種方法部分源於拜占庭系統設計的歷史，作為區塊鏈的靈感來源。該系統做出假設，並構建一個函數，如果該假設成立，則保證一些輸出。例如：比特幣保證在同步網路模型中的活躍性，並且如果網路中的51%的哈希功率是誠實的，則保證一致性。有幾個較小的區塊鏈已經遭受了51%攻擊，違反了納克莫托共識對區塊鏈正確運行所需的誠實多數假設。
代幣設計者可以通過多種方式驗證他們的假設。嚴謹的統計建模，通常以 Agent-Based 建模的形式，可以幫助測試這些假設。有關人類行為的假設也經常通過與用戶交談並觀察人們實際做的事情（而不是他們所說的）來驗證，特別是通過激勵測試網路在沙盒環境中生成實證結果。
正式驗證或密集審核也有助於確保程式碼庫按預期運行。
#5 定義清晰的抽象屏障
「抽象屏障」是系統或協議不同層次之間的接口。它用於分離系統的不同組件，使每個組件可以獨立設計、實現和修改。清晰的抽象屏障在所有工程領域特別是軟體設計中都很有用，對於分散式開發和大團隊構建複雜系統更是必要，因為單個人無法理解整個系統。
在代幣設計中，清晰的抽象屏障的目標是盡量減少複雜性。減少代幣模型不同組件之間的相互依賴性可以得到更乾淨的程式碼，更少的漏洞和更好的代幣設計。
例如，許多區塊鏈是由大型工程團隊構建的。一組可能會假設硬體成本隨時間變化而改變，並使用該假設來確定為特定代幣價格提供多少挖礦設備。如果另一組依賴於代幣價格作為參數，但不知道第一個團隊對硬體成本的假設，那麽它們可能會做出沖突的假設。
不透明的假設和接口有時會導致難以發現的錯誤，特別是在早期的 DeFi 協議中。模糊的抽象屏障還通過增加協議不同組件的團隊之間的溝通來延長開發時間。模糊的抽象屏障還增加了整個協議的複雜性，使任何一個人都難以完全理解該機制。
通過創建清晰的抽象屏障，代幣設計者可以更容易地預測特定的更改將如何影響代幣設計的每個部分。清晰的抽象屏障還使擴展自己的代幣或協議更加容易，並創建一個更包容和廣泛的建設者社群。
#6 減少對外部參數的依賴
在創建代幣模型時，經常會使用一些對於系統本身不是固有參數，但會影響整體性能和成功的外部參數，如計算資源的成本、吞吐量或延遲等。
在創建代幣模型時，經常會使用一些對於系統本身不是固有參數，但會影響整體性能和成功的外在參數，比如計算資源的成本、吞吐量或延遲等。
危險的是，當代幣模型僅在某些參數保持在有限範圍內時才能正常工作，就會出現意外行為。例如，考慮一個協議，它銷售某項服務並以一定數量的代幣獎勵形式提供返利：如果代幣價格意外飆升，代幣獎勵的價值可能會超過服務的成本。在這種情況下，從該協議購買無限數量的服務是有利可圖的，從而導致獎勵用盡或服務被完全利用。
再舉一個例子：去中心化網路通常依賴於加密或計算難題，這些難題非常困難，但並非不可能解決。這些難題的難度通常取決於外部變量，比如電腦可以計算哈希函數或零知識證明的速度。想象一下一個協議，它假設能夠快速計算某個哈希函數的速度，並相應地支付代幣獎勵。如果有人發明了一種更快地計算該哈希函數的方法，或者只是擁有不成比例的巨大資源來解決該問題，他們就可以獲得意外的大量代幣獎勵。
#7重新驗證假設
設計一個代幣應該像設計一個對抗性系統那樣。假設系統中存在拜占庭行為（即可能有不忠誠的節點）。用戶的行為會隨著代幣運行方式的變化而發生改變。
設計者常犯的一個錯誤是在調整代幣模型時沒有確保任意用戶行為仍然能產生可接受的結果。不要假設用戶行為在代幣模型變化時會保持不變。這種錯誤通常發生在設計過程的後期：有人花費了大量時間定義代幣的目標、功能，並驗證其是否按預期工作。然後，他們識別出一個邊緣案例並調整代幣設計以適應它……但是忘記了重新驗證整個代幣模型。他們在解決一個邊緣案例時，可能會產生另一個（或幾個）意外後果。
不要讓辛苦的工作付之東流：每當項目更改其代幣模型時，請重新驗證它是否按預期工作。
📍相關報導📍
a16z 真正掌控 Uniswap？揭開 DeFi 協議背後的 VC 身影
