a16z：關於Token設計的7點小建議

Token是一種強大的新原語，可以用多種方式定義。Token設計空間非常豐富，但我們仍處於探索的早期階段。

實際上，許多團隊努力為他們的項目找到「正確的」Token設計。但行業本就缺乏經過測試的設計框架，因此後人反覆遭遇和前人同樣的挑戰。幸運的是，也有（少數）早期的成功的Token設計的例子。大多數有效的Token模型都有針對其目標的獨特元素，但大多數有缺陷的Token設計都有一些常見的 Bug。因此，本文將討論為什麼我們應該考慮Token的研究和設計，而不僅僅是「Token經濟」，並列出了七項「避坑」小技巧。

1 明確Token的目標

Token設計中最大的問題是在明確目標之前如何構建複雜的Token模型。第一步應該是確定目標，並確保整個團隊能夠完全理解：它是什麼，它為什麼重要，你真正想要完成什麼？未能嚴格定義目標通常會導致重新設計和浪費時間。明確目標還有助於避免「為設計Token經濟而捏造出一Token經濟」的問題，這是某些Token經濟設計的常見現象。

此外，目標應該圍繞Token本身進行，但這一點往往被忽視。明確目標的例子包括：

設計一個Token模型的遊戲，該模型可實現最佳可擴展性和支持建模。

一個 DeFi 協議希望設計一個Token模型，在參與者之間合理分配風險。

設計一個擔保金錢的信譽協議不能直接替代信譽（例如，通過將流動性與信譽信號分離）。

設計一個能夠保證文件在低延遲情況下可用的儲存網路。

設計一個能夠提供最大經濟安全性的質押網路。

設計一個能夠引出真正用戶偏好或最大參與度的治理機制。

這樣的例子不勝枚舉。讓Token可以支持任何用例和達到任何目標，而不是反其道而行。

那麼如何開始定義一個清晰的目標呢？明確定義的目標通常來自於「項目使命」。雖然「項目使命」往往是高層次和抽象的，但目標應該是具體的，並簡化為最基本的形式。

讓我們以 EIP-1559 為例。Roughgarden 對 EIP-1559 的一個明確目標表述：「EIP-1559 應該在需求快速增長的時期之外，以『明顯的最佳出價』的形式，通過簡單的費用估算來改善用戶體驗。」

他接着提出了另一個明確的目標：「我們能否重新設計以太坊的交易費用機制，讓設定交易 Gas 價格更像在亞馬遜上購物般『絲滑』？最理想的是價格發布機制，這意味著一種為每個用戶提供一個接受或放棄 Gas 價格的機制」。

這兩個例子的共同點是陳述了一個高層次的目標，提供一個相關的類比來幫助其他人理解你的目標，然後繼續勾勒出最能支持這一目標的設計方案。

2 根據基本原則評估現有工作

在創造新事物時，從已有的東西下手研究是一個好主意。當你評估現有協議和現有文獻時，應根據其技術優點對其進行客觀評估。

Token模型通常根據Token的價格或相關項目的受歡迎程度進行評估。這些因素可能與Token模型實現其既定目標的能力無關。估值、受歡迎程度或其他評估Token模型的簡單方法可能會導致 Builder「多走彎路」。如果你假設其他Token模型正常運行，而實際上它們不能正常運行，那麼可能會創建一個「天生帶有缺陷」的Token模型。

3 闡明你的假設

明確表達你的假設。當你專注於構建Token時，很容易將基本假設視為理所當然。也很容易錯誤地表達你真正做出的假設。

以一個新協議為例，該協議假設其硬體瓶頸是計算速度。將該假設作為Token模型的一部分（例如，通過限制參與協議所需的硬體成本）可以幫助將設計與期望的行為保持一致。

但是，如果協議和Token設計者沒有明確表達他們的假設，或者他們表達的假設是錯誤的。那麼意識到這種不匹配的參與者就有可能從協議中提取價值。駭客通常是那些比最初構建系統的人更了解系統的人。

闡明你的假設可以讓人更容易地理解你的Token設計並確保其正常運行。如果不明確你的假設，你也無法驗證你的假設。

4 驗證你的假設

有句話說：「不是你不知道的事情讓你陷入困境。而是你確信的事情並非如此。」

