代幣工程系列 3：案例研究

1. 前言

2. 案例研究：比特幣分析

關於優化的最佳實踐如何應用於代幣設計，我們在上一篇文章中討論過了，現在是時候進行一下實踐，從優化設計的角度來分析比特幣。具體來說，我們要著眼於比特幣的目標函數。

比特幣的目標函數是：最大化網絡安全性。然後它將”安全性”定義為計算能力（哈希率），這使得回滾更改交易日誌的成本/代價非常高。比特幣的區塊獎勵函數通過向提高網絡計算能力的人發放區塊獎勵代幣（BTC），將其目標函數清楚地表示出來。

如下圖所示，我們可以寫出目標函數（區塊獎勵函數）的公式。左邊是參與者 i 在一個區塊間隔內預期獲得的代幣獎勵數量 R（比特幣的區塊間隔時間在10分鐘左右）。等式的右邊是參與者 i 的計算能力 （哈希率）與每個區塊分配的代幣數量 T 的乘積，右邊與左邊成正比（α）。區塊獎勵代幣數量目前是每十分鐘 12.5 BTC（原文寫於2018年）。每四年數量減半。

題外話：以方差換取效率

需要註意的是，獎勵是根據期望值 E() 計算的。這意味著並不是每個參與者在每個區塊間隔都會收到區塊獎勵。實際上，在比特幣網絡中，獎勵非常參差不齊：在每個區塊間隔中只獎勵一個參與者（礦工）。但是，由於他們獲得獎勵的機會與他們貢獻的哈希率（計算能力/算力）成正比，那麽期望值確實是他們的貢獻量。Orchid 團隊將此稱為概率微支付。

為什麽比特幣會有這種獎勵差異（高方差），而不是在每個區塊間隔獎勵每個參與者（低方差）？因為這種高方差給網絡帶來了一些優勢：

• 低算力，低帶寬。原因：網絡不需要跟蹤每個參與者的貢獻量是多少。
• 交易少，帶寬低。原因：網絡不需要在每個時間間隔向每個參與者發送 BTC。效率提升！
• 更簡單，更安全。原因：網絡不需要前面兩個操作，系統就簡單了很多，也因此最大限度地減少了攻擊面。

這些都是非常顯著的優勢。最大的不利因素是高方差：參與者需要有很高的哈希率，才能真正有機會獲得獎勵，但是一旦贏得了機會，參與者就可以獲得全部獎勵。不過好在礦池可以直接降低獎勵方差，所以，只需通過礦池就可以改善這種高方差。這一點非常好，因為這意味著比特幣網絡本身甚至不需要降低方差，就可以改善不利條件。一如既往致敬 Satoshi，我們永遠的學習對象：）

3. 比特幣的激勵機制算成功嗎？

比特幣在實現其最大化安全性的目標函數上做得如何？答案是：好到令人難以置信！通過這個簡單的函數，比特幣很好地激勵了參與者，有的人願意花費數億美元設計自定義哈希的 ASIC （專用集成電路）礦機，建立 ASIC 礦場；有的人願意去創建比特幣礦池，成千上萬的礦工都加入其中。現在比特幣的哈希率已超過所有超級計算機的算力總和，耗電量也已超過大多數小國家的用電水平，並且可能在 2019 年 7 月超過美國的耗電量。所有這一切都是為了獲取比特幣區塊獎勵！（顯然，這些也並非都是什麽好事情。）

除了 ASIC 礦場和礦池，我們還看到了一個生態系統圍繞著比特幣建立起來了。軟件錢包、硬件錢包、核心開發者、app 開發者、無數 Reddit 線程內容、會議等等。網絡激勵 BTC 持有者去傳播 BTC 這個詞，從而推動了大部分生態的發展。驅動這一切的就是區塊獎勵，它清楚地表示出比特幣的目標函數。這就是激勵機制的超級力量。”機會成本是一種超級力量，激勵機制也是一種超級力量。” Charlie, 你說得很對：）

4. 案例研究

4.1 協議介紹

2017 年 5 月，我們第一次正式為海洋協議設計代幣時，設計工作進行得非常吃力。我們沒有對目標進行闡述（目標函數和約束條件），而是簡單地考慮了一種即插即用的模式，去中心化市場常常采用的就是這種模式。但後來我們遇到了問題：這種模式對數據共享有何幫助？答案是沒有。需要自己的代幣嗎？答案也是不需要。當然還有一些其他問題。

因此，我們後退了一步，回到起點，給自己設定了一個目標，即寫出適當目標函數和約束條件。然後，事情開始變得順利了。帶著這些目標，我們嘗試了其他即插即用模式（求解器），並且發現了新問題，目標並沒有反映出來的新問題，因此我們修改了目標。迭代過程中不斷循環重複這樣的步驟。很快我們就用完了現有的即插即用模式，結果並不理想，所以我們必須自己設計；我們對此也進行了迭代。

工作這樣進行了一段時間後，我們才意識到原來我們一直將優化設計方法應用在代幣設計上！即：問題表述；嘗試使用現有模式；如果需要，開發自己的模式。所以盡管這篇文章將代幣設計過程作為一個既成事實闡述出來，但實際上我們是在設計過程中發現這個方法的。在這之後，我們才真正將這種方法用於其他代幣設計，為項目提供支持和幫助。

4.2 海洋協議的問題表述

回顧一下，目標函數是驅使人做事情。所以，我們必須先確定讓哪些人做事，明確潛在的利益相關者或系統主體（Agent）。下面這張圖表總結概述了海洋協議生態系統內主要的利益相關者們。

