a16z:代幣模型設計的7個準則


原文作者:Guy Wuollet

原文標題:7 Sanity Checks Before Designing a代幣

原文來源:a16z

編譯:Yvonne,MarsBit

代幣是一種功能強大的新原語,可以通過多種方式進行定義;我在這裡討論了為什麼我們應該考慮代幣的研究和設計,而不僅僅是“代幣經濟學”。

代幣顯然允許非常豐富的設計。但我們仍處於探索的早期階段,更不用說改進代幣設計了。這裡要達到的聖杯將是計算機科學家通常所說的“the Dragon Book”的現代版本。這本書指的是《編譯器:原理、技術和工具》(作者:Alfred Aho、Monica Lam、Ravi Sethi 和Jeffrey Ullman;有時也可以參考該書的早期版本或Aho 和Ullman 的舊作《編譯器設計原理)》 — 統一、定義並影響了幾代計算機科學家對編譯器設計的研究。就在幾年前,兩位作者因為“編程語言實現的基礎算法和理論”以及“在他們極具影響力的書籍中綜合了這些結果和其他人的結果,這些結果教育了一代又一代的計算機科學家”而獲得了ACM圖靈獎。我們距見到代幣設計的“the Dragon Book”還很遠——現在就代幣制定明確的文本還為時過早。我們的研究負責人Tim Roughgarden 指出,雖然我們距離這一目標可能還有不到十年的時間,但這是一項持續的工作。因為Dragon Book 幫助將1950 年代“難以置信的混亂”、龐大的大型計算機科學問題——編譯器設計——變成了一個更容易解決的問題,可以分階段解決,在每個階段應用嚴格的原則。

但一些早期的機會和陷阱已經變得清晰起來——所以我認為,如果我整理了一份清單,列出我們團隊在與其他人合作進行代幣設計時經常討論的一些合理性檢查,將會對建設者有所幫助。我還鼓勵你觀看Eddy Lazzarin最近關於代幣設計的演講,其中涵蓋心智模型、常見模式和陷阱、當前代幣功能以及許多有待探索的設計領域。

實際情況是,許多努力為其項目尋找“正確”代幣設計的團隊往往在沒有經過測試的設計框架的情況下工作——因此遇到了與其他人相同的挑戰。幸運的是,也有早期的成功和“好的”代幣設計的例子。最有效的代幣模型將具有其目標所特有的元素,但大多數有缺陷的代幣設計都有許多常見的陷阱。因此,這裡有一個指導性提示列表,可以避免最常見的錯誤模式。

1.設立一個明確的目標

代幣設計中最大的痛苦來自於,在尚未明確說明目標之前就構建一個複雜的模型。沒有好代幣模型或壞代幣模型一說——只有一個代幣模型是否可以實現你的目標。

第一步應該是嚴格審視目標,並確保你(和你的團隊)完全理解它:它是什麼,它為什麼重要,你真正想要完成什麼?未能嚴格定義目標通常會導致重新設計和浪費時間。明確定義目標還有助於避免“為了代幣經濟學而進行代幣經濟學”的問題,這是對某些代幣設計的常見(並非不公平)批評。

此外,目標應該特定於代幣。這似乎很明顯,但經常被忽視。此類目標的示例包括:

一款希望能夠最好地實現可擴展性和支持封裝的代幣模型的遊戲。

一個DeFi 協議,想要設計一個代幣模型,在參與者之間最佳地分配風險。

一個希望保證文件低延遲可用的存儲網絡。

一個希望提供最大經濟安全性的質押網絡。

一種希望帶來最大參與度的治理機制。

……這個名單可以繼續下去。代幣可以支持任何用例和目標——而不是相反。

那麼你如何開始定義一個明確的目標?明確定義的目標通常來自願景。雖然願景往往是虛無縹緲和抽象的,但目標應該是具體的並簡化為最基本的形式。

讓我們以EIP-1559為例。 Roughgarden將EIP-1559的目標表述得最好:“EIP-1559應該在需求快速增長的時期之外,以’明顯的最佳出價’的形式,通過簡單的費用估算來改善用戶體驗。”

他繼續提出了另一個明確的目標: “我們能否重新設計以太坊的交易費用機制,讓設置交易的gas 價格更像是在亞馬遜上購物?理想的是發布價格機制,這意味著一種機制為每個用戶提供一個接受或放棄的gas 價格以包含在下一個區塊中。我們會看到……EIP-1559 中提出的交易費用機制就像一個定價機制,除非需求突然大量增加……”

這兩個例子的共同點是陳述了一個高層次的目標;提供相關的類比(在這種情況下可能)以幫助其他人理解該目標;然後著手概述最能支持該目標的設計。

2.根據基本原則評估現有模型

在創造新事物時,研究已經存在的事物總是一個好主意。當你評估現有協議和現有資料時,你應該根據它們的技術優點客觀地評估它們。

代幣模型通常根據代幣的價格或相關項目的受歡迎程度進行評估。這些因素可能與代幣模型滿足其既定目標的能力無關。估值、受歡迎程度或其他評估代幣模型的幼稚方法可能會使構建者誤入歧途。

如果你假設其他代幣模型正常運行,而它們卻不能正常運行,那麼你就會創建一個有瑕疵的代幣模型。如果你用不同的目標重新使用一個代幣模型,你可以隱含地繼承那些對你的代幣模型沒有意義的假設。

