積分：加密生態參與的催化劑

作者：Kautuk Kundan,?Manan @Stackr Labs；編譯：Leia?@TEDAO

譯者導讀：

積分系統作為一種激勵機制，能夠促進用戶與協議的互動，從而推動協議的發展與增長。它是一種工具，而不是目標。積分不應該成為用戶使用產品唯一的原因，產品本身應該具有吸引力。同時，用戶需要清晰、可預測的規則來理解如何獲得積分，而鏈上積分可以避免傳統積分系統的“黑箱”問題。

Micro-rollup，作為一種在鏈上實現積分系統的方法，提供了一種既節省成本又高效的方式。它通過在鏈下執行邏輯操作然后將驗證結果推送到鏈上的方式，既保證了操作的速度和靈活性，又確保了數據的可驗證性和安全性。

這不僅為開發者提供了一種新的工具，也為整個加密生態系統提供了一種新的思考方式，即如何將技術創新應用于提高用戶參與度和激勵機制。

近來，積分迅速成為加密生態中推動用戶參與的催化劑，引領了眾多頂尖團隊和協議的成功實踐。其概念并不復雜：用戶通過促進協議發展的方式與之互動，從而獲得協議以積分形式發放的獎勵。這一機制與許多視頻游戲中常見的經驗值（XP）系統類似，玩家通過不斷積累經驗值，提升自己的排名；而排名的提升，又會激勵玩家繼續努力，爭取獲得更高的排名。

許多協議將積分作為引入協議治理代幣（token）的前奏，表明代幣的分發將基于用戶所積累的積分數量。這種策略為協議和團隊在公布代幣細節之前爭取到寶貴的時間，同時也推遲了他們出現失誤時所面臨的審查。積分積累的運作方式和收益耕作（yield farming）類似，但是沒有直接的經濟激勵，而是提供一種更為廣泛的用戶參與和獎勵方式。

現在，使用積分激勵用戶并促進協議的發展已經成為一種新趨勢。有趣的是，從理論上講，積分的供應量可以是無限的，這為傳統空投機制帶來了新的變化，使其與實際代幣區別開來。

積分的問題

PMF 不應被理解為 “Points Market Fit”（積分市場匹配度）。如果一個產品在沒有積分系統的情況下無法獲得用戶青睞，那么在其之上再添加積分系統并稱其為 PMF 也是無濟于事的。積分不應成為決定用戶選擇產品 X 還是產品 Y 的關鍵因素，而應是產品 X 和 Y 都能為用戶提供內在價值。

另一個重大問題是，大多數積分系統都是“黑箱”，隨著時間的推移，它們的計算屬性不可預測。這種不透明性有利有弊——有利是指，它賦予了團隊更大的靈活性來調整系統的規則；而弊端則是，它同時也剝奪用戶可感知的控制權或影響力。

游戲獲取經驗值（即積分）的規則應當是清晰且可預測的！

如果積分系統是可審計、透明且可預測的，同時又能保持足夠的靈活性，讓團隊圍繞它設計各種活動，那將會怎樣呢？

鏈上積分

在鏈上實現積分系統是一個吸引人的想法，但這不應該只是為了創造另一個 ERC-20 代幣的幌子。曾經有協議推出過一種預發行代幣，承諾最終會將其轉換成另一種代幣（本質上就是變相的積分），結果只是讓生態系統中充斥著不必要的代幣。

將鏈上積分設想為與 ERC-20 代幣不同的存在，通過積分系統的組合性可以為用戶創造出獨特的體驗。然而，無論是在 Layer-1 還是 Layer-2 層面實現一個鏈上積分追蹤系統都需要高昂的成本，這就引出了一個非常關鍵問題：為什么不直接用 ERC-20 代幣來代表積分呢？

這種情況凸顯了為什么鏈上積分系統是作為 Stackr 上的 micro-rollup 來開發的理想選擇。深入研究現有積分系統基礎設施所面臨的問題，團隊通宵達旦地進行了內部研究沖刺，最終開發出了一種專用的虛擬機（VM）來跟蹤和管理協議的積分。

Micro-Rollups 快速入門

Micro-Rollup 端到端工作流程

Micro-rollups 本質上是一種狀態機（state machines），它可以在鏈下執行特定的邏輯運算，然后將執行驗證外包給一個叫做 "Vulcan" 的驗證層。Vulcan 負責驗證狀態更新，并將計算數據提交到鏈上。

-狀態機具有定義好的狀態形態，并且會根據一組初始條件（genesis condition）進行初始化，以確定狀態機的起始狀態。

-狀態機包含一組動作（可以理解為交易類型），當被調用時，這些動作會觸發狀態機上的狀態轉換函數。