目標函數：經過上述多次迭代後，我們得出了一個目標函數：最大化相關 AI 數據和服務的供應。這意味著系統不僅要激勵高質量定價數據的供應，還要激勵高質量公共數據的供應；以及激勵與此目標相關的計算服務（例如，隱私計算）。

約束條件：在上述迭代過程中，考慮各種設計時，我們創建並使用了一個清單。大致來說，我們可以將這些視為約束條件。

• 對於定價數據，是否會激勵更多供應？是否具有相關性？是否有良好的垃圾數據預防機制？
• 對於公共（免費）數據，是否會激勵更多供應？是否具有相關性？是否有良好的垃圾數據預防機制？
• 與外部投資者相比，代幣是否為網絡用戶提供了更高的邊際價值？
• 以及更多

除了這些問題，我們還不斷進行調查，了解可能發生的攻擊；將每個新問題添加到要解決的約束條件列表中（包括一個難忘的名稱）；並相應修改設計。新的約束條件包括：”數據轉義”、”策展克隆”、”Elsa & Anna 攻擊（參與者提供自己沒有版權的 IP 到公共數據中，引起關註並獲得獎勵，而版權所有者什麽獎勵都沒有）”等等。海洋協議白皮書的 FAQs 記錄了這些問題，也記錄了我們如何解決這些問題。

4.3 探索設計空間

我們嘗試了多種設計，以各種方式組合代幣模式；並根據上面列出的約束條件對每個設計（在思想試驗中）進行測試。我們嘗試過的設計有：

（1）只為參與者設計TCR （如 adChain ）。結果：失敗；原因：無法處理垃圾數據。

（2）只為數據/服務設計 TCR。結果：失敗；原因無法處理數據轉義。

（3）同時為參與者和數據/服務設計 TCR。結果：失敗；原因：無法從相關的數據/服務中，辨別出非垃圾數據/服務。

（4）為參與者設計 TCR 並且為數據/服務設計策展市場（Curated Markets, CM）。結果：失敗；原因沒有提供數據/服務的激勵措施。

下面是候選設計模式對清單上的問題給出的回答。可以看出，每個候選設計都至少有有一個重大不足之處。

所以，我們不得不采用方法中的第 3 步，即如有需要，設計自己的構建模塊。隨後我們設計了一個策展證明市場（Curated Proofs Markets, CPM；下一節會詳細介紹），是對策展市場的一個輕量擴展。我們在兩種新的設計方案中試用了 CPM：

（5）數據註冊+免費數據 CPM。策展：質押代幣作為聲譽的信任基礎。自動的內容分發網絡（Content Delivery/Distribution Network，CDN）。

（6）參與者註冊+免費數據和定價數據 CPM。策展：質押代幣作為聲譽的信任基礎。自動的內容分發網絡、 “經過驗證的策展市場”。

下表的最右側兩列中添加了這兩個新設計。我們看到第 6 個設計實現了我們的目標！這很重要：這代表著我們可以停止當前的設計過程了（至少目前是這樣）。

4.4 海洋協議的新代幣模式：策展證明市場

海洋協議的目標函數是最大化相關 AI 數據和服務的供應。

為了清楚地表示出這一目標函數，我們必須承認的是 — — 我們無法客觀地衡量什麽是”高質量”。針對這種情況，海洋協議將策展（內容篩選）留給了廣大用戶：用戶會把錢花在該花的地方，通過策展市場設置，可以讓用戶選出最受歡迎的數據集。

然後，我們需要解決的是讓高質量數據和數據可用性的信號達成一致。我們將以下兩者結合才解決了這個問題：預測的熱度與實際的（已證實的）熱度。如果滿足以下兩種情況，用戶將獲得代幣獎勵：

他們已經預測了數據集在策展市場中的受歡迎程度，這是預測的熱度。

他們可以證明自己應要求提供了數據集/服務。根據規定，數據集/服務越受歡迎，請求就越多。這是經過驗證的受歡迎程度，即實際的熱度。

這些共同構成了我們所說的策展證明市場（CPM）。在 CPM 中，策展市場和證明是密切相關的：證明給予策展有效的實施手段，使策展更加以行為為導向；反過來，策展為證明提供了質量信號。隨著 CPM 的加入，我們代幣設計的構建模塊也在不斷壯大：)

下圖中的等式描述了海洋協議的代幣獎勵函數。

等式右側的第一項 Sij 反映的是參與者對數據集/服務的熱度（預測的熱度）的信任。第二項 Dj 反映的是數據集/服務的熱度（已證實的熱度）。第三項 T 是在該時間間隔內發放的代幣數量。第四個術語 Ri 是減輕某一個特定的攻擊向量。獎勵函數期望值 E() 的實現類似於比特幣。海洋協議白皮書詳細說明了此獎勵函數的工作原理。

「2021 年 9 月更新：本節中介紹的代幣設計是我們在邊做邊學過程中取得的成果，與實際發布的有所不同。但，目標是一致的，並且在 Ocean Data Farming 中仍然多次提到這種設計。」

5. 結束語

這篇文章介紹了兩個研究案例，分別是比特幣的分析和海洋協議的設計。在這兩個案例中，我們探討了如何使用代幣工程工具來分析和設計代幣化的生態系統。

原文：Trent McConaghy, Token Engineering Case Studies

譯者：Omelet, TELab

TELab：本文內容僅供學習研究參考，並不構成任何廣告銷售或投資建議。投資者據此操作，

風險自擔。轉載/內容合作/尋求報道，請聯系 TELab 授權並註明出處。

Twitter / Discord / Mirror / Medium / Matters / Vocus