3.闡明猜想

明確闡述你的猜想。當你專注於構建代幣時,很容易將基本猜想視為理所當然。也很容易不正確地闡明你真正的猜想。

讓我們以一個假設其硬件瓶頸是計算速度的新協議為例。使用該假設作為代幣模型的一部分——例如,通過限制參與協議所需的硬件成本——可以幫助使設計與期望的行為保持一致。

但是,如果協議和代幣設計者沒有陳述他們的猜想——或者他們陳述的猜想是錯誤的——那麼意識到不匹配的參與者就有可能從協議中提取價值。 “黑客”通常是比最初構建系統的人更了解系統的人。

闡明你的猜想可以更容易地理解你的代幣設計並確保它正常工作。如果不闡明你的猜想,你也無法驗證你的猜想……

4.驗證猜想

俗話說:讓你陷入麻煩的,不是你不知道的事,而是你自以為知道、其實錯誤的事。 ” (這句話通常被認為是馬克·吐溫和其他人所說,隨著時間的推移,這句話也不斷演變。)

代幣模型通常會做出一組假設。這種方法部分來自拜占庭系統設計的歷史,作為區塊鏈的靈感來源。系統做出假設並構建一個函數,如果假設為真,則可以保證一定的輸出。例如:比特幣保證同步網絡模型的活性,如果網絡中51% 的算力是誠實的,則保證一致性。幾個小型區塊鏈遭到51% 的攻擊,這違反了中本聰共識對區塊鏈正常運行的假設,即多數節點誠實。

代幣設計者可以通過多種方式驗證他們的猜想。嚴格的統計建模(通常以基於主體的模型的形式)可以幫助檢驗這些猜想。關於人類行為的假設通常也可以通過與用戶交談來驗證,更好的是,通過觀察人們實際做了什麼(而不是說他們做了什麼)。這是可能的,尤其是通過在沙盒環境中產生經驗結果的激勵測試網。

形式驗證或密集的審計也將有助於確保代碼庫按預期運行。

5.定義明確的抽象障礙

“抽象障礙”是系統或協議不同層次之間的接口。它用於分離系統的不同組件,允許每個組件獨立設計、實現和修改。明確的抽象障礙在所有工程領域都有用,尤其是軟件設計,但對於分佈式開發和構建單人無法理解的複雜系統的大型團隊來說更是必要的。

在代幣設計中,明確抽象障礙的目標是將復雜性降至最低。減少代幣模型的不同組件之間的(相互)依賴性會帶來更清晰的代碼、更少的錯誤和更好的代幣設計。

舉個例子:許多區塊鍊是由大型工程團隊構建的。一個團隊可能會隨著時間的推移對硬件成本做出假設,並使用它來確定有多少礦工以給定的代幣價格為區塊鏈貢獻硬件。如果另一個團隊依賴代幣價格作為參數,但不知道第一個團隊對硬件成本的假設,他們很容易做出相互矛盾的猜想。

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

不透明的假設和接口偶爾會導致模糊的錯誤,尤其是在早期的DeFi 協議中。晦澀的抽象障礙也延長了開發時間,因為它增加了不同團隊在溝通協議組件方面的溝通時間。模糊的抽象障礙也增加了協議的整體複雜性,使任何一個人都難以完全理解該機制。

通過創建清晰的抽象障礙,代幣設計者可以更輕鬆地預測特定更改將如何影響代幣設計的每個部分。確的抽象障礙還可以更容易地擴展代幣或協議,並創建一個更具包容性和擴張性的開發者社區。

6.減少對外生參數的依賴

外生參數不是系統固有的,但會影響整體性能和成功——例如計算資源的成本、吞吐量或延遲——通常用於創建代幣模型。

危險的是,當代幣模型僅在參數保持在有限範圍內時才起作用,可能會出現意外行為。例如,思考一個出售服務並以固定代幣獎勵形式提供回扣的協議:如果代幣價格出乎意料地高,則代幣獎勵的價值可能大於服務成本。在這種情況下,從協議中購買無限量的服務是有利潤的,這會導致獎勵用完或服務被充分利用。

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

7.重新驗證猜想

設計代幣應該像設計對抗系統一樣。假設拜占庭式的行為。用戶的行為將隨著代幣工作方式的改變而改變。

一個常見的錯誤是,在不確保用戶行為仍會導致可接受結果的情況下,調整自己的代幣模型。不要假設用戶行為會隨著代幣模型的變化而保持不變。通常這個錯誤發生在設計過程的後期:有人花了很多時間來定義代幣的目標、功能,並進行驗證以確保它按預期工作。然後他們確定一個邊緣案例並改變代幣設計以適應它……但忘記重新驗證整個代幣模型。通過修復一個邊緣案例,他們造成了另一個(或其他幾個)意想不到的後果。 (注:邊緣案例是指,在電腦編程中,只出現在可能值範圍的最高或最低端或極端情況下的問題或情況)

不要讓辛勤工作付之東流:每當項目更改代幣模型時,都要重新驗證它是否按預期工作。

資訊來源:由0x資訊採集自互聯網。版權歸作者“比推Bitpush News”所有,未經許可,不得轉載

Total
0
Shares
Related Posts