-狀態轉換函數（State Transition Function，STF）負責執行計算并更新狀態機的狀態。STF 執行完畢后，這些動作會被打包成一個區塊，并發送給 Vulcan。

最后，Vulcan 會：

悲觀地假設 STF 的計算結果可能存在錯誤或者惡意篡改，重新執行區塊中的動作，以確保結果的正確性。

為已驗證的區塊生成元數據。

在 Layer-1 和 DA 上完成結算。

Micro-rollup 更新后的狀態被發送到 DA。

經過驗證的區塊的元數據和更新后的狀態根（state root）被安置到 micro-rollup 在 Layer-1 上的 inbox contract 中。

上述流程共同構成了 Stackr 的 Micro-Rollup 框架的工作原理。

積分系統 Micro-Rollup

那么，為什么 micro-rollups 特別適合構建積分系統呢？

Micro-rollups 提供了快速、靈活、自托管的執行環境。

這確保了積分的發放不會產生“鏈上”開銷，并且所有狀態更新都能盡可能快地發生。

Micro-rollups 支持可驗證的鏈下計算。

盡管是自托管的，該框架仍然可以保證在數據結算到 Layer-1 之前，任何進入系統并改變狀態的數據都能得到充分驗證。這確保了系統以可預測的方式運行，并且不會被篡改。

Micro-rollups 使狀態可審計。

一旦狀態機被部署，STF 的邏輯就不能被更改。這為用戶提供了一種保障，確信系統的規則不會被提供者隨意修改。

Micro-rollups 可以直接在 Layer-1 上進行結算。

由于 micro-rollups 可以直接在 Layer-1 上進行結算，狀態證明可以在合約內部直接使用，進而實現鏈上操作。驗證層通過提供預結算保證，能大大縮短結算周期。

構建積分系統的探索之旅

免責聲明：本演示僅展示了該框架的功能，是一個未經任何優化的版本，不適用于生產環境。請將此內容理解為說明性的示例，而非最終產品。

在開發 micro-rollup 時，以狀態機的形式去構思邏輯至關重要。這需要仔細考慮 micro-rollup 的狀態（即它將保存的數據），以及決定 STF 行為的動作（該函數會對狀態進行操作）。

從狀態機的視角思考應用構建

秉持上述理念，我們使用 Stackr 的 SDK（開發工具包）開始設計 micro-rollup 的狀態。

設計

當用戶在平臺上執行鏈下或鏈上動作時，會觸發事件（events）。管理員也可以為用戶分配事件。

積分存儲在鏈下的狀態機中。

系統包含一個 STF，用于決定授予用戶積分的時間和數量。

事件會觸發 STF，狀態會基于用戶的最新積分進行更新。

每過一個設定的時間段（epoch），就會生成一個區塊，其中包含用戶事件的詳細信息和更新后的積分表狀態。

區塊被發送到 Vulcan 網絡進行驗證。

如果區塊符合狀態機的規則，則被批準。

區塊數據拆分為兩部分，分別在 Layer-1 和 DA 上進行結算。

Micro-rollup 架構中的積分系統

定義基礎狀態

首先，我們添加 admins （管理員）和 eventRegistry（事件注冊表）：

admins： 可以注冊事件實體并為用戶分配積分的地址。

event： 用戶可獲得積分的任何類型的實體。它可以是鏈上事件，也可以是手動添加的自定義事件。例如：“sign-up”注冊事件（自定義）可以獲得 200 積分，“swap”兌換事件（鏈上）可以獲得 500 積分等。

接下來，我們需要一種方法來跟蹤用戶有資格獲得積分的事件。

一個用戶可能進行過 1 次 sign-up 事件和 5 次 swap 事件。每個事件都是?eventLog（事件日志）中的一個條目。

我們在狀態中添加了 eventLog，以跟蹤每個用戶對應的所有鏈上事件以及每個事件的最大積分。目前，我們不需要積分子字段，因為它可以從 eventRegistry 中獲取。但為了使系統更靈活，以便未來擴展，我們仍然添加了該字段。

添加狀態更新處理

在設置好最小可行狀態（minimum viable state）后，我們需要定義更新狀態的 reducers。

添加 logEventReducer，負責為用戶的事件創建日志條目。

詳細拆解如下：

管理員使用事件名稱和用戶標識符調用 logEvent 動作（本文不包含此操作的詳細討論）。

此動作會觸發狀態機并調用 logEventReducer。

這個 Reducer 隨后會：

查找與事件對應的積分。

基于事件和相應的積分來更新用戶的事件日志。

例如：

管理員調用 logEvent({user: mg-labs.eth, event: "deposit"})

Reducer 將在 eventRegistry 中找到 deposit 這個動作，并為用戶 mg-labs.eth 記錄 deposit 事件及其對應的積分。