Token模型通常會做出一系列假設。這種方法部分來自拜占庭系統設計，這是區塊鏈的靈感來源。系統做了一個假設，並建立了一個函數，如果假設為真，則可以保證一定的輸出。例如，比特幣保證了同步網路模型中的活動性，如果網路中 51% 的哈希算力是誠實的，則保證一致性。幾個較小的區塊鏈遭到了 51% 的攻擊，違反了中本聰共識要求區塊鏈正常運行的誠實假設數量。

Token設計者可以通過多種方式驗證他們的假設。嚴格的統計建模，通常以基於代理的模型的形式，可以幫助測試這些假設。關於用戶行為的假設通常也可以通過與用戶交談來驗證，更好是通過觀察人們實際做了什麼（而不是說他們做了什麼）來驗證。這樣成功驗證的可能性較高，尤其是通過在沙盒環境中產生經驗結果的激勵測試網路。正式的驗證或密集的審計也將有助於確保代碼庫按預期的方式運行。

5 明確「抽象障礙」

「抽象障礙」（abstraction barrier）是系統或協議的不同層次之間的界面。它用於分離系統的不同組件，允許獨立地設計、實現和修改每個組件。清晰的抽象障礙在所有工程領域，尤其是軟體設計領域都是有用的，但是對於去中心化開發和大型團隊構建個體無法理解的複雜系統來說更是必要的。

在Token設計中，清除抽象障礙的目標是最小化複雜性。減少Token模型的不同組件之間的（內部）依賴關係可以產生更簡潔的代碼、更少的 Bug 和更好的Token設計。

舉個例子，許多區塊鏈都是由大型工程團隊構建的。一個團隊可能會對一段時間內的硬體成本進行假設，並用它來確定有多少礦工以給定的Token價格為區塊鏈貢獻硬體。如果另一個團隊依賴Token價格作為參數，但不知道第一個團隊對硬體成本的假設，他們很容易做出相互矛盾的假設。

在應用程序層，明確的抽象障礙對於實現可組合性至關重要。隨著越來越多的協議相互組合，適應、構建、擴展和重新混合的能力只會變得越來越重要。更大的構成帶來更大的可能性，但也帶來更大的複雜性。當應用程序想要組合時，它們必須理解它們所使用的組合協議的細節。

不透明的假設和界面偶爾會導致模糊的 Bug，特別是在早期的 DeFi 協議中。模糊的抽象障礙還增加了處理協議不同組件的團隊之間所需的通信效率，從而延長了開發時間。模糊的抽象障礙也增加了協議的複雜性，使得很難完全理解其機制。

通過創建明確的抽象障礙，Token設計者可以更容易地預測特定的更改將如何影響Token設計的每個部分。明確的抽象障礙也使擴展Token或協議變得更容易，並創建一個更具包容性和擴展性的 Builder 社區。

6 減少對外部參數的依賴

外部參數不是系統固有的，但會影響整體性能和成敗，例如在代Token模型的創建初期的計算資源的成本、交易量或延遲。

但當Token模型僅在參數保持在有限範圍內時才起作用時，可能會出現意外行為。例如，一個出售服務並以固定Token獎勵的形式提供回扣的協議，如果Token的價格出乎意料地高，則Token獎勵的價值可能大於服務的成本。在這種情況下，從協議中購買無限量的服務相當劃算，這會充分利用Token獎勵和服務。

或者再舉一個例子，去中心化網路通常依賴於加密算法或計算難題，這些難題解決難度大，但並非不可能解決。難度通常取決於一個外生變量，比如計算機計算哈希函數或零知識證明的速度有多快。比如有一個協議，它假設計算給定哈希函數的速度有多快，並相應地支付Token獎勵。如果有人發明了一種更快地計算哈希函數的新方法，或者只是擁有與他們在系統中的實際工作不成比例的超大資源來解決問題，他們就可以獲得意想不到的巨額Token獎勵。

7 重新驗證假設

設計一個Token應該像設計一個對抗系統一樣。用戶的行為將隨著Token工作方式的改變而改變。

一個常見的錯誤是在沒有確保任意用戶行為仍能產生可接受的結果的情況下調整Token模型。不要認為用戶行為會因Token模型的變化而保持不變。通常這種錯誤會在設計過程的後期發生，有人花了很多時間來定義Token的目標，定義其功能，並進行驗證以確保其按預期運行。然後，他們確定了一個特例，並改變了Token設計以適應它，但忘記了重新驗證整個Token模型。通過修復一個特例，他們產生了另一個（或其他幾個）意想不到的後果。

記住不要讓辛苦的工作白費，每當項目更改其Token模型時，都要重新驗證它是否按預期運行。

原文連結