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