至此，我們已經構建了一個最小可行的積分系統。

智能合約 vs Micro-rollup

如果要計算用戶的總積分，我們需要遍歷該用戶的事件日志，并且每次計算總積分都要重復這個過程。

如果將積分系統構建為一個智能合約，這可能是一種可行的方法，但是與 micro-rollup 相比，EVM 中的存儲成本極為高昂，這種設計可能并不理想。

而我們正在構建的 micro-rollup，成本相對更低，可以更自由靈活地管理狀態和計算，從而可以優先考慮用戶體驗，而不是權衡成本。

存儲計算后的積分

向狀態中添加 userPoints（用戶積分）

它將負責保存分配給用戶的積分總和。

當記錄事件時，我們也更新 logEventReducer 以更新用戶的積分。

完成！

構建一個具有鏈上可追溯性的事件驅動積分系統，就是這么簡單！是不是很容易就能為后端服務器賦予鏈上超能力？

鏈下積分上鏈——空投等更多可能 ?

這個系統的美妙之處在于，它允許積分在無需高昂開銷的情況下無縫地在鏈上使用。

正如文章開頭所述，micro-rollup 的狀態根會在 Layer-1 上結算。值得注意的是，開發者可以選擇哪些狀態數據在 Layer-1 上結算，哪些作為元數據放到 DA 上，從而實現混合安全假設。

在本例中，如果我們提取 userPoints，并將其 Merkle 化的根（root）在 Layer-1 上結算，就能直接實現用戶在 Merkle 樹中的包含證明（inclusion proofs）。

這一特性讓我們能夠無縫構建各種鏈上體驗，包括無信任代幣兌換、積分獎勵、積分的鏈上二級市場等等。通過包含證明的方式將用戶積分數據引入鏈上，鏈上體驗的可能性將會大幅擴展！

這種方法實現了積分上鏈，而又無需將積分完全放置在鏈上（顯著降低成本，并優化用戶體驗）。

暢想

目前在這篇文章中構建的積分系統僅是冰山一角，可以對其進行大幅擴展，實現諸多功能。以下是一些可能的拓展方向：

Multipliers（倍數）

團隊常常喜歡在某些事件或活動的基礎積分上設置有時間限制的 multipliers，因為這是一種非常有效的機制，可以與其他項目展開合作、提高社區和協議活躍度等。在這版積分系統中，我們已經在特定時間為事件存儲了應當分配的積分，因此，迭代和實現?multipliers?都非常簡單。

首先，更新 EventRegistry?為每個事件保存?multipliers 的列表。

如上所示，每個事件都有一組可以由團隊激活和停用的?multipliers，從而實現靈活的活動設計。

為了支持上述的狀態更新，我們更新了 logEventReducer 使其應用有效的?multipliers。

上述邏輯不僅可以應用一個?multiplier，還可以在計算事件分配積分數量時疊加多個?multipliers。

推薦

與?multipliers?類似，推薦系統也是許多積分系統的關鍵。推薦系統由于其結構可能相當復雜，因此難以完全構建在鏈上。

例如，MarginFi 有一個多級推薦系統 ——

將積分系統構建為 micro-rollup，使你能夠在自己的獨立執行環境中自由地實現上述機制，無論它們有多復雜。

積分自動化

上述系統提供了很大的靈活性，但也需要額外的基礎設施，為管理員（或機器人）更新用戶積分增加工作量。

我們可以通過 L1Syncer（SDK 中的內置模塊）將所有用戶事件從選定的合約導入到 micro-rollup；同時，Rollup 的 STF 專注于計算用戶積分的算法，并透明地展示積分計算方式，這樣我們就可以提升系統的自主性。

積分即聲譽

積分可以很容易地被視為社交經濟中的經驗值或聲譽積分。它們是對為協議或產品做出價值貢獻的一種認可形式。在社交經濟中，將積分系統作為聲譽追蹤器，為創造鏈上體驗提供了廣闊的空間，充滿了吸引人參與和創新的激動人心的機會。

例如，Reddit 的 Karma 積分如果建立在 micro-rollup 上，也許就可以立即讓那些被戲稱為“毫無用處的互聯網積分”的東西在鏈上可用。

使用此框架，可能只需要幾天的工作就可以將現有的 Karma 積分系統移植到鏈上。

結語

積分系統在Web2與Web3的交匯處展現出了巨大的潛力，需要一種新穎的混合架構來實現。這正是 micro-rollups 提供的機遇所在。

Micro-rollups 提供了靈活選擇去中心化程度的自由。它們讓開發者能夠按照自己的偏好構建應用程序，無論是追求完全去中心化，還是充分去中心化，亦或是一種尚未揭示的全新模式。